|
From: Landry B. <br...@cr...> - 2015-12-07 08:24:11
|
On 12/04/15 14:11, pclastre wrote: > You were right: i've done it the wrong way !! > > Now, after the last modification of the database-migration.xml (just > suppress the package name and leave the class), here is the new log file > new_catalina.out > <http://osgeo-org.1560.x6.nabble.com/file/n5240019/new_catalina.out> > The problem with constraints remains the same (see lines 283&284), and the > catalog isn't usable. Like you, i saw *many* errors when trying the 'automigration' procedure from older geonetwork instances to 3.0, and i really think that all usecases havent been properly tested. See for reference.. https://github.com/geonetwork/core-geonetwork/issues/782 https://github.com/geonetwork/core-geonetwork/issues/739 https://github.com/geonetwork/core-geonetwork/issues/736 some of those issues are now closed, but there are still corner cases. Last i tried, it was impossible to migrate a catalog with harversters set, i had to remove all harvesters prior to run the migration. That said, for this issue, i remember at some moment manually creating this primary key on services before letting the scripts run: alter table services add constraint services_pkey PRIMARY KEY(id); That *might* help for the specific issue in your log. -- Landry Breuil Mouton a 5 pattes du CRAIG |