Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] debugging schema derivation?
[CDO] debugging schema derivation? [message #1765611] Mon, 12 June 2017 19:03 Go to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
I'm trying to upload existing EMF models into a CDO repository, and while initially things worked OK, at some point I started getting timeout exceptions in the client that performs the upload.

After turning on lots of debug options, I found the culprit to be s.t. like:
org.eclipse.net4j.db.DBException: org.h2.jdbc.JdbcSQLException: Column "FOO" not found; SQL statement:
INSERT INTO MODEL_ENTITY (BAR, ZORK, FOO, GNARP)


Wouldn't it be nice, if the client received an exception that actually tells what's going on? Maybe things were just to borken: when INSERT triggered rollback and rollback didn't seem to complete in time. These are the last lines in the log (not sure if that's a successful rollback):

net4j-thread-8 [debug] Rolling back transaction: Transaction[2:1]
net4j-thread-8 [debug] --- DB ROLLBACK ---


Interestingly, sometimes the upload works fine, but once I saw the exception, I need to delete the database and start over.

Apparently, deriving the SQL schema from my EMF meta models has some non-deterministic bug.

Question: (how) can I turn on specific logging to watch the process of schema derivation? Or at least what schema was actually created? Right now I can't even look at the schema because the exception causes a database rollback and the database is empty again.

FWIW, the EPackages are quite complex, whereas may CDO settings are pretty much the "factory defaults".

The missing COLUMN corresponds to a boolean attribute in my meta model.

I also tried pre-loading my EPackages, but not more luck with that. One problem I recall is: when uploading into the repo with preloaded EPackages the upload operation failed saying the schema was locked (pre-load and upload use the exact same EPackages).

One thing I saw working OK: when pre-loading EPackages the tables included the column(s) that caused DBException before, so in this case the schema was derived correctly.

But even just restarting a server configured to pre-load models failed, here with
org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: "PRIMARY_KEY_F7 ON PUBLIC.CDO_PACKAGE_UNITS(ID)"; SQL statement:
INSERT INTO CDO_PACKAGE_UNITS (ID, ORIGINAL_TYPE, TIME_STAMP, PACKAGE_DATA) VALUES (?, ?, ?, ?) [23505-168]



Since I cannot show all my meta models and models, I'd like to learn how to debug these issues on my end. Any hints?

best,
Stephan
Re: [CDO] debugging schema derivation? [message #1765712 is a reply to message #1765611] Tue, 13 June 2017 17:09 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
Did you change the ecore model and now trying connect to an existing repository/DB that contains the old version (of the model structure)?
Re: [CDO] debugging schema derivation? [message #1765716 is a reply to message #1765712] Tue, 13 June 2017 18:38 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
 Did you change the ecore model and now trying connect to an existing repository/DB that contains the old version (of the model structure)? 


Thanks for asking, but at the point when the above problems happend (time out caused by failing roll back caused by JdbcSQLException), the database was brand new and empty.

On the client side I do have two versions of the meta model, but before anything is pushed to CDO everything is migrated to one meta model only (the newest variant). And even these different meta model versions are distinguished by different nsURI.

There may still be a 1% chance that the wrong meta model was sent to CDO, so, how can I watch which SQL schemas CDO is creating during the transaction commit?

-- Stephan
Re: [CDO] debugging schema derivation? [message #1765720 is a reply to message #1765716] Tue, 13 June 2017 20:37 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
You should be able to have a look at the package registry of your repository. I would set a breakpoint in

org.eclipse.emf.cdo.server.CDOServerUtil.addRepository(IManagedContainer, IRepository)

and debug what is in IRepository.getPackageRegistry()

If both versions of your model (with different nsURIs) are registered, then I think that would be the cause as CDO would try to mix both versions.

Stephan Herrmann wrote on Tue, 13 June 2017 20:38
 Did you change the ecore model and now trying connect to an existing repository/DB that contains the old version (of the model structure)? 


Thanks for asking, but at the point when the above problems happend (time out caused by failing roll back caused by JdbcSQLException), the database was brand new and empty.

On the client side I do have two versions of the meta model, but before anything is pushed to CDO everything is migrated to one meta model only (the newest variant). And even these different meta model versions are distinguished by different nsURI.

There may still be a 1% chance that the wrong meta model was sent to CDO, so, how can I watch which SQL schemas CDO is creating during the transaction commit?

-- Stephan

Re: [CDO] debugging schema derivation? [message #1765927 is a reply to message #1765720] Wed, 14 June 2017 13:40 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Quote:
You should be able to have a look at the package registry of your repository. I would set a breakpoint in

org.eclipse.emf.cdo.server.CDOServerUtil.addRepository(IManagedContainer, IRepository)

and debug what is in IRepository.getPackageRegistry()

Thanks, these hints eventually led me to org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingRead(CDODataInput, OMMonitor), where I could observe bogus EPackages being installed from the commit.

Given the number of existing tracing options, I still wonder if the EPackage->Schema derivation can somehow be observed without source-level debugging?

Quote:
If both versions of your model (with different nsURIs) are registered, then I think that would be the cause as CDO would try to mix both versions.


Why would it mix versions if they have different nsURI?

Anyway, the main problem is solved for me,
thanks,
Stephan
Re: [CDO] debugging schema derivation? [message #1766562 is a reply to message #1765927] Fri, 23 June 2017 05:33 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Stephan,

I could add more trace statements for you. Please submit a bugzilla.

You could also listen to IEvents from the IDBSchema and dump the information in a way that suits your needs. But I just noticed that there are no hooks (events) for opening and closing (committing) IDBSchemaTransactions. I could add them if you submit a bugzilla.


Previous Topic:[CDO] Server Choices and Deployment Options
Next Topic:[CDO] Object level security
Goto Forum:
  


Current Time: Thu Mar 28 19:52:22 GMT 2024

Powered by FUDForum. Page generated in 0.03512 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top