Collections in API
TS
I am currently trying to make an Android client for Zotero and I am having a bit of problems completely understanding the read API. I want to keep all the different collections of the user updated in my database. Is it correct that I need to get the list for all items for each collections on each sync to accomplish this? (data transfer in O(#Items * # Collections))? This seems to be a huge overhead.
If there was a possibility to get one list of all items in the user's database and have for each item a list of all collections it belongs to (as part of the item's XML data), this would be much better. Then, a sync would only use data in the magnitude of O(#Items).
Another question, related to that: if an item gets added to a collection (or tagged), does the item's "updated" timestamp change? If this were the case, it would also be helpful, because I could at least stop fetching items for each collection if I encounter an item that I already have with the current data + collection data in my database.
Ideally both things could be combined (reference to collections within the data for each item + change timestamp on collection change). Then an app could only fetch the items changed since the last sync and be done with it.
Sorry for the confusing english - I hope I got my point across.
Dan Stillman
> I am currently trying to make an Android client for Zotero and I am
> having a bit of problems completely understanding the read API. I want
> to keep all the different collections of the user updated in my
> database. Is it correct that I need to get the list for all items for
> each collections on each sync to accomplish this? (data transfer in
> O(#Items * # Collections))? This seems to be a huge overhead.
The collection timestamp is updated if an item is added or removed, so
if you're storing the list of collections locally you should only need
to process collections up until you hit a cached dateModified (so likely
only one collections request). Unfortunately you would have to retrieve
all items in each modified collection, but you could use content=none if
you already have the full item data.
> If there was a possibility to get one list of all items in the user's
> database and have for each item a list of all collections it belongs
> to (as part of the item's XML data), this would be much better. Then,
> a sync would only use data in the magnitude of O(#Items).
We'll consider this.
If we put it in the JSON then it would have to be passed back, like
tags, with writes. The alternative would be putting it in the Atom
content, which would maintain the conceptual difference apparent to
users and avoid duplicating the existing RESTful methods for modifying
collection membership. I don't have a strong preference.
> Another question, related to that: if an item gets added to a
> collection (or tagged), does the item's "updated" timestamp change? If
> this were the case, it would also be helpful, because I could at least
> stop fetching items for each collection if I encounter an item that I
> already have with the current data + collection data in my database.
Collection and tag changes do not currently affect the item's timestamp.
This makes for quicker syncing by Zotero itself (which doesn't use the
API for syncing), but there'd be a number of benefits, including the one
you mention, so we might be changing this soon.
> Ideally both things could be combined (reference to collections within
> the data for each item + change timestamp on collection change). Then
> an app could only fetch the items changed since the last sync and be
> done with it.
We'll see what we can do here. The API is currently not particularly
well suited for syncing�among other things, it's not possible to handle
collection-item removals or item deletions without doing full scans�but
we know that offline syncing is a desirable use case, and we'll try to
make it easier for apps to achieve this going forward.