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
