db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: [VOTE] Release OJB 1.0.1
Date Wed, 04 Aug 2004 12:46:31 GMT
Okay, what is happening for 1.0.1?

-Brian

On Aug 2, 2004, at 4:00 PM, Jakob Braeuchi wrote:

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



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