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