On Fri, Aug 14, 2009 at 12:56 PM, Michael Dick (via Nabble) < ml-user+17961-1519918...@n2.nabble.com<ml-user%2b17961-1519918...@n2.nabble.com> > 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-%3D-false-question-tp3439111p3446350.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
