Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <6FB083FB72EFD21181D30004AC4CA18A04A0D0C9@SRV002>
From: Charles Anthony <charles.anthony@hpdsoftware.com>
To: 'OJB Developers List' <ojb-dev@db.apache.org>
Subject: RE: Multiple Extents Issue (Was RE: [VOTE] Release OJB 1.0.1)
Date: Sat, 7 Aug 2004 13:57:47 +0100 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Yep; I think Criter.copy should do

copy.m_criteria = new Vector(this.m_criteria);
        copy.m_negative = new Vector(this.m_negative);

etc  - i.e. copy the collection

> -----Original Message-----
> From: Jakob Braeuchi [mailto:jbraeuchi@gmx.ch]
> Sent: 07 August 2004 13:57
> To: OJB Developers List
> Subject: Re: Multiple Extents Issue (Was RE: [VOTE] Release OJB 1.0.1)
> 
> 
> hi charles,
> 
> this means that the copy of the query is wrong.
> i'll check this asap.
> 
> jakob
> 
> 
> Charles Anthony schrieb:
> 
> > I think I've found the underlying problem; when copying a 
> QueryByCritera, we
> > don't copy the criteria itself... So, in
> > BrokerHelper.setConcreteClassCriteria, when we add the IN 
> criteria to the
> > copyQuery we are also adding to the aQuery parameter.
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Charles Anthony 
> >>Sent: 07 August 2004 12:55
> >>To: Charles Anthony; 'OJB Developers List'
> >>Subject: Multiple Extents Issue (Was RE: [VOTE] Release OJB 1.0.1)
> >>
> >>
> >>Hi All, 
> >>
> >>I've managed to modify the MultipleTableExtentAwareQueryTest 
> >>testcase to reproduce this error. Which is handy. 
> >>
> >>I shall email my test case modifcations to Armin, Brian & 
> >>Jakob. Essentially, as soon as you have mutltiple table 
> >>extents, and you use an ojbConcreteClass attribute to specify 
> >>the appropriate class to materialize, queries go horribly wrong.
> >>
> >>At least I've created a test case this weekend, if not a solution...
> >>
> >>(Oh, and  PersistenceBrokerImpl.getRsIteratorFromQuery  
> >>doesn't recurse like I implied yesterday. Doh - it'd been a  
> >>long day.)
> >>
> >>Cheers,
> >>
> >>Charles.
> >>
> >>
> >>>-----Original Message-----
> >>>From: Charles Anthony 
> >>>Sent: 06 August 2004 17:54
> >>>To: Charles Anthony; 'OJB Developers List'
> >>>Subject: RE: [VOTE] Release OJB 1.0.1
> >>>
> >>>
> >>>Actually, just in case anyone is curious, here's a sort of 
> >>>redux of the problem.
> >>>We have a hierarchical situtation a bit like this
> >>>
> >>>             A
> >>>         B     C
> >>>      D    E     F  G
> >>>
> >>>i.e. B and C are subclasses of A, 
> >>>D and E are subclasses of B
> >>>F and G are subclasses of C
> >>>
> >>>A, B and C are mapped to tables TABLE_A, TABLE_B and TABLE_C
> >>>
> >>>(Our hierarchy is much deeper and wider)
> >>>
> >>>If we query for all A's (and subclasses), the actual queries 
> >>>we get are something like
> >>>select * from TABLE_A where OJBCONCRETECLASS in ('A')
> >>>select * from TABLE_B where OJBCONCRETECLASS in ('A') AND 
> >>>OJBCONCRETECLASS in ('B', 'D', 'E') 
> >>>select * from TABLE_C where OJBCONCRETECLASS in ('A') AND 
> >>>OJBCONCRETECLASS in ('C', 'F', 'G') 
> >>>
> >>>So we never find any anthing from tables B or C.
> >>>
> >>>I think we should be getting
> >>>
> >>>select * from TABLE_A where OJBCONCRETECLASS in ('A')
> >>>select * from TABLE_B where OJBCONCRETECLASS in ('B', 'D', 'E') 
> >>>select * from TABLE_C where OJBCONCRETECLASS in ('C', 'F', 'G') 
> >>>
> >>>I think it's something to do with the recursion in 
> >>>PersistenceBrokerImpl.getRsIteratorFromQuery - and maybe the 
> >>>Query.withExtents flag.
> >>>
> >>>But I could be wrong.
> >>>
> >>>If anyone can think of anything, please let me know (it is 
> >>>really rather urgent).
> >>>
> >>>Cheers,
> >>>
> >>>Charles.
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Charles Anthony 
> >>>>Sent: 06 August 2004 17:35
> >>>>To: 'OJB Developers List'
> >>>>Subject: RE: [VOTE] Release OJB 1.0.1
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>I think I've got a nasty issue with extents with the current 
> >>>>cvs version - but I don't think I'll be able to isolate it 
> >>>>any time soon. As soon as I think I know what it is, I'll let 
> >>>>you know - but please don't wait on me (ha! as if).
> >>>>
> >>>>Cheers,
> >>>>
> >>>>Charles
> >>>>
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Brian McCallister [mailto:mccallister@forthillcompany.com]
> >>>>>Sent: 06 August 2004 17:22
> >>>>>To: OJB Developers List
> >>>>>Subject: Re: [VOTE] Release OJB 1.0.1
> >>>>>
> >>>>>
> >>>>>
> >>>>>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
> >>>>>
> >>>>>
> >>>>
> > 
> > 
> > ___________________________________________________________
> > HPD Software Ltd. - Helping Business Finance Business
> > Email terms and conditions: www.hpdsoftware.com/disclaimer 
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > 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 


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