You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Charles Anthony <ch...@hpdsoftware.com> on 2004/08/07 13:55:04 UTC
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"
> <jb...@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
Re: Multiple Extents Issue (Was RE: [VOTE] Release OJB 1.0.1)
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi charles,
the class org.apache.ojb.broker.ObjectRepository$ABE is missing !
jakob
Charles Anthony schrieb:
> 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"
>>
>><jb...@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