Hi Andrea, thanks for the reply.
> > The Wiki page says at first that one should "configure the internal storage > > as done for the former 1.1.X project", then "change content.xml leaving > > only new Entitlements". > > > > Should one have a specific version of content.xml that is only relevant for > > the upgrade? (which then cannot be used to set up a new instance from an > > empty database) > No, there isn't a custom upgrade-purpose content.xml. > You have to use "basic" content.xml, that is the one you have when you > create a new Apache Syncope project, as explained in the wiki. Ok, but somehow I do need to modify this into a migration-specific content.xml (e.g. with the existing entitlements commented out, see below, which then wouldn't work anymore with an empty database), and then change it back after migration, right? > > If I leave other declarations (such as config settings) in, won't they > > overwrite the existing configuration in my 1.1.X database? > > There seems to be a mechanism in content upgrader that explicitly doesn't > > migrate some config settings (such as notificationJob.cronExpression) - > > must these then be manually set again to their previous values in the > > 1.1.X database? > This point you noticed is interesting... The answer is yes, new > content.xml conf have priority and if in the "old" conf 1.1.X table > contains the same key with a value it will be written the "new" value > get from the content.xml mentioned above, especially the old value is > escaped and if the conf (that the upgrader finds) is in the list of new > confs, value isn't written to database. > And so yes you have to manually set the value if you want old one. > Maybe this section has to be re-thinked and improved, I will open an > issue about this problem. That would be very helpful - especially to have information which part of the configuration is migrated from the 1.1.X database and for which part of the configuration the settings in the 1.1.X database are ignored and overwritten with the values in content.xml (thus have to be migrated manually). About the other settings in content.xml I'm still not sure how this is supposed to work exactly. I understood content.xml as default content set up on database schema creation on an empty database, so for me it also contains e.g. predefined user schema attributes, policy declarations and notifications. On the upgrade, the ContentLoader tries to add these as well (and usually fails because of a duplicate key). However, in the general case one couldn't rely on the ContentLoader failing - maybe a user schema that was there initially was deleted via the GUI, then it's added again in the migration... Aren't policies, user schemata and notifications migrated from the 1.1.X database? Wouldn't it be better to leave only the declarations in content.xml that are absolutely necessary for the migration to work and take as much as possible from the 1.1.X database? Cheers, Guido > > [1] > > https://cwiki.apache.org/confluence/display/SYNCOPE/Upgrade+from+1.1.X+to+1.2.X > I'm here available for all other questions.
