I've created a bugzilla bug report (http://bugzilla.exolab.org/show_bug.cgi?id=1653) and attached 6 files: Book/Author classes (w/MySQL ddl included), mapping docs, a db file and a JUnit test case demonstrating the issue. Because I've defined my fk column as not-null, the test case fails due to a SQL exception, but I added another assertion to demonstrate the problem if the FK column wasn't not-null constrained.
--- Werner Guttmann <[EMAIL PROTECTED]> wrote: > > 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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
