René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Split query specification (kind, filter, ancestor, etc.) from query execution (results, cursor, more_results)","articleBody":"(Continued from #432)\n\nIn 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.\n\nIn 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.\n\nThe pattern I'm proposing is something like::\n\n```\nfrom datastore.query import Query\n\npending_reports = Query('Expense Report).filter('status', '==', 'pending')\n\ndef show_pending_reports(request):\n    cursor = pending_reports.fetch()\n\n    for report in cursor:\n        show_report(report)\n```\n\nUnder the covers, iterating the cursor would cause it to fetch subsequent pages until there were no more (or until the user-supplied limit had been reached).  The source Query (`pending_reports`) would be uninvolved in any of that machinery.\n\nThe cursor would have methods for checking whether the back-end reported more results were available, as well as keeping (internal) track for the `start_cursor` / `end_cursor` bits for paging.  If the user wanted to interact with them directly, she could:\n\n```\ndef show_pending_reports(request):\n    cursor = pending_reports.fetch()\n\n    for page in cursor.pages():\n        for report in page:\n            show_report(report)\n```\n","author":{"url":"https://github.com/tseaver","@type":"Person","name":"tseaver"},"datePublished":"2014-12-18T19:42:54.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/439/google-cloud-python/issues/439"}