Return-Path: Delivered-To: apmail-db-ojb-dev-archive@www.apache.org Received: (qmail 20764 invoked from network); 2 Aug 2004 19:59:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 2 Aug 2004 19:59:05 -0000 Received: (qmail 88052 invoked by uid 500); 2 Aug 2004 19:59:04 -0000 Delivered-To: apmail-db-ojb-dev-archive@db.apache.org Received: (qmail 87894 invoked by uid 500); 2 Aug 2004 19:59:03 -0000 Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "OJB Developers List" Reply-To: "OJB Developers List" Delivered-To: mailing list ojb-dev@db.apache.org Received: (qmail 87877 invoked by uid 99); 2 Aug 2004 19:59:03 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.27.1) with SMTP; Mon, 02 Aug 2004 12:59:01 -0700 Received: (qmail 23205 invoked by uid 65534); 2 Aug 2004 19:58:52 -0000 Received: from adsl-62-167-24-225.adslplus.ch (EHLO [192.168.1.10]) (62.167.24.225) by mail.gmx.net (mp009) with SMTP; 02 Aug 2004 21:58:52 +0200 X-Authenticated: #15507884 Message-ID: <410E9D1A.3050809@gmx.ch> Date: Mon, 02 Aug 2004 21:59:22 +0200 From: Jakob Braeuchi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7.1) Gecko/20040707 X-Accept-Language: de, en MIME-Version: 1.0 To: OJB Developers List Subject: Re: [VOTE] Release OJB 1.0.1 References: <6FB083FB72EFD21181D30004AC4CA18A04A0CFDD@SRV002> In-Reply-To: <6FB083FB72EFD21181D30004AC4CA18A04A0CFDD@SRV002> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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" 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