db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert S. Sfeir" <rob...@codepuccino.com>
Subject Re: [VOTE] Release OJB 1.0.1
Date Sat, 31 Jul 2004 11:53:58 GMT
Hum... I've just been catching up to this, I hope I'm not stepping in too
late, or out of line and didn't get the issue...

If you were doing this with standard SQL approach and your DB had foreign
keys, you'd never be able to store your main object without the referenced
keys already existing.  I think this should be considered a feature, and
probably good form to force the user to think about what they're persisting
and how they're doing it.  If it's documented, then users will adapt to it.
I think that trying to make everything transparent to the user is always a
great goal, but let's not treat them like dummies ;-)

Just my 2 cents.

R


On 7/31/04 7:38 AM, "Jakob Braeuchi" <jbraeuchi@gmx.ch> wrote:

> 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



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