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


Mime
View raw message