Hi Mike,
Yeah, I haven't fully tested this, so I guess this change could introduce
other problems.
To answer your question regarding lazy initialization...
I mostly use lazy initialization, but during the process of copying model to
DTO, and back again, an initially null (lazy field) becomes in this case, an
empty collection, which OpenJPA sees as a dirty field.
For example:
TblFndmst has a Collection<TblScmpdt> tblScmpdts's. (@OneToMany)
TblFndmstDTO (GWT 1.4 friendly DTO) will have the exact same fields as
TblFndmst.
The getter method on TblFndmstDTO:
public Collection getTblScmpdts() {
if (tblScmpdts == null) {
tblScmpdts = new ArrayList();
}
return tblScmpdts;
}
So when the DTO comes into the service layer from the GWT frontend, I use
Dozer to copy DTO fields to a "new" TblFndmst entity, to be merged back into
the datastore.
So during this copy process, the model that was initially loaded with a null
value for tblScmpdts, now has an empty collection value, since the getter
method never returns a null value.
Can you run your unit tests with my change, and see if it breaks anything?
Without this change, I will need to rewrite my DTO's to not return empty
collections instead of null, which will probably break my frontend code in
some places.
Kind regards,
Enrico
Michael Dick wrote:
>
> Hi,
>
> Calling merge on a 'new' entity is one of the more error prone aspects of
> JPA. The patch you've proposed will resolve the issue in your scenario but
> it could introduce problems in other scenarios.
>
> The change you made deals with what assumptions OpenJPA can make when we
> find a field that is set to null in a 'new' entity.
>
> Currently if the field is null and we can assume that null fields were not
> loaded we ignore the field. With your change we would ignore such a field
> if
> the collection is empty or null (and we can assuming nulls were not
> loaded).
> Where this goes wrong is if the application intended to set the field to
> an
> empty collection (if I'm reading the code correctly it's a bit more
> complicated than that, but bear with me). There's room for improvement in
> the way we handle merging new instances and we might be able to do
> something
> similar to your patch, but I'd have to take a closer look before I can
> sign
> off on it.
>
> Instead of updating the OpenJPA code, have you tried using lazy
> initialization on the field (I'm assuming you initialize it to an empty
> collection).
>
> -mike
>
--
View this message in context:
http://n2.nabble.com/Non-dirty-entity-version-field-update-SUPER-URGENT%21%21%21-tp1120307p1141645.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
