Jon, you are right that we (aka developers) are quite busy, but that does not excuse us from replying to your questions.
Having said that, and having read below findings, can I please ask you to a) create a bug report at http://bugzilla.exolab.org with a detailed description. b) attach the following information.: - a (JUnit) test case that I can use to see and experience the problem myself. - a mapping file. - some Java (entity) classes. - information about the RDBMS you are using. - DDL for the tables used. And above all, please try to be as minimal as possible when submitting your code. Iow, throw out everything that is not required to run the tests and show the problem. Regards Werner On Fri, 4 Jun 2004 09:24:35 -0700 (PDT), Jon Wilmoth wrote: > >I changed a local copy of >ClassMolder.getIdentity(TransactionContext tx, Object >o) to always return the value of >getActualIdentity(TransactionContext tx, Object o) to >try and see what the comment about a "dummy identity" >being returned the case where key generator is used, >was about and I don't see any "fake" values being >returned. What I do see is my original problem is >fixed! > >Original Problem: >Unable to create objects (in a long trxn context) that >have existing mapped object(s) as properties because >the ClassMolder.getIdentity(TransactionContext tx, >Object o) method returns null for objects that are key >generated and either not read-only or persistent. For >example: > >One txn retrieves an existing object >Long existingId = ...; >MyObject existing = Database.load(MyObject.class, >existingId); > >A subsequent txn uses the previously loaded, >non-persistent object to create a new object >MyComplexObject newComplex = new MyComplexObject(); >newComplex.setMyObject(existing); >Database.create(newComplex); > >I realize the project developers are busy, but this >seems like a core issue and I'm hoping someone has >some feedback to help debunk/resolve this "issue". > >Jon > >--- Jon Wilmoth <[EMAIL PROTECTED]> wrote: >> >> I've been working around the area effected by this >> issue, but thought I'd try to get some more >> info/spawn >> some more thought on this topic. There's a comment >> in >> the ClassMolder.getIdentity(TransactionContext, >> Object) method code that says: "In the case where >> key >> generator is used, the value of identity is dummy, >> set >> it to null". Wouldn't this statement be limited to >> objects being newly created? The problem that I see >> is that it doesn't allow for accessing the identity >> of >> an existing object in a long transaction (i.e. where >> the existing object hasn't been marked persistent. >> >> The workaround I'm considering is to load the castor >> mapped objects prior to calling Database.create on >> the >> object that has these objects as field members in >> order to have the create method correctly get their >> identities. This seeems like a terribly inefficient >> solution (I'm introducing 3 unnecessary db queries) >> for one save operation. Are there other >> alternatives? >> >> Thanks, >> Jon >> >> >> >> >----------------------------------------------------------- >> >> If you wish to unsubscribe from this mailing, send >> mail to >> [EMAIL PROTECTED] with a subject of: >> unsubscribe castor-dev > > > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
