[CDO] DBStore and Model Evolution [message #1705007] |
Tue, 11 August 2015 07:51  |
Eclipse User |
|
|
|
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
|
|
|
|
|
|
|
|
Re: [CDO] DBStore and Model Evolution [message #1705267 is a reply to message #1705184] |
Thu, 13 August 2015 07:41   |
Eclipse User |
|
|
|
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 08:11] by Moderator
|
|
|
Re: [CDO] DBStore and Model Evolution [message #1705312 is a reply to message #1705267] |
Thu, 13 August 2015 12:20  |
Eclipse User |
|
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.06976 seconds