You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Nick Johnson (JIRA)" <ji...@apache.org> on 2007/11/06 06:23:50 UTC
[jira] Created: (OPENJPA-433) Timestamp rounded upon database
updating
Timestamp rounded upon database updating
----------------------------------------
Key: OPENJPA-433
URL: https://issues.apache.org/jira/browse/OPENJPA-433
Project: OpenJPA
Issue Type: Bug
Components: sql
Affects Versions: 1.0.0
Environment: Postgresql dictionary; unsure if others are affected
Reporter: Nick Johnson
Priority: Minor
When updating a Timestamp field, OpenJPA is rounding the time to the nearest hundredth of a second. For example, in this case I print the Timestamp to stdout just before committing the transaction. Note the difference between the printed time and the time given in the SQL:
New time is 2007-11-04 21:16:49.906
4593 tally_ho TRACE [main] openjpa.jdbc.SQL - <t 1205211, conn 6232809> executing prepstmnt 8529229 UPDATE Article SET create_date = ? WHERE object_id = ? [params=(Timestamp) 2007-11-04 21:16:49.91, (long) 1]
This is actually causing a unit test of mine (one which checks that the create_date field updates correctly) to fail. It's fairly easy to kludge around for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-433) Timestamp rounded upon database
updating
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey closed OPENJPA-433.
-----------------------------------
Resolution: Invalid
This is actually intentional, and can be controlled via the DatePrecision DBDictionary setting:
<!-- sets the date precision to milliseconds. Value is in nanos. -->
<property name="openjpa.jdbc.DBDictionary" value="DatePrecision=1000000"/>
You might be able to use the static constants in the DBDictionary class in the property value:
<property name="openjpa.jdbc.DBDictionary" value="DatePrecision=MILLI"/>
OpenJPA does this so that if you load the same record from the DB twice and print out the timestamp field, you get the same values even if the DB does not have sufficient precision to represent the full range. In other words, by setting the low bits all to zero, OpenJPA ensures that only the valid data is available.
> Timestamp rounded upon database updating
> ----------------------------------------
>
> Key: OPENJPA-433
> URL: https://issues.apache.org/jira/browse/OPENJPA-433
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
> Affects Versions: 1.0.0
> Environment: Postgresql dictionary; unsure if others are affected
> Reporter: Nick Johnson
> Priority: Minor
>
> When updating a Timestamp field, OpenJPA is rounding the time to the nearest hundredth of a second. For example, in this case I print the Timestamp to stdout just before committing the transaction. Note the difference between the printed time and the time given in the SQL:
> New time is 2007-11-04 21:16:49.906
> 4593 tally_ho TRACE [main] openjpa.jdbc.SQL - <t 1205211, conn 6232809> executing prepstmnt 8529229 UPDATE Article SET create_date = ? WHERE object_id = ? [params=(Timestamp) 2007-11-04 21:16:49.91, (long) 1]
> This is actually causing a unit test of mine (one which checks that the create_date field updates correctly) to fail. It's fairly easy to kludge around for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-433) Timestamp rounded upon database
updating
Posted by "Albert Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653367#action_12653367 ]
Albert Lee commented on OPENJPA-433:
------------------------------------
I don't think the configuration framework be smart enough to recognize the DBDictionary's static symbollic constants as the property value.
"datePricision" is of type int. One can use int, Integer or String type value to set this dictionary attribute.
Albert Lee.
> Timestamp rounded upon database updating
> ----------------------------------------
>
> Key: OPENJPA-433
> URL: https://issues.apache.org/jira/browse/OPENJPA-433
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
> Affects Versions: 1.0.0
> Environment: Postgresql dictionary; unsure if others are affected
> Reporter: Nick Johnson
> Priority: Minor
>
> When updating a Timestamp field, OpenJPA is rounding the time to the nearest hundredth of a second. For example, in this case I print the Timestamp to stdout just before committing the transaction. Note the difference between the printed time and the time given in the SQL:
> New time is 2007-11-04 21:16:49.906
> 4593 tally_ho TRACE [main] openjpa.jdbc.SQL - <t 1205211, conn 6232809> executing prepstmnt 8529229 UPDATE Article SET create_date = ? WHERE object_id = ? [params=(Timestamp) 2007-11-04 21:16:49.91, (long) 1]
> This is actually causing a unit test of mine (one which checks that the create_date field updates correctly) to fail. It's fairly easy to kludge around for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-433) Timestamp rounded upon database
updating
Posted by "Michal Borowiecki (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653331#action_12653331 ]
Michal Borowiecki commented on OPENJPA-433:
-------------------------------------------
<property name="openjpa.jdbc.DBDictionary" value="DatePrecision=1000000"/> works but
<property name="openjpa.jdbc.DBDictionary" value="DatePrecision=MILLI"/> results in exception:
[INFO] 15:53:11,296 ERROR [OpenEJB] The bean instance business method encountered a system exception: org.apache.openjpa.jdbc.sql.PostgresDictionary@77d241.DatePrecision = MILLI
[INFO] <openjpa-1.0.3-r420667:677674 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: org.apache.openjpa.jdbc.sql.PostgresDictionary@77d241.DatePrecision = MILLI
[INFO] at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:207)
[INFO] at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:142)
[INFO] at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:192)
[INFO] at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:56)
[INFO] at org.apache.geronimo.persistence.CMPEntityManagerTxScoped.createEntityManager(CMPEntityManagerTxScoped.java:74)
[INFO] at org.apache.geronimo.persistence.CMPEntityManagerTxScoped.getEntityManager(CMPEntityManagerTxScoped.java:55)
[INFO] at org.apache.geronimo.persistence.CMPEntityManagerTxScoped.getDelegate(CMPEntityManagerTxScoped.java:315)
[INFO] at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.registerListener(JpaCmpEngine.java:124)
[INFO] at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.getEntityManager(JpaCmpEngine.java:107)
[INFO] at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.createBean(JpaCmpEngine.java:136)
[INFO] at org.apache.openejb.core.cmp.CmpContainer.createEJBObject(CmpContainer.java:605)
[INFO] at org.apache.openejb.core.cmp.CmpContainer.invoke(CmpContainer.java:250)
[INFO] at org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:267)
[INFO] at org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:158)
[INFO] at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321)
[INFO] at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
[INFO] at $Proxy45.create(Unknown Source)
[INFO] at pl.bluemedia.ds.finance.invoice.payment.ejb.session.impl.AccountHelper.create(AccountHelper.java:43)
[INFO] at pl.bluemedia.ds.finance.invoice.payment.ejb.session.impl.InvoicePaymentProcessorBean.registerCustomerAccount(InvoicePaymentProcessorBean.java:65)
[INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO] at java.lang.reflect.Method.invoke(Method.java:597)
[INFO] at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:158)
[INFO] at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:141)
[INFO] at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67)
[INFO] at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210)
[INFO] at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188)
[INFO] at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
[INFO] at org.apache.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:238)
[INFO] at org.apache.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:129)
[INFO] at org.apache.openejb.server.ejbd.EjbDaemon.processEjbRequest(EjbDaemon.java:164)
[INFO] at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:122)
[INFO] at org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
[INFO] at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
[INFO] at org.apache.openejb.server.ServicePool$2.run(ServicePool.java:78)
[INFO] at org.apache.openejb.server.ServicePool$3.run(ServicePool.java:101)
[INFO] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
[INFO] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
[INFO] at java.lang.Thread.run(Thread.java:619)
[INFO] Caused by: org.apache.openjpa.lib.util.ParseException: org.apache.openjpa.jdbc.sql.PostgresDictionary@77d241.DatePrecision = MILLI
[INFO] at org.apache.openjpa.lib.util.Options.setInto(Options.java:237)
[INFO] at org.apache.openjpa.lib.util.Options.setInto(Options.java:190)
[INFO] at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:447)
[INFO] at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:401)
[INFO] at org.apache.openjpa.jdbc.sql.DBDictionaryFactory.newDBDictionary(DBDictionaryFactory.java:155)
[INFO] at org.apache.openjpa.jdbc.sql.DBDictionaryFactory.newDBDictionary(DBDictionaryFactory.java:99)
[INFO] at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance(JDBCConfigurationImpl.java:569)
[INFO] at org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration(MappingRepository.java:1221)
[INFO] at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:476)
[INFO] at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:401)
[INFO] at org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java:102)
[INFO] at org.apache.openjpa.lib.conf.ObjectValue.instantiate(ObjectValue.java:82)
[INFO] at org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:861)
[INFO] at org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:852)
[INFO] at org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:640)
[INFO] at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:171)
[INFO] ... 39 more
[INFO] Caused by: java.lang.reflect.InvocationTargetException
[INFO] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[INFO] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[INFO] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[INFO] at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
[INFO] at org.apache.openjpa.lib.util.Options.stringToObject(Options.java:440)
[INFO] at org.apache.openjpa.lib.util.Options.stringToObject(Options.java:431)
[INFO] at org.apache.openjpa.lib.util.Options.setInto(Options.java:229)
[INFO] ... 54 more
[INFO] Caused by: java.lang.NumberFormatException: For input string: "MILLI"
[INFO] at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
[INFO] at java.lang.Integer.parseInt(Integer.java:447)
[INFO] at java.lang.Integer.<init>(Integer.java:620)
[INFO] ... 61 more
> Timestamp rounded upon database updating
> ----------------------------------------
>
> Key: OPENJPA-433
> URL: https://issues.apache.org/jira/browse/OPENJPA-433
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
> Affects Versions: 1.0.0
> Environment: Postgresql dictionary; unsure if others are affected
> Reporter: Nick Johnson
> Priority: Minor
>
> When updating a Timestamp field, OpenJPA is rounding the time to the nearest hundredth of a second. For example, in this case I print the Timestamp to stdout just before committing the transaction. Note the difference between the printed time and the time given in the SQL:
> New time is 2007-11-04 21:16:49.906
> 4593 tally_ho TRACE [main] openjpa.jdbc.SQL - <t 1205211, conn 6232809> executing prepstmnt 8529229 UPDATE Article SET create_date = ? WHERE object_id = ? [params=(Timestamp) 2007-11-04 21:16:49.91, (long) 1]
> This is actually causing a unit test of mine (one which checks that the create_date field updates correctly) to fail. It's fairly easy to kludge around for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.