Eclipse Community Forums: EMF » [CDO] DBStore and Model Evolution

Help

Home

Home » Modeling » EMF » [CDO] DBStore and Model Evolution

Show: Today's Messages :: Show Polls :: Message Navigator

[CDO] DBStore and Model Evolution [message #1705007]

Tue, 11 August 2015 11:51

Samuel Leisering

Messages: 34
Registered: July 2014

Member

Hi there.
According to some posts here and bugzilla (https://bugs.eclipse.org/bugs/show_bug.cgi?id=256856) there is currently no way to automatically migrate the database after a model evolution.

Because of that, i decided to try to manually migrate the database. The Steps i took were roughly the following:

* Generate a SQL Database with the old version of the model
* Generate a SQL Database with the new version of the model
* Export the structure of both databases to an SQL file and do a diff.

At this point i noticed that the structural differences between the databases were fairly straightforward (to be fair, my edit of the model was just a little thing). In short, it was one additional table and one additional column. To actually migrate the database i continued as following:

* Create the new Table (with the constraints and indices according to the exported SQL file) and the new Column in the correct table
* Update the namespace of the model in the tables CDO_PACKAGE_INFOS
* Update the binary and the namespace in the Table CDO_PACKAGE_UNITS
* Update the namespace and the entries that changed in the evolution in CDO_EXTERNAL_REFS

After a short test, this seems to work.
But given my limited understanding in the way CDOs DBStore handles the database, there might be something that i overlooked. Is this approach feasible, or is there any reason that it shouldnt work?

Some additional Information:
* The Server runs with the standard DBStore horizontal mapping on a MS SQL Database
* The Database i want to migrate is way to big to migrate it with an export-to-xml and reimport

Greetings,
Samuel Leisering

Report message to a moderator

Re: [CDO] DBStore and Model Evolution [message #1705102 is a reply to message #1705007]

Wed, 12 August 2015 07:15

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Hi Samuel,

That sounds like a good approach. The DBStore creates the tables for the deployed packages eagerly, so you shouldn't
miss any schema deltas.

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

Report message to a moderator

Re: [CDO] DBStore and Model Evolution [message #1705117 is a reply to message #1705102]

Wed, 12 August 2015 08:42

Samuel Leisering

Messages: 34
Registered: July 2014

Member

Hi
Thanks for the reply.

I encountered another problem: If i connect to a server with the old model (with the old namespace), with the new model in my code base the calls to the server just hang. They do not time out or give any response.
The actual call i do is
transaction.getObject(CDOIDUtil.createLong(someId));

As i understand it this should throw some kind of exception that the client does not have the correct model to load that object.

Greetings,
Samuel

Report message to a moderator

Re: [CDO] DBStore and Model Evolution [message #1705123 is a reply to message #1705117]

Wed, 12 August 2015 10:09

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Am 12.08.2015 um 10:42 schrieb Samuel Leisering:
> Hi
> Thanks for the reply.
> I encountered another problem: If i connect to a server with the old model (with the old namespace), with the new
> model in my code base the calls to the server just hang. They do not time out or give any response.
> The actual call i do is transaction.getObject(CDOIDUtil.createLong(someId));
>
> As i understand it this should throw some kind of exception that the client does not have the correct model to load
> that object.
This is not so easily (and reliably) detectable. I vaguely remember that we tried to do that long ago but suffered from
too many false positives. I think it's best to not change a published package's contents. The nsURI should change if the
contents change. And then this should not be a problem anymore.

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

Report message to a moderator

Re: [CDO] DBStore and Model Evolution [message #1705131 is a reply to message #1705123]

Wed, 12 August 2015 10:43

Samuel Leisering

Messages: 34
Registered: July 2014

Member

It did change, that was the point.

I have two clients. One still has the old model with the old nsUri, the other has the new model with the new nsUri. The model on the server still has the old nsUri. While the old client can connect just fine, the new client just hangs.
I checked the PackageRegistry of the session with session.getPackageRegistry(). this contains the EPackage with the old nsUri, while the generated field MyModelPackage.eNS_URI contains the new nsURI (on the new client)

Greetings
Samuel

Report message to a moderator

Re: [CDO] DBStore and Model Evolution [message #1705184 is a reply to message #1705131]

Wed, 12 August 2015 16:14

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Am 12.08.2015 um 12:43 schrieb Samuel Leisering:
> It did change, that was the point.
> I have two clients. One still has the old model with the old nsUri, the other has the new model with the new nsUri.
> The model on the server still has the old nsUri. While the old client can connect just fine, the new client just hangs.
Can you see in the debugger why or where it hangs?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

> I checked the PackageRegistry of the session with session.getPackageRegistry(). this contains the EPackage with the
> old nsUri, while the generated field MyModelPackage.eNS_URI contains the new nsURI (on the new client)
>
> Greetings
> Samuel

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] DBStore and Model Evolution [message #1705267 is a reply to message #1705184]

Thu, 13 August 2015 11:41

Samuel Leisering

Messages: 34
Registered: July 2014

Member

Hi
Ok i think i found the problem. I connect to the server with a reconnecting session.
The sessions ExceptionHandler is the org.eclipse.emf.cdo.internal.net4j.RecoveringCDOSessionImpl.RecoveringExceptionHandler.
when i load an object, the method

org.eclipse.emf.internal.cdo.session.DelegatingSessionProtocol.loadRevisions(List<RevisionInfo> infos, CDOBranchPoint branchPoint, int referenceChunk, int prefetchDepth)

is called, which in turn calls loads the revisions on the delegate. The delegate is CDOClientProtocol. In

org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(RequestWithConfirmation<RESULT> request)

the ClientProtocol correctly throws a RuntimeException because the package is not available. The Exception is then caught in the DelegatingSessionProtocol, handled by the RecoveringExceptionHandler, which basically ignores the Exception, and the DelegatingSessionProtocol is stuck in an endless loop in loadRevisions.

Since the ReconnectingCDOSessionConfigurationImpl is restricted and throws an usupported operation exception on setExceptionHandler, there is no straightforward way to set a new ExceptionHandler for the session.

*EDIT*
I tried the same thing with a different ExceptionHandler, and it works.

Greetings,
Samuel

[Updated on: Thu, 13 August 2015 12:11]

Report message to a moderator

Re: [CDO] DBStore and Model Evolution [message #1705312 is a reply to message #1705267]

Thu, 13 August 2015 16:20

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Am 13.08.2015 um 13:41 schrieb Samuel Leisering:
> Hi
> Ok i think i found the problem. I connect to the server with a reconnecting session.
> The sessions ExceptionHandler is the
> org.eclipse.emf.cdo.internal.net4j.RecoveringCDOSessionImpl.RecoveringExceptionHandler. when i load an object, the method
> org.eclipse.emf.internal.cdo.session.DelegatingSessionProtocol.loadRevisions(List<RevisionInfo> infos, CDOBranchPoint
> branchPoint, int referenceChunk, int prefetchDepth)
>
> is called, which in turn calls loads the revisions on the delegate. The delegate is CDOClientProtocol. In
> org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(RequestWithConfirmation<RESULT> request)
>
> the ClientProtocol correctly throws a RuntimeException because the package is not available. The Exception is then
> caught in the DelegatingSessionProtocol, handled by the RecoveringExceptionHandler, which basically ignores the
> Exception, and the DelegatingSessionProtocol is stuck in an endless loop in loadRevisions.
>
> Since the ReconnectingCDOSessionConfigurationImpl is restricted and throws an usupported operation exception on
> setExceptionHandler, there is no straightforward way to set a new ExceptionHandler for the session.
I think the problem is in RecoveringCDOSessionImpl.RecoveringExceptionHandler.handleException(), which indeed ignores
the exception unless it's a TransportException. I've added a test case and fixed the problem in:

474919: RecoveringExceptionHandler swallows non-transport exceptions
https://bugs.eclipse.org/bugs/show_bug.cgi?id=474919

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

Report message to a moderator

Previous Topic:	Persisting chained objects in CDO(MongoDB store)
Next Topic:	how to design a drag and drop between to containment references

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 23:48:14 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter