db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: [VOTE] Release OJB 1.0.1
Date Mon, 02 Aug 2004 19:59:22 GMT
hi charles,

Charles Anthony schrieb:
> 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.

ok, but you have to make the objects explicitely persistent (no persistence by 
reachability, and no auto-xxx settings)

     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);

this should also work if the objects are made persistent in the 'wrong' order ie:

     db.makePersistent(obj_1);
     db.makePersistent(obj_2);

     db.makePersistent(s_ref_1);
     db.makePersistent(s_ref_2);
     db.makePersistent(s_ref_3);
     db.makePersistent(s_ref_4);

actually the reorder has problems with it and tries to insert obj_1 first.

jakob
> 
> 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
> 
> 

---------------------------------------------------------------------
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