Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <410A9D11.7060809@gmx.ch>
References: <5AD054BE-E0C8-11D8-9171-000A95782782@forthillcompany.com>
 <4108A75D.3020304@apache.org> <410925E5.5080407@gmx.ch>
 <41092CB1.3000106@apache.org> <410A9AF9.90905@gmx.ch>
 <410A9D11.7060809@gmx.ch>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <611F8C37-E25D-11D8-9827-000A95782782@forthillcompany.com>
Content-Transfer-Encoding: 7bit
From: Brian McCallister <mccallister@forthillcompany.com>
Subject: Re: [VOTE] Release OJB 1.0.1
Date: Fri, 30 Jul 2004 15:19:29 -0400
To: "OJB Developers List" <ojb-dev@db.apache.org>

Statement re-ordering to help the user would be a nice thing, though to  
my knowledge it doesn't really do it right now.

-Brian

On Jul 30, 2004, at 3:10 PM, 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 ?
>
> 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
>
>


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