Hi Laurie,
I will try to do my best to shed some light on this.
Thanks for the response Armin :)
First do remove all access="anonymous" setting from your descriptors (expect those for 1:1 relations) to eliminate side-effects of this setting.
It shouldn't have any effect on the tests against 0.9.7 should it? IIRC, anonymous access was introduced later. I'll try without it on 1.0rc5 though.
> First, the insertion of player1 fails, as it should. But I expected it
> to fail on the call to lock(). It doesn't fail until the commit() at
> which point I get a org.apache.ojb.odmg.TransactionAbortedExceptionOJB.
> Is this the expected behaviour?
This is normal behaviour. If you lock an existing object nothing should happend. OJB does not perform any sql-queries when you lock an object. When tx.commit() was called OJB performs the sql-queries.
According to p6spy OJB perfoms a SELECT when I lock an object, but OK, as long as what I'm seeing is normal I can adapt my business logic accordingly. Does make it sort of tough to work out where a transaction failed though; is there any recommended approach to that? I.e. if my transaction consists of inserting a couple of objects and some updates, but fails on the commit due to a constraint violation of some kind, is there a way to programatically determine which step failed?
In your example you do
> p1 = new Player("name1", "player11", "pwd");
and say that this object already exist. Why? This object only exist if the same PK exist in DB already. The defined PK field is ID and you don't set this field in p1. So OJB assume this is a new object and try to insert it.
Hmm, OK. The name property is defined as unique and, as far as the object model is concerned, is the identifying attribute for this class. The ID column in the database exists to make joins efficient and it's value is irrelevant outside use in foreign keys. I expect the database to manage this field and assign it a value -- that's the point of setting it up as an auto-incremented column.
Saying that, though, I just noticed that my repository descriptor does *not* have autoincrement="true" on that property. That seems like it might be significant...!
I don't know how the anonymous PK field was handled, AFAIK we don't have tests for that use case. As I said above try without this attribute for PK field. You can set ID as private field without get/set methods in Player (if you using PersistentFieldDirectAccessImpl as PersistentFieldClass property in OJB.properties - this is default setting).
Getting rid of integer PK columns on all tables is a pretty significant impact on my physical data model, since it would impact just about every foreign key relationship in the schema :-( I've already tried getting rid of anonymous access without it maing a difference but perhaps I should keep that out of the equation for now.
What about the delete that caused OJB 097 to run this query: DELETE FROM PLAYER WHERE ID = '0' followed by a commit but which didn't delete the row with ID=0?
Thanks,
L.
regards, Armin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
