Oscar,
Your not missing anything. The point of asking the community is to
solve a perceived problem through dialogue and discussion. So 2. below
is a non-issue - null or not null - whatever is in the DB will be loaded
into the object. When the object is not previously persisted was the
issue i.e. 1 below.
Your suggestion is quite interesting and appears to build on what Egon
suggested except that to get around JPA not invoking getters your
suggesting to ensure that the getters of all these lazy initialize
methods are invoked in a method marked as @PrePersist and @PreUpdate.
Funny I had tried this but found that it resulted in some things that
didn't appear too savory... (at least before).
I once again I very much like the encapsulated aspects of this
solution. It's unfortunate though that the initialization has to be
considered in 2 places i.e. for each attribute to initialize... once in
the getter... and then again to ensure the getter is called in the
@PrePersist and @PreUpdate method. Also if you have a subclass
heirarchy you will need to ensure that the @PrePersist and @PreUpdate
methods also call super.preSave() (or whatever the method was called) as
JPA at least when implemented with Hibernate appears to not call the
same method annotated with @PrePersist and @PreUpdate in a super class
(haven't tested if naming the methods differently would make them all
get called in the heirarchy).
In the end, the @PrePersist and @PreUpdate method looks a lot like the
initializeInternal method I came up with - were I statically assign a
value your solution would invoke a getter - except with more code due to
dual initialize points though on the other hand it eliminates the need
for external stimulation and an internal variable to avoid repeat
initialization.
So you aren't missing anything... this solution, Egon's and even the one
I proposed pretty solve the problem in a very similar manner. Though
from an OO perspective I think I prefer what you / Egon suggest and will
run with that.
Thanks again for the dialog to all... and I hope this discussion helps
others who face this in their projects... .
--Nikolaos
Oscar Westra van Holthe - Kind wrote:
On 06-07-2010 at 12:29, Nikolaos Giannopoulos wrote:
Unfortunately it won't work. I didn't know this previously but
discovered that JPA by default obtains the data from the Entity
objects via reflection NOT via its getters. What this means is that
when the object is being persisted the getters are never called.
Apparently the access type can be controlled in hibernate / JPA to
use field or property access but the default is field and it is
recommended for a number of reasons.
The way I see it, there are two possibilities:
1. The object is not persisted, meaning the property is initialized to null
and the getter can lazily initialize it. A @PrePersist and a @PreUpdate
event handler simply call the getter to ensure there is a value prior to
persisting/updating it (the latter only if it can be set to null).
2. The object is persisted, meaning the property has a value (due to the
@PrePersist event handler). In that case the field will be initialized
correctly by the JPA provider, and the getter will recognize it only needs
to return the value.
Am I missing something here, why such a solution cannot work?
Oscar
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
