Re: Object (Timestamp) entity fields not persisted when changed internally
No I do not.
--Gordon
Marina Vatkina wrote:
> Do you expect the spec to change in requirements for support of
> mutable types?
>
> thanks,
> -marina
>
> Gordon Yorke wrote:
>> The problem here is that this bug was fixed for the Java Util types
>> and not for java.sql types.
>> Also the patch that was put in Glassfish was not merged back into
>> TopLink and therefor will not be in V3 (EclipseLink)
>> --Gordon
>>
>> Marina Vatkina wrote:
>>
>>> Gordon,
>>>
>>> Is it a regression?
>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=1637 had been
>>> fixed a long time ago (as mentioned there, spec says in 3.2.3
>>> Synchronization to the Database:
>>>
>>> An update to the state of an entity includes both the assignment of
>>> a new value to a persistent property or field of the entity as well
>>> as the modification of a mutable value of a persistent property or
>>> field.
>>>
>>> thanks,
>>> -marina
>>>
>>> Gordon Yorke wrote:
>>>
>>>> This has nothing to do with caching. The Timestamp is treated as
>>>> immutable by the change detection code so without changing the
>>>> timestamp instance no change is detected. In V3 (EclipseLink)
>>>> there is a @Mutable annotation to cover the case where your code
>>>> needs to change the internal values.
>>>> --Gordon
>>>>
>>>> Eric Amy wrote:
>>>>
>>>>> The previous posts that I can find regarding this always recommend
>>>>> turning off caching. This would be a functional work-around if the
>>>>> issue is caused by what I initially thought of when I encountered
>>>>> the behavior. I'll now describe the behavior and my guess at the
>>>>> bug. Feel free to tell me I'm over-simplifying it.
>>>>>
>>>>> Using Glassfish v2ur2:
>>>>> Create an @Entity that contains a column field of type
>>>>> java.sql.Timestamp. Persist the entity; then change the
>>>>> timestamp's value by calling setTime(long). After merging and
>>>>> subsequent flushing, the new value is not persisted to the
>>>>> database. The easiest work-around is to construct a new Timestamp
>>>>> rather than using the setter. This makes the new value persist on
>>>>> the first flush.
>>>>>
>>>>> What I imagine could be happening is this: at some point in the
>>>>> caching algorithms, it would be assumed that the entity fields are
>>>>> primitives (or at least passed by value). So the scenario, where
>>>>> (timestamp_old == timestamp_new) is true but
>>>>> (timestamp_old.equals(timestamp_new)) is false, is over-looked.
>>>>>
>>>>> I realize that what I described is a very simple mistake, and I
>>>>> already have a work-around, but I'd still like to know what's
>>>>> going on 'under the hood' to cause this if I'm wrong. :)
>>>>
>>>>
>>>>
>>>
>