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 Multiple Extents Issue (Was RE: [VOTE] Release OJB 1.0.1)
Date Sat, 07 Aug 2004 11:55:04 GMT
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


Mime
View raw message