You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some older deployments of re³gistry that probably origin in an earlier development phase are still using numeral identifiers for some of the database items used to feed the registers. This involves entries in the tables itemclass, localization, reference, register, registry, status. All references to those items in other tables are also affected of course.
Currently the migration assistant for version 2.4.x fails without a clear error message when trying to import such a database (TODO: log that here). One idea to fix the problem, is to change Re3gistry2Migration.MigrateItems s.th. it either can handle these legacy identifiers or to add a functionality to convert an old database scheme to match the current UUID assignment scheme.
A little tricky about that is, that within re³gistry UUIDs are currently derived deterministically from the according records data.
The text was updated successfully, but these errors were encountered:
jane-heller-bkg
changed the title
Migration assistant fails when using legacy database identificator scheme
Migration assistant fails when using legacy database identifier scheme
Feb 8, 2023
Some older deployments of re³gistry that probably origin in an earlier development phase are still using numeral identifiers for some of the database items used to feed the registers. This involves entries in the tables
itemclass
,localization
,reference
,register
,registry
,status
. All references to those items in other tables are also affected of course.Currently the migration assistant for version 2.4.x fails without a clear error message when trying to import such a database (TODO: log that here). One idea to fix the problem, is to change
Re3gistry2Migration.MigrateItems
s.th. it either can handle these legacy identifiers or to add a functionality to convert an old database scheme to match the current UUID assignment scheme.A little tricky about that is, that within re³gistry UUIDs are currently derived deterministically from the according records data.
The text was updated successfully, but these errors were encountered: