[ 
https://issues.apache.org/jira/browse/OPENJPA-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Hardy updated OPENJPA-971:
-------------------------------

    Description: 
I have what looks like a bug in time handling, that probably stems from the 
database Dictionaries. My testing shows it occurs with MySQL and Derby, but not 
for PostgreSQL, H2 or Hypersonic (using latest GA versions of Java, OpenJPA & 
JDBC drivers).

If I save an entity with this set-up, I see incorrect handling of dates:

class MyEntity
{
    ...
    private java.util.Date opening;
    ...
}

and:

<entity>
    <attributes>
      <basic name="opening">
        <column name="OPENING"/>
        <temporal>TIME</temporal>
      </basic>
      ...

and:

create table MY_ENTITY (
    ...
    OPENING time not null,
    ...

In my test I assign a new value to 'opening', save the entity and retrieve it 
from the database again. Then I compare the date on the retrieved entity 
against the value originally assigned, and I get this result:

with Derby: original Calendar.HOUR_OF_DAY == 9, retrieved value = 10

(probably due to timezone offset handling)

with MySQL: original Calendar.YEAR == 1970, retrieved value = 1969

With MySQL it could be declared irrelevant since the value comes from a Time 
database type and the Java comparisons should blank out or ignore non-time Date 
values. However the MySQLDictionary refuses to read in Times in the HH:MM:SS 
format when zero 00:00:00 - it causes the following exception:


<openjpa-1.2.0-r422266:683325 nonfatal general error> 
org.apache.openjpa.persistence.PersistenceException: Cannot convert value 
'00:00:00' from column 9 to TIMESTAMP.
        at 
org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4238)
        at 
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4203)
        at 
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
        at 
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88)
        at 
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
        at 
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:282)
        at 
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
        at 
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
        at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
        at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
        at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
        at 
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:917)
        at 
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:278)
        at 
org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2391)
        at 
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:272)
        at 
org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObject(InstanceResultObjectProvider.java:59)
        at org.apache.openjpa.kernel.QueryImpl.singleResult(QueryImpl.java:1294)
        at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1221)
        at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
        at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
        at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:775)
        at 
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:533)
        at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:251)
        at 
org.apache.openjpa.persistence.QueryImpl.getSingleResult(QueryImpl.java:316)


  was:
I have what looks like a bug in time handling, that probably stems from the 
database Dictionaries. My testing shows it occurs with MySQL and Derby, but not 
for PostgreSQL, H2 or Hypersonic (using latest GA versions of Java, OpenJPA & 
JDBC drivers).

If I save an entity with this set-up, I see incorrect handling of dates:

class MyEntity
{
    ...
    private java.util.Date opening;
    ...
}

and:

<entity>
    <attributes>
      <basic name="opening">
        <column name="OPENING"/>
        <temporal>TIME</temporal>
      </basic>
      ...

and:

create table MY_ENTITY (
    ...
    OPENING time not null,
    ...

In my test I assign a new value to 'opening', save the entity and retrieve it 
from the database again. Then I compare the date on the retrieved entity 
against the value originally assigned, and I get this result:

with Derby: original Calendar.HOUR_OF_DAY == 9, retrieved value = 10

(probably due to Daylight Saving Time handling)

with MySQL: original Calendar.YEAR == 1970, retrieved value = 1969

With MySQL it could be declared irrelevant since the value comes from a Time 
database type and the Java comparisons should blank out or ignore non-time Date 
values. However the MySQLDictionary refuses to read in Times in the HH:MM:SS 
format when zero 00:00:00 - it causes the following exception:


<openjpa-1.2.0-r422266:683325 nonfatal general error> 
org.apache.openjpa.persistence.PersistenceException: Cannot convert value 
'00:00:00' from column 9 to TIMESTAMP.
        at 
org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4238)
        at 
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4203)
        at 
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
        at 
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88)
        at 
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
        at 
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:282)
        at 
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
        at 
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
        at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
        at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
        at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
        at 
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:917)
        at 
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:278)
        at 
org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2391)
        at 
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:272)
        at 
org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObject(InstanceResultObjectProvider.java:59)
        at org.apache.openjpa.kernel.QueryImpl.singleResult(QueryImpl.java:1294)
        at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1221)
        at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
        at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
        at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:775)
        at 
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:533)
        at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:251)
        at 
org.apache.openjpa.persistence.QueryImpl.getSingleResult(QueryImpl.java:316)



> Time handling in Dates
> ----------------------
>
>                 Key: OPENJPA-971
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-971
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 1.2.0
>         Environment: Linux
> Java 1.6.0_12
> MySQL, Hypersonic
>            Reporter: Adam Hardy
>
> I have what looks like a bug in time handling, that probably stems from the 
> database Dictionaries. My testing shows it occurs with MySQL and Derby, but 
> not for PostgreSQL, H2 or Hypersonic (using latest GA versions of Java, 
> OpenJPA & JDBC drivers).
> If I save an entity with this set-up, I see incorrect handling of dates:
> class MyEntity
> {
>     ...
>     private java.util.Date opening;
>     ...
> }
> and:
> <entity>
>     <attributes>
>       <basic name="opening">
>         <column name="OPENING"/>
>         <temporal>TIME</temporal>
>       </basic>
>       ...
> and:
> create table MY_ENTITY (
>     ...
>     OPENING time not null,
>     ...
> In my test I assign a new value to 'opening', save the entity and retrieve it 
> from the database again. Then I compare the date on the retrieved entity 
> against the value originally assigned, and I get this result:
> with Derby: original Calendar.HOUR_OF_DAY == 9, retrieved value = 10
> (probably due to timezone offset handling)
> with MySQL: original Calendar.YEAR == 1970, retrieved value = 1969
> With MySQL it could be declared irrelevant since the value comes from a Time 
> database type and the Java comparisons should blank out or ignore non-time 
> Date values. However the MySQLDictionary refuses to read in Times in the 
> HH:MM:SS format when zero 00:00:00 - it causes the following exception:
> <openjpa-1.2.0-r422266:683325 nonfatal general error> 
> org.apache.openjpa.persistence.PersistenceException: Cannot convert value 
> '00:00:00' from column 9 to TIMESTAMP.
>       at 
> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4238)
>       at 
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4203)
>       at 
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
>       at 
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88)
>       at 
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
>       at 
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:282)
>       at 
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
>       at 
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
>       at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
>       at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
>       at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
>       at 
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:917)
>       at 
> org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:278)
>       at 
> org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2391)
>       at 
> org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:272)
>       at 
> org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObject(InstanceResultObjectProvider.java:59)
>       at org.apache.openjpa.kernel.QueryImpl.singleResult(QueryImpl.java:1294)
>       at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1221)
>       at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
>       at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
>       at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:775)
>       at 
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:533)
>       at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:251)
>       at 
> org.apache.openjpa.persistence.QueryImpl.getSingleResult(QueryImpl.java:316)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to