[CDO] debugging schema derivation? [message #1765611] |
Mon, 12 June 2017 19:03 |
Stephan Herrmann 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 #1765927 is a reply to message #1765720] |
Wed, 14 June 2017 13:40 |
Stephan Herrmann 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
|
|
|
|
Powered by
FUDForum. Page generated in 0.03642 seconds