Well first you ask for this as an "optimization", but this is not an
optimization... it is a change in expectation. In fact it is probably less
optimized (performant) to do what you ask. I'd personally hate to add
performance overhead to everybody for edge cases.
We've recently done some work and had some discussion on a similar
converter concern regarding state mutability. There, in fact, we did have
to add the performance overhead systemtically because we simply don't know
(usually) whether the value is mutable. Much of that discussion applies
here as well.
On Thu, Jan 7, 2016 at 7:16 AM Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi,
I have an entity with an attribute whose value is converted by means
of an attribute converter. The converter operations are not symmetric,
i.e. it's not guaranteed that
value.equals( convertToEntityAttribute( convertToDatabaseColumn( value
) ) )
is true.
Question 1: Is such converter valid, or is it a requirement that its
operations are symmetric?
If this converter is valid, then I am curious whether the following
optimization could be applied.
Currently, the dirty checking is based on equality comparison of the
attribute value. During persist a deep copy of the entity attribute
array is made, which does the forth-and-back conversion above. If the
converter isn't symmetric, this may yield a value which is different
from the one in the entity attribute.
Then at dirty check, the entity attribute is compared to that value
resulting from deep-copying, causing the property to be considered
dirty, although the value to be stored in the database actually is the
same. Subsequently, an UPDATE will be issued which contains the same
column value as the previous INSERT.
So, question 2: Would it be feasible to do the dirty check based on
the converted value?
Thanks,
--Gunnar
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev