[hibernate-dev] Attribute converters and dirty checks

[Gunnar Morling]

2016-01-07 15:25 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> 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.

Sure, I agree to that.

Where do you see the overhead being added? If there is overhead in the
common case (I suppose from the fact that the current order allows to
abort before doing type conversion?) it's not worth doing.

>
> 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev