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 Mon, 02 Aug 2004 20:00:46 GMT
hi all,

J.Braeuchi schrieb:

> hi robert,
> 
> Robert S. Sfeir schrieb:
> 
>> 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
>>  
>>
> 
> that's why i'd like to have referential integrity enabled in our test-dbs.
> 
>> 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 ;-)
>>  
>>
> we'll have to document it, because we do not have statement reordering.

sorry for this misinformation. we *have* reordering, although not always perfect ;)

jakob

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