Hi Steve,
[EMAIL PROTECTED] wrote:
Now I remember why I'm always hesitant to upgrade OJB - it seems like there is some fundamental change to how things work.
we made a complete refactoring of the odmg implementation in 1.0.2/3, because of the many known issues in OJB <=1.0.1 (see release-notes 1.0.2/3).
I did my best not to break backward compatibility. The problem is that we don't get much feedback from the ODMG users, so I only can test against the OJB test-suite which never could reflect behavior of a real OJB application.
Major changes are noted in release-notes. But you are right, internally the odmg implementation changed (better dirty-detection, avoid of materialization proxy objects, ...).
I hope things are getting more stable, 'cause in the in-between times when I don't have to rework, it's a great tool.
My intention was to make it more stable ;-)
Here's where I'm stuck now. I just upgraded from 1.0.0 to 1.0.3; I use the ODMG API. I have the following pseudo-code:
child = retrieveSomeObjectFromDatabase(); tx = odmg.newTransaction(); parent = new Parent(); database.makePersistent(parent); parent.addChild(child); tx.commit();
parent.addChild() does what it sounds like: calls children.add(child).
When I commit the transaction, OJB tries to insert a new Child. Can anybody tell me why this might happen? This is, obviously, a showstopper for me. It happens with default caching (i.e. none) and with the two-level cache.
I wrote a test-case to reproduce your problem, but I can't. I stumble across another bug (OJB-33, will be fixed soon http://issues.apache.org/jira/browse/OJB-33).
Could you post some more details of the used objects. Does the Child object use primitive number fields (e.g. int) as PK? Could the PK of the Child object be '0'?
Current behavior of ODMG seems that the n-side object will be completely ignored: Book -1:n-> Review
Review review = new Review(name); TransactionExt tx = (TransactionExt) odmg.newTransaction(); tx.begin(); database.makePersistent(review); tx.commit();
Date date = new Date();
byte[] cover = new byte[]{2,3,4,5,6,7,8,9};
Book book = new Book(name, date, cover);
tx = (TransactionExt) odmg.newTransaction();
tx.begin();
database.makePersistent(book);
book.addReview(review);
tx.commit();Other random ODMG questions:
At some point, the instructions for adding a new persistent object using ODMG changed; I'm not sure when. It used to say that tx.lock(object, tx.WRITE) would add the object to the db if it wasn't already there, and this is how I've always done it. Now I see that the tutorial says to use db.makePersistent(object), and the code for the two is different. Will tx.lock() still work, or do I have to rewrite all of my DAOs?
Yep, this changed. Persist new objects with tx.lock should work too. I didn't change the old tests in test-suite and didn't notice side-effects (think they use tx.lock too some time to insert new objects).
Is it true that the (unofficial) feature which actually did allow ODMG to observe auto-delete settings is gone?
I didn't take care of this "unkown feature" when refactoring ODMG (the official setting was auto-update/delete 'false' in <=1.0.1). But I think your setting could cause side-effects, because the objects deleted with auto-delete 'true' will not be controlled by ODMG, thus they will not be locked before delete.
I've always (in OJB ODMG) used cascading delete bounded by appropriate auto-delete settings; now it looks as if I have no choice but to delete each individual object by hand. True?
When using default behavior - yep.
Setting the cascading delete settings by relationship type (1:1, 1:n, m:n) seems extremely weird, and certainly won't be very useful, since the correct delete semantics are always a function of the particular relationship, not of the form of the relationship.
Completely agree, I think the introduced settings in OJB.properties are nonsense in most cases. Currently the only methods help to improve deletion are TransactionExt#setCascadingDelete...
http://db.apache.org/ojb/api/org/apache/ojb/odmg/TransactionExt.html#setCascadingDelete(java.lang.Class,%20boolean)
If your are interested in an official support of auto-delete setting in odmg-api please make a feature request on jira. I don't know if this will be possible in near future, but will do my best.
regards, Armin
thanks, -steve
Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
