Re: [eclipselink-users] TemporalType.TIMESTAMP and Oracle DATE columns

[James Sutherland <jamesssss@xxxxxxxxx>]

You either need to null out the milliseconds in your date, or store your date
into a TIMESTAMP column that allows the milliseconds to be stored.

You could also use your own converter that automatically removes the
milliseconds from the date.

Since EclipseLink does not know if it is storing to a DATE or TIMESTAMP
column, it cannot clear the milliseconds.  You should only store DATE's in
Oracle DATE columns and use the  TemporalType.DATE not
TemporalType.TIMESTAMP, you should only use TemporalType.TIMESTAMP for
TIMESTAMP columns.

You could also refresh the object after the insert to reset its date to
match the database.

You could subclass your OraclePlatform to automatically clear millis, but
then you would not be able to use the TIMESTAMP type.


patric-7 wrote:
> 
> Hello everyone,
> 
> I am encountering the following situation: (tested using EclipseLink 
> 2.1.3)
> 
> 1. Consider an Oracle schema a table contains one column, defined as 
> type DATE
> 2. The corresponding entity maps this column as a java.util.Date, 
> annotated with TemporalType.TIMESTAMP
> 3. Within a transaction create a new instance of this entity, and set 
> the field of the column to new Date()
> 4. Persist it to the persistence context and commit the transaction
> 5. The (now detached) entity is merged back into the persistence 
> context using EntityManager.merge()
> 6. The transaction is commited again
> 
> Surprisingly, EclipseLink issues an UPDATE of this record to the 
> database although the entity
> has obviously not been changed between the first and the second commit.
> 
> After some debugging I realized that the cause of this is an 
> inconsistency in the granularity
> of the time component between the entity and its backup clone.
> The backup clone - which has been read from the database within the 
> merge() operation - does not contain milliseconds information,
> while the entity itself still contains the original Date object, 
> storing milliseconds.
> 
> I would expect that in case that eclipselink server session is running 
> on the oracle platform it should be able to detect
> that we have a DATE column here which is not capable of storing 
> millis/nanos and hence should not use these for change detection.
> 
> Is this behavior intended?
> 
> 
> Thank you and best regards,
> Patric
> 
> 


-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland 
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink 
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink , 
http://wiki.oracle.com/page/TopLink TopLink 
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , 
http://www.nabble.com/EclipseLink-f26430.html EclipseLink 
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence 
Blog:  http://java-persistence-performance.blogspot.com/ Java Persistence
Performance 
-- 
View this message in context: http://old.nabble.com/TemporalType.TIMESTAMP-and-Oracle-DATE-columns-tp32773065p32811447.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.