You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by "Trenton D. Adams" <tr...@trentonadams.ca> on 2010/05/28 02:49:26 UTC
equals, hashcode, toString, etc, and field access
Hi Guys,
The PCEnhancer complains about field access in some of these methods. Do I need to worry about those particular methods?
As an example...
"org.adamsbros.rmi.entities.TelephonePK" uses property access, but its field "entityId" is accessed directly in method "toString" defined in "org.adamsbros.rmi.entities.TelephonePK"
I mean I know if I'm doing lazy loading, toString won't get all the data, cause it hasn't been enhanced. That's basically what all the enhancement is for, right? But, I don't think I care, do I?
Can I disable the analysis for certain methods?
Thanks.
Re: equals, hashcode, toString, etc, and field access
Posted by Craig L Russell <cr...@oracle.com>.
If you're using property access, then you should never access the
fields directly except for getters and setters. It can cause wrong
results.
If you know that the property is always loaded (identity fields are
always loaded into instances), then you don't have to worry about the
messages.
Craig
On May 27, 2010, at 5:49 PM, Trenton D. Adams wrote:
> Hi Guys,
>
> The PCEnhancer complains about field access in some of these
> methods. Do I need to worry about those particular methods?
>
> As an example...
> "org.adamsbros.rmi.entities.TelephonePK" uses property access, but
> its field "entityId" is accessed directly in method "toString"
> defined in "org.adamsbros.rmi.entities.TelephonePK"
>
> I mean I know if I'm doing lazy loading, toString won't get all the
> data, cause it hasn't been enhanced. That's basically what all the
> enhancement is for, right? But, I don't think I care, do I?
>
> Can I disable the analysis for certain methods?
>
> Thanks.
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!
RE: equals, hashcode, toString, etc, and field access
Posted by C N Davies <cn...@cndavies.com>.
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" <cn...@cndavies.com> wrote:
> From: "C N Davies" <cn...@cndavies.com>
> To: "Trenton D. Adams" <tr...@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" <cn...@cndavies.com> wrote:
>
> > From: "C N Davies" <cn...@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
> > > <tr...@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!
Re: equals, hashcode, toString, etc, and field access
Posted by "Trenton D. Adams" <tr...@trentonadams.ca>.
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" <cn...@cndavies.com> wrote:
> From: "C N Davies" <cn...@cndavies.com>
> To: "Trenton D. Adams" <tr...@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" <cn...@cndavies.com> wrote:
>
> > From: "C N Davies" <cn...@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
> > > <tr...@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!
RE: equals, hashcode, toString, etc, and field access
Posted by C N Davies <cn...@cndavies.com>.
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" <cn...@cndavies.com> wrote:
> From: "C N Davies" <cn...@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
> > <tr...@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!
Re: equals, hashcode, toString, etc, and field access
Posted by "Trenton D. Adams" <tr...@trentonadams.ca>.
EMF?
ElectorMagnetic Field?
English Musical Festival?
Educational Media Foundation?
Energy Modeling Forum?
Eclipse Modeling Framework?
Google wasn't helpful. lol
----- "C N Davies" <cn...@cndavies.com> wrote:
> From: "C N Davies" <cn...@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
> > <tr...@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!
RE: equals, hashcode, toString, etc, and field access
Posted by C N Davies <cn...@cndavies.com>.
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
> <tr...@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!
Re: equals, hashcode, toString, etc, and field access
Posted by Craig L Russell <cr...@oracle.com>.
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
> <tr...@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!
Re: equals, hashcode, toString, etc, and field access
Posted by "Trenton D. Adams" <tr...@trentonadams.ca>.
----- "C N Davies" <cn...@cndavies.com> wrote:
> From: "C N Davies" <cn...@cndavies.com>
> To: users@openjpa.apache.org
> Sent: Friday, May 28, 2010 8:18:18 AM GMT -07:00 US/Canada Mountain
> Subject: RE: equals, hashcode, toString, etc, and field access
>
>
> Yet another reason to drag the JPA spec into the 20th century and do
> away
> with this whole attached / detached state business.
What are you proposing here? That it should be EAGER only? Or that it should be watching it the entire time? Or perhaps it should allow entities to be Stateful session beans, and load entirely on demand?
>
> 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
> <tr...@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
RE: equals, hashcode, toString, etc, and field access
Posted by C N Davies <cn...@cndavies.com>.
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
<tr...@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
Re: equals, hashcode, toString, etc, and field access
Posted by Daryl Stultz <da...@opentempo.com>.
On Thu, May 27, 2010 at 8:49 PM, Trenton D. Adams <tr...@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