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!
