Hi Laird, Have you tried em.getReference(MyEntity.class, id) ? That will return a lazily loaded entity and IIRC that lazily loaded state cascades through the object graph. This sounds like what you want to do, without the hassle of RW and RO fields.
If that doesn't work the way you want we can look into adding a feature to do the RW/RO field option.. Would you mind opening a JIRA? I can't promise a delivery date, but it's easier to find JIRA issues than old emails (at least for me).. -mike ljnelson wrote: > > On Fri, Aug 14, 2009 at 12:56 PM, Michael Dick (via Nabble) < > [email protected]<ml-user%[email protected]> >> wrote: > >> I haven't tested any of this out, but I'd guess that OpenJPA (and >> apparently >> other providers) have loaded your @ManyToOne relationship before you call >> the accessor method. > > > You know, that's an excellent point. I wonder. > > If the field was loaded by the provider there may be no reason to think > that >> >> it's dirty and we need to fetch it from the database (em.refresh will >> force >> >> a reload). > > > Here's the thing, though (continuing my earlier example running through > this > thread; see earlier messages for details). If I merge e2, with its "x" > field set, but not its e1 field, which, yes, is lazy, but is also > insertable > = false and updatable = false, then there is no circumstance that I can > think of where the e1 state SHOULDN'T be reloaded. > > Do you see what I mean? If I can't insert or update my e1 field, then why > wouldn't the provider be required, upon a merge, to load the e1 instance > from disk at merge time? > > >> It's possible that we could detect this case. Basically you have two >> fields >> >> (read-only and read-write) in an entity mapped to the same column. Once >> the >> RW field has been updated we could reset the isLoaded attribute on the >> other >> one - that should trigger a reload from the database when you call the >> accessor method. > > > Yeah, that's exactly what I'm looking for. I'm not looking for it as a > special case, but as (I think) the "right" way to interpret the spec. I'm > totally happy to be corrected on this--and the fact that all the providers > seem to NOT do this obviously makes me queasy. Surely, I thought, I must > be > missing something, but I can't find whatever it is that I'm missing. :-) > That is, this seems like it should be the required behavior. > > >> Are you doing this in many places throughout your app, or is this a >> one-off? > > > Well, I'm doing it lots of places. I don't have to, but it seemed to me > that forcing the relationship navigation machinery to load objects was > more > elegant than "brute forcing" the loads by using refresh() or find(). That > is, I can surely take in what amounts to a giant object graph (E2 and E1 > are > only parts of this giant hairball I have to work with) and break it apart > and perform EntityManager operations on all the component parts, but I'd > like to be able to force the JPA relationship navigation machinery to do > as > much of that for me as possible. > > The larger pattern here is that I'm mapping a legacy database that uses > lots > of multiple primary keys that are strings (lots of "codes"). So a given > object might be related to another object in the database by three VARCHAR > fields. > > Additionally, it is impractical for someone to build up an object graph of > the size that actually needs to be persisted. It's just too big. So > rather > than forcing someone to create a graph with, in this case, an E2 and an E1 > that they previously loaded, I want them to simply hand me an E2 with only > its "foreign keys" set--i.e. its "x" field in my example. Everything > else--the relationship, the instantiation of the related entity--is > derivable from that. I thought I had hit on a good pattern here, but it > kind of broke down when my reading of the spec. did. :-) > > Best, > Laird > > -- View this message in context: http://n2.nabble.com/insertable-updatable-false-question-tp3439111p3492355.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
