db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: [VOTE] Release OJB 1.0.1
Date Sat, 31 Jul 2004 11:38:21 GMT
hi armin,

Armin Waibel schrieb:
> 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).

well i'm not sure about this. i'd expect that the fks are set properly, but i 
doubt that it works with referential integrity enabled :(

> If we can't fix the problem we should note your workaround in 
> release-notes file.

that's the only solution i have.

jakob

> 
> 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
> 
> 

---------------------------------------------------------------------
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