EMF? ElectorMagnetic Field? English Musical Festival? Educational Media Foundation? Energy Modeling Forum? Eclipse Modeling Framework?
Google wasn't helpful. lol ----- "C N Davies" <[email protected]> wrote: > From: "C N Davies" <[email protected]> > To: [email protected] > Sent: Sunday, May 30, 2010 7:14:44 PM GMT -07:00 US/Canada Mountain > Subject: RE: equals, hashcode, toString, etc, and field access > > I know others share my feelings because many have articulated the very > same > thoughts to me on numerous occasions, the attached/dettached state > complicates the whole JPA process. Having worked with a couple of > commercial persistence APIs for a number of years, I don't really see > the > need for it. > > Why we have to open and close a entity service repeatedly doesn't make > any > sense to me, if we want back to using basic JDBC calls we'd just > open > connection or create a connection pool at application start and close > it at > exist. The actual connection management should be transparent to the > user > once the connection pool has been established. Instead we now have to > worry > about creating an entity manager and working out if the entity is > attached > or detached. If you take a look at the list archives you will see that > it is > a significant issue for many people. > > What I would envision is a static multithreaded EMF with no need for > an > entity manager that automatically manages attached and detached state, > you > still get lazy loading because the EMF is smart enough to lazy load > unless > the user accesses the lazy loaded field. The EMF would then persist or > merge > automatically depending on whether the entity is new or dirty. > Building > these smarts into the EMF would make things much easier especially for > new > users and frankly would make the code a whole lost tidier. > > Chris > > -----Original Message----- > From: Craig L Russell [mailto:[email protected]] > Sent: Sunday, 30 May 2010 5:12 PM > To: [email protected] > Subject: Re: equals, hashcode, toString, etc, and field access > > I'm interested in hearing what you would like to see with regard to > entities after the persistence context in which they were valid no > longer exists. > > Thanks, > > Craig > > On May 28, 2010, at 7:18 AM, C N Davies wrote: > > > Darryl is right, I fought with this one for some time then it dawned > > > upon me > > that I was dealing with a detached entity that had a lazy loaded > > field. The > > result of toString is like picking the lottery numbers.. pot luck! > > > Now do > > the same thing with runtime enhancement during development and > > deploy it > > with build time enhancement. > > > > Yet another reason to drag the JPA spec into the 20th century and do > > > away > > with this whole attached / detached state business. > > > > Chris > > > > > > > > -----Original Message----- > > From: Daryl Stultz [mailto:[email protected]] > > Sent: Friday, 28 May 2010 10:23 PM > > To: [email protected] > > Subject: Re: equals, hashcode, toString, etc, and field access > > > > On Thu, May 27, 2010 at 8:49 PM, Trenton D. Adams > > <[email protected]>wrote: > > > >> > >> I mean I know if I'm doing lazy loading, toString won't get all the > > >> data, > >> cause it hasn't been enhanced. > > > > > > Assuming the object is detached, yes. I believe the JPA spec does > not > > specify the behavior for attempted access of an unloaded property on > a > > detached entity. I believe OpenJPA returns null. This makes it very > > difficult to tell if an association is null or not loaded. I have > > configured > > OpenJPA to disallow access to unloaded properties of detached > > entities to > > avoid the confusion. This means a toString method like yours in my > > > project > > could crash. > > > > -- > > Daryl Stultz > > _____________________________________ > > 6 Degrees Software and Consulting, Inc. > > http://www.6degrees.com > > http://www.opentempo.com > > mailto:[email protected] > > > > Craig L Russell > Architect, Oracle > http://db.apache.org/jdo > 408 276-5638 mailto:[email protected] > P.S. A good JDO? O, Gasp!
