[jira] [Commented] (OPENJPA-2159) Add support for no rounding of Date

2012-04-30 Thread Heath Thomann (JIRA) 

[ 
https://issues.apache.org/jira/browse/OPENJPA-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13265043#comment-13265043
 ] 

Heath Thomann commented on OPENJPA-2159:


The code of this JIRA is enabled by a system property as follows:   
  



> Add support for no rounding of Date
> ---
>
> Key: OPENJPA-2159
> URL: https://issues.apache.org/jira/browse/OPENJPA-2159
> Project: OpenJPA
>  Issue Type: Improvement
>Affects Versions: 2.3.0, 2.2.1
>Reporter: Dianne Richards
>Assignee: Dianne Richards
>Priority: Minor
> Fix For: 2.3.0, 2.2.1
>
>
> A user does not like the fact the we round the Date field at milliseconds. 
> So, we're providing a dictionary option to not do that. The default will be 
> to round as we do today so as to not break anyone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OPENJPA-2180) OpenJPA build broken in java7 / jdk-1.7

2012-04-30 Thread Rick Curtis (JIRA) 

[ 
https://issues.apache.org/jira/browse/OPENJPA-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264972#comment-13264972
 ] 

Rick Curtis commented on OPENJPA-2180:
--

I haven't dug into this one, but I found if I change the annotation on 
org.apache.openjpa.persistence.datacache.common.apps.PObject.id from 
@GeneratedValue to @GeneratedValue(strategy=GenerationType.AUTO), the test 
passes.

> OpenJPA build broken in java7 / jdk-1.7
> ---
>
> Key: OPENJPA-2180
> URL: https://issues.apache.org/jira/browse/OPENJPA-2180
> Project: OpenJPA
>  Issue Type: Bug
>  Components: build / infrastructure
>Affects Versions: 2.2.0
> Environment: Fedora-16 x86_64; Java HotSpot 1.7.0_04
>Reporter: Mark Struberg
>Priority: Critical
> Fix For: 2.3.0
>
>
> Currently I get a test error when compiling OpenJPA with jdk 1.7
> Tests in error:
>   
> testDirtyRefreshWithoutDataCacheAlwaysHitsDatabase(org.apache.openjpa.persistence.datacache.TestDataCacheBehavesIdentical)
>   
> testCleanRefreshWithoutDataCacheDoesNotHitDatabase(org.apache.openjpa.persistence.datacache.TestDataCacheBehavesIdentical)
>   
> testDeleteIsDetectedOnCleanRefreshWithoutLockWithoutDataCache(org.apache.openjpa.persistence.datacache.TestDataCacheBehavesIdentical)
>   
> testDeleteIsDetectedOnCleanRefreshWithLockWithoutDataCache(org.apache.openjpa.persistence.datacache.TestDataCacheBehavesIdentical)
> Here is one of the detailed logs:
>classname="org.apache.openjpa.persistence.datacache.TestDataCacheBehavesIdentical"
>  name="testDirtyRefreshWithoutDataCacheAlwaysHitsDatabase">
>  type="  fatal store error> org.apache.openjpa.persistence.RollbackException: The 
> transaction has been rolled back.  See the nested exceptions for details on 
> the errors that occurred.
> FailedObject: 
> org.apache.openjpa.persistence.datacache.common.apps.PObject@3fc25500
> at 
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:594)
> at 
> org.apache.openjpa.persistence.datacache.TestDataCacheBehavesIdentical.verifyRefresh(TestDataCacheBehavesIdentical.java:320)
> at 
> org.apache.openjpa.persistence.datacache.TestDataCacheBehavesIdentical.testDirtyRefreshWithoutDataCacheAlwaysHitsDatabase(TestDataCacheBehavesIdentical.java:438)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at 
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runTest(AbstractPersistenceTestCase.java:579)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at 
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:566)
> at 
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.runBare(AbstractPersistenceTestCase.java:542)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at 
> org.apache.openjpa.persistence.test.AbstractPersistenceTestCase.run(AbstractPersistenceTestCase.java:206)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at sun.reflect.GeneratedMethodAccessor196.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
> at 
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
> at 
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInP

[jira] [Commented] (OPENJPA-2179) 'distinct' and 'join' combinations lead lots of unneccessary sub-queries for @Embedded and @Lob fields

2012-04-30 Thread Mark Struberg (JIRA) 

[ 
https://issues.apache.org/jira/browse/OPENJPA-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264937#comment-13264937
 ] 

Mark Struberg commented on OPENJPA-2179:


If I change the fields inside the @Embedded entity from @Lob to String, then 
all things work fine again. I'm currently digging into the 
MaxEmbeddedClobFieldStrategy. Any hints/ideas what could be going wrong? 

> 'distinct' and 'join' combinations lead lots of unneccessary sub-queries for 
> @Embedded and @Lob fields
> --
>
> Key: OPENJPA-2179
> URL: https://issues.apache.org/jira/browse/OPENJPA-2179
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 2.2.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 2.3.0
>
> Attachments: OPENJPA-2179-test-1.patch
>
>
> I have an Entity (Course) with a simple @Embedded field and a @Lob. I do not 
> use any LAZY attribution on them!
> If I do a normal em.find, the entity will be loaded as a whole (all the 
> fields, including the embedded and the lob will be fetched immediately).
> Sidenote: the Lecturer referred in the select is defined as
> @OneToMany(mappedBy = "course",
> cascade = {CascadeType.PERSIST, CascadeType.REMOVE, 
> CascadeType.MERGE},
> orphanRemoval = true, fetch = FetchType.EAGER)
> @OrderColumn(name = "POSITION")
> private List lecturers;
> The following selects DO work
> * "select c from Course c join c.lecturers l "
> * "select distinct c from Course c"
> The following selects create tons of subqueries! 1 separate sub-query for 
> each @Embedded field, and also for each @Lob
> * "select distinct c from Course c join c.lecturers l "
> * "select distinct c from Lecturer l join l.course c"
> * "select c from Lecturer l join l.course c" 
> This happens ONLY if I run this stuff against Oracle. In MySQL it seems to 
> work properly.
> I'll try to create a unit test for it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OPENJPA-2179) 'distinct' and 'join' combinations lead lots of unneccessary sub-queries for @Embedded and @Lob fields

2012-04-30 Thread Mark Struberg (JIRA) 

[ 
https://issues.apache.org/jira/browse/OPENJPA-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264718#comment-13264718
 ] 

Mark Struberg commented on OPENJPA-2179:


I've now committed a unit test which shows the problem. The new 
TestOracleDistinctJoin also contains a guide howto invoke this test on the 
commandline.

The test will give the following output (amonst others), where you can clearly 
see that SomeEmbeddable get's fetched via a separate SQL statement, even though 
there is no LAZY loading set on the Embedded field:

1348  test  TRACE  [main] openjpa.Query - Executing query: select c from 
Lecturer l join l.course c
1348  test  TRACE  [main] openjpa.jdbc.SQL -  
executing prepstmnt 960389670 SELECT t1.ID, t1.OPTLOCK, t1.COURSENUMBER, 
t1.NORMALATTRIBUTE FROM SMSGW.Lecturer t0, SMSGW.Course t1 WHERE t0.COURSE_ID = 
t1.ID
1350  test  TRACE  [main] openjpa.jdbc.SQL -  [2 
ms] spent
1350  test  TRACE  [main] openjpa.jdbc.SQLDiag - load: class 
org.apache.openjpa.jdbc.oracle.SomeEmbeddable oid: 2551
1350  test  TRACE  [main] openjpa.jdbc.SQL -  
executing prepstmnt 2034408626 SELECT t0.OBJECTIVEDE, t0.OBJECTIVEEN FROM 
SMSGW.Course t0 WHERE t0.ID = ? [params=?]
1351  test  TRACE  [main] openjpa.jdbc.SQL -  [1 
ms] spent
1354  test  TRACE  [main] openjpa.jdbc.SQLDiag - load: class 
org.apache.openjpa.jdbc.oracle.Course oid: 2551
1354  test  TRACE  [main] openjpa.jdbc.SQLDiag - Eager relations: 
[org.apache.openjpa.jdbc.oracle.Course.lecturers]
1354  test  TRACE  [main] openjpa.jdbc.SQL -  
executing prepstmnt 698114403 SELECT t0.LOBCOLUMN, t1.COURSE_ID, t1.POSITION, 
t1.ID, t1.OPTLOCK, t1.NAME FROM SMSGW.Course t0, SMSGW.Lecturer t1 WHERE t0.ID 
= ? AND t0.ID = t1.COURSE_ID(+) ORDER BY t1.COURSE_ID ASC, t1.POSITION ASC 
[params=?]
1355  test  TRACE  [main] openjpa.jdbc.SQL -  [1 
ms] spent

> 'distinct' and 'join' combinations lead lots of unneccessary sub-queries for 
> @Embedded and @Lob fields
> --
>
> Key: OPENJPA-2179
> URL: https://issues.apache.org/jira/browse/OPENJPA-2179
> Project: OpenJPA
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 2.2.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 2.3.0
>
> Attachments: OPENJPA-2179-test-1.patch
>
>
> I have an Entity (Course) with a simple @Embedded field and a @Lob. I do not 
> use any LAZY attribution on them!
> If I do a normal em.find, the entity will be loaded as a whole (all the 
> fields, including the embedded and the lob will be fetched immediately).
> Sidenote: the Lecturer referred in the select is defined as
> @OneToMany(mappedBy = "course",
> cascade = {CascadeType.PERSIST, CascadeType.REMOVE, 
> CascadeType.MERGE},
> orphanRemoval = true, fetch = FetchType.EAGER)
> @OrderColumn(name = "POSITION")
> private List lecturers;
> The following selects DO work
> * "select c from Course c join c.lecturers l "
> * "select distinct c from Course c"
> The following selects create tons of subqueries! 1 separate sub-query for 
> each @Embedded field, and also for each @Lob
> * "select distinct c from Course c join c.lecturers l "
> * "select distinct c from Lecturer l join l.course c"
> * "select c from Lecturer l join l.course c" 
> This happens ONLY if I run this stuff against Oracle. In MySQL it seems to 
> work properly.
> I'll try to create a unit test for it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira