On Tue, Aug 18, 2009 at 3:10 PM, christopher delahunt
<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
