Hello,
I did an experiment and would like to share the results. So far I implemented
only _all_dbs/cursor
Here is how it works (I have only 2 databases)
curl -u adm:pass "http://127.0.0.1:15984/_all_dbs/cursor?limit=1; | jq '.'
{
"items": [
"_users"
],
"completed": false,
I don't think a whole new API is required here, but I would like to see
some sort of "bookmark" facility for _all_docs and views, as pagination
with the current API is awkward.
I would imagine it working as follows:
// first request
curl $URL/mydb/_all_docs?startkey="aardvark"="moose"=10
^ the
On versioning, I've not seen a better article than this one:
https://www.troyhunt.com/your-api-versioning-is-wrong-which-is/
For _changes, definitely agree we should be including it in this discussion, it
is the only endpoint with, in theory, an eternal response, and I think that's a
bug not a
I'd agree that my initial reaction to cursor was that its not a great
fit, but there does seem to be the existing name used in the greater
REST world for this sort of pagination so I'm not concerned about
using that terminology.
I'm generally on board with allowing and setting some default sane
I think it's a key difference from "cursor" as I've seen them elsewhere, that
ours will point at an ever changing database, you couldn't seamlessly cursor
through a large data set, one "page" at a time.
Bookmarks began in search (raises guilty hand) in order to address a
Lucene-specific
I realise this is bikeshedding, but I guess that's kind of the point...
Everything below is my opinion, not "fact."
It's unfortunate we need a new endpoint for all of this. In a vacuum I
might have just suggested we use the semantics we already have, perhaps
with ?from= instead of ?since= .
cursor has established meaning in other databases and ours would not be very
close to them. I don’t think it’s a good idea.
B.
> On 23 Apr 2020, at 11:50, Ilya Khlopotov wrote:
>
>
>>
>> The best I could come up with is replacing page with
>> cursor - {db}/_all_docs/cursor or possibly
> The best I could come up with is replacing page with
> cursor - {db}/_all_docs/cursor or possibly {db}/_cursor/_all_docs
Good idea, I like {db}/_all_docs/cursor (or {db}/_all_docs/_cursor).
On 2020/04/23 08:54:36, Garren Smith wrote:
> I agree with Bob that page doesn't make sense as an
> All the fields in the bookmark make sense except timestamp. Why would it
> matter if the timestamp is old? What happens if a node's time is an hour
> behind another node?
Bookmarks are not permalinks. The exact behavior would depend on the type of
pagination.
# offset based pagination
There
I agree with Bob that page doesn't make sense as an endpoint. I'm also
rubbish with naming. The best I could come up with is replacing page with
cursor - {db}/_all_docs/cursor or possibly {db}/_cursor/_all_docs
All the fields in the bookmark make sense except timestamp. Why would it
matter if the
10 matches
Mail list logo
