[jira] Commented: (OPENJPA-123) Test framework should allow tests that are expected to fail to be checked in
[ https://issues.apache.org/jira/browse/OPENJPA-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469355 ] Patrick Linskey commented on OPENJPA-123: - OPENJPA-122 is an example of a test case that should have been commitable before the behavior was implemented. > Test framework should allow tests that are expected to fail to be checked in > > > Key: OPENJPA-123 > URL: https://issues.apache.org/jira/browse/OPENJPA-123 > Project: OpenJPA > Issue Type: Bug >Reporter: Patrick Linskey > > Often, tests are developed before solutions are implemented. It should be > possible for us to check in such tests to svn without causing the build to > fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-123) Test framework should allow tests that are expected to fail to be checked in
[ https://issues.apache.org/jira/browse/OPENJPA-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey updated OPENJPA-123: Priority: Major > Test framework should allow tests that are expected to fail to be checked in > > > Key: OPENJPA-123 > URL: https://issues.apache.org/jira/browse/OPENJPA-123 > Project: OpenJPA > Issue Type: Bug >Reporter: Patrick Linskey > > Often, tests are developed before solutions are implemented. It should be > possible for us to check in such tests to svn without causing the build to > fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-123) Test framework should allow tests that are expected to fail to be checked in
Test framework should allow tests that are expected to fail to be checked in Key: OPENJPA-123 URL: https://issues.apache.org/jira/browse/OPENJPA-123 Project: OpenJPA Issue Type: Bug Reporter: Patrick Linskey Often, tests are developed before solutions are implemented. It should be possible for us to check in such tests to svn without causing the build to fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-40) Testing OpenJPA and Spring integration fails
[ https://issues.apache.org/jira/browse/OPENJPA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469347 ] Patrick Linskey commented on OPENJPA-40: To my knowledge, this has been resolved. > Testing OpenJPA and Spring integration fails > > > Key: OPENJPA-40 > URL: https://issues.apache.org/jira/browse/OPENJPA-40 > Project: OpenJPA > Issue Type: Test > Environment: [java] os.name: Mac OS X > [java] os.version: 10.4.7 > [java] os.arch: ppc > [java] java.version: 1.5.0_06 > [java] java.vendor: Apple Computer, Inc. > OpenJPA built from SVN (revision 440460) >Reporter: Thomas Risberg > Assigned To: Marc Prud'hommeaux > Attachments: OpenJpaLoadTimeWeaver.java, testOpenJpa.zip > > > I have attached a test case including jar files and a build script. > src/repository-config.xml contains the Spring configuration and switching to > the TopLink vendor adapter does not show any issues - the test runs fine. > Using the current OpenJPA vendor adapter (Spring sandbox source is included > in src directory) causes this failure: > First the version info: > samoa:~/Projects/testOpenJpa trisberg$ ant openjpa-version > Buildfile: build.xml > openjpa-version: > [java] OpenJPA 0.9.0-incubating-SNAPSHOT > [java] version id: 0.9.0-incubating-SNAPSHOT-r0 > [java] revision: 0 > [java] os.name: Mac OS X > [java] os.version: 10.4.7 > [java] os.arch: ppc > [java] java.version: 1.5.0_06 > [java] java.vendor: Apple Computer, Inc. > [java] java.class.path: > [java] > /Users/trisberg/Projects/testOpenJpa/lib/commons-collections-3.2.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/commons-lang-2.1.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/commons-logging-1.0.4.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/commons-pool-1.3.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/geronimo-j2ee-connector_1.5_spec-1.0.1.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/geronimo-jta_1.0.1B_spec-1.0.1.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/hsqldb.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-jdbc-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-jdbc-5-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-kernel-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-kernel-5-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-lib-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-persistence-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-persistence-jdbc-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-xmlstore-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/persistence-api-1.0.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/serp-1.11.0.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/spring-jpa.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/spring-sandbox.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/spring.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/toplink-essentials.jar > [java] /Users/trisberg/Projects/testOpenJpa/classes > [java] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/.compatibility/14compatibility.jar > [java] user.dir: /Users/trisberg/Projects/testOpenJpa > BUILD SUCCESSFUL > Total time: 3 seconds > And now the runtime error: > samoa:~/Projects/testOpenJpa trisberg$ ant run-test > Buildfile: build.xml > run-test: > [java] TestApp! > [java] Sep 6, 2006 1:11:02 PM org.springframework.core.CollectionFactory > > [java] INFO: JDK 1.4+ collections available > [java] Sep 6, 2006 1:11:02 PM org.springframework.core.CollectionFactory > > [java] INFO: Commons Collections 3.x available > [java] Sep 6, 2006 1:11:02 PM > org.springframework.beans.factory.xml.XmlBeanDefinitionReader > loadBeanDefinitions > [java] INFO: Loading XML bean definitions from class path resource > [repository-config.xml] > [java] Sep 6, 2006 1:11:03 PM > org.springframework.context.support.AbstractRefreshableApplicationContext > refreshBeanFactory > [java] INFO: Bean factory for application context > [org.springframework.context.support.ClassPathXmlApplicationContext;hashCode=85537]: > org.springframework.beans.factory.support.DefaultListableBeanFactory > defining beans > [enti
[jira] Resolved: (OPENJPA-40) Testing OpenJPA and Spring integration fails
[ https://issues.apache.org/jira/browse/OPENJPA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey resolved OPENJPA-40. Resolution: Fixed > Testing OpenJPA and Spring integration fails > > > Key: OPENJPA-40 > URL: https://issues.apache.org/jira/browse/OPENJPA-40 > Project: OpenJPA > Issue Type: Test > Environment: [java] os.name: Mac OS X > [java] os.version: 10.4.7 > [java] os.arch: ppc > [java] java.version: 1.5.0_06 > [java] java.vendor: Apple Computer, Inc. > OpenJPA built from SVN (revision 440460) >Reporter: Thomas Risberg > Assigned To: Marc Prud'hommeaux > Attachments: OpenJpaLoadTimeWeaver.java, testOpenJpa.zip > > > I have attached a test case including jar files and a build script. > src/repository-config.xml contains the Spring configuration and switching to > the TopLink vendor adapter does not show any issues - the test runs fine. > Using the current OpenJPA vendor adapter (Spring sandbox source is included > in src directory) causes this failure: > First the version info: > samoa:~/Projects/testOpenJpa trisberg$ ant openjpa-version > Buildfile: build.xml > openjpa-version: > [java] OpenJPA 0.9.0-incubating-SNAPSHOT > [java] version id: 0.9.0-incubating-SNAPSHOT-r0 > [java] revision: 0 > [java] os.name: Mac OS X > [java] os.version: 10.4.7 > [java] os.arch: ppc > [java] java.version: 1.5.0_06 > [java] java.vendor: Apple Computer, Inc. > [java] java.class.path: > [java] > /Users/trisberg/Projects/testOpenJpa/lib/commons-collections-3.2.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/commons-lang-2.1.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/commons-logging-1.0.4.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/commons-pool-1.3.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/geronimo-j2ee-connector_1.5_spec-1.0.1.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/geronimo-jta_1.0.1B_spec-1.0.1.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/hsqldb.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-jdbc-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-jdbc-5-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-kernel-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-kernel-5-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-lib-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-persistence-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-persistence-jdbc-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/openjpa-xmlstore-0.9.0-incubating-SNAPSHOT.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/persistence-api-1.0.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/serp-1.11.0.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/spring-jpa.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/spring-sandbox.jar > [java] /Users/trisberg/Projects/testOpenJpa/lib/spring.jar > [java] > /Users/trisberg/Projects/testOpenJpa/lib/toplink-essentials.jar > [java] /Users/trisberg/Projects/testOpenJpa/classes > [java] > /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/.compatibility/14compatibility.jar > [java] user.dir: /Users/trisberg/Projects/testOpenJpa > BUILD SUCCESSFUL > Total time: 3 seconds > And now the runtime error: > samoa:~/Projects/testOpenJpa trisberg$ ant run-test > Buildfile: build.xml > run-test: > [java] TestApp! > [java] Sep 6, 2006 1:11:02 PM org.springframework.core.CollectionFactory > > [java] INFO: JDK 1.4+ collections available > [java] Sep 6, 2006 1:11:02 PM org.springframework.core.CollectionFactory > > [java] INFO: Commons Collections 3.x available > [java] Sep 6, 2006 1:11:02 PM > org.springframework.beans.factory.xml.XmlBeanDefinitionReader > loadBeanDefinitions > [java] INFO: Loading XML bean definitions from class path resource > [repository-config.xml] > [java] Sep 6, 2006 1:11:03 PM > org.springframework.context.support.AbstractRefreshableApplicationContext > refreshBeanFactory > [java] INFO: Bean factory for application context > [org.springframework.context.support.ClassPathXmlApplicationContext;hashCode=85537]: > org.springframework.beans.factory.support.DefaultListableBeanFactory > defining beans > [entityManagerFactory,transactionManager,transaction
[jira] Resolved: (OPENJPA-36) Add cwiki url to incubator status page
[ https://issues.apache.org/jira/browse/OPENJPA-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey resolved OPENJPA-36. Resolution: Fixed > Add cwiki url to incubator status page > -- > > Key: OPENJPA-36 > URL: https://issues.apache.org/jira/browse/OPENJPA-36 > Project: OpenJPA > Issue Type: Task >Reporter: David Blevins >Priority: Minor > > Small item. Some chatting on #asfinfra and they requested you add the url to > cwiki (http://cwiki.apache.org/openjpa/) to your incubator status page ( > http://incubator.apache.org/projects/openjpa.html) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-36) Add cwiki url to incubator status page
[ https://issues.apache.org/jira/browse/OPENJPA-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469346 ] Patrick Linskey commented on OPENJPA-36: Resolved with Marc's synchronization between the wiki and the site. > Add cwiki url to incubator status page > -- > > Key: OPENJPA-36 > URL: https://issues.apache.org/jira/browse/OPENJPA-36 > Project: OpenJPA > Issue Type: Task >Reporter: David Blevins >Priority: Minor > > Small item. Some chatting on #asfinfra and they requested you add the url to > cwiki (http://cwiki.apache.org/openjpa/) to your incubator status page ( > http://incubator.apache.org/projects/openjpa.html) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-10) persistence unit name should be default diagnostic context for standard OpenJPA log impl
[ https://issues.apache.org/jira/browse/OPENJPA-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469345 ] Patrick Linskey commented on OPENJPA-10: Resolved with 475084 > persistence unit name should be default diagnostic context for standard > OpenJPA log impl > > > Key: OPENJPA-10 > URL: https://issues.apache.org/jira/browse/OPENJPA-10 > Project: OpenJPA > Issue Type: Improvement >Reporter: Patrick Linskey >Priority: Minor > > OpenJPA's default logging implementation has a concept of a diagnostic > context, roughly stolen from log4j. The basic idea is that in a configuration > file, the user can specify a diagnostic context string that will be printed > out with each log message. The result is that if a user has multiple > EntityManagerFactories running in the same JVM, she can distinguish between > the different logging outputs, even if they all just go to stderr. > The JPA spec requires that persistence units are named uniquely. This > presents us with an opportunity: we could check for the existence of multiple > EMFs and, if found and the user did not specify a diagnostic context, > automatically set the logging diagnostic context based on the name of the > persistence unit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-10) persistence unit name should be default diagnostic context for standard OpenJPA log impl
[ https://issues.apache.org/jira/browse/OPENJPA-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey resolved OPENJPA-10. Resolution: Fixed > persistence unit name should be default diagnostic context for standard > OpenJPA log impl > > > Key: OPENJPA-10 > URL: https://issues.apache.org/jira/browse/OPENJPA-10 > Project: OpenJPA > Issue Type: Improvement >Reporter: Patrick Linskey >Priority: Minor > > OpenJPA's default logging implementation has a concept of a diagnostic > context, roughly stolen from log4j. The basic idea is that in a configuration > file, the user can specify a diagnostic context string that will be printed > out with each log message. The result is that if a user has multiple > EntityManagerFactories running in the same JVM, she can distinguish between > the different logging outputs, even if they all just go to stderr. > The JPA spec requires that persistence units are named uniquely. This > presents us with an opportunity: we could check for the existence of multiple > EMFs and, if found and the user did not specify a diagnostic context, > automatically set the logging diagnostic context based on the name of the > persistence unit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-122) EntityManager does not throw exceptions after close() in required cases
[ https://issues.apache.org/jira/browse/OPENJPA-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell updated OPENJPA-122: -- Attachment: EntityManagerImpl.patch.txt Please review this patch. This patch fixes the issue but I'd like to have it reviewed. > EntityManager does not throw exceptions after close() in required cases > --- > > Key: OPENJPA-122 > URL: https://issues.apache.org/jira/browse/OPENJPA-122 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Reporter: Craig Russell >Priority: Minor > Attachments: EntityManagerImpl.patch.txt, > TestEntityManagerMethodsThrowAfterClose.java > > > A new test case TestEntityManagerMethodsThrowAfterClose has 2 failures and 2 > errors. > The test case has not been checked in so that the build does not fail. The > test case is attached. > 1. Wrong exception thrown for flush after close: > testFlushAfterClose(org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose) > Time elapsed: 1.294 sec <<< ERROR! > <4|false|0.9.7-incubating-SNAPSHOT> > org.apache.openjpa.persistence.TransactionRequiredException: Can only perform > operation while a transaction is active. > at > org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(BrokerImpl.java:4252) > at > org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(DelegatingBroker.java:1292) > at > org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:472) > at > org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose.testFlushAfterClose(TestEntityManagerMethodsThrowAfterClose.java:113) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > 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 junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) > at org.apache.maven.surefire.Surefire.run(Surefire.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) > 2. No exception thrown for setFlushMode after close: > testSetFlushModeAfterClose(org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose) > Time elapsed: 0.338 sec <<< FAILURE! > junit.framework.AssertionFailedError: Expected exception for method > setFlushMode after em.close() > at junit.framework.Assert.fail(Assert.java:47) > at > org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose.testSetFlushModeAfterClose(TestEntityManagerMethodsThrowAfterClose.java:123) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:12
[jira] Updated: (OPENJPA-122) EntityManager does not throw exceptions after close() in required cases
[ https://issues.apache.org/jira/browse/OPENJPA-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell updated OPENJPA-122: -- Attachment: TestEntityManagerMethodsThrowAfterClose.java This test cannot be checked in until the bugs are fixed, or the build will break. > EntityManager does not throw exceptions after close() in required cases > --- > > Key: OPENJPA-122 > URL: https://issues.apache.org/jira/browse/OPENJPA-122 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Reporter: Craig Russell >Priority: Minor > Attachments: TestEntityManagerMethodsThrowAfterClose.java > > > A new test case TestEntityManagerMethodsThrowAfterClose has 2 failures and 2 > errors. > The test case has not been checked in so that the build does not fail. The > test case is attached. > 1. Wrong exception thrown for flush after close: > testFlushAfterClose(org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose) > Time elapsed: 1.294 sec <<< ERROR! > <4|false|0.9.7-incubating-SNAPSHOT> > org.apache.openjpa.persistence.TransactionRequiredException: Can only perform > operation while a transaction is active. > at > org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(BrokerImpl.java:4252) > at > org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(DelegatingBroker.java:1292) > at > org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:472) > at > org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose.testFlushAfterClose(TestEntityManagerMethodsThrowAfterClose.java:113) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > 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 junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) > at org.apache.maven.surefire.Surefire.run(Surefire.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) > 2. No exception thrown for setFlushMode after close: > testSetFlushModeAfterClose(org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose) > Time elapsed: 0.338 sec <<< FAILURE! > junit.framework.AssertionFailedError: Expected exception for method > setFlushMode after em.close() > at junit.framework.Assert.fail(Assert.java:47) > at > org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose.testSetFlushModeAfterClose(TestEntityManagerMethodsThrowAfterClose.java:123) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit
[jira] Created: (OPENJPA-122) EntityManager does not throw exceptions after close() in required cases
EntityManager does not throw exceptions after close() in required cases --- Key: OPENJPA-122 URL: https://issues.apache.org/jira/browse/OPENJPA-122 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Craig Russell Priority: Minor A new test case TestEntityManagerMethodsThrowAfterClose has 2 failures and 2 errors. The test case has not been checked in so that the build does not fail. The test case is attached. 1. Wrong exception thrown for flush after close: testFlushAfterClose(org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose) Time elapsed: 1.294 sec <<< ERROR! <4|false|0.9.7-incubating-SNAPSHOT> org.apache.openjpa.persistence.TransactionRequiredException: Can only perform operation while a transaction is active. at org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(BrokerImpl.java:4252) at org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(DelegatingBroker.java:1292) at org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:472) at org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose.testFlushAfterClose(TestEntityManagerMethodsThrowAfterClose.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) 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 junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) 2. No exception thrown for setFlushMode after close: testSetFlushModeAfterClose(org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose) Time elapsed: 0.338 sec <<< FAILURE! junit.framework.AssertionFailedError: Expected exception for method setFlushMode after em.close() at junit.framework.Assert.fail(Assert.java:47) at org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose.testSetFlushModeAfterClose(TestEntityManagerMethodsThrowAfterClose.java:123) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) 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 junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.Delegatin
[jira] Closed: (OPENJPA-62) Ejbql join queries show invalid null Entities when run in a new persistence context where no entity instances exist.
[ https://issues.apache.org/jira/browse/OPENJPA-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Wisneski closed OPENJPA-62. - Resolution: Fixed fixed in recent code > Ejbql join queries show invalid null Entities when run in a new persistence > context where no entity instances exist. > > > Key: OPENJPA-62 > URL: https://issues.apache.org/jira/browse/OPENJPA-62 > Project: OpenJPA > Issue Type: Bug > Components: query > Environment: openjpa version 443432, derby, db2 >Reporter: George Hongell > Attachments: failureEntities.zip > > > Each of the following queries, when run by itself in a new persistence > context where EmpBean and DeptBean are not populated, > is showing null values for DeptBean and EmpBean respectively which should be > impossible for an inner join. > Outer join queries have similar results. > The DataBase is populated. > Whether or not the query is run in a transaction context does not matter. > select d,e from DeptBean d join d.emps e where e.bonus<100.02 or > e.name='name2' > select d,e from EmpBean e join e.dept d where e.bonus<100.02 or > e.name='name6' > TEST1; select d,e from DeptBean d join d.emps e where e.bonus<100.02 or > e.name='name2' > DeptBean EmpBean > ~~~ > null [1] > null [3] > null [5] > null [6] > [100] [8] > [200] [4] > [210] [2] > [210] [7] > [210] [9] > TEST1; 9 tuples > TEST1; select d,e from EmpBean e join e.dept d where e.bonus<100.02 or > e.name='name6' > DeptBean EmpBean > ~~~ > [100] [8] > [100]null > [200] [3] > [200]null > [210]null > [210]null > [210]null > [210]null > [220]null > TEST1; 9 tuples > Furthermore, if either of these queries is run twice in a new persistence > context, > the second query gets a Cannot load object with id "1" error. >ACTUAL( > TEST2; select d,e from EmpBean e join e.dept d where e.bonus<100.02 or > e.name='name6' > > d > > > ~~~ > > Cannot load object with id "1". Instance > "com.ibm.ws.query.entities.objectgrid.annotated.DeptBean-1" with the same id > already exists in the L1 cache. This can occur when you assign an existing > id to a new instance, and before flushing attempt to load the existing > instance for that id. > TEST2; 1 tuple > However, if > select d,e from DeptBean d join d.emps e where e.bonus<100.02 or > e.name='name2' > is proceeded by > select d from DeptBean d > it gets the correct result. > and if select d,e from EmpBean e join e.dept d where e.bonus<100.02 or > e.name='name6' > is proceeded by > select e from EmpBean e > it gets the correct result. > should be > TEST2; select d,e from EmpBean e join e.dept d where e.bonus<100.02 or > e.name='name6' > DeptBean EmpBean > ~~~ > [100] [6] > [100] [8] > [200] [3] > [200] [4] > [210] [1] > [210] [2] > [210] [7] > [210] [9] > [220] [5] > TEST2; 9 tuples) > TEST2; select d,e from DeptBean d join d.emps e where e.bonus<100.02 or > e.name='name2' > DeptBean EmpBean > ~~~ > [100] [6] > [100] [8] > [200] [3] > [200] [4] > [210] [1] > [210] [2] > [210] [7] > [210] [9] > [220] [5] > TEST2; 9 tuples) > the database shows > select t0.empid, t0.dept_deptno, t0.name, t0.bonus, t0.home_street, > t0.work_street FROM EmpBean t0 > EMPID :DEPT_DEPTNO :NAME :BONUS :HOME_STREET :WORK_STREET : > 1 :210 :david :0.0 :1780 Mercury Way :555 Silicon Valley Drive : > 2 :210 :andrew :0.0 :1780 Mercury Way :555 Silicon Valley Drive : > 3 :200 :minmei :0.0 :1780 Mercury Way :555 Silicon Valley Drive : > 4 :200 :george :0.0 :512 Venus Drive :555 Silicon Valley Drive : > 5 :220 :ritika :0.0 :12440 Vulcan Avenue :555 Silicon Valley Drive : > 6 :100 :ahmad :0.0 :4983 Plutonium Avenue :4983 Plutonium Avenue : > 7 :210 :charlene :0.0 :182 Martian Street :555 Silicon Valley Drive : > 8 :100 :Tom Rayburn :0.0 :6200 Vegas Drive :555 Silicon Valley Drive : > 9 :210
[jira] Closed: (OPENJPA-110) Every NamedNativeQuery using ResultSetMapping fails at runtime with class cast exception when try to iterate over list
[ https://issues.apache.org/jira/browse/OPENJPA-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Wisneski closed OPENJPA-110. -- Resolution: Fixed already fixed in current code > Every NamedNativeQuery using ResultSetMapping fails at runtime with class > cast exception when try to iterate over list > --- > > Key: OPENJPA-110 > URL: https://issues.apache.org/jira/browse/OPENJPA-110 > Project: OpenJPA > Issue Type: Bug > Environment: windows xp, openjpa_097_incubating >Reporter: George Hongell > > Every NamedNativeQuery using ResultSetMapping fails at runtime with class > cast exception when try to iterate over list > java.lang.ClassCastException: java.lang.Integer incompatible with > com.ibm.ws.query.entities.objectgrid.xml.DeptBean > at > com.ibm.ws.query.tests.JUNamedNativeQueryTest.testJoinQuery(JUNamedNativeQueryTest.java:563) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at junit.framework.TestCase.runTest(Unknown Source) > at junit.framework.TestCase.runBare(Unknown Source) > at junit.framework.TestResult$1.protect(Unknown Source) > at junit.framework.TestResult.runProtected(Unknown Source) > at junit.framework.TestResult.run(Unknown Source) > at junit.framework.TestCase.run(Unknown Source) > at junit.framework.TestSuite.runTest(Unknown Source) > at junit.framework.TestSuite.run(Unknown Source) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-121) Table name defaults to the class name instead of the entity name
Table name defaults to the class name instead of the entity name Key: OPENJPA-121 URL: https://issues.apache.org/jira/browse/OPENJPA-121 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Marc Prud'hommeaux Priority: Minor Section 9.1.1 of the JPA 1.0 spec says that if the @Table annotation is not defined, then it should default to the name of the entity. However, we always default to the name of the class. For example, the entity define as "@Entity(name="FOO") public class Bar" should default to be mapped to the table named "FOO", but we incorrectly default to "Bar". The workaround is to just specify the @Table name as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-120) For Multi Table Entity subselect with field in second table gets DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601
For Multi Table Entity subselect with field in second table gets DB2 SQL error:
SQLCODE: -104, SQLSTATE: 42601
--
Key: OPENJPA-120
URL: https://issues.apache.org/jira/browse/OPENJPA-120
Project: OpenJPA
Issue Type: Bug
Components: query
Environment: incubator 097
Reporter: George Hongell
For Multi Table Entity subselect with field in second table gets DB2 SQL error:
SQLCODE: -104, SQLSTATE: 42601
the field salary is in table 2
--select e from EmpBean e where (e.salary > (select sum(e.salary) from EmpBean
e))
--DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLERRMC: );SUM(t3.salary)
FROM; {prepstmnt 43647642 SELECT t0.empid, t0.bonus, t4.deptno,
t4.budget, t5.empid, t5.bonus, t5.dept_deptno, t5.execLevel, t5.hireDate,
t5.hireTime, t5.hireTimestamp, t5.home_street, t5.isManager, t5.name,
t6.salary, t5.work_street, t4.name, t7.deptno, t7.budget, t7.mgr_empid,
t7.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t8.street,
t8.city, t8.state, t8.zip, t0.isManager, t0.name, t1.salary, t9.street,
t9.city, t9.state, t9.zip FROM EmpBean t0 INNER JOIN empbean2 t1 ON t0.empid =
t1.EmpBean_empid LEFT OUTER JOIN DeptBean t4 ON t0.dept_deptno = t4.deptno LEFT
OUTER JOIN AddressBean t8 ON t0.home_street = t8.street LEFT OUTER JOIN
AddressBean t9 ON t0.work_street = t9.street LEFT OUTER JOIN EmpBean t5 ON
t4.mgr_empid = t5.empid LEFT OUTER JOIN DeptBean t7 ON t4.reportsTo_deptno =
t7.deptno LEFT OUTER JOIN empbean2 t6 ON t5.empid = t6.EmpBean_empid INNER JOIN
empbean2 t3 ON t2.empid = t3.EmpBean_empid WHERE (t1.salary > (SELECT
SUM(t3.salary) FROM ))} [code=-104, state=42601]
select x from EmpBean x where x.salary < (select max(y.salary) from EmpBean y
where x.salary=y.salary)
--DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLERRMC: (;.salary) FROM
WHERE;WHERE {prepstmnt 214568138 SELECT t0.empid, t0.bonus, t4.deptno,
t4.budget, t5.empid, t5.bonus, t5.dept_deptno, t5.execLevel, t5.hireDate,
t5.hireTime, t5.hireTimestamp, t5.home_street, t5.isManager, t5.name,
t6.salary, t5.work_street, t4.name, t7.deptno, t7.budget, t7.mgr_empid,
t7.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t8.street,
t8.city, t8.state, t8.zip, t0.isManager, t0.name, t1.salary, t9.street,
t9.city, t9.state, t9.zip FROM EmpBean t0 INNER JOIN empbean2 t1 ON t0.empid =
t1.EmpBean_empid LEFT OUTER JOIN DeptBean t4 ON t0.dept_deptno = t4.deptno LEFT
OUTER JOIN AddressBean t8 ON t0.home_street = t8.street LEFT OUTER JOIN
AddressBean t9 ON t0.work_street = t9.street LEFT OUTER JOIN EmpBean t5 ON
t4.mgr_empid = t5.empid LEFT OUTER JOIN DeptBean t7 ON t4.reportsTo_deptno =
t7.deptno LEFT OUTER JOIN empbean2 t6 ON t5.empid = t6.EmpBean_empid INNER JOIN
empbean2 t3 ON t2.empid = t3.EmpBean_empid WHERE (t1.salary < (SELECT
MAX(t3.salary) FROM WHERE (t1.salary = t3.salary)))} [code=-104, state=42601]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-50) bad sql pushdown, cast changes datatype
[
https://issues.apache.org/jira/browse/OPENJPA-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Wisneski closed OPENJPA-50.
-
Resolution: Fixed
fixed in recent code
> bad sql pushdown, cast changes datatype
> ---
>
> Key: OPENJPA-50
> URL: https://issues.apache.org/jira/browse/OPENJPA-50
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, db2, derby
>Reporter: George Hongell
> Attachments: failureEntities.jar
>
>
> 444 - bad sql pushdown, cast changes datatype
> TEST444; select e from EmpBean e where e.salary > 5 and abs(e.salary) > 12
> 28203 TRACE [main] openjpa.jdbc.SQL - [0 ms]
> executing prepstmnt 1712481810 SELECT t0.empid, t0.bonus, t1.deptno,
> t1.budget, t1.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp,
> t2.street, t2.city, t2.state, t2.zip, t0.isManager, t0.name, t0.salary,
> t3.street, t3.city, t3.state, t3.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean
> t1 ON t0.dept_deptno = t1.deptno LEFT OUTER JOIN AddressBean t2 ON
> t0.home_street = t2.street LEFT OUTER JOIN AddressBean t3 ON t0.work_street =
> t3.street WHERE (CAST(t0.salary AS DOUBLE) > CAST(? AS DOUBLE) AND
> CAST(ABS(t0.salary) AS BIGINT) > CAST(? AS BIGINT)) [params=(long) 5, (long)
> 12]
> select t0.empid, t0.salary FROM EmpBean t0 LEFT OUTER JOIN DeptBean t1 ON
> t0.dept_deptno = t1.deptno WHERE (CAST(t0.salary AS DOUBLE) > ?) AND
> (CAST(ABS(t0.salary) AS BIGINT) > ?) {long 5, long 12}
> why CAST(ABS(t0.salary) AS BIGINT)?
> select t0.empid, t0.salary FROM EmpBean t0 WHERE (CAST(t0.salary AS DOUBLE)
> > ?) AND (CAST(ABS(t0.salary) AS BIGINT) > ?) {long 5, long 12}
> s/b
> select t0.empid, t0.salary FROM EmpBean t0 LEFT OUTER JOIN DeptBean t1 ON
> t0.dept_deptno = t1.deptno WHERE (CAST(t0.salary AS DOUBLE) > ?) AND
> (CAST(ABS(t0.salary) AS DOUBLE) > ?) {long 5, long 12}
> [ FAILED 444- bucket = fvtfull, query = select e from EmpBean e where
> e.salary > 5 and abs(e.salary) > 12 :
>EXPECTED(
> TEST444; select e from EmpBean e where e.salary > 5 and abs(e.salary) > 12
> EmpBean
> ~~~
> [1]
> [2]
> [3]
> TEST444; 3 tuples)
>ACTUAL(
> TEST444; select e from EmpBean e where e.salary > 5 and abs(e.salary) > 12
> EmpBean
> ~~~
> [2]
> [3]
> TEST444; 2 tuples) ]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-48) parsing error - cast of subselect does not work
[
https://issues.apache.org/jira/browse/OPENJPA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Wisneski closed OPENJPA-48.
-
Resolution: Fixed
fixed in recent code
> parsing error - cast of subselect does not work
>
>
> Key: OPENJPA-48
> URL: https://issues.apache.org/jira/browse/OPENJPA-48
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, derby and db2
>Reporter: George Hongell
> Attachments: failureEntities.jar
>
>
> 163 - parsing error - cast of subselect does not work
> TEST163; select e from EmpBean e where e.salary + 100 > all (select
> e1.salary from EmpBean e1 left join e1.dept d where d.no = 20)
> Syntax error: Encountered "ALL" at line 1, column 484. {SELECT t0.empid,
> t0.bonus, t3.deptno, t3.budget, t3.name, t0.execLevel, t0.hireDate,
> t0.hireTime, t0.hireTimestamp, t4.street, t4.city, t4.state, t4.zip,
> t0.isManager, t0.name, t0.salary, t5.street, t5.city, t5.state, t5.zip FROM
> EmpBean t0 LEFT OUTER JOIN DeptBean t3 ON t0.dept_deptno = t3.deptno LEFT
> OUTER JOIN AddressBean t4 ON t0.home_street = t4.street LEFT OUTER JOIN
> AddressBean t5 ON t0.work_street = t5.street WHERE ((CAST(t0.salary AS
> DOUBLE) + CAST(? AS DOUBLE)) > CAST(ALL((SELECT t1.salary FROM EmpBean t1,
> DeptBean t2 WHERE (CAST(t2.deptno AS BIGINT) = CAST(? AS BIGINT)) AND
> t1.dept_deptno = t2.deptno)) AS DOUBLE))} [code=3, state=42X01]
> {double 100, int 20}
> this works
> select t0.empid, t0.salary FROM EmpBean t0 LEFT OUTER JOIN DeptBean t3 ON
> t0.dept_deptno = t3.deptno WHERE ((CAST(t0.salary AS DOUBLE) + CAST(? AS
> DOUBLE)) > ALL (SELECT t1.salary FROM EmpBean t1, DeptBean t2 WHERE
> (CAST(t2.deptno AS BIGINT) = CAST(? AS BIGINT)) AND t1.dept_deptno =
> t2.deptno)) {double 100, int 20}
> <0|false|0.0.0> org.apache.openjpa.persistence.PersistenceException: Syntax
> error: Encountered "ALL" at line 1, column 484. {SELECT t0.empid, t0.bonus,
> t3.deptno, t3.budget, t3.name, t0.execLevel, t0.hireDate, t0.hireTime,
> t0.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t0.isManager,
> t0.name, t0.salary, t5.street, t5.city, t5.state, t5.zip FROM EmpBean t0 LEFT
> OUTER JOIN DeptBean t3 ON t0.dept_deptno = t3.deptno LEFT OUTER JOIN
> AddressBean t4 ON t0.home_street = t4.street LEFT OUTER JOIN AddressBean t5
> ON t0.work_street = t5.street WHERE ((CAST(t0.salary AS DOUBLE) + CAST(? AS
> DOUBLE)) > CAST(ALL((SELECT t1.salary FROM EmpBean t1, DeptBean t2 WHERE
> (CAST(t2.deptno AS BIGINT) = CAST(? AS BIGINT)) AND t1.dept_deptno =
> t2.deptno)) AS DOUBLE))} [code=3, state=42X01]
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
> at
> org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:37)
> at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
> at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
> at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
> at
> com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at
> junit.extensions.jfunc.TestletWrapper.runBare(TestletWrapper.java:116)
> at
> junit.extensions.jfunc.TestletWrapper$1.protect(TestletWrapper.java:106)
> at junit.framework.TestResult.runProtected(Unknown Source)
> at juni
[jira] Closed: (OPENJPA-55) Allow executeUpdate() invocations on native queries
[ https://issues.apache.org/jira/browse/OPENJPA-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Wisneski closed OPENJPA-55. - Resolution: Fixed fixed by revision 497605 > Allow executeUpdate() invocations on native queries > --- > > Key: OPENJPA-55 > URL: https://issues.apache.org/jira/browse/OPENJPA-55 > Project: OpenJPA > Issue Type: Improvement > Components: query >Reporter: Abe White > Assigned To: David Wisneski >Priority: Minor > > Currently, native queries only allow you to execute via getResultList or > getSingleResult. Also allow execution through executeUpdate(). Original > report: > I have a customer who is using Kodo 4.0.1 JPA and tried to use the following > line to lock back end tables: > > > String sql = "LOCK TABLE .. IN EXCLUSIVE MODE"; > > Query q = em.createNativeQuery(sql); > > q.executeUpdate(); > > But he got errors: > > Caused by: <4|false|4.0.1> kodo.persistence.InvalidStateException: Cannot > perform an update or delete operation on select query: "LOCK TABLE IN > EXCLUSIVE MODE". > at kodo.persistence.QueryImpl.executeUpdate(QueryImpl.java:355) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-25) Incorrect SQL generated for queries involving more than one AbstractSchemaNames, generated SQL FROM clause is missing 'Table alias'
[ https://issues.apache.org/jira/browse/OPENJPA-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Wisneski closed OPENJPA-25. - Resolution: Fixed not a problem anymore > Incorrect SQL generated for queries involving more than one > AbstractSchemaNames, generated SQL FROM clause is missing 'Table alias' > --- > > Key: OPENJPA-25 > URL: https://issues.apache.org/jira/browse/OPENJPA-25 > Project: OpenJPA > Issue Type: Bug > Components: query >Reporter: Catalina Wei > > select e, d from EmpBean e, DeptBean d generates following SQL where t2 is > undefined: > SELECT t1.empid, t2.deptno FROM EmpBean t0 JOIN EmpBean t1 ON (1 = > 1) > 'DeptBean t2' is missing in the FROM clause. > Similar problem occurs to the following query: > select d from EmpBean e left join e.dept d, ProjectBean p where e.salary = > p.budget ==> incorrect SQL (t3 is undefined): > SELECT t1.deptno, t1.budget, t1.mgr_empid, t1.name, t1.reportsTo_deptno FROM > EmpBean t0 LEFT OUTER JOIN DeptBean t1 ON t0.dept_deptno = t1.deptno JOIN > EmpBean t2 ON (1 = 1) WHERE (t2.salary = t3.budget) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-54) bad sql pushdown, should use all syntax
[
https://issues.apache.org/jira/browse/OPENJPA-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Wisneski closed OPENJPA-54.
-
Resolution: Fixed
already fixed
> bad sql pushdown, should use all syntax
> ---
>
> Key: OPENJPA-54
> URL: https://issues.apache.org/jira/browse/OPENJPA-54
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, derby, db2
>Reporter: George Hongell
> Attachments: failureEntities.jar
>
>
> 454 bad sql pushdown, should use all syntax
> TEST454; select e from EmpBean e where e.empid not in (select e.no from
> DeptBean e)
> Scalar subquery is only allowed to return a single row. {prepstmnt 241176160
> SELECT t0.empid, t0.bonus, t2.deptno, t2.budget, t2.name, t0.execLevel,
> t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street, t3.city, t3.state,
> t3.zip, t0.isManager, t0.name, t0.salary, t4.street, t4.city, t4.state,
> t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON t0.dept_deptno =
> t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street = t3.street LEFT
> OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE (NOT (t0.empid
> = (SELECT t1.deptno FROM DeptBean t1)) AND t0.empid IS NOT NULL)}
> [code=3, state=21000]
> s/b
> select t0.empid from EMPBean t0 where ( t0.empid <> ALL ( select
> t2.deptno from DEPTbean t2) )
> [ FAILED 454- bucket = fvtfull, query = select e from EmpBean e where
> e.empid not in (select e.no from DeptBean e) :
>DIFFERENCE-locations based on expected-(
> diff at line 2 position 2 EXPECTED [T] ACTUAL [ ]
> TEST454; 0 tuples
>
>
>
> e
>
>
>
>
> )
>EXPECTED(
> TEST454; select e from EmpBean e where e.empid not in (select e.no from
> DeptBean e)
> TEST454; 0 tuples )
>ACTUAL(
> TEST454; select e from EmpBean e where e.empid not in (select e.no from
> DeptBean e)
>
>
>
> e
>
>
>
>
> ~~
>
> Scalar subquery is only allowed to return a single row. {prepstmnt 241176160
> SELECT t0.empid, t0.bonus, t2.deptno, t2.budget, t2.name, t0.execLevel,
> t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street, t3.city, t3.state,
> t3.zip, t0.isManager, t0.name, t0.salary, t4.street, t4.city, t4.state,
> t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON t0.dept_deptno =
> t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street = t3.street LEFT
> OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE (NOT (t0.empid
> = (SELECT t1.deptno FROM DeptBean t1)) AND t0.empid IS NOT NULL)}
> [code=3, state=21000]
> TEST454; 1 tuple) ]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-53) bad sql pushdown for nested subselects, missing nested subselect
[
https://issues.apache.org/jira/browse/OPENJPA-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Wisneski closed OPENJPA-53.
-
Resolution: Fixed
not a problem anymore
> bad sql pushdown for nested subselects, missing nested subselect
> -
>
> Key: OPENJPA-53
> URL: https://issues.apache.org/jira/browse/OPENJPA-53
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, derby, db2
>Reporter: George Hongell
> Attachments: failureEntities.jar
>
>
> 536 bad sql pushdown for nested subselects
> TEST536; select e from EmpBean e where (e.salary = (select max(e.salary)
> from EmpBean e where e.salary > some (select f.salary from EmpBean f where
> f.dept.mgr.empid=e.dept.mgr.empid)) )
> Syntax error: Encountered ")" at line 1, column 504. {SELECT t0.empid,
> t0.bonus, t5.deptno, t5.budget, t5.name, t0.execLevel, t0.hireDate,
> t0.hireTime, t0.hireTimestamp, t7.street, t7.city, t7.state, t7.zip,
> t0.isManager, t0.name, t0.salary, t8.street, t8.city, t8.state, t8.zip FROM
> EmpBean t0 LEFT OUTER JOIN DeptBean t5 ON t0.dept_deptno = t5.deptno LEFT
> OUTER JOIN AddressBean t7 ON t0.home_street = t7.street LEFT OUTER JOIN
> AddressBean t8 ON t0.work_street = t8.street WHERE (t0.salary = (SELECT
> MAX(t1.salary) FROM EmpBean t1 WHERE (t1.salary > ANY(()} [code=3,
> state=42X01]
> s/b
> select q1."EMPID", q1."SALARY", q1."DEPT_DEPTNO" from EMPVO q1 where (
> q1."SALARY" = ( select max( q2."SALARY") from EMPVO q2, DEPTVO q3, EMPVO q4
> where ( q2."SALARY" > ANY ( select q5."SALARY" from EMPVO q5, DEPTVO q6,
> EMPVO q7 where ( q7."EMPID" = q4."EMPID") and ( q6."DEPTNO" =
> q5."DEPT_DEPTNO") and ( q7."EMPID" = q6."MGR_EMPID") ) ) and (
> q3."DEPTNO" = q2."DEPT_DEPTNO") and ( q4."EMPID" = q3."MGR_EMPID") ) )
> [ FAILED 536- bucket = fvtfull, query = select e from EmpBean e where
> (e.salary = (select max(e.salary) from EmpBean e where e.salary > some
> (select f.salary from EmpBean f where f.dept.mgr.empid=e.dept.mgr.empid)) )
> :
>DIFFERENCE-locations based on expected-(
> diff at line 2 position 295 EXPECTED [ ] ACTUAL [e]
>
>
>
>
> e
>
>
>
>
>
>
>
> e
>
>
>
>
> )
>EXPECTED(
> TEST536; select e from EmpBean e where (e.salary = (select max(e.salary)
> from EmpBean e where e.salary > some (select f.salary from EmpBean f where
> f.dept.mgr.empid=e.dept.mgr.empid)) )
>
>
>
>
> e
>
>
>
>
>
[jira] Closed: (OPENJPA-56) in derby concat with input parameter needs a cast, otherwise becomes long varchar and some operations do not work
[
https://issues.apache.org/jira/browse/OPENJPA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Wisneski closed OPENJPA-56.
-
Resolution: Fixed
already fixed in latest code
> in derby concat with input parameter needs a cast, otherwise becomes long
> varchar and some operations do not work
> -
>
> Key: OPENJPA-56
> URL: https://issues.apache.org/jira/browse/OPENJPA-56
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, derby, openjpa version 443432.
>Reporter: George Hongell
> Attachments: failureEntities.jar
>
>
> run on version 443432.
> in derby concat with input parameter needs a cast, otherwise becomes long
> varchar and some operations do not work
> (NOTE:already done if concat is inside substring eg.
> substring(concat(xxx,yyy),n,m)
> EJBQL:
> select d from EmpBean e left join e.dept d where concat(d.name, 'ahmad') =
> 'AhmadDept'
>
> OPENJPA ERROR OR SQL PUSHDOWN:
> Comparisons between 'LONG VARCHAR' and 'LONG VARCHAR' are not supported.
> {SELECT t1.deptno, t1.budget, t1.mgr_empid, t1.name, t1.reportsTo_deptno FROM
> EmpBean t0 LEFT OUTER JOIN DeptBean t1 ON t0.dept_deptno = t1.deptno WHERE
> ((t1.name||?) = ?)} [code=3, state=42818]
> SUGGESTED SQL PUSHDOWN:
> select t1.deptno, t1.name FROM EmpBean t0 LEFT OUTER JOIN DeptBean t1 ON
> t0.dept_deptno = t1.deptno WHERE (cast((t1.name||?) as Varchar(1000))) = ?
> {String ahmad, String AhmadDept}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-45) pushdown sql uses outer join when it should use inner join
[ https://issues.apache.org/jira/browse/OPENJPA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Wisneski closed OPENJPA-45. - Resolution: Duplicate duplicate of OPENJPA-49 > pushdown sql uses outer join when it should use inner join > -- > > Key: OPENJPA-45 > URL: https://issues.apache.org/jira/browse/OPENJPA-45 > Project: OpenJPA > Issue Type: Bug > Components: query > Environment: windows xp, derby, db2 >Reporter: George Hongell > Attachments: failureEntities.jar > > > 13 - uses outer join not inner join > TEST13; select $ from EmpBean $, DeptBean _a > 5859 TRACE [main] openjpa.jdbc.SQL - [0 ms] > executing prepstmnt 612246654 SELECT t0.empid, t0.bonus, t1.deptno, > t1.budget, t1.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, > t2.street, t2.city, t2.state, t2.zip, t0.isManager, t0.name, t0.salary, > t3.street, t3.city, t3.state, t3.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean > t1 ON t0.dept_deptno = t1.deptno LEFT OUTER JOIN AddressBean t2 ON > t0.home_street = t2.street LEFT OUTER JOIN AddressBean t3 ON t0.work_street = > t3.street > pushdown sql s/b > select t0.empid, t0.bonus, t1.deptno, t1.budget, t1.name, t0.execLevel, > t0.hireDate, t0.hireTime, t0.hireTimestamp, t2.street, t2.city, t2.state, > t2.zip, t0.isManager, t0.name, t0.salary, t3.street, t3.city, t3.state, > t3.zip FROM EmpBean t0 JOIN DeptBean t1 ON t0.dept_deptno = t1.deptno LEFT > OUTER JOIN AddressBean t2 ON t0.home_street = t2.street LEFT OUTER JOIN > AddressBean t3 ON t0.work_street = t3.street > [ FAILED 13- bucket = fvtfull, query = select $ from EmpBean $, DeptBean _a > : >DIFFERENCE-locations based on expected-( > diff at line 2 position 1 EXPECTED [ ] ACTUAL [E] > $ > > EmpBean > ) >EXPECTED( > TEST13; select $ from EmpBean $, DeptBean _a > EmpBean > ~~~ > [1] > [2] > [3] > [4] > [5] > [6] > [7] > [8] > [9] > TEST13; 9 tuples) ] >ACTUAL( > TEST13; select $ from EmpBean $, DeptBean _a > EmpBean > ~~~ > [1] > [2] > [3] > [4] > [5] > [6] > [7] > [8] > [9] > [10] > TEST13; 10 tuples) ] > 83 pushdown uses all left outer joins but last 2 joins should be inner > TEST83; select d.name, e.name, p.name from DeptBean d left join d.emps e > join e.tasks p > bad trace /does not work > 9234 TRACE [main] openjpa.jdbc.SQL - [15 ms] > executing prepstmnt 343938176 SELECT t0.name, t1.name, t3.name FROM DeptBean > t0 LEFT OUTER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN > TaskBean_EmpBean t2 ON t1.empid = t2.empid LEFT OUTER JOIN TaskBean t3 ON > t2.tasks_taskid = t3.taskid > trace s/b > 9234 TRACE [main] openjpa.jdbc.SQL - [15 ms] > executing prepstmnt 343938176 SELECT t0.name, t1.name, t3.name FROM DeptBean > t0 LEFT OUTER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN > TaskBean_EmpBean t2 ON t1.empid = t2.emps_empid LEFT OUTER JOIN TaskBean t3 > ON t2.tasks_taskid = t3.taskid > pushdown sql s/b > select t0.name, t1.name, t3.name FROM DeptBean t0 LEFT OUTER JOIN EmpBean t1 > ON t0.deptno = t1.dept_deptno JOIN TaskBean_EmpBean t2 ON t1.empid = > t2.emps_empid JOIN TaskBean t3 ON t2.tasks_taskid = t3.taskidactual TEST83; > select d.name, e.name, p.name from DeptBean d left join d.emps e join e.tasks > p > [ FAILED 83- bucket = fvtfull, query = select d.name, e.name, p.name from > DeptBean d left join d.emps e join e.tasks p : >EXPECTED( > TEST83; select d.name, e.name, p.name from DeptBean d left join d.emps e > join e.tasks p > d.name e.namep.name > ~~~ ~~~ ~~ > Service ritika Test > Developmentdavid Code > DevelopmentdavidDesign > DevelopmentdavidDesign > Developmentharry Code > Developmentharry Test > Development andrew Code > TEST83; 7 tuples ) >ACTUAL( > TEST83; select d.name, e.name, p.name from DeptBean d left join d.emps e > join e.tasks p > d.name e.namep.name > ~~~ ~~~ ~~ > CEOahmad null > CEO Tom Rayburn null >Admin george null >Admin minmei null >Sales null null > Service ritika Test > Developmentdavid Code > DevelopmentdavidDesign > DevelopmentdavidDesign > Developmentharry Code > Developmentharry Test > Development andrew Code > Development charlenenull > TEST83; 13 tuples) ] > 85 same as 83 but last join uses the (,in relationship) syntax > TEST85; select d.name, e.name, p.name from DeptBean d left joi
[jira] Closed: (OPENJPA-47) 143 arithmetic unary operator (+,-) gives parsing error
[ https://issues.apache.org/jira/browse/OPENJPA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Wisneski closed OPENJPA-47. - Resolution: Duplicate duplicate of OPENJPA-26 > 143 arithmetic unary operator (+,-) gives parsing error > --- > > Key: OPENJPA-47 > URL: https://issues.apache.org/jira/browse/OPENJPA-47 > Project: OpenJPA > Issue Type: Bug > Components: query > Environment: windows xp, derby, db2 >Reporter: George Hongell > Attachments: failureEntities.jar > > > 143 unary operator (+,-) gives parsing error > select e from EmpBean e where -(e.salary) >-10; > select e from EmpBean e where -e.salary >-10; > select e, -e.salary , +e.salary from EmpBean e where +e.salary >-10; > [ FAILED 143- bucket = fvtfull, query = select e from EmpBean e where > -(e.salary+10) > -10 : >DIFFERENCE-locations based on expected-( > diff at line 2 position 1 EXPECTED [[] ACTUAL [ ] > [( class com.dw.test.EmpBean empid=2 name=andrew salary=13.1 dept=210)] > > > > > > e > > > > > > > ) >EXPECTED( > TEST143; select e from EmpBean e where -(e.salary+10) > -10 > [( class com.dw.test.EmpBean empid=2 name=andrew salary=13.1 dept=210)] > [( class com.dw.test.EmpBean empid=4 name=george salary=0.0 dept=200)] > [( class com.dw.test.EmpBean empid=1 name=david salary=12.1 dept=210)] > [( class com.dw.test.EmpBean empid=10 name=Catalina Wei salary=0.0 dept=0)] > [( class com.dw.test.EmpBean empid=3 name=minmei salary=15.5 dept=200)] > [( class com.dw.test.EmpBean empid=5 name=ritika salary=0.0 dept=220)] > [( class com.dw.test.EmpBean empid=6 name=ahmad salary=0.0 dept=100)] > [( class com.dw.test.EmpBean empid=7 name=charlene salary=0.0 dept=210)] > [( class com.dw.test.EmpBean empid=8 name=Tom Rayburn salary=0.0 dept=100)] > [( class com.dw.test.EmpBean empid=9 name=harry salary=0.0 dept=210)] > TEST143; 10 tuples) >ACTUAL( > TEST143; select e from EmpBean e where -(e.salary+10) > -10 > > > > > > e > > > > > > > > > An error occurred while parsing the query filter 'select e from EmpBean e > where -(e.salary+10) > -10'. Error message: <4|false|0.0.0> > org.apache.openjpa.kernel.jpql.ParseE
[jira] Closed: (OPENJPA-52) bad sql pushdown, puts group by in outer select
[
https://issues.apache.org/jira/browse/OPENJPA-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Wisneski closed OPENJPA-52.
-
Resolution: Duplicate
duplicate of OPENJPA-28
> bad sql pushdown, puts group by in outer select
> ---
>
> Key: OPENJPA-52
> URL: https://issues.apache.org/jira/browse/OPENJPA-52
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, derby, db2
>Reporter: George Hongell
> Attachments: failureEntities.jar
>
>
> 457 bad sql pushdown, puts group by in outer select
> TEST457; select e.name, e.salary from EmpBean e where (e.name = Any(select
> e1.name from EmpBean e1 group by e1.name )) order by e.name
> Column reference 'T0.NAME' is invalid. For a SELECT list with a GROUP BY,
> the list may only contain grouping columns and valid aggregate expressions.
> {SELECT t0.name, t0.salary FROM EmpBean t0 JOIN EmpBean t1 ON (1 = 1) WHERE
> (t0.name = ANY((SELECT t2.name FROM EmpBean t2 GROUP BY t2.name))) GROUP BY
> t1.name ORDER BY t0.name ASC} [code=3, state=42Y36]
> s/b
> select t0.name, t0.salary FROM EmpBean t0 WHERE (t0.name = ANY((select
> t2.name FROM EmpBean t2 GROUP BY t2.name))) ORDER BY t0.name ASC
> <0|false|0.0.0> org.apache.openjpa.persistence.PersistenceException: Column
> reference 'T0.NAME' is invalid. For a SELECT list with a GROUP BY, the list
> may only contain grouping columns and valid aggregate expressions. {SELECT
> t0.name, t0.salary FROM EmpBean t0 JOIN EmpBean t1 ON (1 = 1) WHERE (t0.name
> = ANY((SELECT t2.name FROM EmpBean t2 GROUP BY t2.name))) GROUP BY t1.name
> ORDER BY t0.name ASC} [code=3, state=42Y36]
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
> at
> org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:37)
> at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
> at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
> at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
> at
> com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at
> junit.extensions.jfunc.TestletWrapper.runBare(TestletWrapper.java:116)
> at
> junit.extensions.jfunc.TestletWrapper$1.protect(TestletWrapper.java:106)
> at junit.framework.TestResult.runProtected(Unknown Source)
> at junit.extensions.jfunc.TestletWrapper.run(TestletWrapper.java:109)
> at junit.framework.TestSuite.runTest(Unknown Source)
> at junit.framework.TestSuite.run(Unknown Source)
> at junit.extensions.jfunc.JFuncSuite.run(JFuncSuite.java:134)
> at junit.extensions.jfunc.textui.JFuncRunner.doRun(JFuncRunner.java:76)
> at junit.extensions.jfunc.textui.JFuncRunner.start(JFuncRunner.java:398)
> at junit.extensions.jfunc.textui.JFuncRunner.main(JFuncRunner.java:218)
> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: Column
> reference 'T0.NAME' is invalid. For a SELECT list with a GROUP BY, the list
> may only contain grouping columns and valid aggregate expressions. {SELECT
> t0.name, t0.salary FROM EmpBean t0 JOIN EmpBean t1 ON (1 = 1) WHERE (t0.name
> = ANY((SELECT t2.name FROM EmpBean t2 GROUP BY t2.name))) GROUP BY t1.name
> ORDER BY t0.name ASC} [code=3, state=42Y36]
> at
> org.apache.op
[jira] Closed: (OPENJPA-27) SQL Parameter markers generated for literals causes DB2 SQL error SQLCODE -417(SQLSTATE 42609), 418(SQLSTATE 42610)
[ https://issues.apache.org/jira/browse/OPENJPA-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Wisneski closed OPENJPA-27. - Resolution: Duplicate duplicate of OPENJPA-22 > SQL Parameter markers generated for literals causes DB2 SQL error SQLCODE > -417(SQLSTATE 42609), 418(SQLSTATE 42610) > --- > > Key: OPENJPA-27 > URL: https://issues.apache.org/jira/browse/OPENJPA-27 > Project: OpenJPA > Issue Type: Bug > Components: query >Reporter: Catalina Wei > > over usage of parameter markers for LITERALS causes DB2 SQL errors. > Literals in the JP query if generated 'as is' in the pushdown SQL, can avoid > DB2 SQL errors. > Simple predicates caused DB2 SQL errors: > where substring(e.name, 1, 5) = 'Harry' >where mod(e.empid, 2) > 0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-16) NPE in createQuery for EJB QL with nested correlated subqueries
[ https://issues.apache.org/jira/browse/OPENJPA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Wisneski closed OPENJPA-16. - Resolution: Fixed This problem has been fixed > NPE in createQuery for EJB QL with nested correlated subqueries > --- > > Key: OPENJPA-16 > URL: https://issues.apache.org/jira/browse/OPENJPA-16 > Project: OpenJPA > Issue Type: Bug > Components: query >Reporter: David Wisneski > > EJBQL:select c from Customer c where exists ( select o from Order o where > o.cutomer = c and o.delivered=false and > exists ( select l1 from LineItem l, in(o.lineitems) as l2 where l1=l2 )) > partial stack trace is > Caused by: java.lang.NullPointerException > at > org.apache.openjpa.jdbc.kernel.exps.PCPath.initialize(PCPath.java:359) > at > org.apache.openjpa.jdbc.kernel.exps.CompareEqualExpression.initialize(CompareEqualExpression.java:64) > at > org.apache.openjpa.jdbc.kernel.exps.ContainsExpression.initialize(ContainsExpression.java:56) > at > org.apache.openjpa.jdbc.kernel.exps.BindVariableAndExpression.initialize(BindVariableAndExpression.java:49) > at > org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.initializeJoins(SelectConstructor.java:222) > at > org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.newJoinsSelect(SelectConstructor.java:166) > at > org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:88) > at org.apache.openjpa.jdbc.kernel.exps.SubQ.appendTo(SubQ.java:198) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: FishEye indexing of OpenJPA source code
FYI, the indexing finished finally (their settings for the Apache repositories are very slow so that they don't unnecessarily load down the servers). You can see the up-to-date index at: http://fisheye3.cenqua.com/changelog/openjpa/ On Jan 24, 2007, at 9:12 AM, Patrick Linskey wrote: I think that this is because it's still scanning the repository. I'm guessing that once that's done, things will settle down. We used to use FishEye for Kodo source browsing; it's awesome. -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Kevin Sutter [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 24, 2007 5:55 AM To: open-jpa-dev@incubator.apache.org Subject: Re: FishEye indexing of OpenJPA source code My first experience with FishEye. Looks interesting. How do we go about modifying the Constraints' pulldown options? For example, the list of Branches is not complete and neither is the list of Authors. Thanks, Kevin On 1/23/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: Cenqua graciously offered to complimentarily index the OpenJPA source code using their FishEye product (which I find quite nice for online searching and reporting on source code). You can view the interface at: http://fisheye3.cenqua.com/browse/openjpa
[jira] Created: (OPENJPA-119) EntityManager.clear() should not implicitly invoke the flush operation
EntityManager.clear() should not implicitly invoke the flush operation
--
Key: OPENJPA-119
URL: https://issues.apache.org/jira/browse/OPENJPA-119
Project: OpenJPA
Issue Type: Bug
Components: jpa
Reporter: Kevin Sutter
Assigned To: Kevin Sutter
>From the dev mailing list...
===
We've noticed that when EntityManager.clear() is invoked, an implicit flush()
is performed. Although the spec is cloudy in this area, I don't think this
processing is correct. The javadoc is as follows for clear():
/**
* Clear the persistence context, causing all managed
* entities to become detached. Changes made to entities that
* have not been flushed to the database will not be
* persisted.
*/
public void clear();
This indicates that Entities that have not been flushed will not be persisted.
Thus, I would say this implies that we should not be doing an implicit flush.
If the application wanted their Entities to be flushed before the clear, then
they can call the flush() method before calling clear(). We shouldn't be doing
this for them because then they have no choice.
The Pro EJB3 Java Persistence API book has similar wording on pages 138-139:
"..In many respects [clear] is semantically equivalent to a transaction
rollback. All entity instances managed by the persistence context become
detached with their state left exactly as it was when the clear() operation was
invoked..."
Our current processing for clear() eventually gets to this code:
public void detachAll(OpCallbacks call) {
beginOperation(true);
try {
if ((_flags & FLAG_FLUSH_REQUIRED) != 0)
flush();
detachAllInternal(call);
} catch (OpenJPAException ke) {
throw ke;
} catch (RuntimeException re) {
throw new GeneralException(re);
} finally {
endOperation();
}
}
Basically, if we have dirtied the Persistence Context, then do a flush()
followed by the detachAllInternal(). I don't think the clear() should be doing
this flush() operation. Any disagreement?
===
There was no disagreement, thus this JIRA issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-118) AutoDetach property has no effect
[ https://issues.apache.org/jira/browse/OPENJPA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marc Prud'hommeaux resolved OPENJPA-118. Resolution: Fixed I've corrected a couple minior problems with the patch (no ASF license header, files in DOS format, non-standard indentation & linebreaks) and committed. Tests pass, closing issue. > AutoDetach property has no effect > - > > Key: OPENJPA-118 > URL: https://issues.apache.org/jira/browse/OPENJPA-118 > Project: OpenJPA > Issue Type: Bug > Components: lib > Environment: Java SE >Reporter: David Ezzio > Attachments: TestFixesForOpenJPA-118.zip > > > Setting the openjpa.AutoDetach property to the string "commit, close, > nontx-read" has no effect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: log create table statements?
I'm dumb. I thought I was using hsqldb in memory only mode, but instead it was in file mode. -dain On Jan 31, 2007, at 6:33 AM, Kevin Sutter wrote: Another possibility is that you need to explicitly declare the classes that you want processed for automatic table creation via the ..class> elements. Scanning for available Entity classes won't work when attempting to auto create the tables. Kevin On 1/30/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: Dain- Odd ... you certainly should see the statements. Are you sure you aren't running against a database where the tables already exist (since OpenJPA won't try to create tables when they exist)? Can you see any SQL statements in the logged messages at all (e.g., when you run a query)? Can you post the logging output? (I want to make sure the log setting is not being overridden somewhere else). On Jan 30, 2007, at 3:30 PM, Dain Sundstrom wrote: > I have openjpa setup to auto create my tables, and I see openjpa > the tables using in my log, but I don't see the create table > statements. I have this in my persistenc.xml file > > > > value="buildSchema(ForeignKeys=true)"/> > > > I there some other property I need to set? > > -dain
[jira] Resolved: (OPENJPA-94) Allow MappingTool and persistence.xml to support drop-create for database schema
[ https://issues.apache.org/jira/browse/OPENJPA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey resolved OPENJPA-94. Resolution: Fixed > Allow MappingTool and persistence.xml to support drop-create for database > schema > > > Key: OPENJPA-94 > URL: https://issues.apache.org/jira/browse/OPENJPA-94 > Project: OpenJPA > Issue Type: New Feature >Reporter: Shay Banon > > Currently, in the persistence context, one can define: > > Which causes OpenJPA to build the database schema based on the mapping > defined. Currently, there is no way to define it to drop tables if they > exists before creating the database schema. This is very useful for tests > that drop (if exists) and creates new tables for each test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Perform automatic drop and create db schema
It's in 0.9.7-snapshot; I don't remember the change number. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 31, 2007 12:22 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: Perform automatic drop and create db schema > > What version of OpenJPA will this be in and did dropTable get > implemented? > > -dain > > On Jan 2, 2007, at 6:50 PM, Patrick Linskey wrote: > > >> -Original Message- > >> From: Shay Banon [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, January 02, 2007 2:33 PM > >> To: open-jpa-dev@incubator.apache.org > >> Subject: RE: Perform automatic drop and create db schema > >> > >> > >> Automatically clean that data without dropping the tables > >> makes even more > >> sense. That would be a really cool feature. > > > > Deciding that two is a quorum, and needing something to do on my > > flight > > to Salt Lake City, I implemented a new SchemaTool action called > > 'deleteTableContents' that does what you'd expect, more-or-less. > > > > Along the way, I made it possible to specify multiple SchemaTool > > actions > > via a comma-separated list. > > > > I've done some basic testing of it; more testing > (especially around > > the > > scope of the classes that the operations happen on) would probably > > be a > > good thing. > > > > You can try it out like so: > > > > > value="buildSchema,deleteTableContents" /> > > > > or: > > > > > value="refresh,deleteTableContents" /> > > > > -Patrick > > > __ > > > _ > > Notice: This email message, together with any attachments, may > > contain > > information of BEA Systems, Inc., its subsidiaries and > > affiliated > > entities, that may be confidential, proprietary, copyrighted > > and/or > > legally privileged, and is intended solely for the use of the > > individual > > or entity named in this message. If you are not the intended > > recipient, > > and have received this message in error, please immediately return > > this > > by email and then delete it. > > > >
Re: svn commit: r501955 - /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/simple/TestPersistence.java
Hi Kevin,
Sorry for commenting before reading this...
On Jan 31, 2007, at 11:39 AM, Kevin Sutter wrote:
Sorry about the "whole changed file" thing again. I thought I had
found the
problem with a doubly defined [miscellany] section in my svn config
file.
But, I changed that and I still have the problem. Like I mentioned
before,
this only seems to happen after using the SVN Eclipse plugin to do
a merge
of a patch.
Do you review the diff in Eclipse before committing?
Maybe I should just use the SVN command line to do the commit?
That works.
Or, maybe I have to manually do the Windows->Linux line ending
conversion
before committing any changes? Seems kind of error prone,
especially as my
memory continues to grow older... :-)
This also works.
I looked back in our dev mailing list and Craig had performed an
operation
on two of the OpenJPA sub-projects that supposedly helps with this
situation. Is this operation "permanent"?
Yes. For existing files that should have the eol-style, svn
automatically normalizes the files upon commit.
That is, if I run this on each
sub-project and push the changes out, will that clean up this line
ending
thing?
Yes. When you first apply the property to a file, it might give you
one of those 100% changed commits, but that will not happen on
subsequent commits.
The problem with this approach is that it seems to only work with
existing files. Any new files and we would have to remember to run
this
operation again.
Yes, IIRC this is true. New files need to have the property added.
There is a property that you can set in your environment but there's
nothing that I can recall to set an entire directory tree permanently
to this status.
Craig
Any other ideas? I would like to get this cleaned up so that my
commits
look consistent with everybody else's. When I do my diffs before
committing, only the changed lines show up. It's the commit
processing that
picks up the whole file.
Thank you and, again, my apologies!
Kevin
On 1/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: kwsutter
Date: Wed Jan 31 11:27:11 2007
New Revision: 501955
URL: http://svn.apache.org/viewvc?view=rev&rev=501955
Log:
Simple test for OPENJPA-116. Just modified the simple
TestPersistence
testcase with a new variation for testing the exception on
getDelegate()
when the EM is closed.
Modified:
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/
org/apache/openjpa/persistence/simple/TestPersistence.java
Modified:
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/
apache/openjpa/persistence/simple/TestPersistence.java
URL:
http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
persistence-jdbc/src/test/java/org/apache/openjpa/persistence/
simple/TestPersistence.java?view=diff&rev=501955&r1=501954&r2=501955
=
=
---
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/
apache/openjpa/persistence/simple/TestPersistence.java
(original)
+++
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/
apache/openjpa/persistence/simple/TestPersistence.java
Wed Jan 31 11:27:11 2007
@@ -1,114 +1,134 @@
-/*
- * Copyright 2006 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
- * See the License for the specific language governing
permissions and
- * limitations under the License.
- */
-package org.apache.openjpa.persistence.simple;
-
-import java.util.HashMap;
-import java.util.Map;
-import javax.persistence.EntityManager;
-import javax.persistence.EntityManagerFactory;
-import javax.persistence.EntityTransaction;
-import javax.persistence.Persistence;
-
-import junit.framework.TestCase;
-import junit.textui.TestRunner;
-import org.apache.openjpa.persistence.OpenJPAEntityManager;
-
-/**
- * Simple test case to get an EntityManager and perform some basic
operations.
- *
- * @author Marc Prud'hommeaux
- */
-public class TestPersistence
-extends TestCase {
-
-private EntityManagerFactory emf;
-
-public void setUp() {
-Map props = new HashMap(System.getProperties());
-props.put("openjpa.MetaDataFactory",
-"jpa(Types=" + AllFieldTypes.class.getName() + ")");
-emf = Persistence.createEntityManagerFactory("test", props);
-}
-
-public void tearDown() {
-if (emf == null)
-return;
-try {
-EntityManager em = emf.createEntityManager();
-em.getTransact
RE: svn commit: r501955 - /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/simple/TestPersistence.java
I seem to recall deciding to not use the SVN eclipse integration a few months ago -- I do all my svn work from the command line. Maybe this was why I made that decision. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Kevin Sutter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 31, 2007 11:40 AM > To: open-jpa-commits@incubator.apache.org > Subject: Re: svn commit: r501955 - > /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/jav a/org/apache/openjpa/persistence/simple/TestPersistence.java > > Sorry about the "whole changed file" thing again. I thought > I had found the > problem with a doubly defined [miscellany] section in my svn > config file. > But, I changed that and I still have the problem. Like I > mentioned before, > this only seems to happen after using the SVN Eclipse plugin > to do a merge > of a patch. Maybe I should just use the SVN command line to > do the commit? > Or, maybe I have to manually do the Windows->Linux line > ending conversion > before committing any changes? Seems kind of error prone, > especially as my > memory continues to grow older... :-) > > I looked back in our dev mailing list and Craig had performed > an operation > on two of the OpenJPA sub-projects that supposedly helps with this > situation. Is this operation "permanent"? That is, if I run > this on each > sub-project and push the changes out, will that clean up this > line ending > thing? The problem with this approach is that it seems to > only work with > existing files. Any new files and we would have to remember > to run this > operation again. > > Any other ideas? I would like to get this cleaned up so that > my commits > look consistent with everybody else's. When I do my diffs before > committing, only the changed lines show up. It's the commit > processing that > picks up the whole file. > > Thank you and, again, my apologies! > Kevin > > On 1/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Author: kwsutter > > Date: Wed Jan 31 11:27:11 2007 > > New Revision: 501955 > > > > URL: http://svn.apache.org/viewvc?view=rev&rev=501955 > > Log: > > Simple test for OPENJPA-116. Just modified the simple > TestPersistence > > testcase with a new variation for testing the exception on > getDelegate() > > when the EM is closed. > > > > Modified: > > > > > incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java /org/apache/openjpa/persistence/simple/TestPersistence.java > > > > Modified: > > > incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java /org/apache/openjpa/persistence/simple/TestPersistence.java > > URL: > > > http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-p ersistence-> jdbc/src/test/java/org/apache/openjpa/persistence/simple/TestP > ersistence.java?view=diff&rev=501955&r1=501954&r2=501955 > > > > > == > > > --- > > > incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java /org/apache/openjpa/persistence/simple/TestPersistence.java > > (original) > > +++ > > > incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java /org/apache/openjpa/persistence/simple/TestPersistence.java > > Wed Jan 31 11:27:11 2007 > > @@ -1,114 +1,134 @@ > > -/* > > - * Copyright 2006 The Apache Software Foundation. > > - * > > - * Licensed under the Apache License, Version 2.0 (the "License"); > > - * you may not use this file except in compliance with the License. > > - * You may obtain a copy of the License at > > - * > > - * http://www.apache.org/licenses/LICENSE-2.0 > > - * > > - * Unless required by applicable law or agreed to in > writing, software > > - * distributed under the License is distributed on an "AS > IS" BASIS, > > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > > implied. > > - * See the License for the specific language governing > permissions and > > - * limitations under the License. > > - */ > > -package org.apache.openjpa.persistence.simple; > > - > > -import java.util.HashMap; > > -import java.util.Map; > > -import javax.persistence.EntityManager; > > -import javax.persistence.EntityManagerFactory; > > -import javax.persistence.EntityTransaction; > > -import javax.persistence.Persistence; > > - > > -import junit.framework.TestCase; > > -import junit.textui.TestRunner; > > -import org.apache.openjpa.persistence.OpenJPAEntityManager; >
Re: Perform automatic drop and create db schema
What version of OpenJPA will this be in and did dropTable get implemented? -dain On Jan 2, 2007, at 6:50 PM, Patrick Linskey wrote: -Original Message- From: Shay Banon [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2007 2:33 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Perform automatic drop and create db schema Automatically clean that data without dropping the tables makes even more sense. That would be a really cool feature. Deciding that two is a quorum, and needing something to do on my flight to Salt Lake City, I implemented a new SchemaTool action called 'deleteTableContents' that does what you'd expect, more-or-less. Along the way, I made it possible to specify multiple SchemaTool actions via a comma-separated list. I've done some basic testing of it; more testing (especially around the scope of the classes that the operations happen on) would probably be a good thing. You can try it out like so: or: -Patrick __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: svn commit: r501955 - /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/simple/TestPersistence.java
Yeah, I tend to agree. Just wanted to get something out there for the fix
that was provided... And, doing it this way allows me to experiment more
with getting these line ending characters correct... :-) JK!
On 1/31/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
I'd prefer to see a separate test that tests all of the em methods
that are supposed to throw an exception (all of them except isOpen
and getTransaction). Putting this new test here is awkward.
Craig
On Jan 31, 2007, at 11:27 AM, [EMAIL PROTECTED] wrote:
> Author: kwsutter
> Date: Wed Jan 31 11:27:11 2007
> New Revision: 501955
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=501955
> Log:
> Simple test for OPENJPA-116. Just modified the simple
> TestPersistence testcase with a new variation for testing the
> exception on getDelegate() when the EM is closed.
>
> Modified:
> incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/
> org/apache/openjpa/persistence/simple/TestPersistence.java
>
> Modified: incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/
> java/org/apache/openjpa/persistence/simple/TestPersistence.java
> URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
> persistence-jdbc/src/test/java/org/apache/openjpa/persistence/
> simple/TestPersistence.java?view=diff&rev=501955&r1=501954&r2=501955
> ==
>
> --- incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/
> org/apache/openjpa/persistence/simple/TestPersistence.java (original)
> +++ incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/
> org/apache/openjpa/persistence/simple/TestPersistence.java Wed Jan
> 31 11:27:11 2007
> @@ -1,114 +1,134 @@
> -/*
> - * Copyright 2006 The Apache Software Foundation.
> - *
> - * Licensed under the Apache License, Version 2.0 (the "License");
> - * you may not use this file except in compliance with the License.
> - * You may obtain a copy of the License at
> - *
> - * http://www.apache.org/licenses/LICENSE-2.0
> - *
> - * Unless required by applicable law or agreed to in writing,
> software
> - * distributed under the License is distributed on an "AS IS" BASIS,
> - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> - * See the License for the specific language governing permissions
> and
> - * limitations under the License.
> - */
> -package org.apache.openjpa.persistence.simple;
> -
> -import java.util.HashMap;
> -import java.util.Map;
> -import javax.persistence.EntityManager;
> -import javax.persistence.EntityManagerFactory;
> -import javax.persistence.EntityTransaction;
> -import javax.persistence.Persistence;
> -
> -import junit.framework.TestCase;
> -import junit.textui.TestRunner;
> -import org.apache.openjpa.persistence.OpenJPAEntityManager;
> -
> -/**
> - * Simple test case to get an EntityManager and perform some basic
> operations.
> - *
> - * @author Marc Prud'hommeaux
> - */
> -public class TestPersistence
> -extends TestCase {
> -
> -private EntityManagerFactory emf;
> -
> -public void setUp() {
> -Map props = new HashMap(System.getProperties());
> -props.put("openjpa.MetaDataFactory",
> -"jpa(Types=" + AllFieldTypes.class.getName() + ")");
> -emf = Persistence.createEntityManagerFactory("test", props);
> -}
> -
> -public void tearDown() {
> -if (emf == null)
> -return;
> -try {
> -EntityManager em = emf.createEntityManager();
> -em.getTransaction().begin();
> -em.createQuery("delete from
> AllFieldTypes").executeUpdate();
> -em.getTransaction().commit();
> -em.close();
> -emf.close();
> -} catch (Exception e) {
> -}
> -}
> -
> -public void testCreateEntityManager() {
> -EntityManager em = emf.createEntityManager();
> -
> -EntityTransaction t = em.getTransaction();
> -assertNotNull(t);
> -t.begin();
> -t.setRollbackOnly();
> -t.rollback();
> -
> -// openjpa-facade test
> -assertTrue(em instanceof OpenJPAEntityManager);
> -OpenJPAEntityManager ojem = (OpenJPAEntityManager) em;
> -ojem.getFetchPlan().setMaxFetchDepth(1);
> -assertEquals(1, ojem.getFetchPlan().getMaxFetchDepth());
> -em.close();
> -}
> -
> -public void testPersist() {
> -EntityManager em = emf.createEntityManager();
> -em.getTransaction().begin();
> -em.persist(new AllFieldTypes());
> -em.getTransaction().commit();
> -em.close();
> -}
> -
> -public void testQuery() {
> -EntityManager em = emf.createEntityManager();
> -em.getTransaction().begin();
> -AllFieldTypes aft = new AllFieldTypes();
> -aft.setStringField("foo");
> -aft.setIntField(10);
> -em.persist(aft);
> -em.getTransaction().commit();
> -em.close();
> -
>
Re: svn commit: r501955 - /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/simple/TestPersistence.java
I'd prefer to see a separate test that tests all of the em methods
that are supposed to throw an exception (all of them except isOpen
and getTransaction). Putting this new test here is awkward.
Craig
On Jan 31, 2007, at 11:27 AM, [EMAIL PROTECTED] wrote:
Author: kwsutter
Date: Wed Jan 31 11:27:11 2007
New Revision: 501955
URL: http://svn.apache.org/viewvc?view=rev&rev=501955
Log:
Simple test for OPENJPA-116. Just modified the simple
TestPersistence testcase with a new variation for testing the
exception on getDelegate() when the EM is closed.
Modified:
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/
org/apache/openjpa/persistence/simple/TestPersistence.java
Modified: incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/
java/org/apache/openjpa/persistence/simple/TestPersistence.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
persistence-jdbc/src/test/java/org/apache/openjpa/persistence/
simple/TestPersistence.java?view=diff&rev=501955&r1=501954&r2=501955
==
--- incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/
org/apache/openjpa/persistence/simple/TestPersistence.java (original)
+++ incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/
org/apache/openjpa/persistence/simple/TestPersistence.java Wed Jan
31 11:27:11 2007
@@ -1,114 +1,134 @@
-/*
- * Copyright 2006 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
- * See the License for the specific language governing permissions
and
- * limitations under the License.
- */
-package org.apache.openjpa.persistence.simple;
-
-import java.util.HashMap;
-import java.util.Map;
-import javax.persistence.EntityManager;
-import javax.persistence.EntityManagerFactory;
-import javax.persistence.EntityTransaction;
-import javax.persistence.Persistence;
-
-import junit.framework.TestCase;
-import junit.textui.TestRunner;
-import org.apache.openjpa.persistence.OpenJPAEntityManager;
-
-/**
- * Simple test case to get an EntityManager and perform some basic
operations.
- *
- * @author Marc Prud'hommeaux
- */
-public class TestPersistence
-extends TestCase {
-
-private EntityManagerFactory emf;
-
-public void setUp() {
-Map props = new HashMap(System.getProperties());
-props.put("openjpa.MetaDataFactory",
-"jpa(Types=" + AllFieldTypes.class.getName() + ")");
-emf = Persistence.createEntityManagerFactory("test", props);
-}
-
-public void tearDown() {
-if (emf == null)
-return;
-try {
-EntityManager em = emf.createEntityManager();
-em.getTransaction().begin();
-em.createQuery("delete from
AllFieldTypes").executeUpdate();
-em.getTransaction().commit();
-em.close();
-emf.close();
-} catch (Exception e) {
-}
-}
-
-public void testCreateEntityManager() {
-EntityManager em = emf.createEntityManager();
-
-EntityTransaction t = em.getTransaction();
-assertNotNull(t);
-t.begin();
-t.setRollbackOnly();
-t.rollback();
-
-// openjpa-facade test
-assertTrue(em instanceof OpenJPAEntityManager);
-OpenJPAEntityManager ojem = (OpenJPAEntityManager) em;
-ojem.getFetchPlan().setMaxFetchDepth(1);
-assertEquals(1, ojem.getFetchPlan().getMaxFetchDepth());
-em.close();
-}
-
-public void testPersist() {
-EntityManager em = emf.createEntityManager();
-em.getTransaction().begin();
-em.persist(new AllFieldTypes());
-em.getTransaction().commit();
-em.close();
-}
-
-public void testQuery() {
-EntityManager em = emf.createEntityManager();
-em.getTransaction().begin();
-AllFieldTypes aft = new AllFieldTypes();
-aft.setStringField("foo");
-aft.setIntField(10);
-em.persist(aft);
-em.getTransaction().commit();
-em.close();
-
-em = emf.createEntityManager();
-em.getTransaction().begin();
-assertEquals(1, em.createQuery
-("select x from AllFieldTypes x where x.stringField =
'foo'").
-getResultList().size());
-assertEquals(0, em.createQuery
-("select x from AllFieldTypes x where x.stringField =
'bar'").
-getResultList().size());
-assertEquals(1, em.createQuery
-("select x from AllFieldTypes x where x
Re: svn commit: r501955 - /incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/simple/TestPersistence.java
This commit is way too big for its changes.
I recommend that everyone do an svn diff prior to commit to make sure
that you don't have a line-end problem, such as this appears to have.
Craig
On Jan 31, 2007, at 11:27 AM, [EMAIL PROTECTED] wrote:
Author: kwsutter
Date: Wed Jan 31 11:27:11 2007
New Revision: 501955
URL: http://svn.apache.org/viewvc?view=rev&rev=501955
Log:
Simple test for OPENJPA-116. Just modified the simple
TestPersistence testcase with a new variation for testing the
exception on getDelegate() when the EM is closed.
Modified:
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/
org/apache/openjpa/persistence/simple/TestPersistence.java
Modified: incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/
java/org/apache/openjpa/persistence/simple/TestPersistence.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
persistence-jdbc/src/test/java/org/apache/openjpa/persistence/
simple/TestPersistence.java?view=diff&rev=501955&r1=501954&r2=501955
==
--- incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/
org/apache/openjpa/persistence/simple/TestPersistence.java (original)
+++ incubator/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/
org/apache/openjpa/persistence/simple/TestPersistence.java Wed Jan
31 11:27:11 2007
@@ -1,114 +1,134 @@
-/*
- * Copyright 2006 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
- * See the License for the specific language governing permissions
and
- * limitations under the License.
- */
-package org.apache.openjpa.persistence.simple;
-
-import java.util.HashMap;
-import java.util.Map;
-import javax.persistence.EntityManager;
-import javax.persistence.EntityManagerFactory;
-import javax.persistence.EntityTransaction;
-import javax.persistence.Persistence;
-
-import junit.framework.TestCase;
-import junit.textui.TestRunner;
-import org.apache.openjpa.persistence.OpenJPAEntityManager;
-
-/**
- * Simple test case to get an EntityManager and perform some basic
operations.
- *
- * @author Marc Prud'hommeaux
- */
-public class TestPersistence
-extends TestCase {
-
-private EntityManagerFactory emf;
-
-public void setUp() {
-Map props = new HashMap(System.getProperties());
-props.put("openjpa.MetaDataFactory",
-"jpa(Types=" + AllFieldTypes.class.getName() + ")");
-emf = Persistence.createEntityManagerFactory("test", props);
-}
-
-public void tearDown() {
-if (emf == null)
-return;
-try {
-EntityManager em = emf.createEntityManager();
-em.getTransaction().begin();
-em.createQuery("delete from
AllFieldTypes").executeUpdate();
-em.getTransaction().commit();
-em.close();
-emf.close();
-} catch (Exception e) {
-}
-}
-
-public void testCreateEntityManager() {
-EntityManager em = emf.createEntityManager();
-
-EntityTransaction t = em.getTransaction();
-assertNotNull(t);
-t.begin();
-t.setRollbackOnly();
-t.rollback();
-
-// openjpa-facade test
-assertTrue(em instanceof OpenJPAEntityManager);
-OpenJPAEntityManager ojem = (OpenJPAEntityManager) em;
-ojem.getFetchPlan().setMaxFetchDepth(1);
-assertEquals(1, ojem.getFetchPlan().getMaxFetchDepth());
-em.close();
-}
-
-public void testPersist() {
-EntityManager em = emf.createEntityManager();
-em.getTransaction().begin();
-em.persist(new AllFieldTypes());
-em.getTransaction().commit();
-em.close();
-}
-
-public void testQuery() {
-EntityManager em = emf.createEntityManager();
-em.getTransaction().begin();
-AllFieldTypes aft = new AllFieldTypes();
-aft.setStringField("foo");
-aft.setIntField(10);
-em.persist(aft);
-em.getTransaction().commit();
-em.close();
-
-em = emf.createEntityManager();
-em.getTransaction().begin();
-assertEquals(1, em.createQuery
-("select x from AllFieldTypes x where x.stringField =
'foo'").
-getResultList().size());
-assertEquals(0, em.createQuery
-("select x from AllFieldTypes x where x.stringField =
'bar'").
-getResultList().size());
-assertEquals(1, em.createQuery
-("select x from AllFieldTypes x where x.intField
[jira] Commented: (OPENJPA-118) AutoDetach property has no effect
[ https://issues.apache.org/jira/browse/OPENJPA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469126 ] Patrick Linskey commented on OPENJPA-118: - Sadly, due to some maven environment issues, all tests that need to communicate with a database need to be in openjpa-persistence-jdbc. > AutoDetach property has no effect > - > > Key: OPENJPA-118 > URL: https://issues.apache.org/jira/browse/OPENJPA-118 > Project: OpenJPA > Issue Type: Bug > Components: lib > Environment: Java SE >Reporter: David Ezzio > Attachments: TestFixesForOpenJPA-118.zip > > > Setting the openjpa.AutoDetach property to the string "commit, close, > nontx-read" has no effect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-93) Sequence generation in a JTA environment should not require non-JTA datasource
[ https://issues.apache.org/jira/browse/OPENJPA-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469123 ] Patrick Linskey commented on OPENJPA-93: Has anyone tested this on non-WLS appservers? > Sequence generation in a JTA environment should not require non-JTA datasource > -- > > Key: OPENJPA-93 > URL: https://issues.apache.org/jira/browse/OPENJPA-93 > Project: OpenJPA > Issue Type: New Feature > Components: jdbc >Reporter: Patrick Linskey > Assigned To: Patrick Linskey > > When obtaining non-transactional sequence numbers in a JTA environment when > no non-jta-data-source or JDBC connection information is supplied, OpenJPA > should suspend the current transaction, perform the sequence maintenance in a > new transaction, commit, and resume the suspended transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: EntityManager.clear() semantics
Understood, Abe. I just wanted to get some agreement with you and/or Patrick before pursuing this type of change. Thanks! Kevin On 1/31/07, Abe White <[EMAIL PROTECTED]> wrote: > Basically, if we have dirtied the Persistence Context, then do a > flush() > followed by the detachAllInternal(). I don't think the clear() > should be > doing this flush() operation. Any disagreement? I agree. But note that just removing the flush call won't work for a couple of reasons: it's needed by JDO, and we'll just flush later in the DetachManager when we detect a dirty instance. So just a warning that it isn't quite as trivial a fix as it might appear to be. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: EntityManager.clear() semantics
Basically, if we have dirtied the Persistence Context, then do a flush() followed by the detachAllInternal(). I don't think the clear() should be doing this flush() operation. Any disagreement? I agree. But note that just removing the flush call won't work for a couple of reasons: it's needed by JDO, and we'll just flush later in the DetachManager when we detect a dirty instance. So just a warning that it isn't quite as trivial a fix as it might appear to be. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469093 ] Pinaki Poddar commented on OPENJPA-117: --- > Adding listeners should generally either be done as an initialization step Of course. The use case that prompted the request is the code that registers listeners do not initialize Persistence/EntityManagers. At least that is what I gathered from the users' input. Did not feel 'strongly' about the use case either which reflects in the 'minor' priority of the request. As an alternative, one may consider a listener mechanism attached to the BrokerFactory itself that will notify creation/closure of managed Brokers. Then a user code that does not explictly control Broker may get a hook during broker initialization/closure. Exposing list of listeners does raise the concern about one user removing others listeners -- but isn't one of the prevailing themes of OpenJPA architecture thrieves upon the users having deep visibility and customization of its myriad internal features? > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-118) AutoDetach property has no effect
[ https://issues.apache.org/jira/browse/OPENJPA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Ezzio updated OPENJPA-118: Attachment: TestFixesForOpenJPA-118.zip Tests and fixes for the bug. Not sure if the tests are in the right module. Perhaps they should be in openjpa-persistence instead of openjpa-persistence-jdbc. The fixes also clean up the error message when the property has invalid values to conform to the documented settings. > AutoDetach property has no effect > - > > Key: OPENJPA-118 > URL: https://issues.apache.org/jira/browse/OPENJPA-118 > Project: OpenJPA > Issue Type: Bug > Components: lib > Environment: Java SE >Reporter: David Ezzio > Attachments: TestFixesForOpenJPA-118.zip > > > Setting the openjpa.AutoDetach property to the string "commit, close, > nontx-read" has no effect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-118) AutoDetach property has no effect
AutoDetach property has no effect - Key: OPENJPA-118 URL: https://issues.apache.org/jira/browse/OPENJPA-118 Project: OpenJPA Issue Type: Bug Components: lib Environment: Java SE Reporter: David Ezzio Setting the openjpa.AutoDetach property to the string "commit, close, nontx-read" has no effect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: log create table statements?
Another possibility is that you need to explicitly declare the classes that you want processed for automatic table creation via the .. elements. Scanning for available Entity classes won't work when attempting to auto create the tables. Kevin On 1/30/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: Dain- Odd ... you certainly should see the statements. Are you sure you aren't running against a database where the tables already exist (since OpenJPA won't try to create tables when they exist)? Can you see any SQL statements in the logged messages at all (e.g., when you run a query)? Can you post the logging output? (I want to make sure the log setting is not being overridden somewhere else). On Jan 30, 2007, at 3:30 PM, Dain Sundstrom wrote: > I have openjpa setup to auto create my tables, and I see openjpa > the tables using in my log, but I don't see the create table > statements. I have this in my persistenc.xml file > > > > value="buildSchema(ForeignKeys=true)"/> > > > I there some other property I need to set? > > -dain
Re: EntityManager.clear() semantics
Craig,
If anybody would have a channel to the CTS team, I would think it would be
you. :-) I have also passed on this request to our CTS rep to see where it
takes us. Good idea. Thanks.
Kevin
On 1/30/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
Hi Kevin,
I agree with your analysis.
I would also like to see a CTS test made for this case. Do we have a
channel through BEA or IBM for requests for CTS test cases?
Another recent example is the EntityManager.getDelegate behavior
which surely should be a candidate for a CTS test.
Craig
On Jan 30, 2007, at 2:32 PM, Kevin Sutter wrote:
> Hi,
> We've noticed that when EntityManager.clear() is invoked, an implicit
> flush() is performed. Although the spec is cloudy in this area, I
> don't
> think this processing is correct. The javadoc is as follows for
> clear():
>
> /**
> * Clear the persistence context, causing all managed
> * entities to become detached. Changes made to entities that
> * have not been flushed to the database will not be
> * persisted.
> */
> public void clear();
>
> This indicates that Entities that have not been flushed will not be
> persisted. Thus, I would say this implies that we should not be
> doing an
> implicit flush. If the application wanted their Entities to be
> flushed
> before the clear, then they can call the flush() method before calling
> clear(). We shouldn't be doing this for them because then they
> have no
> choice.
>
> The Pro EJB3 Java Persistence API book has similar wording on pages
> 138-139:
>
> "..In many respects [clear] is semantically equivalent to a
> transaction
> rollback. All entity instances managed by the persistence context
> become
> detached with their state left exactly as it was when the clear()
> operation
> was invoked..."
>
> Our current processing for clear() eventually gets to this code:
>
>public void detachAll(OpCallbacks call) {
>beginOperation(true);
>try {
>if ((_flags & FLAG_FLUSH_REQUIRED) != 0)
>flush();
>detachAllInternal(call);
>} catch (OpenJPAException ke) {
>throw ke;
>} catch (RuntimeException re) {
>throw new GeneralException(re);
>} finally {
>endOperation();
>}
>}
>
> Basically, if we have dirtied the Persistence Context, then do a
> flush()
> followed by the detachAllInternal(). I don't think the clear()
> should be
> doing this flush() operation. Any disagreement?
>
> Thanks,
> Kevin
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
AW: [jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
Hello Abe, in our use Case we need the Transactionlister to implement an audit-log on PC-Object and PC-Object-Attributelevel. Because were a building a item/masterdata-Management-system. One of the main targets is to track every change on the Masterdata and then to export the Change to over 100 other Systems. In our case we want to use OPEN-JPA Broker-Listeners to replace a whole bunch of oracle Database triggers, because they make us some headaches. If you want more details, feel free to ask for. regards Marcus -Ursprüngliche Nachricht- Von: Abe White (JIRA) [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 30. Januar 2007 21:16 An: open-jpa-dev@incubator.apache.org Betreff: [jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection [ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468770 ] Abe White commented on OPENJPA-117: --- I don't see why listeners are some special case that require more isolation than all of the other state we expose. There are tons of things you can do with a broker,etc to screw other users of that broker,etc. I don't see how this is unique. That said, I also think the proposed use case is weak. I'd question the quality of an application that had code paths that could result in the same listener being added twice. Adding listeners should generally either be done as an initialization step or as a temporary step where the listener is removed immediately following a specific action. It's hard to imagine a scenario where listeners are added so haphazardly that duplicates could occur. I'd be interested to hear a more concrete use case. > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
> 1. Why could the Transactionlister not have the same > structure of API as the Instancelifecycle Listener. That mean > configuring a Default Transactionlister with the > brokerfactory, reading actual transactionlistener's in the > broker and manipulating actual transactionlisterners (that > means deactivating or changing) Personally, I think that this would be very useful. To extend on this, I think it'd be nice to be able to configure default TxListeners and InstanceLifecycleListeners declaratively, in the OpenJPA properties. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Thierling, Marcus (Salt Solutions) > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 31, 2007 1:22 AM > To: open-jpa-dev@incubator.apache.org > Subject: AW: [jira] Commented: (OPENJPA-117) Collection of > TransactionListeners registered to a Broker should be > available as unmodifiable collection > > Hello, > > the request from Pinaki regarding the transactionlistener > also are in our business need. The actual possibility of > Transactionlistener API are to small in OPEN-JPA/Kodo. It > would be great when the folloing apsects could be considered. > > 1. Why could the Transactionlister not have the same > structure of API as the Instancelifecycle Listener. That mean > configuring a Default Transactionlister with the > brokerfactory, reading actual transactionlistener's in the > broker and manipulating actual transactionlisterners (that > means deactivating or changing) > > 2. I can understand your concerns Patrick, but I'm as a > customer can tell you that KODO is great becouse you can > configure and change so much in the deep of brokers and > factory's...The responsibility not to build something what is > not working, is at the teams which are using Open-JPA. E.g. > in our team the code and Configuration which is making all > the lister stuff is "holy", that means almost untouchable > (only for the priest's)(;-). So the normal developer is not > allowed to change something on the listener Configuration. > > My post is not so on that technical Level, but I've > understand the mailing list also as a place for committing > and discussing Changerequest. When it is wanted, I could give > sometimes a view from a OPEN-JPA user. Pinaki knows a little > bit about our projects, because he was involevd in Workshop > in november in Hamburg. > > many Regards > > Marcus Thierling > > > -Ursprüngliche Nachricht- > Von: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 30. Januar 2007 19:38 > An: open-jpa-dev@incubator.apache.org > Betreff: [jira] Commented: (OPENJPA-117) Collection of > TransactionListeners registered to a Broker should be available as > unmodifiable collection > > > > [ > https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atl assian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468735 > ] > > Patrick Linskey commented on OPENJPA-117: > - > > The problem is that this lets party A get what party B set. > So if one bit of code added a particular listener, a > different bit of code could then get the listener and remove > it. Is this something that we want to make easy for people to > do? It seems like different listeners should be relatively > isolated from each other. > > > Collection of TransactionListeners registered to a Broker > should be available as unmodifiable collection > > > -- > -- > > > > Key: OPENJPA-117 > > URL: > https://issues.apache.org/jira/browse/OPENJPA-117 > > Project: OpenJPA > > Issue Type: Improvement > > Components: kernel > >Reporter: Pinaki Poddar > > Assigned To: Pinaki Poddar > >Priority: Minor > > > > Currently TransactionListeners can be added/removed to a > broker but the list of transaction listeners registered to a > particular broker is not available. Such a collection can be > made available in read-only mode so a caller can determine > whether to add a new listener or not, or whether a particular > listener is already registered. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
AW: [jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
Hello, the request from Pinaki regarding the transactionlistener also are in our business need. The actual possibility of Transactionlistener API are to small in OPEN-JPA/Kodo. It would be great when the folloing apsects could be considered. 1. Why could the Transactionlister not have the same structure of API as the Instancelifecycle Listener. That mean configuring a Default Transactionlister with the brokerfactory, reading actual transactionlistener's in the broker and manipulating actual transactionlisterners (that means deactivating or changing) 2. I can understand your concerns Patrick, but I'm as a customer can tell you that KODO is great becouse you can configure and change so much in the deep of brokers and factory's...The responsibility not to build something what is not working, is at the teams which are using Open-JPA. E.g. in our team the code and Configuration which is making all the lister stuff is "holy", that means almost untouchable (only for the priest's)(;-). So the normal developer is not allowed to change something on the listener Configuration. My post is not so on that technical Level, but I've understand the mailing list also as a place for committing and discussing Changerequest. When it is wanted, I could give sometimes a view from a OPEN-JPA user. Pinaki knows a little bit about our projects, because he was involevd in Workshop in november in Hamburg. many Regards Marcus Thierling -Ursprüngliche Nachricht- Von: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 30. Januar 2007 19:38 An: open-jpa-dev@incubator.apache.org Betreff: [jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection [ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468735 ] Patrick Linskey commented on OPENJPA-117: - The problem is that this lets party A get what party B set. So if one bit of code added a particular listener, a different bit of code could then get the listener and remove it. Is this something that we want to make easy for people to do? It seems like different listeners should be relatively isolated from each other. > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Is it possible to extend SchemaTool with MS SQL Server collation setting?
Wow~~~ You're the man, Marc! The problem is resolved!
On 1/31/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
William-
If you wanted to have all your varchar columns be specified as
"varchar(SIZE) COLLATE French_CI_AS", you could specify the property:
openjpa.jdbc.DBDictionary: VarcharTypeName="varchar{0} COLLATE
French_CI_AS"
On Jan 31, 2007, at 12:39 AM, William Cai wrote:
> Marc,
> In SQL Server, we specify Collation with below code. Therefore, we
> can't set
> the option in "type-name". In our project, there are hundreds of
> columns
> need case-sensitive collation support. It's really painful to set
> all of
> them in generated script. The best solution is custom
> SQLServerDictionary.
> I'll try it. Perhaps we need improve SQLServerDictionary at a
> point. :-)
> Thanks a lot for your help.
>
> CREATE TABLE MyTable
> (PrimaryKey int PRIMARY KEY,
> CharCol varchar(10) COLLATE French_CI_AS NOT NULL
> )
> GO
>
>
>
>
> On 1/31/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
>>
>> William-
>>
>> I don't know how you specify collation, but if it is expressible via
>> the column type name, you could always set the "type-name" of the
>> column in the schema file (e.g., setting the type-name to be "VARCHAR
>> WITH ASCII COLLATION").
>>
>> If it needs to be specific in the "CREATE TABLE" part, then the
>> schematool doesn't have any built-in way to alter that. However, you
>> can always make a custom subclass of the SQLServerDictionary and
>> override the "public String[] getCreateTableSQL(Table table)" method,
>> and make it do whatever you want.
>>
>> Lastly, you could always use the default SQL generated by the
>> schematool, and then just follow up with some custom SQL that issues
>> "ALTER TABLE" statements that change whatever attributes of the
>> tables you want.
>>
>>
>> On Jan 30, 2007, at 10:48 PM, William Cai wrote:
>>
>> > Folks,
>> > I used SchemaTool to create tables in MS SQL Server, but the schema
>> > file
>> > structure is pretty simple, so some SQL Server specific setting
>> > can't be set
>> > with SchemaTool. Does SchemaTool allow custom extension so that I
>> > can create
>> > a table with collation setting in MS SQL?
>> >
>> > Thanks,
>> > William
>>
>>
Re: Is it possible to extend SchemaTool with MS SQL Server collation setting?
William-
If you wanted to have all your varchar columns be specified as
"varchar(SIZE) COLLATE French_CI_AS", you could specify the property:
openjpa.jdbc.DBDictionary: VarcharTypeName="varchar{0} COLLATE
French_CI_AS"
On Jan 31, 2007, at 12:39 AM, William Cai wrote:
Marc,
In SQL Server, we specify Collation with below code. Therefore, we
can't set
the option in "type-name". In our project, there are hundreds of
columns
need case-sensitive collation support. It's really painful to set
all of
them in generated script. The best solution is custom
SQLServerDictionary.
I'll try it. Perhaps we need improve SQLServerDictionary at a
point. :-)
Thanks a lot for your help.
CREATE TABLE MyTable
(PrimaryKey int PRIMARY KEY,
CharCol varchar(10) COLLATE French_CI_AS NOT NULL
)
GO
On 1/31/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
William-
I don't know how you specify collation, but if it is expressible via
the column type name, you could always set the "type-name" of the
column in the schema file (e.g., setting the type-name to be "VARCHAR
WITH ASCII COLLATION").
If it needs to be specific in the "CREATE TABLE" part, then the
schematool doesn't have any built-in way to alter that. However, you
can always make a custom subclass of the SQLServerDictionary and
override the "public String[] getCreateTableSQL(Table table)" method,
and make it do whatever you want.
Lastly, you could always use the default SQL generated by the
schematool, and then just follow up with some custom SQL that issues
"ALTER TABLE" statements that change whatever attributes of the
tables you want.
On Jan 30, 2007, at 10:48 PM, William Cai wrote:
> Folks,
> I used SchemaTool to create tables in MS SQL Server, but the schema
> file
> structure is pretty simple, so some SQL Server specific setting
> can't be set
> with SchemaTool. Does SchemaTool allow custom extension so that I
> can create
> a table with collation setting in MS SQL?
>
> Thanks,
> William
Re: Is it possible to extend SchemaTool with MS SQL Server collation setting?
Marc, In SQL Server, we specify Collation with below code. Therefore, we can't set the option in "type-name". In our project, there are hundreds of columns need case-sensitive collation support. It's really painful to set all of them in generated script. The best solution is custom SQLServerDictionary. I'll try it. Perhaps we need improve SQLServerDictionary at a point. :-) Thanks a lot for your help. CREATE TABLE MyTable (PrimaryKey int PRIMARY KEY, CharCol varchar(10) COLLATE French_CI_AS NOT NULL ) GO On 1/31/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: William- I don't know how you specify collation, but if it is expressible via the column type name, you could always set the "type-name" of the column in the schema file (e.g., setting the type-name to be "VARCHAR WITH ASCII COLLATION"). If it needs to be specific in the "CREATE TABLE" part, then the schematool doesn't have any built-in way to alter that. However, you can always make a custom subclass of the SQLServerDictionary and override the "public String[] getCreateTableSQL(Table table)" method, and make it do whatever you want. Lastly, you could always use the default SQL generated by the schematool, and then just follow up with some custom SQL that issues "ALTER TABLE" statements that change whatever attributes of the tables you want. On Jan 30, 2007, at 10:48 PM, William Cai wrote: > Folks, > I used SchemaTool to create tables in MS SQL Server, but the schema > file > structure is pretty simple, so some SQL Server specific setting > can't be set > with SchemaTool. Does SchemaTool allow custom extension so that I > can create > a table with collation setting in MS SQL? > > Thanks, > William
Re: Is it possible to extend SchemaTool with MS SQL Server collation setting?
William- I don't know how you specify collation, but if it is expressible via the column type name, you could always set the "type-name" of the column in the schema file (e.g., setting the type-name to be "VARCHAR WITH ASCII COLLATION"). If it needs to be specific in the "CREATE TABLE" part, then the schematool doesn't have any built-in way to alter that. However, you can always make a custom subclass of the SQLServerDictionary and override the "public String[] getCreateTableSQL(Table table)" method, and make it do whatever you want. Lastly, you could always use the default SQL generated by the schematool, and then just follow up with some custom SQL that issues "ALTER TABLE" statements that change whatever attributes of the tables you want. On Jan 30, 2007, at 10:48 PM, William Cai wrote: Folks, I used SchemaTool to create tables in MS SQL Server, but the schema file structure is pretty simple, so some SQL Server specific setting can't be set with SchemaTool. Does SchemaTool allow custom extension so that I can create a table with collation setting in MS SQL? Thanks, William
