db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Anthony <charles.anth...@hpdsoftware.com>
Subject RE: [VOTE] Release OJB 1.0.1
Date Thu, 05 Aug 2004 06:47:30 GMT
Hi Jakob, Brian,

I've attached my patched ObjectEnvelopeTable - but will not be offended in
the slightest if you don't use it.

I'm not very proud of it, I'll admit - it's a kludgy, nasty, horrible bodge
that works for us in most scenarios - not all. (Essentially, I keep track of
whether the reorder method actually changed anything, and I keep reordering
until we don't change the order any more, or until I hit a magic number of
re-orders. I think our magic number is too high (I think one of our
developers arbitrarily increased to a big number)).

It also includes something which I think should go into the codebase;  when
the LockNotGranted optimistic lock is thrown, we include the Object.toString
in the exception - because otherwise, how do you know which object failed
with an optimistic lock ? It would better if I just include the Identity of
the object (as opposed to the toString) but other than that we find it very
useful.

Cheers,

Charles.





-----Original Message-----
From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch]
Sent: 04 August 2004 16:47
To: OJB Developers List
Subject: Re: [VOTE] Release OJB 1.0.1


hi brian,

i changed the testcase to make it run.

charles has a better algorithm for statement reordering, so we could give it
a 
try; but this may be too late for 1.0.1.

jakob

Brian McCallister schrieb:
> 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
> 
> 

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



___________________________________________________________
HPD Software Ltd. - Helping Business Finance Business
Email terms and conditions: www.hpdsoftware.com/disclaimer 


  



Mime
View raw message