Upgrade StorageSync question, error report 677622845
I'm playing some dirty tricks here that give rise to a question.
I'm running a local version of Zotero with some extensions to suit special needs of our users (legal materials). One of the extensions adds some fields to the schema, in fields and in itemTypeFields.
Our aim is to work with the modified schema locally, and then on the basis of experience to make suggestions to xbiblio, gain agreement on any necessary extensions to CSL, and then once the changes have fed through to Zotero, to provide a migration mechanism so our users and their databases can rejoin the mainstream. The basic infrastructure for that (an upgrade/downgrade widget) is built into the UI of our version. We're now trying to figure out the best way of managing the additional fields and the upgrade chain.
My initial thought was to assign high fieldID's to the added fields. This seems to work fine in the interface; I am able to "upgrade" the schema to wake up the fields in an item type, downgrade, and upgrade again, and the field content reappears as expected.
However, synchronization fails when content is present in any of the additional fields (with fieldID's 10001-10005). I've tried Reset to Server, but the error shown in the report (677622845) persists. I'm thinking that maybe the sync process grabs the max fieldID in the fields table, and then steps forward through them -- but trips in our case because the numbers are not sequential? If that's the only issue, we can work around it, but I'd like to check first that there's not something more fundamentally wrong with using an extended schema with sync (as in "impossible to do" -- I know that we've already crossed the "not advisable" boundary).
I'm running a local version of Zotero with some extensions to suit special needs of our users (legal materials). One of the extensions adds some fields to the schema, in fields and in itemTypeFields.
Our aim is to work with the modified schema locally, and then on the basis of experience to make suggestions to xbiblio, gain agreement on any necessary extensions to CSL, and then once the changes have fed through to Zotero, to provide a migration mechanism so our users and their databases can rejoin the mainstream. The basic infrastructure for that (an upgrade/downgrade widget) is built into the UI of our version. We're now trying to figure out the best way of managing the additional fields and the upgrade chain.
My initial thought was to assign high fieldID's to the added fields. This seems to work fine in the interface; I am able to "upgrade" the schema to wake up the fields in an item type, downgrade, and upgrade again, and the field content reappears as expected.
However, synchronization fails when content is present in any of the additional fields (with fieldID's 10001-10005). I've tried Reset to Server, but the error shown in the report (677622845) persists. I'm thinking that maybe the sync process grabs the max fieldID in the fields table, and then steps forward through them -- but trips in our case because the numbers are not sequential? If that's the only issue, we can work around it, but I'd like to check first that there's not something more fundamentally wrong with using an extended schema with sync (as in "impossible to do" -- I know that we've already crossed the "not advisable" boundary).
If syncing can be enabled for black sheep like us, it would be great. If it would be an unnecessary complication, I'll understand and can explain the situation to our users. What's the score?