Re: [eclipselink-users] Specification interpretation question

[christopher delahunt <christopher.delahunt@xxxxxxxxxx>]

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
>