I'm implementing SEO-friendly infinite scroll on our web page, given that, we use ?page parameter in the URL, so if user sees something interesting on page 15, he can copy link over to some buddies of him.
We are using ElasticSearch as main search engine, however, there might be a moment, when it's down, and then I need to use backup scenario, from ndb.
Let's say, our ElasticSearch is down. We are using backup scenario from ndb. User enters straight to page 15. Is there any way I can retrieve Cursor for page 15(and 10 entities per page), assuming I was not performing fetch_page queries, so don't know next or prev Cursor values?
Is there any way I can retrieve Cursor for page 15(and 10 entities per page), assuming I was not performing fetch_page queries, so don't know next or prev Cursor values?
If I am understanding correctly, you wish to retrieve an ndb.Cursor object for a given start point in a given query's result-set, without having executed any prior queries using fetch_page.
See https://cloud.google.com/appengine/docs/standard/python/datastore/query-cursors and for convenience, here's a relevant snippet:
"After performing a retrieval operation, the application can obtain a cursor..."
Basically, a Cursor object can only be obtained via query (or reconstructed from a pre-existing urlsafe cursor, but obviously that doesn't help us here). So the short answer is "no - you must call fetch_page".
While ultimately Cloud Datastore is not the optimal tool for your case, there is a way to accomplish the behavior you're seeking. You will have to actually call fetch_page() first. In your case, since you know your page size and page number, you could simply execute a single fetch_page for (10 * 15) records qry.fetch_page(page_size=150) and ignore the returned records, simply stashing the returned ndb.Cursor object for use in the subsequent query, which will actually get the dataset your user is looking for. Yes, this costs an additional RPC, but depending on the model you're querying, the overhead may not be prohibitive (I don't really know the details of your use case).
Your subsequent query using that cursor can be executed with the normal page size you wanted to show your client - 10 records, etc. This is because Cursors from one query impose no requirements on the page size of subsequent queries performed with that cursor. It really only refers to a point in the data set. NOTE: This does mean you need to keep the same filters/sort order on all queries - changing this between queries will mean you need a new cursor.
Hope that helps!