Issue with Lyz in Zotero 5 - Update Bibtex broken for existing documents

tmchartrand

The Lyz extension (Lyx integration) relies on item IDs from getLibraryKeyHash to identify zotero items, and it seems like these changed for existing items with the Zotero 5 update? Specifically, the user library used to have a 0_ prefix and now has a 1_.
This breaks the "Update Bibtex" function of Lyz for Lyx documents started in Zotero 4 or earlier.
A fix that seems to work for me is to manually replace all '0_' with '1_' in the bibtex .bib file and in lyz.sqlite. You can edit the database using sqlite-manager addon, run the SQL command
`UPDATE keys SET zid = replace( zid, '0_', '1_')`
A more permanent fix will need to be implemented in Lyz (I've opened an issue at https://github.com/willsALMANJ/lyz/issues/23).

bwiernik

You will need to discuss this with the LyZ developer on GitHub. In the meantime, I recommend using BetterBibTeX to maintain your .bib file.

tmchartrand

As I stated, I'm working on the LyZ fixes. Posted here so this issue and workaround will be more visible to other users.
However, although I agree it doesn't make sense to change this on the zotero side now, it seems to me that issues from LibraryKeyHash changes could have been foreseen with the zotero 5 update, and there should have been a clearer warning in addition to the deprecation notices on getLibraryKeyHash and related.
Also, maybe someone could clarify for me, where should the libraryKey be used to identify an item vs just the key? Are key collisions expected with multiple libraries?

dstillman

Zotero 5 was in beta for over a year — there was plenty of time for third-party developers to update their code.

Are key collisions expected with multiple libraries?

Yes, object keys are unique only within libraries, so they have to be paired with the libraryID. But while object keys are synced, library IDs are local to the database, so those shouldn't be used externally.

If you want to identify an item globally, you can get a URI with Zotero.URI.getItemURI(item) and convert it back to a Zotero.Item with Zotero.URI.getURIItem(uri). The URI in this case will be something like http://zotero.org/users/1/items/ABCD2345. (Basically, global uniqueness requires the library type, library type id (userID/groupID), object type, and object key.) This assumes the user has synced — if not, the generated URI will include a local component and won't be usable on other computers after the user has set up syncing. (I can't remember whether local URIs are still resolved on the same computer after the user sets up syncing. Possibly not, though that could probably be made to work.)

willshanks

In case anyone ends up here instead of the LyZ GitHub page -- LyZ 3.0.2 checks items in its database with ID's starting with 0_ and changes them to 1_ to avoid this issue.

For what it's worth, LyZ was updated and tested for Zotero 5.0 shortly after the first alpha version was released, but I didn't test migrating a Zotero 4.0 install to Zotero 5.0. I can't really afford to spend more time on LyZ than the bare minimum to keep it working -- outside contributions are welcome.

douglasrhess

Any updates on this? When Zotero is asked to update bibtex, Lyx crashes. I don't know if that's the same problem as this.

willshanks

That sounds like an unrelated issue. The issue here did not cause LyX to crash. Also, a workaround was added to LyZ back in December. You can open an issue at https://github.com/willsALMANJ/lyz/issues if you like.