Re: [DISCUSS] draft Incubator graduation request
Ship it. :-) On 5/6/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi, The following is a draft request for the Incubator PMC to graduate OpenJPA to TLP status. The request will be in the form of a VOTE to recommend the board resolution (minor tweaks are being discussed in a parallel thread). Please review and comment. I'll incorporate comments as I receive them, but expect to send the request to the Incubator a few days after getting the last comment, to be sure everyone can comment on the comments. The earliest would be Wednesday 9-May-2007. Craig Dear Incubator, The OpenJPA podling respectfully requests the Incubator to consider its graduation to a Top Level Project. Please vote on recommending the attached draft board resolution. [ ] +1 Recommend to the board to establish Apache OpenJPA [ ] -1 Do not recommend establishing Apache OpenJPA because... Over the past several months the OpenJPA community has grown from a single large donation to a diverse community of contributors and users. OpenJPA meets the technical requirements for diversity, with committers from three and PPMC members from four independent organizations. Committers from other Apache projects have not only used the incubating releases as dependencies in their projects but provided patches to OpenJPA as well. The OpenJPA community prepared and voted out two releases performed by different release managers. The community readily agreed on the bike-shed issues of code formatting and indentation, and there has been no resurrection of these issues. The community had issues with commit-then-review versus review-then-commit and resolved them win-win. Most recently, a public issue regarding the proposed charter of the TLP was resolved. During the process of incubation, the PPMC learned how to govern itself, voting in new committers and PPMC members. Mentors offered invaluable advice and assistance in getting the project set up and organized. The status file for OpenJPA can be found at: http://svn.apache.org/ repos/asf/incubator/openjpa/STATUS The incubator checklist web page for OpenJPA can be found at: http:// incubator.apache.org/projects/openjpa.html Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo
[jira] Commented: (OPENJPA-51) bad sql pushdown, sub select is missing from clause
[
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494070
]
Abe White commented on OPENJPA-51:
--
Yes, the test was passing before. Have you tried against a to-one relation
rather than a to-many?
Perhaps it was never working against a to-many.
bad sql pushdown, sub select is missing from clause
---
Key: OPENJPA-51
URL: https://issues.apache.org/jira/browse/OPENJPA-51
Project: OpenJPA
Issue Type: Bug
Components: query
Environment: Windows xp, db2, derby
Reporter: George Hongell
Assigned To: David Wisneski
Fix For: 0.9.8
Attachments: failureEntities.jar, SelectImpl.java.patch
451 - bad sql pushdown sub select is missing from clause
TEST451; select e from EmpBean e where e.empid any (select e1.empid from
DeptBean d, in(d.emps) e1 where d.no = 200)
28344 TRACE [main] openjpa.jdbc.SQL - t 1094861122, conn 295440796 [0 ms]
executing prepstmnt 81790176 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
(t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
s/b
select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
WHERE t1.empid ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
200}
0|false|0.0.0 org.apache.openjpa.persistence.PersistenceException: Syntax
error: Encountered WHERE at line 1, column 520. {SELECT t2.empid, t2.bonus,
t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
t5.street WHERE (t2.empid ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
AS BIGINT) = CAST(? AS BIGINT)} [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.init(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
Re: [VOTE] Packaging with maven
+1 What would the impact be if we renamed openjpa-all to openjpa? We could change our checkout instructions to read svn co http://svn.apache.org/repos/asf/incubator/openjpa/trunkopenjpa-parent and then the directories match the artifactId's in pom.xml. The only reason I think this is worth doing is to avoid confusion for new developers down the road. It's just one more thing that we have to remember and explain. Maybe there's an impact to changing the directory name that I missed though. -Mike On 5/6/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Poking around the ActiveMQ pom.xml files, I notice that you can have a different artifactId than the module name (i.e., directory) you are in. I hadn't known you could do this. Currently, our artifacts name are: trunk/pom.xml: openjpa trunk/openjpa-all/pom.xml: openjpa-all trunk/openjpa-project/pom.xml: openjpa-project We could change these to: trunk/pom.xml: openjpa-parent trunk/openjpa-all/pom.xml: openjpa trunk/openjpa-project/pom.xml: apache-openjpa I've tested this out, and it results in the openjpa aggregate jar being named openjpa-VERSION.jar, the dependency being simply named openjpa, and the assembly is named apache-openjpa-VERSION.zip . None of the directories needed to be renamed. I've attached the patch that does this to https://issues.apache.org/jira/browse/OPENJPA-194 Since this will mess up people who currently have maven dependencies on OpenJPA (i.e., people who depend on openjpa-all will now need to depend on openjpa), we should probably get this hammered out before leaving incubation. So I've gone ahead and turned the [DISCUSS] into a [VOTE] to see if we should go ahead and do this. A vote of +1 means we should do the renaming, -1 means we should not, and 0 means don't care. The vote will remain open until Wednesday May 9th at 23:59 GMT. On May 4, 2007, at 6:55 AM, Michael Dick wrote: Some comments below On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like reopen the discussion on how to package and name our artifacts. I think the current setup could be improved, to give a better experience for users who might not be using maven for dependency management. It's easy for us to change now before graduation because once we graduate, people will need to update their dependencies anyway so there are no backward compatibility issues. The name of the single jar that has all of the openjpa stuff in it except for the documentation and examples is currently called openjpa- all. This name is confusing because unless they RTFM, people don't really know that it's not all the code you need, just all the jpa code. So I'd like to call this artifact openjpa. +1 But we already have a project with that name, and that project builds the distributions. So I'd rename the current openjpa to openjpa-dist. Its ultimate destination in the Apache mirror structure is under www.apache.org/dist/openjpa once we graduate, so having dist in the project name helps understanding that this project builds the artifacts that go into dist. Separate from the artifacts that are published via maven. +1 Finally, the openjpa-all jar includes its subcomponents as dependencies. I think this is wrong, since you end up with a class path with openjpa-all.jar as well as openjpa-kernel.jar and all the others. I would like to change this too. I did a little experimenting and it looks like the dependencies aren't needed in openjpa-all, but they are needed for openjpa-project (to populate the lib directory). Moving the dependencies into openjpa-project should be safe. We're also going to need to change the deploy logic to strip out the -project suffix from the zip files. We've talked about it before when I was releasing 0.9.7 (and before that when Marc was working on 0.9.6), but I haven't had time to look into it. It should be fairly easy to make the change. Thoughts? Craig 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! -Michael Dick
Re: [VOTE] Packaging with maven
Patrick raises a good point. Also, we might also be able to just have the openjpa aggregate jar module be in a sub-directory named openjpa without having to rename the parent module's enclosing directory, since I don't think Maven much cares what the name of the directory in which the parent module resides (I doubt it even ever looks at it). I.e., it would be located at http://svn.apache.org/ repos/asf/openjpa/trunk/openjpa/openjpa. How does that sound? On May 7, 2007, at 9:15 AM, Patrick Linskey wrote: I think it makes sense to rename dirs as appropriate. Remember that once we graduate, we'll be moving repositories anyways, so it would seem like a good opportunity to make structural changes. -Patrick On 5/7/07, Michael Dick [EMAIL PROTECTED] wrote: +1 What would the impact be if we renamed openjpa-all to openjpa? We could change our checkout instructions to read svn co http://svn.apache.org/repos/asf/incubator/openjpa/ trunkopenjpa-parent and then the directories match the artifactId's in pom.xml. The only reason I think this is worth doing is to avoid confusion for new developers down the road. It's just one more thing that we have to remember and explain. Maybe there's an impact to changing the directory name that I missed though. -Mike On 5/6/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Poking around the ActiveMQ pom.xml files, I notice that you can have a different artifactId than the module name (i.e., directory) you are in. I hadn't known you could do this. Currently, our artifacts name are: trunk/pom.xml: openjpa trunk/openjpa-all/pom.xml: openjpa-all trunk/openjpa-project/pom.xml: openjpa-project We could change these to: trunk/pom.xml: openjpa-parent trunk/openjpa-all/pom.xml: openjpa trunk/openjpa-project/pom.xml: apache-openjpa I've tested this out, and it results in the openjpa aggregate jar being named openjpa-VERSION.jar, the dependency being simply named openjpa, and the assembly is named apache-openjpa-VERSION.zip . None of the directories needed to be renamed. I've attached the patch that does this to https://issues.apache.org/jira/browse/OPENJPA-194 Since this will mess up people who currently have maven dependencies on OpenJPA (i.e., people who depend on openjpa-all will now need to depend on openjpa), we should probably get this hammered out before leaving incubation. So I've gone ahead and turned the [DISCUSS] into a [VOTE] to see if we should go ahead and do this. A vote of +1 means we should do the renaming, -1 means we should not, and 0 means don't care. The vote will remain open until Wednesday May 9th at 23:59 GMT. On May 4, 2007, at 6:55 AM, Michael Dick wrote: Some comments below On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like reopen the discussion on how to package and name our artifacts. I think the current setup could be improved, to give a better experience for users who might not be using maven for dependency management. It's easy for us to change now before graduation because once we graduate, people will need to update their dependencies anyway so there are no backward compatibility issues. The name of the single jar that has all of the openjpa stuff in it except for the documentation and examples is currently called openjpa- all. This name is confusing because unless they RTFM, people don't really know that it's not all the code you need, just all the jpa code. So I'd like to call this artifact openjpa. +1 But we already have a project with that name, and that project builds the distributions. So I'd rename the current openjpa to openjpa-dist. Its ultimate destination in the Apache mirror structure is under www.apache.org/dist/openjpa once we graduate, so having dist in the project name helps understanding that this project builds the artifacts that go into dist. Separate from the artifacts that are published via maven. +1 Finally, the openjpa-all jar includes its subcomponents as dependencies. I think this is wrong, since you end up with a class path with openjpa-all.jar as well as openjpa-kernel.jar and all the others. I would like to change this too. I did a little experimenting and it looks like the dependencies aren't needed in openjpa-all, but they are needed for openjpa-project (to populate the lib directory). Moving the dependencies into openjpa-project should be safe. We're also going to need to change the deploy logic to strip out the -project suffix from the zip files. We've talked about it before when I was releasing 0.9.7 (and before that when Marc was working on 0.9.6), but I haven't had time to look into it. It should be fairly easy to make the change. Thoughts? Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408
Re: [VOTE] Packaging with maven
directory, since I don't think Maven much cares what the name of the directory in which the parent module resides (I doubt it even ever looks at it). I.e., it would be located at http://svn.apache.org/ I think you're probably right -- currently, the dir is named 'trunk', for example. looks at it). I.e., it would be located at http://svn.apache.org/ repos/asf/openjpa/trunk/openjpa/openjpa. Isn't that one too many 'openjpa' tokens? Couldn't it just be http://svn.apache.org/repos/asf/openjpa/trunk/openjpa, instead of http://svn.apache.org/repos/asf/openjpa/trunk/openjpa-all? -Patrick On 5/7/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Patrick raises a good point. Also, we might also be able to just have the openjpa aggregate jar module be in a sub-directory named openjpa without having to rename the parent module's enclosing directory, since I don't think Maven much cares what the name of the directory in which the parent module resides (I doubt it even ever looks at it). I.e., it would be located at http://svn.apache.org/ repos/asf/openjpa/trunk/openjpa/openjpa. How does that sound? On May 7, 2007, at 9:15 AM, Patrick Linskey wrote: I think it makes sense to rename dirs as appropriate. Remember that once we graduate, we'll be moving repositories anyways, so it would seem like a good opportunity to make structural changes. -Patrick On 5/7/07, Michael Dick [EMAIL PROTECTED] wrote: +1 What would the impact be if we renamed openjpa-all to openjpa? We could change our checkout instructions to read svn co http://svn.apache.org/repos/asf/incubator/openjpa/ trunkopenjpa-parent and then the directories match the artifactId's in pom.xml. The only reason I think this is worth doing is to avoid confusion for new developers down the road. It's just one more thing that we have to remember and explain. Maybe there's an impact to changing the directory name that I missed though. -Mike On 5/6/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Poking around the ActiveMQ pom.xml files, I notice that you can have a different artifactId than the module name (i.e., directory) you are in. I hadn't known you could do this. Currently, our artifacts name are: trunk/pom.xml: openjpa trunk/openjpa-all/pom.xml: openjpa-all trunk/openjpa-project/pom.xml: openjpa-project We could change these to: trunk/pom.xml: openjpa-parent trunk/openjpa-all/pom.xml: openjpa trunk/openjpa-project/pom.xml: apache-openjpa I've tested this out, and it results in the openjpa aggregate jar being named openjpa-VERSION.jar, the dependency being simply named openjpa, and the assembly is named apache-openjpa-VERSION.zip . None of the directories needed to be renamed. I've attached the patch that does this to https://issues.apache.org/jira/browse/OPENJPA-194 Since this will mess up people who currently have maven dependencies on OpenJPA (i.e., people who depend on openjpa-all will now need to depend on openjpa), we should probably get this hammered out before leaving incubation. So I've gone ahead and turned the [DISCUSS] into a [VOTE] to see if we should go ahead and do this. A vote of +1 means we should do the renaming, -1 means we should not, and 0 means don't care. The vote will remain open until Wednesday May 9th at 23:59 GMT. On May 4, 2007, at 6:55 AM, Michael Dick wrote: Some comments below On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like reopen the discussion on how to package and name our artifacts. I think the current setup could be improved, to give a better experience for users who might not be using maven for dependency management. It's easy for us to change now before graduation because once we graduate, people will need to update their dependencies anyway so there are no backward compatibility issues. The name of the single jar that has all of the openjpa stuff in it except for the documentation and examples is currently called openjpa- all. This name is confusing because unless they RTFM, people don't really know that it's not all the code you need, just all the jpa code. So I'd like to call this artifact openjpa. +1 But we already have a project with that name, and that project builds the distributions. So I'd rename the current openjpa to openjpa-dist. Its ultimate destination in the Apache mirror structure is under www.apache.org/dist/openjpa once we graduate, so having dist in the project name helps understanding that this project builds the artifacts that go into dist. Separate from the artifacts that are published via maven. +1 Finally, the openjpa-all jar includes its subcomponents as dependencies. I think this is wrong, since you end up with a class path with openjpa-all.jar as well as openjpa-kernel.jar and all the others. I would like to change this
Re: [VOTE] Packaging with maven
On May 7, 2007, at 9:35 AM, Patrick Linskey wrote: Isn't that one too many 'openjpa' tokens? Couldn't it just be http://svn.apache.org/repos/asf/openjpa/trunk/openjpa, instead of http://svn.apache.org/repos/asf/openjpa/trunk/openjpa-all? Yes, you're right.
Re: [VOTE] Packaging with maven
+1 Patrick, you and I were writing at the same time. Gotta stop that. ;-) Craig On May 7, 2007, at 9:35 AM, Patrick Linskey wrote: directory, since I don't think Maven much cares what the name of the directory in which the parent module resides (I doubt it even ever looks at it). I.e., it would be located at http://svn.apache.org/ I think you're probably right -- currently, the dir is named 'trunk', for example. looks at it). I.e., it would be located at http://svn.apache.org/ repos/asf/openjpa/trunk/openjpa/openjpa. Isn't that one too many 'openjpa' tokens? Couldn't it just be http://svn.apache.org/repos/asf/openjpa/trunk/openjpa, instead of http://svn.apache.org/repos/asf/openjpa/trunk/openjpa-all? -Patrick On 5/7/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Patrick raises a good point. Also, we might also be able to just have the openjpa aggregate jar module be in a sub-directory named openjpa without having to rename the parent module's enclosing directory, since I don't think Maven much cares what the name of the directory in which the parent module resides (I doubt it even ever looks at it). I.e., it would be located at http://svn.apache.org/ repos/asf/openjpa/trunk/openjpa/openjpa. How does that sound? On May 7, 2007, at 9:15 AM, Patrick Linskey wrote: I think it makes sense to rename dirs as appropriate. Remember that once we graduate, we'll be moving repositories anyways, so it would seem like a good opportunity to make structural changes. -Patrick On 5/7/07, Michael Dick [EMAIL PROTECTED] wrote: +1 What would the impact be if we renamed openjpa-all to openjpa? We could change our checkout instructions to read svn co http://svn.apache.org/repos/asf/incubator/openjpa/ trunkopenjpa-parent and then the directories match the artifactId's in pom.xml. The only reason I think this is worth doing is to avoid confusion for new developers down the road. It's just one more thing that we have to remember and explain. Maybe there's an impact to changing the directory name that I missed though. -Mike On 5/6/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Poking around the ActiveMQ pom.xml files, I notice that you can have a different artifactId than the module name (i.e., directory) you are in. I hadn't known you could do this. Currently, our artifacts name are: trunk/pom.xml: openjpa trunk/openjpa-all/pom.xml: openjpa-all trunk/openjpa-project/pom.xml: openjpa-project We could change these to: trunk/pom.xml: openjpa-parent trunk/openjpa-all/pom.xml: openjpa trunk/openjpa-project/pom.xml: apache-openjpa I've tested this out, and it results in the openjpa aggregate jar being named openjpa-VERSION.jar, the dependency being simply named openjpa, and the assembly is named apache-openjpa- VERSION.zip . None of the directories needed to be renamed. I've attached the patch that does this to https://issues.apache.org/jira/browse/ OPENJPA-194 Since this will mess up people who currently have maven dependencies on OpenJPA (i.e., people who depend on openjpa-all will now need to depend on openjpa), we should probably get this hammered out before leaving incubation. So I've gone ahead and turned the [DISCUSS] into a [VOTE] to see if we should go ahead and do this. A vote of +1 means we should do the renaming, -1 means we should not, and 0 means don't care. The vote will remain open until Wednesday May 9th at 23:59 GMT. On May 4, 2007, at 6:55 AM, Michael Dick wrote: Some comments below On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like reopen the discussion on how to package and name our artifacts. I think the current setup could be improved, to give a better experience for users who might not be using maven for dependency management. It's easy for us to change now before graduation because once we graduate, people will need to update their dependencies anyway so there are no backward compatibility issues. The name of the single jar that has all of the openjpa stuff in it except for the documentation and examples is currently called openjpa- all. This name is confusing because unless they RTFM, people don't really know that it's not all the code you need, just all the jpa code. So I'd like to call this artifact openjpa. +1 But we already have a project with that name, and that project builds the distributions. So I'd rename the current openjpa to openjpa-dist. Its ultimate destination in the Apache mirror structure is under www.apache.org/dist/openjpa once we graduate, so having dist in the project name helps understanding that this project builds the artifacts that go into dist. Separate from the artifacts that are published via maven. +1 Finally, the openjpa-all jar includes its subcomponents as dependencies. I think this is wrong,
[jira] Created: (OPENJPA-236) No apparent way to generate all required SQL within a class derived from FullClassStrategy
No apparent way to generate all required SQL within a class derived from FullClassStrategy -- Key: OPENJPA-236 URL: https://issues.apache.org/jira/browse/OPENJPA-236 Project: OpenJPA Issue Type: Bug Reporter: David Ezzio FullClassStrategy has several optional methods for overriding OpenJPA's generation of SQL. However, in a simple case, there is no apparent way to generate the required SQL within a class derived from FullClassStrategy. The model consists of two classes, BizA which has a one-way, one-to-many relationship to BizB. The relationship is mapped with an inverse key within the BizB table. The custom class strategy BizBMapping attempts to insert a BizB record and is able to do so, provided that it is not contained within a BizA collection. Otherwise, the attempt to persist a BizA with a contained BizB yields a SQL exception because OpenJPA generates additional SQL that conflicts with the SQL generated within BizBMapping.customInsert. Even if OpenJPA did not generate conflicting insert statement, there is no apparent way to get the value for the A_ID column within the BizBMapping.customInsert method. This issue is critical for users who want to substitute their own SQL (such as calls to stored procedures) for all of the OpenJPA generated SQL. Synopsis of the output log: INSERT INTO BIZB (ID, INFO) VALUES (?, ?) [params=(String) B22047141, (String) random] INSERT INTO BizA (id, info) VALUES (?, ?) [params=(String) A32968849, (String) random] INSERT INTO BizB (A_ID) VALUES (?) [params=(String) A32968849] SQLException: Column 'ID' cannot accept a NULL value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-236) No apparent way to generate all required SQL within a class derived from FullClassStrategy
[ https://issues.apache.org/jira/browse/OPENJPA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Ezzio updated OPENJPA-236: Component/s: kernel Affects Version/s: 0.9.7 No apparent way to generate all required SQL within a class derived from FullClassStrategy -- Key: OPENJPA-236 URL: https://issues.apache.org/jira/browse/OPENJPA-236 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.7 Reporter: David Ezzio FullClassStrategy has several optional methods for overriding OpenJPA's generation of SQL. However, in a simple case, there is no apparent way to generate the required SQL within a class derived from FullClassStrategy. The model consists of two classes, BizA which has a one-way, one-to-many relationship to BizB. The relationship is mapped with an inverse key within the BizB table. The custom class strategy BizBMapping attempts to insert a BizB record and is able to do so, provided that it is not contained within a BizA collection. Otherwise, the attempt to persist a BizA with a contained BizB yields a SQL exception because OpenJPA generates additional SQL that conflicts with the SQL generated within BizBMapping.customInsert. Even if OpenJPA did not generate conflicting insert statement, there is no apparent way to get the value for the A_ID column within the BizBMapping.customInsert method. This issue is critical for users who want to substitute their own SQL (such as calls to stored procedures) for all of the OpenJPA generated SQL. Synopsis of the output log: INSERT INTO BIZB (ID, INFO) VALUES (?, ?) [params=(String) B22047141, (String) random] INSERT INTO BizA (id, info) VALUES (?, ?) [params=(String) A32968849, (String) random] INSERT INTO BizB (A_ID) VALUES (?) [params=(String) A32968849] SQLException: Column 'ID' cannot accept a NULL value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-236) No apparent way to generate all required SQL within a class derived from FullClassStrategy
[ https://issues.apache.org/jira/browse/OPENJPA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Ezzio updated OPENJPA-236: Attachment: OpenJPABugCustomSQL.zip Test case demonstrating the issue. No apparent way to generate all required SQL within a class derived from FullClassStrategy -- Key: OPENJPA-236 URL: https://issues.apache.org/jira/browse/OPENJPA-236 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.7 Reporter: David Ezzio Attachments: OpenJPABugCustomSQL.zip FullClassStrategy has several optional methods for overriding OpenJPA's generation of SQL. However, in a simple case, there is no apparent way to generate the required SQL within a class derived from FullClassStrategy. The model consists of two classes, BizA which has a one-way, one-to-many relationship to BizB. The relationship is mapped with an inverse key within the BizB table. The custom class strategy BizBMapping attempts to insert a BizB record and is able to do so, provided that it is not contained within a BizA collection. Otherwise, the attempt to persist a BizA with a contained BizB yields a SQL exception because OpenJPA generates additional SQL that conflicts with the SQL generated within BizBMapping.customInsert. Even if OpenJPA did not generate conflicting insert statement, there is no apparent way to get the value for the A_ID column within the BizBMapping.customInsert method. This issue is critical for users who want to substitute their own SQL (such as calls to stored procedures) for all of the OpenJPA generated SQL. Synopsis of the output log: INSERT INTO BIZB (ID, INFO) VALUES (?, ?) [params=(String) B22047141, (String) random] INSERT INTO BizA (id, info) VALUES (?, ?) [params=(String) A32968849, (String) random] INSERT INTO BizB (A_ID) VALUES (?) [params=(String) A32968849] SQLException: Column 'ID' cannot accept a NULL value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-236) No apparent way to generate all required SQL within a class derived from FullClassStrategy
[ https://issues.apache.org/jira/browse/OPENJPA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494086 ] Abe White commented on OPENJPA-236: --- One-way inverse-key-based relations are not a typical case, given that they aren't even supported in standard JPA. You might need to use a custom field mapping in conjunction with the custom class mapping. No apparent way to generate all required SQL within a class derived from FullClassStrategy -- Key: OPENJPA-236 URL: https://issues.apache.org/jira/browse/OPENJPA-236 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.7 Reporter: David Ezzio Attachments: OpenJPABugCustomSQL.zip FullClassStrategy has several optional methods for overriding OpenJPA's generation of SQL. However, in a simple case, there is no apparent way to generate the required SQL within a class derived from FullClassStrategy. The model consists of two classes, BizA which has a one-way, one-to-many relationship to BizB. The relationship is mapped with an inverse key within the BizB table. The custom class strategy BizBMapping attempts to insert a BizB record and is able to do so, provided that it is not contained within a BizA collection. Otherwise, the attempt to persist a BizA with a contained BizB yields a SQL exception because OpenJPA generates additional SQL that conflicts with the SQL generated within BizBMapping.customInsert. Even if OpenJPA did not generate conflicting insert statement, there is no apparent way to get the value for the A_ID column within the BizBMapping.customInsert method. This issue is critical for users who want to substitute their own SQL (such as calls to stored procedures) for all of the OpenJPA generated SQL. Synopsis of the output log: INSERT INTO BIZB (ID, INFO) VALUES (?, ?) [params=(String) B22047141, (String) random] INSERT INTO BizA (id, info) VALUES (?, ?) [params=(String) A32968849, (String) random] INSERT INTO BizB (A_ID) VALUES (?) [params=(String) A32968849] SQLException: Column 'ID' cannot accept a NULL value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-236) No apparent way to generate all required SQL within a class derived from FullClassStrategy
[ https://issues.apache.org/jira/browse/OPENJPA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Ezzio updated OPENJPA-236: Description: FullClassStrategy has several optional methods for overriding OpenJPA's generation of SQL. However, in a simple case, there is no apparent way to generate the required SQL within a class derived from FullClassStrategy. The model consists of two classes, BizA which has a one-way, one-to-many relationship to BizB. The relationship is mapped with a FK within the BizB table. The custom class strategy BizBMapping attempts to insert a BizB record and is able to do so, provided that it is not contained within a BizA collection. Otherwise, the attempt to persist a BizA with a contained BizB yields a SQL exception because OpenJPA generates additional SQL that conflicts with the SQL generated within BizBMapping.customInsert. Even if OpenJPA did not generate conflicting insert statement, there is no apparent way to get the value for the A_ID column within the BizBMapping.customInsert method. This issue is critical for users who want to substitute their own SQL (such as calls to stored procedures) for all of the OpenJPA generated SQL. Synopsis of the output log: INSERT INTO BIZB (ID, INFO) VALUES (?, ?) [params=(String) B22047141, (String) random] INSERT INTO BizA (id, info) VALUES (?, ?) [params=(String) A32968849, (String) random] INSERT INTO BizB (A_ID) VALUES (?) [params=(String) A32968849] SQLException: Column 'ID' cannot accept a NULL value. was: FullClassStrategy has several optional methods for overriding OpenJPA's generation of SQL. However, in a simple case, there is no apparent way to generate the required SQL within a class derived from FullClassStrategy. The model consists of two classes, BizA which has a one-way, one-to-many relationship to BizB. The relationship is mapped with an inverse key within the BizB table. The custom class strategy BizBMapping attempts to insert a BizB record and is able to do so, provided that it is not contained within a BizA collection. Otherwise, the attempt to persist a BizA with a contained BizB yields a SQL exception because OpenJPA generates additional SQL that conflicts with the SQL generated within BizBMapping.customInsert. Even if OpenJPA did not generate conflicting insert statement, there is no apparent way to get the value for the A_ID column within the BizBMapping.customInsert method. This issue is critical for users who want to substitute their own SQL (such as calls to stored procedures) for all of the OpenJPA generated SQL. Synopsis of the output log: INSERT INTO BIZB (ID, INFO) VALUES (?, ?) [params=(String) B22047141, (String) random] INSERT INTO BizA (id, info) VALUES (?, ?) [params=(String) A32968849, (String) random] INSERT INTO BizB (A_ID) VALUES (?) [params=(String) A32968849] SQLException: Column 'ID' cannot accept a NULL value. No apparent way to generate all required SQL within a class derived from FullClassStrategy -- Key: OPENJPA-236 URL: https://issues.apache.org/jira/browse/OPENJPA-236 Project: OpenJPA Issue Type: Bug Components: kernel Affects Versions: 0.9.7 Reporter: David Ezzio Attachments: OpenJPABugCustomSQL.zip FullClassStrategy has several optional methods for overriding OpenJPA's generation of SQL. However, in a simple case, there is no apparent way to generate the required SQL within a class derived from FullClassStrategy. The model consists of two classes, BizA which has a one-way, one-to-many relationship to BizB. The relationship is mapped with a FK within the BizB table. The custom class strategy BizBMapping attempts to insert a BizB record and is able to do so, provided that it is not contained within a BizA collection. Otherwise, the attempt to persist a BizA with a contained BizB yields a SQL exception because OpenJPA generates additional SQL that conflicts with the SQL generated within BizBMapping.customInsert. Even if OpenJPA did not generate conflicting insert statement, there is no apparent way to get the value for the A_ID column within the BizBMapping.customInsert method. This issue is critical for users who want to substitute their own SQL (such as calls to stored procedures) for all of the OpenJPA generated SQL. Synopsis of the output log: INSERT INTO BIZB (ID, INFO) VALUES (?, ?) [params=(String) B22047141, (String) random] INSERT INTO BizA (id, info) VALUES (?, ?) [params=(String) A32968849, (String) random] INSERT INTO BizB (A_ID) VALUES (?) [params=(String) A32968849] SQLException: Column 'ID' cannot accept a NULL value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-51) bad sql pushdown, sub select is missing from clause
[
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494138
]
Catalina Wei commented on OPENJPA-51:
-
Abe,
You are right, the code before theispatch (SelectImpl.java revision 52881)
worked for to-one relation,
but never worked for to-many relation.
Do you have any idea of fixing this problem?
bad sql pushdown, sub select is missing from clause
---
Key: OPENJPA-51
URL: https://issues.apache.org/jira/browse/OPENJPA-51
Project: OpenJPA
Issue Type: Bug
Components: query
Environment: Windows xp, db2, derby
Reporter: George Hongell
Assigned To: David Wisneski
Fix For: 0.9.8
Attachments: failureEntities.jar, SelectImpl.java.patch
451 - bad sql pushdown sub select is missing from clause
TEST451; select e from EmpBean e where e.empid any (select e1.empid from
DeptBean d, in(d.emps) e1 where d.no = 200)
28344 TRACE [main] openjpa.jdbc.SQL - t 1094861122, conn 295440796 [0 ms]
executing prepstmnt 81790176 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
(t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
s/b
select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
WHERE t1.empid ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
200}
0|false|0.0.0 org.apache.openjpa.persistence.PersistenceException: Syntax
error: Encountered WHERE at line 1, column 520. {SELECT t2.empid, t2.bonus,
t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
t5.street WHERE (t2.empid ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
AS BIGINT) = CAST(? AS BIGINT)} [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.init(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)
Re: svn commit: r536001 - /incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/enhance/PCEnhancer.java
Out of curiosity, is there an existing problem that this fixes, or did you just notice through code inspection they we weren't passing the ClassLoader in places where it appeared we should? On May 7, 2007, at 2:38 PM, [EMAIL PROTECTED] wrote: Author: pcl Date: Mon May 7 14:38:20 2007 New Revision: 536001 URL: http://svn.apache.org/viewvc?view=revrev=536001 Log: Propagate the provided classloader further into the PCEnhancer call stack. Modified: incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/ openjpa/enhance/PCEnhancer.java
Re: svn commit: r536001 - /incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/enhance/PCEnhancer.java
I needed it to get my IntelliJ plugin working. I probably could have set the thread's context classloader, but it seemed like this was a better fix. -Patrick On 5/7/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Out of curiosity, is there an existing problem that this fixes, or did you just notice through code inspection they we weren't passing the ClassLoader in places where it appeared we should? On May 7, 2007, at 2:38 PM, [EMAIL PROTECTED] wrote: Author: pcl Date: Mon May 7 14:38:20 2007 New Revision: 536001 URL: http://svn.apache.org/viewvc?view=revrev=536001 Log: Propagate the provided classloader further into the PCEnhancer call stack. Modified: incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/ openjpa/enhance/PCEnhancer.java -- Patrick Linskey 202 669 5907
[jira] Created: (OPENJPA-237) Value.setAliases does not copy alias strings
Value.setAliases does not copy alias strings Key: OPENJPA-237 URL: https://issues.apache.org/jira/browse/OPENJPA-237 Project: OpenJPA Issue Type: Bug Components: lib Affects Versions: 0.9.7 Reporter: David Ezzio The org.apache.openjpa.lib.conf.Value.setAliases method does not copy the array of strings passed as a parameter. As a result, later operations on the Value object's aliases can change the array that the caller is using. This method should be pass by value rather than by reference -- in other words, the method should copy the array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-237) Value.setAliases does not copy alias strings
[ https://issues.apache.org/jira/browse/OPENJPA-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Ezzio updated OPENJPA-237: Attachment: Value.diff SVN diff for the change required, plus a test case. Value.setAliases does not copy alias strings Key: OPENJPA-237 URL: https://issues.apache.org/jira/browse/OPENJPA-237 Project: OpenJPA Issue Type: Bug Components: lib Affects Versions: 0.9.7 Reporter: David Ezzio Attachments: Value.diff The org.apache.openjpa.lib.conf.Value.setAliases method does not copy the array of strings passed as a parameter. As a result, later operations on the Value object's aliases can change the array that the caller is using. This method should be pass by value rather than by reference -- in other words, the method should copy the array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
