| [CDO] Database backup/restore on server side [message #663750] |
Wed, 06 April 2011 11:38  |
 Nils Israel
Messages: 72
Registered: May 2010 |
Member |
|
|
Hi,
I recently switched from CDO3 to CDO4. The problem I have right now is
that my model is evolving. Classes and attributes are added (hopefully
never removed or renamed...).
In version 3 the workflow was the following:
1. Backup current state of repository with EcoreUtil.copyAll into a file
2. Shutdown server, delete database
3. Alter ecore-Model, change nsURI, generate code
4. update exportfile manually to match new model
5. Start server, register new model
6. Restore state with EcoreUtil.copyAll from updated exportfile
In version 4 I want to do the backup and restore on the server side. At
first I tested exporting the repo and reimporting it unaltered. The
server tells me everything went fine but as soon as I connect via CDO
Explorer or client-app I get the following error message:
java.lang.IllegalStateException: External ID -14 not found. Database
inconsistent!
at
org.eclipse.emf.cdo.server.internal.db.ExternalReferenceMana ger.unmapURI(ExternalReferenceManager.java:122)
at
org.eclipse.emf.cdo.server.internal.db.ExternalReferenceMana ger.unmapExternalReference(ExternalReferenceManager.java:93)
at
org.eclipse.emf.cdo.server.internal.db.LongIDHandler.unmapEx ternalReference(LongIDHandler.java:191)
at
org.eclipse.emf.cdo.server.internal.db.LongIDHandler.getCDOI D(LongIDHandler.java:173)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ob jectTypeTable.getObjectType(ObjectTypeTable.java:89)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.De legatingObjectTypeMapper.getObjectType(DelegatingObjectTypeM apper.java:62)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalMappingStrategy.readObjectType(AbstractHoriz ontalMappingStrategy.java:73)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalMappingStrategy.readObjectType(HorizontalMappingStra tegy.java:194)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readO bjectType(DBStoreAccessor.java:173)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getOb jectType(DBStoreAccessor.java:190)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readR evision(DBStoreAccessor.java:210)
at
org.eclipse.emf.cdo.internal.server.Repository.loadRevisions (Repository.java:441)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.loadRevisions(CDORevisionManagerImpl.java:352)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.getRevisions(CDORevisionManagerImpl.java:263)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.getRevision(CDORevisionManagerImpl.java:246)
at
org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.execute (RevisionInfo.java:132)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadRevis ionsIndication.responding(LoadRevisionsIndication.java:169)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServer Indication.responding(CDOServerIndication.java:133)
at
org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:296)
at
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOReadIn dication.execute(CDOReadIndication.java:36)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I think the problem is that the table "cdo_external_refs" (I am using
dbstore with mysql btw) is not being restored. After the import there
are only 13 entries, all of them cdo classes. As a workaround I can stop
the server, fill the table cdo_external_refs from a mysql backup and
start the server again.
Is this a bug or am I doing something wrong?
The second question is about the model evolution:
In the output there are revisions with the attributes class and feature.
Example:
<revision id="L88" class="http://local/db/1.0/a2#SomeClass" version="1"
time="1302013629367" container="L81" feature="-38">...</revision>
When I modify the model and add a class, how can I assure that the class
"SomeClass" gets the feature id "-38" on the restore? The feature id is
not saved in the data attribute of the package unit.
Is this handled internally or do I have to register the model on an
empty repository, look at the table cdo_external_refs and match class
und feature manually?
Btw, I was impressed how smooth the restore worked even with "large"
repositories. With CDO3 and EcoreUtil.copyAll, there was no way I could
import an 40 MB XML-File.
Regards,
Nils
|
|
|
| Re: [CDO] Database backup/restore on server side [message #663751 is a reply to message #663750] |
Wed, 06 April 2011 11:51  |
|
Am 06.04.2011 13:38, schrieb Nils Israel:
> Hi,
>
> I recently switched from CDO3 to CDO4. The problem I have right now is that my model is evolving. Classes and attributes are added (hopefully never removed or renamed...).
>
> In version 3 the workflow was the following:
> 1. Backup current state of repository with EcoreUtil.copyAll into a file
> 2. Shutdown server, delete database
> 3. Alter ecore-Model, change nsURI, generate code
> 4. update exportfile manually to match new model
> 5. Start server, register new model
> 6. Restore state with EcoreUtil.copyAll from updated exportfile
>
> In version 4 I want to do the backup and restore on the server side. At first I tested exporting the repo and reimporting it unaltered. The server tells me everything went fine but as soon as I connect via CDO Explorer or client-app I get the following error message:
>
> java.lang.IllegalStateException: External ID -14 not found. Database inconsistent!
> at org.eclipse.emf.cdo.server.internal.db.ExternalReferenceMana ger.unmapURI(ExternalReferenceManager.java:122)
> at org.eclipse.emf.cdo.server.internal.db.ExternalReferenceMana ger.unmapExternalReference(ExternalReferenceManager.java:93)
> at org.eclipse.emf.cdo.server.internal.db.LongIDHandler.unmapEx ternalReference(LongIDHandler.java:191)
> at org.eclipse.emf.cdo.server.internal.db.LongIDHandler.getCDOI D(LongIDHandler.java:173)
> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ob jectTypeTable.getObjectType(ObjectTypeTable.java:89)
> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.De legatingObjectTypeMapper.getObjectType(DelegatingObjectTypeM apper.java:62)
> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalMappingStrategy.readObjectType(AbstractHoriz ontalMappingStrategy.java:73)
> at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalMappingStrategy.readObjectType(HorizontalMappingStra tegy.java:194)
> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readO bjectType(DBStoreAccessor.java:173)
> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getOb jectType(DBStoreAccessor.java:190)
> at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readR evision(DBStoreAccessor.java:210)
> at org.eclipse.emf.cdo.internal.server.Repository.loadRevisions (Repository.java:441)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.loadRevisions(CDORevisionManagerImpl.java:352)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.getRevisions(CDORevisionManagerImpl.java:263)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.getRevision(CDORevisionManagerImpl.java:246)
> at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.execute (RevisionInfo.java:132)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadRevis ionsIndication.responding(LoadRevisionsIndication.java:169)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServer Indication.responding(CDOServerIndication.java:133)
> at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:296)
> at org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOReadIn dication.execute(CDOReadIndication.java:36)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
> I think the problem is that the table "cdo_external_refs" (I am using dbstore with mysql btw) is not being restored. After the import there are only 13 entries, all of them cdo classes. As a workaround I can stop the server, fill the table cdo_external_refs from a mysql backup and start the server again.
>
> Is this a bug or am I doing something wrong?
It sounds like a bug. Can you please submit a bugzilla?
>
> The second question is about the model evolution:
> In the output there are revisions with the attributes class and feature. Example:
>
> <revision id="L88" class="http://local/db/1.0/a2#SomeClass" version="1" time="1302013629367" container="L81" feature="-38">...</revision>
>
> When I modify the model and add a class, how can I assure that the class "SomeClass" gets the feature id "-38" on the restore? The feature id is not saved in the data attribute of the package unit.
> Is this handled internally or do I have to register the model on an empty repository, look at the table cdo_external_refs and match class und feature manually?
The feature attribute on a <revision> element corresponds to eContainingFeatureID of your EObject. It is directly and exclusively inferred from your meta model.
I can't rememebr right now but if the <feature> elements nested inside the <revision> element refer to their EStructuralFeature by name then it might make sense to use a name key in the <revision> element, too. Please file a separate enhancement request in this case.
>
> Btw, I was impressed how smooth the restore worked even with "large" repositories. With CDO3 and EcoreUtil.copyAll, there was no way I could import an 40 MB XML-File.
Thank you. Making this mechanism scale well was a major requirement and the main challenge ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Database backup/restore on server side [message #664034 is a reply to message #663751] |
Thu, 07 April 2011 08:45 |
Nils Israel
Messages: 72
Registered: May 2010 |
Member |
|
|
Am 06.04.2011 13:51, schrieb Eike Stepper:
> Am 06.04.2011 13:38, schrieb Nils Israel:
>> Hi,
>>
>> I recently switched from CDO3 to CDO4. The problem I have right now is
>> that my model is evolving. Classes and attributes are added (hopefully
>> never removed or renamed...).
>>
>> In version 3 the workflow was the following:
>> 1. Backup current state of repository with EcoreUtil.copyAll into a file
>> 2. Shutdown server, delete database
>> 3. Alter ecore-Model, change nsURI, generate code
>> 4. update exportfile manually to match new model
>> 5. Start server, register new model
>> 6. Restore state with EcoreUtil.copyAll from updated exportfile
>>
>> In version 4 I want to do the backup and restore on the server side.
>> At first I tested exporting the repo and reimporting it unaltered. The
>> server tells me everything went fine but as soon as I connect via CDO
>> Explorer or client-app I get the following error message:
>>
>> java.lang.IllegalStateException: External ID -14 not found. Database
>> inconsistent!
>> at
>> org.eclipse.emf.cdo.server.internal.db.ExternalReferenceMana ger.unmapURI(ExternalReferenceManager.java:122)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.ExternalReferenceMana ger.unmapExternalReference(ExternalReferenceManager.java:93)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.LongIDHandler.unmapEx ternalReference(LongIDHandler.java:191)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.LongIDHandler.getCDOI D(LongIDHandler.java:173)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ob jectTypeTable.getObjectType(ObjectTypeTable.java:89)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.De legatingObjectTypeMapper.getObjectType(DelegatingObjectTypeM apper.java:62)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalMappingStrategy.readObjectType(AbstractHoriz ontalMappingStrategy.java:73)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalMappingStrategy.readObjectType(HorizontalMappingStra tegy.java:194)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readO bjectType(DBStoreAccessor.java:173)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.getOb jectType(DBStoreAccessor.java:190)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.readR evision(DBStoreAccessor.java:210)
>>
>> at
>> org.eclipse.emf.cdo.internal.server.Repository.loadRevisions (Repository.java:441)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.loadRevisions(CDORevisionManagerImpl.java:352)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.getRevisions(CDORevisionManagerImpl.java:263)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.getRevision(CDORevisionManagerImpl.java:246)
>>
>> at
>> org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.execute (RevisionInfo.java:132)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadRevis ionsIndication.responding(LoadRevisionsIndication.java:169)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServer Indication.responding(CDOServerIndication.java:133)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
>>
>> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:296)
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOReadIn dication.execute(CDOReadIndication.java:36)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>>
>> I think the problem is that the table "cdo_external_refs" (I am using
>> dbstore with mysql btw) is not being restored. After the import there
>> are only 13 entries, all of them cdo classes. As a workaround I can
>> stop the server, fill the table cdo_external_refs from a mysql backup
>> and start the server again.
>>
>> Is this a bug or am I doing something wrong?
> It sounds like a bug. Can you please submit a bugzilla?
done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=342105
>
>>
>> The second question is about the model evolution:
>> In the output there are revisions with the attributes class and
>> feature. Example:
>>
>> <revision id="L88" class="http://local/db/1.0/a2#SomeClass"
>> version="1" time="1302013629367" container="L81"
>> feature="-38">...</revision>
>>
>> When I modify the model and add a class, how can I assure that the
>> class "SomeClass" gets the feature id "-38" on the restore? The
>> feature id is not saved in the data attribute of the package unit.
>> Is this handled internally or do I have to register the model on an
>> empty repository, look at the table cdo_external_refs and match class
>> und feature manually?
> The feature attribute on a <revision> element corresponds to
> eContainingFeatureID of your EObject. It is directly and exclusively
> inferred from your meta model.
ahh, now I get it.
>
> I can't rememebr right now but if the <feature> elements nested inside
> the <revision> element refer to their EStructuralFeature by name then it
> might make sense to use a name key in the <revision> element, too.
> Please file a separate enhancement request in this case.
done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=342115
Regards,
Nils
|
|
|
Powered by
FUDForum. Page generated in 0.02580 seconds
] 
Search
Help
Register
Login
Home
