'self' entry missing from links

[davidswelt]

With version 1.1.2, I am getting the error below during a request to 'everything'.

A little investigation shows that there is indeed no 'self' pagination entry in 'links'. I think one can produce this from self.request.url, but I wonder if there's an easier way.

From the v3 Zotero API, it does not seem there is a 'self' entry in the pagination links:

When the total number of results matched by a read request is greater than the current limit, the API
will include pagination links in the HTTP Link header. Possible values are rel=first, rel=prev, rel=next,
and rel=last. For some requests, the header may also include a rel=alternate link for the relevant
page on the Zotero website.

So, I'm not sure how this is/was supposed to work. My application (zot_bib_web) runs fine with a previous version, 0.10.2.

File "./zot.py", line 185, in retrieve_bib
items = zot.everything(zot.collection_items(collection, content=content, style=style, order=order_by, sort=sort_order))
File "/Library/Python/2.7/site-packages/pyzotero/zotero.py", line 544, in everything
while not self.links['self'] == self.links['last']:
KeyError: u'self'

[davidswelt]

Here is an update on this from a user of zot_bib_web:

Thanks for looking into this. I just tested it more thoroughly: versions 0.9.9, 0.9.9.1, 0.10, 0.10.1, and
0.10.2 are all working here, whereas versions 1.0.0, 1.0.1, 1.1.0, 1.1.1, and 1.1.2 are not working.

[urschrei]

Could you try again with the dev branch? I've just altered the logic to check for a 'next' link, the absence of which should indicate that there's nothing left to retrieve.

[davidswelt]

I made that change, and this appears to fix the problem with "everything" -
except that now, zot.collections() will no longer retrieve all collections, but some subset of them. I don't know if this indicates your change isn't working properly due some pagination issue, or if this is a separate problem. (collections_sub() works better, but because it's not recursive, I'd have to change the logic of my application.)

[urschrei]

Do you mean that collections() isn't working anymore, or that it's not returning all collections when called from everything()?

[davidswelt]

When called directly, it does not return all collections.  

—
A terse message sent with my phone

On Wed, Feb 11, 2015 at 9:32 AM, Stephan Hügel notifications@github.com
wrote:

Do you mean that collections() isn't working anymore, or that it's not returning all collections when called from everything()?

Reply to this email directly or view it on GitHub:
#43 (comment)

[urschrei]

OK, looking at this a bit more, it seems as if collections() doesn't return all collections by default; currently, it's only the first 25. (the default per the server API docs should be 50, and I'll raise that in the group).

So if you want to return all of them, you'd have to either use everything(), or follow().

[davidswelt]

I'm now using a recursive algorithm based on collections_sub. That works, too, causes more requests but for smaller chunks of data from the server.

Closing this, because the bug I reported seems fixed now. Thanks.