Hi again, I have tried upgrading with the most recent release (4.1.3) and seem to have a successful upgrade. However there are issues in the logs (full stack attached [1]), which make me think there may be issues with the installation in the end. So my DB name is "xwiki_utf8_innodb_413". 1. 2012-07-14 23:56:15,392 [http://localhost/xwiki/bin/view/Main/WebHome] WARN o.i.c.InfinispanConfiguration - ISPN000139: Infinispan configuration schema could not be resolved locally nor fetched from URL. Local path=null, schema path=schema/infinispan-config-5.1.xsd, schema URL=http://www.infinispan.org/schemas/infinispan-config-5.1.xsd I believe schema will be created automatically and this error can be ignored, correct? 2. 2012-07-14 23:56:18,251 [http://localhost/xwiki/bin/view/Main/WebHome] WARN h.R40001XWIKI7540DataMigration - Skipping database [xwiki] because it uses a custom annotation class. Comments and anotations will remain separated This one is really weird because my db name is "xwiki_utf8_innodb_413" (and as you'll see in the logs the rest of upgrade items refer to name "xwiki_utf8_innodb_413". More over I'd really like to use merged comments and annotations feature. What should I fix in order to merge comments and annotations? 3. Then there's a bunch of info messages following next pattern 2012-07-14 23:56:35,897 [http://localhost/xwiki/bin/view/Main/WebHome] INFO c.x.x.s.m.liquibase - Change set liquibase.xml::R40000-000::sdumitriu failed, this error could be safely ignored until something worse happens. Error: Error executing SQL ALTER TABLE `$table_name$` DROP FOREIGN KEY `$FOREING_KEY_ID$`: Error on rename of './xwiki_utf8_innodb_413/$table_name$' to './xwiki_utf8_innodb_413/#sql2-dfb-c08f' (errno: 152) Where $table_name$ = {xwikiintegers, xwikistrings, xwikifloats, xwikidoubles, xwikilistitems, xwikidates, xwikilargestrings, xwikilists, xwikilongs, feeds_feedentrytags, feeds_aggregatorurlgroups} Even though the message says "safely ignore", I tend not to trust it when I see words "failed" and "something worse might happen", because in IT it does happen. So again how can I fix this message? 4. And finally there's a bunch of deprecated methods used in the end: method [com.xpn.xwiki.api.Util.parseInt] in unknown namespace@68,26 getter [com.xpn.xwiki.api.Util.getArrayList] in unknown namespace@788,35 method [com.xpn.xwiki.api.Util.parseInt] in unknown namespace@68,26 getter [com.xpn.xwiki.api.Util.getArrayList] in unknown namespace@788,35 Can they be fixed? 5. Also one more question: after this serious migration, is there a way to find out that my database and application has a valid state? (I mean some other way than just start using and find an error after 2-3 weeks of adding pages, to find out that it wont be able to either downgrade or fix the issue) [1] Full upgrade logs attached: http://xwiki.475771.n2.nabble.com/file/n7580357/db-migration.log db-migration.log -- View this message in context: http://xwiki.475771.n2.nabble.com/Possible-upgrade-3-5-1-to-4-0-issue-tp752… Sent from the XWiki- Users mailing list archive at Nabble.com.

Hi Roman, Sorry for my late answer. I have written most of this large migration, you will find my comments interspersed below. On Tue, Jul 17, 2012 at 5:27 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote: I fully confirm that, the name used in the log are the wiki names and not the database names. The main wiki is always called xwiki. You do not need to lower the database version. You may force any migration to execute by adding a configuration in xwiki.cfg For exemple, to force R40001XWIKI7540 migration to be executed again, you add the following line to xwiki.cfg: xwiki.store.migration.force=R40001XWIKI7540 Do not forget to remove it later. You cannot and you need not. This usually happen on MySQL database that have been migrated from MyISAM engine to InnoDB engine. It only means that dropping a constraint has failed, but if the constraint were not present, this was not really an issue. These were blocking you in your initial thread, and have been transformed in warning the latest release. Unless you get other errors during migration due to the constraint being there and not being properly dropped, this is not an issue in itself. So you should really not care and be confident here. I have check your logs, and it shows that the migration has been properly applied. Moreover, the missing constraints had been added back and therefore the state of your database has been improved. You may use the sanity check script available at http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Database+Administration… the Admin Tools Application in version 3.0 or later at http://extensions.xwiki.org/xwiki/bin/view/Extension/Admin+Tools+Application . Both will execute the same sanity checks. Please note that inconsistencies being there before the migration will still be there after the migration. So it is good to check the database before migration and after migration, and it should not reveal an increase of the inconsistencies. This is really a good check that ensure the database consistency has not been affected. Regards, -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO