openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C N Davies" <...@cndavies.com>
Subject RE: equals, hashcode, toString, etc, and field access
Date Mon, 31 May 2010 06:01:23 GMT
I think where a member is to be lazy loaded this can be achieved is the EMF is smart enough.
 As a basic outline, the enhancement of an entity includes a mechanism to handle the remote
calls of lazily loaded members. If I locally access a member that is lazily loaded, the enhancement
them initiates the remote call.

I think a remote interface is the way to go, it will allow for a multi-vm lazy loading, the
structure of which could later be determined. One could argue that in this case we haven't
gained much over EJB 2.0, but that is my basic point in the first place:) 

Chris


-----Original Message-----
From: Trenton D. Adams [mailto:trent@trentonadams.ca] 
Sent: Monday, 31 May 2010 2:37 PM
To: cnd@cndavies.com
Cc: Trenton D. Adams; users@openjpa.apache.org
Subject: Re: equals, hashcode, toString, etc, and field access

Okay, some thoughts about your suggestion.

When the object gets returned by a method call, to be serialized across the network, how will
the entity manager be in control of that object anymore, to make sure the needed items are
lazily loaded?  I suppose it could implement the serializable methods, and load everything
when they are called by the system.  But, if it did that, it may be loading more than what
is really needed.  Say I have a student object that holds all the information about the student,
including courses, demographics, grades, etc.  Wouldn't that be a bit heavy on the network
link?

Unless we can answer a question like that, I would rather see, at least in terms of EJB, a
remote-able entity.

Perhaps one solution could be to pass the system a map (not java.util.Map necessarily) of
what part of the object needs to be fully loaded before being serialized across the network
link?

Anyhow, your suggestion would totally work in a single VM, where you use enhancement.

----- "C N Davies" <cnd@cndavies.com> wrote:

> From: "C N Davies" <cnd@cndavies.com>
> To: "Trenton D. Adams" <trent@trentonadams.ca>, users@openjpa.apache.org
> Sent: Sunday, May 30, 2010 11:22:18 PM GMT -07:00 US/Canada Mountain
> Subject: RE: equals, hashcode, toString, etc, and field access
>
> EntityManagerFactory.
> 
> 
> -----Original Message-----
> From: Trenton D. Adams [mailto:trent@trentonadams.ca] 
> Sent: Monday, 31 May 2010 2:19 PM
> To: users@openjpa.apache.org; cnd@cndavies.com
> Subject: Re: equals, hashcode, toString, etc, and field access
> 
> EMF?
> ElectorMagnetic Field?
> English Musical Festival?
> Educational Media Foundation?
> Energy Modeling Forum?
> Eclipse Modeling Framework?
> 
> Google wasn't helpful. lol
> 
> ----- "C N Davies" <cnd@cndavies.com> wrote:
> 
> > From: "C N Davies" <cnd@cndavies.com>
> > To: users@openjpa.apache.org
> > 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:craig.russell@oracle.com] 
> > Sent: Sunday, 30 May 2010 5:12 PM
> > To: users@openjpa.apache.org
> > 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:daryl.stultz@opentempo.com]
> > > Sent: Friday, 28 May 2010 10:23 PM
> > > To: users@openjpa.apache.org
> > > Subject: Re: equals, hashcode, toString, etc, and field access
> > >
> > > On Thu, May 27, 2010 at 8:49 PM, Trenton D. Adams
> > > <trent@trentonadams.ca>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:daryl.stultz@opentempo.com
> > >
> > 
> > Craig L Russell
> > Architect, Oracle
> > http://db.apache.org/jdo
> > 408 276-5638 mailto:Craig.Russell@oracle.com
> > P.S. A good JDO? O, Gasp!


Mime
View raw message