Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove explicit field syncing from Python client #2716

Merged
merged 5 commits into from
Aug 10, 2022

Conversation

SuperTails
Copy link
Contributor

Listing the available tables on the Python client now just performs a request to the server instead of trying to manage an entire cache of tables.
The open_table function now just constructs the ticket based on the table name and tries to open it directly.
This means that all of the field-fetching and syncing stuff is gone.

return self.table_service.grpc_table_op(self._fields[('scope', name)][1], table_op)
ticket = ticket_pb2.Ticket(ticket=f's/{name}'.encode(encoding='ascii'))

faketable = Table(session=self, ticket=ticket)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So - I wonder if we want to actually add abstractions, or safety barriers, such that returning faketable here makes sense. (For example, we need to make sure that we don't try to close() w/ a s/... ticket.)

Or may introduce ref_table(...) and fetch(), such that open_table(...) == ref_table(...).fetch()? (I think naming could be better.)

Of particular interest is the interest in obtaining ref_table(...).snapshot() without needing a FetchTableOp against the server.

Copy link
Member

@devinrsmith devinrsmith Aug 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe, still have only open_table, but only execute the FetchTableOp when the user calls into a method that needs FetchTableOp-provided data?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having open_table() still makes more sense if we consider the typical use case of a client wants to get a reference to a table in the server for the only reason to perform some operations on it. So lazy fetching isn't too meaningful here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think it would be more intuitive that the "this table doesn't exist" error shows up when you try to open the table, rather than the first time you try to use it. If we wanted lazy fetching, I think a separate open_lazy_table method would make more sense (and that can go into a separate PR if we thought it was useful).

@devinrsmith devinrsmith self-requested a review August 9, 2022 20:43
Copy link
Member

@devinrsmith devinrsmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, all fine by me. Will leave up to @jmao-denver for final approval.

Copy link
Contributor

@jmao-denver jmao-denver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@devinrsmith devinrsmith merged commit 8b9532c into deephaven:main Aug 10, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Aug 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants