topic Direct migration 2.1 -> 3.3 is it possible? in Alfresco Archive

Direct migration 2.1 -> 3.3 is it possible?

joko71 — Fri, 25 Mar 2011 11:46:57 GMT

Hi,I've googled the net to find out if direct migration 2.1 -> 3.3 is possible. All I've found is recommendations to go with intermediary versions, but not the definite answer if direct migration is possible/not possible.Can someone tell me if direct migration is possible, and if it is not possib

Re: Direct migration 2.1 -> 3.3 is it possible?

mrogers — Fri, 25 Mar 2011 12:24:01 GMT

You need to give more details.   For example what do you mean by "crashes", crashes are unlikely.

You describe replacing the database.    What about the content?   Its that is being complained about leading to the ERROR below.

For Enterprise versions upgrade from 2.1.7 to 3.3.0 works.    I've no idea about community versions although it sounds like others have shared their experiences.

Re: Direct migration 2.1 -> 3.3 is it possible?

joko71 — Fri, 25 Mar 2011 12:52:17 GMT

You need to give more details.   For example what do you mean by "crashes", crashes are unlikely.

You describe replacing the database.    What about the content?   Its that is being complained about leading to the ERROR below.

For Enterprise versions upgrade from 2.1.7 to 3.3.0 works.    I've no idea about community versions although it sounds like others have shared their experiences.

Well, when I said "crashes" I meant we get the error like in the quoted log.

Of course, it's both content and database.

In the meantime we've been playing with some settings in repository.properties

# Property to enable upgrade from 2.1-A
#V2.1-A.fixes.to.schema=0
V2.1-A.fixes.to.schema=82‍‍‍

and we got a different error:

13:25:03,384 INFO  [STDOUT] 13:25:03,384 INFO  [repo.admin.ConfigurationChecker] The Alfresco root data directory ('dir.root') is: C:\Jboss\bin\alf_data
13:25:03,400 INFO  [STDOUT] 13:25:03,400 ERROR [web.context.ContextLoader] Context initialization failed
org.alfresco.error.AlfrescoRuntimeException: 02250001 The store 'user://alfrescoUserStore' has a duplicate root node entry.‍‍‍

Maybe there is something wrong with original 2.1 DB & content? Or maybe 3.3 DB is not being deleted correctly so we have duplicate entries?

Re: Direct migration 2.1 -> 3.3 is it possible?

joko71 — Wed, 30 Mar 2011 13:12:52 GMT

We've made some progress in our effort to migrate from 2.1 to 3.3…

Errors mentioned before were happening because we had two Alfresco DBases on our MySQL by accident. We discovered that and made further progress.

Patches are being applied, but this one

patch.calendarNamespaceUri

with error:

[admin.patch.PatchExecuter]    Applying patch 'patch.calendarNamespaceUri' (Update the Calendar model namespace URI and reindex all calendar objects.).
2011-03-30 13:30:47,710 INFO  [STDOUT] 13:30:47,710 ERROR [admin.patch.PatchExecuter] 02300001 org.springframework.dao.DataIntegrityViolationException: Cannot update namespace as it doesn't exist: com.infoaxon.alfresco.calendar
   at org.alfresco.repo.domain.qname.AbstractQNameDAOImpl.updateNamespace(AbstractQNameDAOImpl.java:144)
   at org.alfresco.repo.admin.patch.impl.CalendarModelUriPatch.applyInternal(CalendarModelUriPatch.java:73)
   at org.alfresco.repo.admin.patch.AbstractPatch$1$1.execute(AbstractPatch.java:416)
   at org.alfresco.repo.admin.patch.AbstractPatch$1$1.execute(AbstractPatch.java:410)
   at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:321)
   at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:228)
   at org.alfresco.repo.admin.patch.AbstractPatch$1.doWork(AbstractPatch.java:442)
   at org.alfresco.repo.admin.patch.AbstractPatch$1.doWork(AbstractPatch.java:406)
   at org.alfresco.repo.security.authentication.AuthenticationUtil.runAs(AuthenticationUtil.java:508)
   at org.alfresco.repo.admin.patch.AbstractPatch.apply(AbstractPatch.java:446)
   at org.alfresco.repo.admin.patch.PatchServiceImpl.applyPatch(PatchServiceImpl.java:297)
   at org.alfresco.repo.admin.patch.PatchServiceImpl.access$200(PatchServiceImpl.java:50)
   at org.alfresco.repo.admin.patch.PatchServiceImpl$2.execute(PatchServiceImpl.java:226)
   at org.alfresco.repo.admin.patch.PatchServiceImpl$2.execute(PatchServiceImpl.java:224)

…‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

We found out that this new calendar feature was added to 3.0 Alfresco version. Most probably patch script wrongly assumes the feature in earlier versions.

That bug was solved on 3.3 Enterprise version:
http://issues.alfresco.com/jira/browse/ALF-2819

And someone tried a workaround by adding (or modifying) namespace in CalendarModel.xml:
https://issues.alfresco.com/jira/browse/ETHREEOH-886

next import fails due to com.infoaxon.alfresco.calendar namespace URL not being defined.

so, I added

<namespace uri="com.infoaxon.alfresco.calendar" prefix="ia"/>
next to
<namespace uri="http://www.alfresco.org/model/calendar" prefix="ia"/>

in the calendarModel.xml model.

We tried ourselves modifying CalendarModel.xml, but we got the same error as before.

Does anyone have idea how to fix this error and move on with migration?

Re: Direct migration 2.1 -> 3.3 is it possible?

joko71 — Fri, 01 Apr 2011 11:47:18 GMT

There has been new development in our situation.

Unable to solve "calendar bug" (see previous post) we decided to temporarily comment out that patch and proceed with migration.

All went well until we came to Ibatis SQL insert bug. There is read-only transaction that tries SQL insert or something:

2011-03-31 09:31:16,960 INFO  [STDOUT] 09:31:16,960 INFO  [admin.patch.PatchExecuter] 
=== Applied patch                 === 
ID: patch.convertContentUrls
RESULT: 
Content URL conversion completed.
=====================================
2011-03-31 09:31:16,976 INFO  [STDOUT] 09:31:16,976 INFO  [admin.patch.PatchExecuter] 
=== Applied patch                 === 
ID: patch.transferServiceFolder
RESULT: 
Imported view into bootstrap location: /app:company_home/app:dictionary (workspace://SpacesStore/abb6ce0d-5aa6-11e0-97c4-69bb87980473)
=====================================
2011-03-31 09:31:17,038 INFO  [STDOUT] 09:31:17,038 INFO  [repo.module.ModuleServiceImpl] Found 0 module(s).
2011-03-31 09:31:17,085 INFO  [STDOUT] 09:31:17,085 INFO  [alfresco.config.JndiPropertyPlaceholderConfigurer] Loading properties file from class path resource [alfresco/alfresco-shared.properties]
2011-03-31 09:31:17,757 INFO  [STDOUT] 09:31:17,757 INFO  [alfresco.config.JndiPropertyPlaceholderConfigurer] Loading properties file from class path resource [alfresco/alfresco-shared.properties]
2011-03-31 09:31:18,163 INFO  [STDOUT] 09:31:18,163 ERROR [org.alfresco.fileserver] Error accessing Win32 NetBIOS, check DLL is on the path
2011-03-31 09:31:18,398 INFO  [STDOUT] 09:31:18,398 INFO  [alfresco.config.JndiPropertyPlaceholderConfigurer] Loading properties file from class path resource [alfresco/alfresco-shared.properties]
2011-03-31 09:31:18,632 INFO  [STDOUT] 09:31:18,632 INFO  [alfresco.config.JndiPropertyPlaceholderConfigurer] Loading properties file from class path resource [alfresco/alfresco-shared.properties]
2011-03-31 09:31:18,788 INFO  [STDOUT] 09:31:18,788 INFO  [alfresco.config.JndiPropertyPlaceholderConfigurer] Loading properties file from class path resource [alfresco/alfresco-shared.properties]
2011-03-31 09:31:18,882 INFO  [STDOUT] 09:31:18,882 WARN  [springframework.beans.GenericTypeAwarePropertyDescriptor] Invalid JavaBean property 'blockedSenders' being accessed! Ambiguous write methods found next to actually used [public void org.alfresco.email.server.EmailServer.setBlockedSenders(java.lang.String)]: [public void org.alfresco.email.server.EmailServer.setBlockedSenders(java.util.List)]
2011-03-31 09:31:18,898 INFO  [STDOUT] 09:31:18,898 WARN  [springframework.beans.GenericTypeAwarePropertyDescriptor] Invalid JavaBean property 'allowedSenders' being accessed! Ambiguous write methods found next to actually used [public void org.alfresco.email.server.EmailServer.setAllowedSenders(java.util.List)]: [public void org.alfresco.email.server.EmailServer.setAllowedSenders(java.lang.String)]
2011-03-31 09:31:57,822 INFO  [STDOUT] 09:31:57,791 ERROR [web.context.ContextLoader] Context initialization failed
org.springframework.dao.TransientDataAccessResourceException: SqlMapClient operation; SQL [];   
— The error occurred in alfresco/ibatis/#resource.dialect#/qname-insert-SqlMap.xml.  
— The error occurred while applying a parameter map.  
— Check the alfresco.qname.insert_QName-InlineParameterMap.  
— Check the statement (update failed).  
— Cause: java.sql.SQLException: Connection is read-only. Queries leading to data modification are not allowed; nested exception is com.ibatis.common.jdbc.exception.NestedSQLException:   
— The error occurred in alfresco/ibatis/#resource.dialect#/qname-insert-SqlMap.xml.  
— The error occurred while applying a parameter map.  
— Check the alfresco.qname.insert_QName-InlineParameterMap.  
— Check the statement (update failed).  
— Cause: java.sql.SQLException: Connection is read-only. Queries leading to data modification are not allowed
   at org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.doTranslate(SQLStateSQLExceptionTranslator.java:107)
   at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:72)
   at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80)
   at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80)
   at org.springframework.orm.ibatis.SqlMapClientTemplate.execute(SqlMapClientTemplate.java:203)
   at org.springframework.orm.ibatis.SqlMapClientTemplate.insert(SqlMapClientTemplate.java:364)
   at org.alfresco.repo.domain.qname.ibatis.QNameDAOImpl.createQNameEntity(QNameDAOImpl.java:112)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

We googled and found out that this bug has been solved for Enterprise version.

Then we decided to try 2.1 -> 3.2 -> 3.3 migration. Patch installation went well, "calendar bug" was not seen, but Ibatis SQL insert remained.

Is there a solution for that bug in 3.3 Community version?

Re: Direct migration 2.1 -> 3.3 is it possible?

joko71 — Wed, 27 Apr 2011 09:26:18 GMT

We're still struggling with migration, but for now just one simple question:

Let's say that on surface all patches were installed, but DB schema according to log remains the same (the old 2.1 schema). What could go wrong?

Re: Direct migration 2.1 -> 3.3 is it possible?

mrogers — Wed, 27 Apr 2011 09:30:33 GMT

The schemas are incompatible between 2.1 and 3.3. Alfresco will not work.

Re: Direct migration 2.1 -> 3.3 is it possible?

joko71 — Wed, 27 Apr 2011 09:41:06 GMT

The schemas are incompatible between 2.1 and 3.3. Alfresco will not work.

I said that patches (at least on surface) seem to be installed correctly. We have some other difficulties like not being able to log in into Alfresco web client, but our custom applications on top of Alfresco are working (all standard operations with repository using 3.2 Java libraries). But DB schema is according to log 2.1. Seems like DB migration is finished, but lacks final step of changing DB schema name from 2.1 to 3.2.

Re: Direct migration 2.1 -> 3.3 is it possible?

mrogers — Wed, 27 Apr 2011 09:53:21 GMT

What are you seeing in your log file? What's the startup message.

After the patches run the "current repository descriptor" is updated. It is the patch process that is the important thing. If all patches run then that's O.K.

Re: Direct migration 2.1 -> 3.3 is it possible?

joko71 — Wed, 27 Apr 2011 09:56:41 GMT

If we become dead sure one day that patch process is complete, is there a way to manually update current repository descriptor?

Re: Direct migration 2.1 -> 3.3 is it possible?

joko71 — Fri, 29 Apr 2011 08:53:03 GMT

What are you seeing in your log file? What's the startup message.

After the patches run the "current repository descriptor" is updated. It is the patch process that is the important thing. If all patches run then that's O.K.

To answer your question, this is what I see:

INFO  [service.descriptor.DescriptorService] Alfresco started (Community): Current version 3.2.0 (2039) schema 2019 - Installed version 2.1.0 (482) schema 64‍

Re: Direct migration 2.1 -> 3.3 is it possible?

joko71 — Thu, 19 May 2011 06:15:33 GMT

Now I know that "Alfresco started" string is ok. It's ambiguity confused me, like the others.

In the meantime we almost completed our migration from 2.1 to 3.2. There is one problem though in the form of (as I can see) well known "patch.authorityMigration" bug:

http://issues.alfresco.com/jira/browse/ALF-2029

2011-05-18 10:45:30,406 INFO  [STDOUT] 10:45:30,406 User:System INFO  [admin.patch.PatchExecuter]    Applying patch 'patch.authorityMigration' (Copies any old authorities from the user store to the spaces store.).
2011-05-18 10:45:43,324 INFO  [STDOUT] 10:45:43,324 User:System ERROR [admin.patch.PatchExecuter] 04180001 org.alfresco.service.cmr.repository.DuplicateChildNodeNameException: Duplicate child name not allowed: name_of_the_file.txt
   at org.alfresco.repo.node.db.hibernate.HibernateNodeDaoServiceImpl$12.doInHibernate(HibernateNodeDaoServiceImpl.java:2000)
   at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:372)
   at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:338)
   at org.alfresco.repo.node.db.hibernate.HibernateNodeDaoServiceImpl.newChildAssoc(HibernateNodeDaoServiceImpl.java:1961)
   at sun.reflect.GeneratedMethodAccessor474.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:304)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
   at org.alfresco.repo.transaction.TransactionalDaoInterceptor.invoke(TransactionalDaoInterceptor.java:68)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
   at org.alfresco.repo.domain.hibernate.DirtySessionMethodInterceptor.invoke(DirtySessionMethodInterceptor.java:381)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
   at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
   at $Proxy63.newChildAssoc(Unknown Source)

…‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Now, what can be done? Questions:

1) Is there a patch for 3.2 Community version which will enable correct patching with patch.authorityMigration?
2) If not, is there a way to do this manually, either by hand, either with some program?
3) If not, how can I turn off this patch so that his long error stack strace is not visible in the server log?
4) Is this bug serious? Is Alfresco going to work if users are added manually without successful patch?

Re: Direct migration 2.1 -> 3.3 is it possible?

joko71 — Thu, 19 May 2011 15:27:35 GMT

I've found a solution for the problem above. Two users/persons were referencing the same TXT file in their properties, hence the error. One of the references was removed with JavaScript script and the remaining patches were applied correctly.

Migration to 3.2 version is finished (on test server with real content & DB). We started with idea to migrate to 3.3, but bugs were too complicated. 3.2 was buggy too, but mildly in comparison. Al least now we can say we're using a "modern" version.

Re: Direct migration 2.1 -> 3.3 is it possible?

sidi — Tue, 31 May 2011 09:50:25 GMT

Hi joko71 we are facing the same issue from 2.1.1 to 3.3 so your idea of stoping at 3.2 looks good enough, can you detail us all the steps solving bugs you had to do?. Did you upgrade to 3.2 or 3.2r2? we are going to try it directly to 3.2r2. Is it a good idea?.

Best regards waiting for your answer.

Re: Direct migration 2.1 -> 3.3 is it possible?

joko71 — Thu, 02 Jun 2011 08:58:55 GMT

We went to 3.2, not 3.2r2. I haven't so far looked into 3.2r2, so I can't really tell what is the difference in comparison to 3.2.

Few advices:
- before DB upgrade, add avm_issuer_ids table to the schema
- during upgrade you might run into this issue: http://forums.alfresco.com/en/viewtopic.php?f=8&t=35238
- it seems that 3.2 has some difficulties regarding extension folder, so I had to make some modification on original files
- some patches can be sensitive, like patch.authorityMigration mentioned above