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 Fri, 06 Aug 2004 16:22:27 GMT

On Aug 6, 2004, at 11:29 AM, Armin Waibel wrote:

>
> Code freeze at Sunday night (GTM), then one or two days to run the  
> unit-tests against all popular databases, check performance tests.
> --> Release end of next week?


Perfect!

-Brian

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