db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: [VOTE] Release OJB 1.0.1
Date Sat, 31 Jul 2004 09:17:34 GMT
Hi,

Jakob Braeuchi wrote:

 > hi armin,
 >
 > storing the single-refs *before* storing the mainObj solves the problem:
 >
 >         Transaction tx = odmg.newTransaction();
 >         tx.begin();
 >         db.makePersistent(s_ref_1);
 >         db.makePersistent(s_ref_2);
 >         db.makePersistent(s_ref_3);
 >         db.makePersistent(s_ref_4);
 >
 >         db.makePersistent(obj_1);
 >         db.makePersistent(obj_2);
 >         tx.commit();
 >
 > so what's wrong with this ? is the odmg-api supposed to be able to 
solve this problem without a little help from the user ?
 >

Indeed it should always be possible to store an object with references
without persist each reference before the main object. If you don't use
Identity columns it is possible (think we have odmg-tests doing this).
If we can't fix the problem we should note your workaround in 
release-notes file.

The problem (as you mentioned) is the early FK binding in odmg 
implementation. On commit the objects should be reordered and then after 
the insert of the 1:1 reference the FK should be set in main object. 
Same way PB-api works.

 >> we have a mainObject with a 1:1 relationship to a SingleReference.
 >> during tx.commit the mainObj is save first, storeReferences does NOT
 >> save this singleRef because of auto-settings set to false.


[off-topic]
This is a more general problem of current odmg/otm design, they can't 
use the auto-xxx features of the PB-api. For odmg (and otm as far as I 
know) all reference auto-update/delete settings have to be 'false'. It's 
a shame, because PB-api can handle all kinds of reference/linking in a 
correct way.
But current top-level implementations rebuild this functionality instead 
of using the PB-api resources. So the PB-api lacks of functionality and 
extendable design or the top-level implementations "use wrong design".
Think we should discuss this.

Some time ago I think about a callback/listener method in the internal 
PB-api (in 1.1 we will extend PB interface to deal with internal 
functionality - for the present this new interface called 
PersistenceBrokerExt and extend PersistenceBroker).
Maybe a special action listener. E.g. the transaction class of the 
top-level api (TL-api) implements this listener and on commit the TL-api 
pass the first persistent object to the PB-api (store/delete). But 
before perform the delete/store call the PB-api notify the listener. If 
the listener allows the operation the PB store/delete call will be done 
and if the persistent object has references the PB-api handle these 
referenced objects dependent on the auto-xxx settings. But for each 
referenced object store/delete call the listener will be asked again. If 
the listener dislike the operation the PB-api doesn't store/delete and 
the cascade operation leave out this object.
This way the TL-api can decide (dirty check, locking check, ...) which 
persistent object should be stored/deleted without dealing with FK 
settings/linking/references.

Alternative will be to move all TL-api services like dirty-detection, 
locking, ... to the kernel, then the TL-api can use these services. This 
means that OTM and kernel will be merged in some way.

regards,
Armin


 > jakob
 >
 > Jakob Braeuchi schrieb:
 >
 >> hi armin,
 >>
 >> i was debugging NativeIdentifierTest#testReferenceInsertUpdateODMG 
for quite some time and unfortunately i do not see a solution to this 
problem :(
 >>
 >> we have a mainObject with a 1:1 relationship to a SingleReference. 
during tx.commit the mainObj is save first, storeReferences does NOT 
save this singleRef because of auto-settings set to false. afterStore of 
mainObj the db-generated key is put into the object. i tried to call 
setReferenceFKs in afterStore, but this is useless because singleRef is 
not saved and still carries the dummy key !
 >>
 >> so, imo we cannot insert the mainObj referencing a non existent 
singleRef !
 >> evene if we could update all the fks in the mainObj the row in the 
database is still wrong, because it contains to dummy key of the singleRef:
 >>
 >> INSERT INTO NATIVE_MAIN_OBJECT (REF_ID,NAME) VALUES 
('-2','testReferenceInsert_main_1091213387781')
 >>
 >> this actually only works because there are no referential constraints.
 >>
 >> jakob
 >>
 >>
 >> Armin Waibel schrieb:
 >>
 >>> Jakob Braeuchi wrote:
 >>>
 >>>> hi armin,
 >>>>
 >>>> are you solving this issues for 1.0.1 ?
 >>>>
 >>>
 >>> I will try to do so, but concurrently I'm working on the 1.1 stuff 
so any help is much appreciated.
 >>>
 >>> Armin
 >>>
 >>>> jakob
 >>>>
 >>>> Armin Waibel schrieb:
 >>>>
 >>>>> Hi all,
 >>>>>
 >>>>> Brian McCallister wrote:
 >>>>>
 >>>>>> We have a number of user-requested bug fixes in the 
OJB_1_0_RELEASE branch at the moment. I'd like to push a release.
 >>>>>>
 >>>>>
 >>>>> There are some open issues (2 failing odmg-test cases, 
CollectionTest) and a serious bug in FK assignment when odmg-api was 
used with native DB Identity columns (SequenceManagerNativeImpl). 
NativeIdentifierTest, on insert of objects with 1:1 references. Problem 
occurs in TransactionImpl#lock(Object obj, int lockMode) line 235.
 >>>>>
 >>>>> When using native Identity columns, OJB use a temporary dummy 
value for created OJB Identity objects of new pc objects (negative long 
values are used as dummy values for Identity columns), so the FK 
assignment is only valid after store of the referenced object.
 >>>>> TransactionImpl#lock assign the FK before the referenced object 
was written to DB.
 >>>>>
 >>>>>
 >>>>> regards,
 >>>>> Armin
 >>>>>
 >>>>>> +1/0/-1
 >>>>>>
 >>>>>> Vote will end Sunday, Aug 1.
 >>>>>>
 >>>>>> -Brian
 >>>>>>





---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message