[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Specification interpretation question
|
Hello Laird,
Merge merges the state into the managed object - in this case a new
object into a new object it has to create. Nothing exists on the
database, so there is no point in putting in indirection into the new
managed object's relationship; the relationship is null as the foreign
key value at this point is null. Until the object gets inserted, the
relationship mapping has no way of knowing that the e1ID value is going
into the databasefield that it is going to use for the foreign key. So,
if indirection were put in instead of null, it would perform a query
using null as the foreign key anyway.
You can flush and then refresh the entity to have the relationship
populated in the transaction is the only way to do it without explicitly
performing a find for e1.
Best Regards,
Chris
Laird Nelson wrote:
On Tue, Aug 18, 2009 at 3:10 PM, christopher delahunt
<christopher.delahunt@xxxxxxxxxx
<mailto:christopher.delahunt@xxxxxxxxxx>> wrote:
No, lazy loading is done when reading from the database, not
creating new objects.
Even after a merge() that results in a managed object? How come?
Well, at any rate, so in this case I could force it within a
transaction by doing a flush()?
What I'm looking to do is this: E2 is "in the middle" of an object
graph that is simply too big and hairy to expect the caller to have in
hand when he calls my EJB that Does Things with E2. I can't really
expect him to supply me with a graph all fleshed out--he's going to
give me an E2 with an "x" field set. Then, in my EJB, I need to
actually get the E1 to which the "x" refers, and use it to determine
some other processing logic.
Now E2, as in my example, has an "x" field that is the "code" if you
like that stands in for E1.
I was hoping there was an easy spec-compliant way, involving
lazy-loading, merge() and insertable/updatable = false, to make it so
that if all I have is the "code"--the "x" value--I could simply invoke
the relationship accessor--getE1()--and have the relationship
traversal machinery load up the corresponding E1 for me. Obviously I
can go get it by hand--I can take the "x", load up the E1, and set it
on my E2 instance, taking great care to validate that the E1 I'm
setting does indeed have an "x" that matches my E2's "x"--but that is
all boilerplate that I was hoping to avoid.
Best,
Laird
------------------------------------------------------------------------
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
