-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Removing cursor and more results from query object. #432
Conversation
715f8d6
to
2d40365
Compare
@@ -239,8 +238,8 @@ def kind(self, *kinds): | |||
:type kinds: string | |||
:param kinds: The entity kinds for which to query. | |||
|
|||
:rtype: string or :class:`Query` | |||
:returns: If no arguments, returns the kind. | |||
:rtype: string, list of strings, or :class:`Query` |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
I wonder if the |
I have a few thoughts:
I think overall the added complexity / maintenance may not be worth it, but I am biased based on |
In larger applications, I envision a set of Query objects which are pre-built, something like "prepared statements" in SQL-based apps. Application code would reuse them over and over without needing to re-construct them on the fly. In the current setup, the application code would have to do that by cloning the queries (even though they weren't going to be modifying the filters). It would be nice if the short-lived / stateful concerns weren't intertwined with the long-lived, stateless ones. |
@dhermes Here's a rundown on all the types of more_results:
|
@tseaver Can we file a bug and flesh out what you mean more. I can't quite envision what the limitation / new feature is. @pcostell So we should treat both more_results = True or you think having all three is necessary? I'm worried that having an enum instead of a boolean will confuse / turn away some users, but I'm also worried that sophisticated users may want the added distinction between the two "unfinished" states. |
@dhermes I think MORE_RESULTS_AFTER_LIMIT and NO_MORE_RESULTS should be more_results = False. It means that the user doesn't need to do any more queries to get the information they asked for (if they asked for 5 and got 5, MORE_RESULTS_AFTER_LIMIT would be true). That way, more_results = True implies that they must do another query to get what they asked for. |
Thanks @pcostell! |
This is a follow up to a discussion in googleapis#423 and googleapis#425. Also - Adding fetch_page() method to return the needed properties no longer available on the Query object. - Made fetch_page() fail if more_results is `NOT_FINISHED`, which seems to be intended for batched requests. - Added start_cursor and end_cursor properties to Query. - Updated docstrings to reflect change - Updated tests to ensure the returned cursor was always set. - Streamlined fetch()/fetch_page() tests to run via a single tweakable helper. - Updated a datastore.connection test to construct and return an initialized QueryResultBatch to simulate a valid cursor. - Updated regression.clear_datastore and regression.datastore to reflect changed API surface.
Incorporates feedback from @pcostell. In particular, treats `NOT_FINISHED` as the only enum that needs `more_results=True` and both `NO_MORE_RESULTS` and `MORE_RESULTS_AFTER_LIMIT` as responses which don't need paging.
2d40365
to
1c1333e
Compare
I think we can merge even with my last question un-answered. |
OK cool, LGTY then it LGTM :) |
Removing cursor and more results from query object.
Source-Link: googleapis/synthtool@c4dd595 Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:ce3c1686bc81145c81dd269bd12c4025c6b275b22d14641358827334fddb1d72
Source-Link: googleapis/synthtool@c4dd595 Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:ce3c1686bc81145c81dd269bd12c4025c6b275b22d14641358827334fddb1d72
Source-Link: googleapis/synthtool@c4dd595 Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:ce3c1686bc81145c81dd269bd12c4025c6b275b22d14641358827334fddb1d72
Source-Link: googleapis/synthtool@c4dd595 Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:ce3c1686bc81145c81dd269bd12c4025c6b275b22d14641358827334fddb1d72
Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
* chore(deps): update all dependencies * revert * 🦉 Updates from OwlBot post-processor See https://github.com/googleapis/repo-automation-bots/blob/main/packages/owl-bot/README.md * 🦉 Updates from OwlBot post-processor See https://github.com/googleapis/repo-automation-bots/blob/main/packages/owl-bot/README.md Co-authored-by: Anthonios Partheniou <partheniou@google.com> Co-authored-by: Owl Bot <gcf-owl-bot[bot]@users.noreply.github.com>
Source-Link: https://github.com/googleapis/synthtool/commit/26c7505b2f76981ec1707b851e1595c8c06e90fc Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:f946c75373c2b0040e8e318c5e85d0cf46bc6e61d0a01f3ef94d8de974ac6790
Source-Link: googleapis/synthtool@fdba3ed Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:1f0dbd02745fb7cf255563dab5968345989308544e52b7f460deadd5e78e63b0
Source-Link: https://github.com/googleapis/synthtool/commit/cb960373d12d20f8dc38beee2bf884d49627165e Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:2d816f26f728ac8b24248741e7d4c461c09764ef9f7be3684d557c9632e46dbd
* fix(deps): require protobuf <4.0.0dev * update constraints
Source-Link: googleapis/synthtool@4826337 Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:60a63eddf86c87395b4bb394fdddfe30f84a7726ee8fe0b758ea132c2106ac75 Co-authored-by: Owl Bot <gcf-owl-bot[bot]@users.noreply.github.com>
Source-Link: googleapis/synthtool@c4dd595 Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:ce3c1686bc81145c81dd269bd12c4025c6b275b22d14641358827334fddb1d72
This is a follow up to a discussion in #423 and #425.
Also
fetch_page()
method to return the needed propertiesno longer available on the
Query
object.fetch_page()
fail ifmore_results
isNOT_FINISHED
, whichseems to be intended for batched requests.
start_cursor
andend_cursor
properties to Query.fetch()
/fetch_page()
tests to run via a singletweakable helper.
datastore.connection
test to construct and return aninitialized
QueryResultBatch
to simulate a valid cursor.regression.clear_datastore
andregression.datastore
toreflect changed API surface.