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 Mon, 02 Aug 2004 07:21:21 GMT
Hi,

With ODMG, you *are* supposed to be able to lock, modify, delete and insert
objects with no knowledge of the underlying foreign key issues.

The ObjectEnvelopeTable class actually has code to re-order the insert,
update and delete statements (Well, the object envelopes encapsulating the
state of the objects, whether they are inserts/updates/deltes) - so maybe
I'm a little confused here.
Anyway, the ObjectEnvelopeTable sorted algorithm is not perfect - we do have
issues with foreign key exceptions. We have locally patched the class to
keep re-sorting the statements until no more changes occur (or a maximum
number of sorts occurs) which improves things, but is not ideal, more of a
sledgehammer-to-crack-a-nut  - which is why I haven't submitted a patch.

In our app, it is not possible to know in advance what objects are going to
be created/updated/deleted in what order (well, it *is* possible, but not
feasible or practical), and so we rely on OJB to sort it out for us. 

I hope Brians new graph-ordering stuff can be plugged into the ODMG; it
would make my life much easier !

Cheers,

Charles.

> -----Original Message-----
> From: Robert S. Sfeir [mailto:robert@codepuccino.com]
> Sent: 31 July 2004 12:54
> To: OJB Developers List
> Subject: Re: [VOTE] Release OJB 1.0.1
> 
> 
> 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
> 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 ;-)
> 
> 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
> 
> 


___________________________________________________________
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