Remember, I'm totally new to EJB and JPA, so my ideas might not be feasible.
Not sure what Darryl was thinking about when he wrote that, but it certainly might be interesting to allow the combination of a stateful session bean, and an entity bean. Perhaps it would essentially be implicitly created as an extended persistence context, if marked @Stateful and @Entity at the same time. This would work well for very large objects with lots of data. For example, I work for a university, and I work on the web system for the student information system. The system allows students to do course registrations, admission, change of program, change of demographics, etc, etc. It would be nice, to say the least, to have one large RemoteStudent entity/stateful session bean object, that gets entirely lazily loaded. That way, when they are doing a single thing, such as registering in a course, the system would only need to load the information needed at the time, on demand. But, that crosses the boundary of EJB and JPA now doesn't it! So, I don't even know if something like that is feasible. But, it would likely be an EJB feature, not a JPA one I suppose, whereby it automatically sets an extended persistence context and what not, as well as automatically marshals the returned entity (from another EJB) into a stateful bean, with the same persistence context as the EJB that grabbed the entity in the first place. Of course the EJB proxy would need to be changed as well, to "monitor" the object on the client side, for when it's modified, so that it can update the db. Or there could also be a feature where the developer is in control of when the save occurs. That way they can set the street, zip/postal, province/state, country, etc, and then save. As it stands, one could write their on RemoteStudent object, which simply retrieves and manages multiple entity objects. But it sure would be a lot nicer to have it done automagically. ----- "Craig L Russell" <[email protected]> wrote: > From: "Craig L Russell" <[email protected]> > To: [email protected] > Sent: Sunday, May 30, 2010 1:12:07 AM GMT -07:00 US/Canada Mountain > 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!
