[jira] Commented: (OPENJPA-238) Error in XMLFileHandler, failed to load field element with type org.apace.openjpa.util.StringId.
[ https://issues.apache.org/jira/browse/OPENJPA-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496016 ] Abe White commented on OPENJPA-238: --- Custom id classes can have either a (Class,String) or just a String constructor. So the patch can't just assume a (Class,String) constructor -- it has to check to see what the class has. That's pretty ugly and still won't cover certain cases, but it'll work for this user and previous users. If we really want to make a proper solution, we'd write out the class of the entity and the stringified oid instead of the class of the oid and the stringified oid. Then in fromXMLString we'd check to see if relMeta uses datastore identity and if so construct a LongId from the stored entity class and string. If not we'd use PCRegistry.newObjectId(Class,String). We'd also need the old processing for old XML files... we could detect an old file by maybe adding a new version attribute to the top-level element -- old files will be missing the version attribute. > Error in XMLFileHandler, failed to load field element with type > org.apace.openjpa.util.StringId. > > > Key: OPENJPA-238 > URL: https://issues.apache.org/jira/browse/OPENJPA-238 > Project: OpenJPA > Issue Type: Bug > Components: xml store >Reporter: Catalina Wei > Attachments: XMLFileHandler.java.patch > > > Problem reported by Ngo, Anh (full description with attachments can be found > in openjpa-dev mails, subject title: xml store help? > In evaluating openJPA to use for our current project. It works fine for our > need with database. But I am having problem with the XMLStoreManager. I > have two simple objects - Customer and User. Customer can have multiple > users. I look at the object store in xml file. It stored like this: > > > > version="0"> > > "1" > > > "customer1" > > > > org.apache.openjpa.util.StringId:1 > > > org.apache.openjpa.util.StringId:2 > > > > > > Shoud the Users element store User object? The XMLStoreManager failed to > load data in because it doest not know how to create this object: >org.apache.openjpa.util.StringId:1 > > Please help... -- 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] 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 - [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.(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:
[jira] Reopened: (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:all-tabpanel
]
Abe White reopened OPENJPA-51:
--
I have to reopen this, as the fix is causing a regression in our test suite.
Given an entity EntityA with a field "b" of type EntityB, the following JPQL:
select a from EntityA a where
exists (select b from a.b b where b.intfield = 1)
or
exists (select b from a.b b where b.intfield = 0)
is getting translated to:
SELECT t1.ID, t1.TYP, t1.A FROM ENTITYA t1 WHERE (
EXISTS (SELECT t0.ID FROM ENTITYB t0 WHERE t0.INTFIELD = 1 AND t1.B = t0.ID))
OR
EXISTS (SELECT t2.ID FROM ENTITYB t2, ENTITYA t3 WHERE t2.INTFIELD = 0 AND
t3.B = t2.ID))
)
Notice that the first correlated subselect is fine, but the second has lost its
correlation -- it creates a new alias for EntityA's table.
> 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 - [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.(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.NativeMe
[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_12493200
]
Abe White commented on OPENJPA-51:
--
OK, I see. You still shouldn't be using a fixed array. Use a BitSet.
As to the rest... as I said before, I don't remember how this stuff works. So
it could be wrong
and I wouldn't know it without doing more code-diving than I have time for.
It's our fault for
not having enough tests checked into OpenJPA. So after changing it to use a
BitSet,
assuming it passes all your tests, I'd vote to commit it. Once that happens
we'll see how it
fairs against our more extensive Kodo test suite.
> 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, openjpa-51.patch,
> SelectImpl.java.patch, 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 - [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.(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(DelegatingMe
[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_12493172
]
Abe White commented on OPENJPA-51:
--
No, this is no better. And now you've changed the meaning of the code.
Before, the remove-from-parent
logic was based on the key to the last call to findAlias. Now it's based on
the key to any previous call to findAlias
(so long as 0 <= alias <= 16 ??!!). The fact that you changed the meaning of
the patch seemingly without intent
and still feel it is correct doesn't give me any confidence in it.
p.s. The boolean array is pointless since you never flip the
boolean values -- you only ever set to true that I see, and then test if any
index is true later. So you could just as
easily get by with a single boolean where you "|=" its value each time.
p.p.s. I notice that you also have a "boolean removed = false"
local declared in one method and you never change its value, making the local
pointless too, unless
you meant to assign it a new value based on something somewhere.
> 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, openjpa-51.patch,
> 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 - [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.(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.testRunQueryLoop
[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_12493126
]
Abe White commented on OPENJPA-51:
--
I don't remember how any of that stuff works at all. However, the following
line in findAlias is suspect:
_removeAliasFromParent = key.toString().contains(":");
findAlias is called a lot with different keys. Setting a member field that is
used in other methods based
on whether the latest key happens to match a certain criteria seems like it
could lead to arbitrary
results in different circumstances. If there is a continuous thread of logic
that links the last call to
findAlias with the other methods where _removeAliasFromParent is used, it needs
to be make more
explicit.
> 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, openjpa-51.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 - [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.(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.DelegatingM
[jira] Commented: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios
[ https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491310 ] Abe White commented on OPENJPA-219: --- 1. Yes, clearly we'd use our org.apache.openjpa.lib.util.concurrent. ConcurrentReferenceHashMap with weak keys to hold the Classes. 2. We have no evidence that a positive cache would consume any more memory than a negative cache in this case. A positive cache's entry size for a given class is limited by the number of fields/methods in that class. A negative cache's entry size is limited only by how many nonexistent field/method names we look for. The negative cache will probably be smaller in this case except in deep inheritance hierarchies because I don't think we look for field or method names outside the inheritance hierarchy, but (a) I'm not sure of that and (b) there's no guarantee that will always be the case. 3. You know, another way to approach this would be not to cache at all, and just iterate over getDeclaredFields/Methods() looking for a match rather than using the singular getDeclaredField/Method() that throws an exception. If that gives decent performance, we wouldn't have to worry about the memory consumption and complication of caching. Bret, do you think you could try that out and see how it does? > Reflection: negative caching would be beneficial in redeployment scenarios > -- > > Key: OPENJPA-219 > URL: https://issues.apache.org/jira/browse/OPENJPA-219 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Patrick Linskey > Fix For: 0.9.8 > > Attachments: OPENJPA-219.patch > > > In a variety of situations, OpenJPA searches class hierarchies for fields. > These searches invoke Class.getDeclaredField() in order to find non-public > fields. This method throws an exception when it fails to find the specified > field, and the exception creation is, as ever, slow. > It would be useful to create a static (and thus per-classloader) > Map,Collection> of fields known not to be > available in a given class. > It may also be beneficial to maintain a cache of which fields *are* present > in a given class, but this issue is being filed as a result of a demonstrated > performance hit during deployment due to the lack of a negative cache. If we > obtain quantitative data indicating that a positive cache would be useful, we > might want to implement such a thing at that time. > Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: > domainName > at > java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown > Source) > at > org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101) > at > org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object; > (ApplicationIds.java:89) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios
[ https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491038 ] Abe White commented on OPENJPA-219: --- If we're going to cache, I don't see why we wouldn't cache the declared fields/methods rather than the nonexistent ones. It would be a simple matter of keeping a Class->Set cache, where the Set is the names of the fields/methods returned by Class.getDeclaredFields/Methods(). Then we'd have both a positive (set.contains(x)) and negative (!set.contains(x)) cache. I'd also like to see some explicit control over whether requests to find a field/method cause cache additions. It might be that we always want caching now, but it's such a general class that I can imagine naïvely using the Reflection class's helper methods on one-off random field/method requests in the future without remembering the memory consequences. If all use results in caching, that could be bad. So I'd like us to either add separate caching methods or a boolean parameter to the existing methods. And either way, we need to revisit our current use of Reflection to decide which version to use in the current code. > Reflection: negative caching would be beneficial in redeployment scenarios > -- > > Key: OPENJPA-219 > URL: https://issues.apache.org/jira/browse/OPENJPA-219 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Patrick Linskey > Fix For: 0.9.8 > > Attachments: OPENJPA-219.patch > > > In a variety of situations, OpenJPA searches class hierarchies for fields. > These searches invoke Class.getDeclaredField() in order to find non-public > fields. This method throws an exception when it fails to find the specified > field, and the exception creation is, as ever, slow. > It would be useful to create a static (and thus per-classloader) > Map,Collection> of fields known not to be > available in a given class. > It may also be beneficial to maintain a cache of which fields *are* present > in a given class, but this issue is being filed as a result of a demonstrated > performance hit during deployment due to the lack of a negative cache. If we > obtain quantitative data indicating that a positive cache would be useful, we > might want to implement such a thing at that time. > Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: > domainName > at > java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown > Source) > at > org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101) > at > org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object; > (ApplicationIds.java:89) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-214) Need to support floating point primary keys
[ https://issues.apache.org/jira/browse/OPENJPA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-214. --- Resolution: Fixed Assignee: (was: Abe White) Support float/Float and double/Double primary key fields in single-field identity handling. Fixed in revision 527648. > Need to support floating point primary keys > --- > > Key: OPENJPA-214 > URL: https://issues.apache.org/jira/browse/OPENJPA-214 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 0.9.7 >Reporter: Kevin Sutter > Fix For: 0.9.8 > > > Dain first reported this problem on the dev mailing list: > http://www.nabble.com/Float-primary-key--tf3557137.html > >My response: > >Okay, I looked at the spec a bit closer and it looks like we need to allow > >for floats as primary keys: > >"The primary key (or field or property of a composite primary key) should be > >one of the following types: > >any Java primitive type; any primitive wrapper type; java.lang.String; > >java.util.Date; > >java.sql.Date. In general, however, approximate numeric types (e.g., > >floating point types) should > >never be used in primary keys." > >Although the spec clearly recommends against the use of floating points, > >floats are a primitive type (or the Float wrapper) and need to be allowed. > >With no >special "AllowStupidApproximatePrimaryKeys" flag. :-) > >Am I trying to read too much into the spec or Dain's request? This seems to > >be something that we need to support. > >>Abe's response: > >>Given the spec section you quoted, you're definitely right. It's something > >>we need to support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-214) Need to support floating point primary keys
[ https://issues.apache.org/jira/browse/OPENJPA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White reassigned OPENJPA-214: - Assignee: Abe White > Need to support floating point primary keys > --- > > Key: OPENJPA-214 > URL: https://issues.apache.org/jira/browse/OPENJPA-214 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 0.9.7 >Reporter: Kevin Sutter > Assigned To: Abe White > Fix For: 0.9.8 > > > Dain first reported this problem on the dev mailing list: > http://www.nabble.com/Float-primary-key--tf3557137.html > >My response: > >Okay, I looked at the spec a bit closer and it looks like we need to allow > >for floats as primary keys: > >"The primary key (or field or property of a composite primary key) should be > >one of the following types: > >any Java primitive type; any primitive wrapper type; java.lang.String; > >java.util.Date; > >java.sql.Date. In general, however, approximate numeric types (e.g., > >floating point types) should > >never be used in primary keys." > >Although the spec clearly recommends against the use of floating points, > >floats are a primitive type (or the Float wrapper) and need to be allowed. > >With no >special "AllowStupidApproximatePrimaryKeys" flag. :-) > >Am I trying to read too much into the spec or Dain's request? This seems to > >be something that we need to support. > >>Abe's response: > >>Given the spec section you quoted, you're definitely right. It's something > >>we need to support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-134) Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER
[ https://issues.apache.org/jira/browse/OPENJPA-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-134. --- Resolution: Fixed Assignee: (was: Abe White) Fixed the most egregious issue, which was the cyclic fetching of eager bidirectional relations. Changed to cut off SELECTs when we're traversing the back-ptr to the owning side of a relation we've already fetched. I'm not convinced all the other issues mentioned are bugs given the eager fetch settings used. Please open new JIRAs for any individual issues that you believe remain. Fixed in revision 527565. > Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER > - > > Key: OPENJPA-134 > URL: https://issues.apache.org/jira/browse/OPENJPA-134 > Project: OpenJPA > Issue Type: Bug > Components: sql >Reporter: Catalina Wei > Fix For: 0.9.8 > > > Running JPAConfiguration default setting for EagerFetchMode > (FetchModeValue.EAGER_PARALLEL), > the SQL generated is sub-optimal. > Consider the following entities: > lineitems( OneToMany ) > Order <===> OrderItem > order ( ManyToOne ) > Case 1: why not combining 2 SQL to 1 SQL ? > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o > 2173 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1299336562 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr FROM Order t0 > 2213 demo TRACE [main] openjpa.jdbc.SQL - > [40 ms] spent > 2223 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1406424020 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t1.order_oid, t1.part_partno, > t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = t1.order_oid > ORDER BY t0.oid ASC > Case 2: extra unneeded LEFT OUTER JOIN, if eliminated, the selection aliase > t2 should change to t1: > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o left join fetch o.lineitems > 2403 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1500797300 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, > t2.cost, t2.part_partno, t2.quantity FROM Order t0 LEFT OUTER JOIN OrderItem > t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN OrderItem t2 ON t0.oid = > t2.order_oid ORDER BY t2.order_oid ASC > Case 3: why not generating 1 SQL ? > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o > 2343 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 384833264 SELECT t0.oid, t0.version, t0.amount, > t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr FROM Order > t0 > 2383 demo TRACE [main] openjpa.jdbc.SQL - > [40 ms] spent > 2393 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1722705582 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t2.oid, t2.version, t2.amount, > t2.customer_countryCode, t2.customer_id, t2.delivered, t2.shipaddr, > t1.part_partno, t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = > t1.order_oid LEFT OUTER JOIN Order t2 ON t1.order_oid = t2.oid ORDER BY > t0.oid ASC > 2393 demo TRACE [main] openjpa.jdbc.SQL - > [0 ms] spent > 3134 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 950548648 > SELECT t0.lid, t0.version, t0.cost, t1.oid, t1.version, t1.amount, > t1.customer_countryCode, t1.customer_id, t1.delivered, t1.shipaddr, > t0.part_partno, t0.quantity FROM OrderItem t0 LEFT OUTER JOIN Order t1 ON > t0.order_oid = t1.oid WHERE t0.order_oid = ? [params=(int) 88] > 3134 demo TRACE [main] openjpa.jdbc.SQL - > [0 ms] spent > Case 4: duplicate selections and redundant joins > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o left join fetch o.lineitems > 2273 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1565154634 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, > t2.cost, t3.oid, t3.version, t3.amount, t3.customer_countryCode, > t3.customer_id, t3.delivered, t3.shipaddr, t2.part_partno, t2.quantity FROM
[jira] Commented: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used
[
https://issues.apache.org/jira/browse/OPENJPA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487816
]
Abe White commented on OPENJPA-201:
---
I'm sorry, but I don't understand what you're trying to accomplish. You say
that Winery maps to two tables, but I don't see any SecondaryTable defined for
it. You give the results of various annotations, but I don't know what the
actual schema looks like or what relations you want mapped to what columns.
> Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if
> the table argument is used
> -
>
> Key: OPENJPA-201
> URL: https://issues.apache.org/jira/browse/OPENJPA-201
> Project: OpenJPA
> Issue Type: Bug
> Environment: 0.9.7-incubating-SNAPSHOT
>Reporter: George Hongell
>Priority: Minor
> Attachments: Wine.java, Winery.java
>
>
> @Entity
> @Table(name="CxWine")
> public class Wine {
> @Id
> private Integer wineid;
> ...
> @ManyToOne()
> @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="WINERYID",
> table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID", table="cxWINERY")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="wineryid")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID")
> private Winery winery;
> ...
> }
> generates
> 2744 cxwineTour TRACE [main] openjpa.jdbc.SQL - 98698722> executing stmnt 1325027066 CREATE TABLE CxWine (wineid INTEGER NOT
> NULL, cost SMALLINT, description VARCHAR(254), minimumHoldYears INTEGER,
> rating SMALLINT, stockCount INTEGER, type VARCHAR(20), version INTEGER,
> alcoholPercent DOUBLE, ava VARCHAR(40), bottler VARCHAR(40), brandName
> VARCHAR(40), labelWineClass VARCHAR(20), labelWineColor VARCHAR(20),
> estateBottled SMALLINT, hasSulfites SMALLINT, labelid INTEGER, mlContents
> INTEGER, qualityDesignation VARCHAR(40), vineyardName VARCHAR(40), vintage
> TIMESTAMP, wineName VARCHAR(40), winery_wineryid INTEGER, PRIMARY KEY
> (wineid))
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used
[
https://issues.apache.org/jira/browse/OPENJPA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487565
]
Abe White commented on OPENJPA-201:
---
The primary table for what entity? The primary table for the entity shown in
your example is clearly "CxWine", but the JoinColumn references a table
"cxWINERY". That table doesn't appear anywhere else in the example code. So
if it's not the entity's table and it's not a secondary table, then it's not a
valid mapping.
If you mean it's the primary table of the related entity, then that is not
supported by vanilla JPA. The JPA spec does not support one-sided relations
based on an inverse foreign key. You'd have to make the relation a two-sided
relation and use "mappedBy" on the side that doesn't own the foreign key.
OpenJPA does actually support one-sided inverse-key relations, however. We can
go over its support in OpenJPA, but first I'd like confirmation that that's the
intent. It doesn't seem likely that each Winery record contains a foreign key
to a single Wine record, so maybe I'm on the wrong track.
> Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if
> the table argument is used
> -
>
> Key: OPENJPA-201
> URL: https://issues.apache.org/jira/browse/OPENJPA-201
> Project: OpenJPA
> Issue Type: Bug
> Environment: 0.9.7-incubating-SNAPSHOT
>Reporter: George Hongell
>Priority: Minor
>
> @Entity
> @Table(name="CxWine")
> public class Wine {
> @Id
> private Integer wineid;
> ...
> @ManyToOne()
> @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="WINERYID",
> table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID", table="cxWINERY")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="wineryid")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID")
> private Winery winery;
> ...
> }
> generates
> 2744 cxwineTour TRACE [main] openjpa.jdbc.SQL - 98698722> executing stmnt 1325027066 CREATE TABLE CxWine (wineid INTEGER NOT
> NULL, cost SMALLINT, description VARCHAR(254), minimumHoldYears INTEGER,
> rating SMALLINT, stockCount INTEGER, type VARCHAR(20), version INTEGER,
> alcoholPercent DOUBLE, ava VARCHAR(40), bottler VARCHAR(40), brandName
> VARCHAR(40), labelWineClass VARCHAR(20), labelWineColor VARCHAR(20),
> estateBottled SMALLINT, hasSulfites SMALLINT, labelid INTEGER, mlContents
> INTEGER, qualityDesignation VARCHAR(40), vineyardName VARCHAR(40), vintage
> TIMESTAMP, wineName VARCHAR(40), winery_wineryid INTEGER, PRIMARY KEY
> (wineid))
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used
[
https://issues.apache.org/jira/browse/OPENJPA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487321
]
Abe White commented on OPENJPA-201:
---
Is the named table defined as a SecondaryTable anywhere? How is OpenJPA
supposed to know what to do with it? (This would still be a bug either way,
but I'm curious whether it's a "need better mapping validation" bug or a "not
functioning correctly" bug.)
> Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if
> the table argument is used
> -
>
> Key: OPENJPA-201
> URL: https://issues.apache.org/jira/browse/OPENJPA-201
> Project: OpenJPA
> Issue Type: Bug
> Environment: 0.9.7-incubating-SNAPSHOT
>Reporter: George Hongell
>Priority: Minor
>
> @Entity
> @Table(name="CxWine")
> public class Wine {
> @Id
> private Integer wineid;
> ...
> @ManyToOne()
> @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="WINERYID",
> table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID", table="cxWINERY")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="wineryid")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID")
> private Winery winery;
> ...
> }
> generates
> 2744 cxwineTour TRACE [main] openjpa.jdbc.SQL - 98698722> executing stmnt 1325027066 CREATE TABLE CxWine (wineid INTEGER NOT
> NULL, cost SMALLINT, description VARCHAR(254), minimumHoldYears INTEGER,
> rating SMALLINT, stockCount INTEGER, type VARCHAR(20), version INTEGER,
> alcoholPercent DOUBLE, ava VARCHAR(40), bottler VARCHAR(40), brandName
> VARCHAR(40), labelWineClass VARCHAR(20), labelWineColor VARCHAR(20),
> estateBottled SMALLINT, hasSulfites SMALLINT, labelid INTEGER, mlContents
> INTEGER, qualityDesignation VARCHAR(40), vineyardName VARCHAR(40), vintage
> TIMESTAMP, wineName VARCHAR(40), winery_wineryid INTEGER, PRIMARY KEY
> (wineid))
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-202) after invoking LRS processing in a client by calling an @LRS annotated relationship, the next em.clear()/em.close() gets org.apache.openjpa.persistence.InvalidStateExcep
[ https://issues.apache.org/jira/browse/OPENJPA-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-202. --- Resolution: Fixed Fix Version/s: 0.9.7 Changed detach process to never detach LRS fields. In the future we might consider enhancements like detaching write-only proxies for LRS fields. The only way to fully detach an LRS field, though, would be to read it all into memory, which would defeat the purpose. Fixed in revision 526253. > after invoking LRS processing in a client by calling an @LRS annotated > relationship, the next em.clear()/em.close() gets > org.apache.openjpa.persistence.InvalidStateException: You cannot transfer > large result set fields from one object or field to another > -- > > Key: OPENJPA-202 > URL: https://issues.apache.org/jira/browse/OPENJPA-202 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.7 > Environment: 0.9.7-incubating-SNAPSHOT >Reporter: George Hongell > Fix For: 0.9.7 > > Attachments: lrsBugWineryTest.zip > > > after invoking LRS processing in a client by calling an @LRS annotated > relationship, the next em.clear()/em.close() gets > org.apache.openjpa.persistence.InvalidStateException: You cannot transfer > large result set fields from one object or field to another > <4|false|0.9.7-incubating-SNAPSHOT> > org.apache.openjpa.persistence.InvalidStateException: You cannot transfer > large result set fields from one object or field to another. > at > org.apache.openjpa.util.AbstractLRSProxyCollection.setOwner(AbstractLRSProxyCollection.java:77) > at > org.apache.openjpa.kernel.DetachManager$DetachFieldManager.reproxy(DetachManager.java:523) > at > org.apache.openjpa.kernel.DetachManager.detachInternal(DetachManager.java:431) > at > org.apache.openjpa.kernel.DetachManager.detachAll(DetachManager.java:299) > at > org.apache.openjpa.kernel.BrokerImpl.detachAllInternal(BrokerImpl.java:3150) > at org.apache.openjpa.kernel.BrokerImpl.detachAll(BrokerImpl.java:3123) > at > org.apache.openjpa.kernel.DelegatingBroker.detachAll(DelegatingBroker.java:1136) > at > org.apache.openjpa.persistence.EntityManagerImpl.clear(EntityManagerImpl.java:868) > at > com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.testLargeResultSetAnnotation(BugWineryTest.java:902) > at > com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(BugWineryTest.java:146) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487085 ] Abe White commented on OPENJPA-182: --- > I know that Oracle allows you to add a FOR UPDATE clause to a query, and > this affects the results of that query. In Sun appserver CMP we use this to > set exclusive locks on rows where we want pessimistic locking behavior just > for certain tables. Again, this is exactly what our existing lock levels and APIs do. > db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS > -- > > Key: OPENJPA-182 > URL: https://issues.apache.org/jira/browse/OPENJPA-182 > Project: OpenJPA > Issue Type: New Feature > Components: jdbc > Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-182.patch, openJPA182.patch > > > A while back we changed the syntax of update locking from FOR UPDATE OF to > WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because > 1. if isolation=serializable is configured, then the syntax should be WITH > RR USE AND KEEP UDPATE LOCKS > 2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND > KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 > only supports read or exclusive locks. > 3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses. > So we change supportsLockingWithSelectRange = true in the > AbstractDB2Dictionary class and change the DB2Dictionary to append the > correct LOCKS syntax depending on vendor, release and isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows
[
https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487078
]
Abe White commented on OPENJPA-203:
---
If we don't want the subclasses to have to unset the lock value in case of
exception, another option would be to have lock() delegate to lockInternal for
setting the lock value, but to unset the lock value itself on error:
int oldValue = getLockValue(sm);
try {
lockInternal(...);
} catch (RuntimeException re) {
setLockValue(sm, oldValue);
throw re;
}
> Pessimistic Lock Manager not locking the rows
> --
>
> Key: OPENJPA-203
> URL: https://issues.apache.org/jira/browse/OPENJPA-203
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 0.9.0, 0.9.6
> Environment: ran against Oracle
>Reporter: Srinivasa
> Attachments: NotesAndDiff.txt, testcase.zip
>
>
> With pessimistic lock manager multiple EMs are able to modify the same
> object concurrently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487000 ] Abe White commented on OPENJPA-182: --- > Hopefully, this will be useful for applications where there are "hot" tables > that require pessimistic locking even though the rest of the application does > better with optimistic. That's what our lock levels and lock APIs are for. I'm still not clear on what this is adding to the mix for most DBs. > db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS > -- > > Key: OPENJPA-182 > URL: https://issues.apache.org/jira/browse/OPENJPA-182 > Project: OpenJPA > Issue Type: New Feature > Components: jdbc > Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-182.patch, openJPA182.patch > > > A while back we changed the syntax of update locking from FOR UPDATE OF to > WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because > 1. if isolation=serializable is configured, then the syntax should be WITH > RR USE AND KEEP UDPATE LOCKS > 2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND > KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 > only supports read or exclusive locks. > 3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses. > So we change supportsLockingWithSelectRange = true in the > AbstractDB2Dictionary class and change the DB2Dictionary to append the > correct LOCKS syntax depending on vendor, release and isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows
[ https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486999 ] Abe White commented on OPENJPA-203: --- Looks good. Although I think I'd prefer to make lockInternal() responsible for setting the lock level rather than having to set it and unset it so that lock() can set it again... it's just too ugly. So instead we just remove the setting of the lock level in lock() and make VersionLockManager only unset the lock level in its lockInternal if an exception occurs. PessimisticLockManager wouldn't have to change (outside of the changes already in your patch) because it delegates to super.lockInternal already, so the lock level would get set appropriately. > Pessimistic Lock Manager not locking the rows > -- > > Key: OPENJPA-203 > URL: https://issues.apache.org/jira/browse/OPENJPA-203 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6 > Environment: ran against Oracle >Reporter: Srinivasa > Attachments: NotesAndDiff.txt, testcase.zip > > > With pessimistic lock manager multiple EMs are able to modify the same > object concurrently. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486987 ] Abe White commented on OPENJPA-182: --- What is setting the isolation level this way actually doing? For anything other than DB2 right now, it looks like it doesn't do anything. And even for DB2, it's unclear to me exactly what the isolation level hint is doing, and why the information can't be gleaned from the global setting or the connection. It seems very misleading to me to have a setIsolationLevel API (or generic "IsolationLevel" hint) that doesn't actually change the connection's isolation level. If we can determine that this API is actually useful for more than DB2, and if we can name it appropriately for what it actually does, then I like Patrick's proposal of a FetchPlan API. The fact that all FetchPlan properties can be expressed as hints should make everyone happy. But if this is just a DB2 thing, then we should rename the hint to have a DB2-specific name and be done with it IMO. > db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS > -- > > Key: OPENJPA-182 > URL: https://issues.apache.org/jira/browse/OPENJPA-182 > Project: OpenJPA > Issue Type: New Feature > Components: jdbc > Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-182.patch, openJPA182.patch > > > A while back we changed the syntax of update locking from FOR UPDATE OF to > WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because > 1. if isolation=serializable is configured, then the syntax should be WITH > RR USE AND KEEP UDPATE LOCKS > 2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND > KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 > only supports read or exclusive locks. > 3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses. > So we change supportsLockingWithSelectRange = true in the > AbstractDB2Dictionary class and change the DB2Dictionary to append the > correct LOCKS syntax depending on vendor, release and isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
[
https://issues.apache.org/jira/browse/OPENJPA-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White closed OPENJPA-197.
-
Resolution: Invalid
> @Version property doesn't ensure integrity when performing the merge operation
> --
>
> Key: OPENJPA-197
> URL: https://issues.apache.org/jira/browse/OPENJPA-197
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 0.9.7
>Reporter: Jacek Laskowski
>
> See the simple test case:
> {
> Query query = em.createQuery("SELECT o FROM Osoba o WHERE o.imie
> = 'Jacek' AND o.nazwisko = 'Laskowski'");
> final Osoba osoba = (Osoba) query.getSingleResult();
> final Long numerOsoby = osoba.getNumer(); // numer is the pk
> long wersja = osoba.getWersja(); // wersja is a versioned property
> {
> EntityTransaction tx = em.getTransaction();
> tx.begin();
> Osoba osobaWersja0 = em.find(Osoba.class, numerOsoby);
> assert osobaWersja0.getWersja() == wersja;
> osobaWersja0.setImie("change");
> em.flush();
> wersja++;
> assert osobaWersja0.getWersja() == wersja;
> tx.commit();
> assert osobaWersja0.getWersja() == wersja;
> em.refresh(osobaWersja0);
> assert osobaWersja0.getWersja() == wersja;
> }
> {
> em.clear(); // osoba is now detached
> final String noweImie = "Yet another name change";
> osoba.setImie(noweImie);
> EntityTransaction tx = em.getTransaction();
> tx.begin();
> Osoba osobaWersja1 = em.find(Osoba.class, numerOsoby);
> osobaWersja1.setImie("and another");
> tx.commit(); // change is on its way to database
> wersja++;
> assert osobaWersja1.getWersja() == wersja;
> assert osobaWersja1.getWersja() != osoba.getWersja();
> if
> (em.getClass().getCanonicalName().equals("org.apache.openjpa.persistence.EntityManagerImpl"))
> {
> Osoba osobaPoMerge = em.merge(osoba);
> assert osobaPoMerge.getImie().equals(osoba.getImie());
> assert osobaPoMerge.getImie().equals(noweImie);
> em.getTransaction().begin();
> try {
> em.flush();
> assert false;
> } catch (/* OptimisticLock */Exception oczekiwano) {
> em.getTransaction().rollback();
> }
> }
> }
> }
> It works fine with Apache OpenJPA 0.9.7-SNAPSHOT with the sources on the past
> Friday. Hibernate EntityManager 3.3.1 and TopLink Essentials 2.0 BUILD 40
> throw exception as the detached entity is merged to em. According to the
> spec 9.1.17 Version Annotation p. 178 (and the javadoc -
> http://java.sun.com/javaee/5/docs/api/javax/persistence/Version.html - too):
> The Version annotation specifies the version field or property of an entity
> class that serves as its optimistic lock value. The version is used to ensure
> integrity when performing the merge operation and for optimistic concurrency
> control.
> So, I think that it's a bug in OpenJPA.
> BTW, I'm still unable to send emails to open-jpa-dev. Who should I contact to
> in order to fix it?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-134) Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER
[ https://issues.apache.org/jira/browse/OPENJPA-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White reassigned OPENJPA-134: - Assignee: Abe White > Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER > - > > Key: OPENJPA-134 > URL: https://issues.apache.org/jira/browse/OPENJPA-134 > Project: OpenJPA > Issue Type: Bug > Components: sql >Reporter: Catalina Wei > Assigned To: Abe White > Fix For: 0.9.7 > > > Running JPAConfiguration default setting for EagerFetchMode > (FetchModeValue.EAGER_PARALLEL), > the SQL generated is sub-optimal. > Consider the following entities: > lineitems( OneToMany ) > Order <===> OrderItem > order ( ManyToOne ) > Case 1: why not combining 2 SQL to 1 SQL ? > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o > 2173 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1299336562 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr FROM Order t0 > 2213 demo TRACE [main] openjpa.jdbc.SQL - > [40 ms] spent > 2223 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1406424020 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t1.order_oid, t1.part_partno, > t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = t1.order_oid > ORDER BY t0.oid ASC > Case 2: extra unneeded LEFT OUTER JOIN, if eliminated, the selection aliase > t2 should change to t1: > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o left join fetch o.lineitems > 2403 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1500797300 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, > t2.cost, t2.part_partno, t2.quantity FROM Order t0 LEFT OUTER JOIN OrderItem > t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN OrderItem t2 ON t0.oid = > t2.order_oid ORDER BY t2.order_oid ASC > Case 3: why not generating 1 SQL ? > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o > 2343 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 384833264 SELECT t0.oid, t0.version, t0.amount, > t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr FROM Order > t0 > 2383 demo TRACE [main] openjpa.jdbc.SQL - > [40 ms] spent > 2393 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1722705582 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t2.oid, t2.version, t2.amount, > t2.customer_countryCode, t2.customer_id, t2.delivered, t2.shipaddr, > t1.part_partno, t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = > t1.order_oid LEFT OUTER JOIN Order t2 ON t1.order_oid = t2.oid ORDER BY > t0.oid ASC > 2393 demo TRACE [main] openjpa.jdbc.SQL - > [0 ms] spent > 3134 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 950548648 > SELECT t0.lid, t0.version, t0.cost, t1.oid, t1.version, t1.amount, > t1.customer_countryCode, t1.customer_id, t1.delivered, t1.shipaddr, > t0.part_partno, t0.quantity FROM OrderItem t0 LEFT OUTER JOIN Order t1 ON > t0.order_oid = t1.oid WHERE t0.order_oid = ? [params=(int) 88] > 3134 demo TRACE [main] openjpa.jdbc.SQL - > [0 ms] spent > Case 4: duplicate selections and redundant joins > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o left join fetch o.lineitems > 2273 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1565154634 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, > t2.cost, t3.oid, t3.version, t3.amount, t3.customer_countryCode, > t3.customer_id, t3.delivered, t3.shipaddr, t2.part_partno, t2.quantity FROM > Order t0 LEFT OUTER JOIN OrderItem t1 ON t0.oid = t1.order_oid LEFT OUTER > JOIN OrderItem t2 ON t0.oid = t2.order_oid LEFT OUTER JOIN Order t3 ON > t2.order_oid = t3.oid ORDER BY t2.order_oid ASC -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-191) cannot define composite ID that incorproates @ManyToOne field
[ https://issues.apache.org/jira/browse/OPENJPA-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White closed OPENJPA-191. - Resolution: Invalid The given test case is invalid. Per the docs, the book field in the PageId class must be of type String to match the primary key field type of Book. Please reopen if that doesn't work. > cannot define composite ID that incorproates @ManyToOne field > - > > Key: OPENJPA-191 > URL: https://issues.apache.org/jira/browse/OPENJPA-191 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.6 > Environment: java se 5 > derby >Reporter: Jeffrey Blatttman >Priority: Minor > Attachments: book.zip > > > cannot define composite ID that incorproates @ManyToOne field. see sample > test case attached (book.zip). this is a maven2 project, and you can > reproduce the bug by starting derby on localhost and doing a "mvn install". > the resulting error message during enhancement is: > [java] Exception in thread "main" <4|true|0.9.6-incubating> > org.apache.openjpa.util.MetaDataException: The id class specified by type > "class com.mycompany.book.Page" does not match the primary key fields of the > class. Make sure your identity class has the same primary keys as your > persistent type, that the access types are the same, and if you are getting > this error at runtime, that you have your persistent class since last > compiling your identity class. > [java] FailedObject: book [java.lang.String] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-187) MEMBER OF query fails on OpenJPA, but works fine with TopLink and Hibernate EM
[
https://issues.apache.org/jira/browse/OPENJPA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484899
]
Abe White commented on OPENJPA-187:
---
Does it work if you actually look up the "Apache OpenEJB" Projekt instance
through the EntityManager rather than constructing a new one? It might be that
OpenJPA is recognizing that the given Projekt isn't actually persistent.
> MEMBER OF query fails on OpenJPA, but works fine with TopLink and Hibernate EM
> --
>
> Key: OPENJPA-187
> URL: https://issues.apache.org/jira/browse/OPENJPA-187
> Project: OpenJPA
> Issue Type: Bug
> Components: query
>Affects Versions: 0.9.7
>Reporter: Jacek Laskowski
>
> What's wrong with the following query?
> Query query = em.createQuery("SELECT DISTINCT o FROM Osoba o WHERE :projekt
> MEMBER OF o.projekty");
> query.setParameter("projekt", new Projekt("Apache OpenEJB",
> RodzajProjektu.OTWARTY));
> List osoby = query.getResultList();
> assert osoby.size() == 1 : "Otrzymano " + osoby.size();
> where Projekt is an entity where @Id is of type String (the first input
> parameter in the two-param constructor above).
> TopLink 2.0 BUILD 40 and Hibernate EntityManager 3.3.0.GA work fine whereas
> OpenJPA 0.9.7-SNAPSHOT finishes with the java.lang.AssertionError error (it's
> the test itself actually, but since the query returns 0 elements the issue
> originates in OpenJPA).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-181) ClassCastException when executing bulk delete on an entity that owns a OneToOne with a Cascade.DELETE when DataCache is on
[
https://issues.apache.org/jira/browse/OPENJPA-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-181.
---
Resolution: Fixed
Fix Version/s: 0.9.7
Fixed in SVN revision 523046. See test case added to TestBulkJPQLAndDataCache.
> ClassCastException when executing bulk delete on an entity that owns a
> OneToOne with a Cascade.DELETE when DataCache is on
> --
>
> Key: OPENJPA-181
> URL: https://issues.apache.org/jira/browse/OPENJPA-181
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 0.9.7
>Reporter: Jonathan Feinberg
> Fix For: 0.9.7
>
>
> Given an entity class A which owns a OneToOne entity of class B, and given a
> cascade on that OneToOne that includes DELETE, an attempt to bulk-delete A
> when using the DataCache results in a stack trace like the following:
> java.lang.ClassCastException:
> org.apache.openjpa.datacache.QueryCacheStoreQuery cannot be cast to
> org.apache.openjpa.kernel.ExpressionStoreQuery
> at
> org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:674)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:979)
> at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1005)
> ... 28 more
> The proximate cause for the bug is that when the JDBCStoreQuery does this:
> private Table getTable(FieldMapping fm, Table table) {
> if (fm.getCascadeDelete() != ValueMetaData.CASCADE_NONE)
> return INVALID;
> it causes "isSingleTableMapping" to be considered false, which in turn
> permits executeBulkOperation to return null. Meanwhile, back in
> DataStoreExecutor:
>public Number executeDelete(StoreQuery q, Object[] params) {
> Number num = ((ExpressionStoreQuery) q).executeDelete(this, _meta,
> _metas, _subs, _facts, _exps, params);
> if (num == null)
> return q.getContext().deleteInMemory(this, params); // <-
> now we have come here because executeDelete punted
> return num;
> }
> So deleteInMemory gets called in QueryImpl:
>public Number deleteInMemory(StoreQuery.Executor executor,
> Object[] params) {
> try {
> Object o = execute(executor, params);
> , but a DataStoreExecutor doesn't know how to execute the
> QueryCacheStoreQuery that it gets.
> Somehwere, something is too unwrapped, or not wrapped enough. Good luck!
> Workaround:
> If A owns B, then instead of cascade=CascadeType.ALL, you can
> @Entity
> class A {
> B myThing;
> @OneToOne(cascade = { CascadeType.PERSIST, CascadeType.MERGE,
> CascadeType.REFRESH })
>B getMyThing() { return myThing; }
> }
> @Entity
> class B {
> A owner;
> @ForeignKey(deleteAction=ForeignKeyAction.CASCADE)
> A getOwner() { return owner; }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484474 ] Abe White commented on OPENJPA-168: --- Something is wrong with my email system so instead of replying to the SVN commit message, I'm posting my comments on the commit of this patch here. I didn't go through the entire commit, but what I saw looked really good. There are, however, a few problems I'd like to see fixed: 1. The formatting is messed up (in that it is unlike all our other formatting) in many places. Indentation is off, spaces are missing before opening braces or added before line-ending semicolons, etc. Can you change the formatting to be consistent with the rest of the codebase? 2. The point of making the optimize hint string a static constant is not only to avoid typo errors when we use it internally, but also to make it available to users. In this way it is exactly like the constants in org.apache.openjpa.kernel.QueryFlushModes, for example. I'd like to see the constant removed from AbstractStoreQuery. Instead, I'd like to see an org.apache.openjpa.kernel.QueryHints interface with a HINT_RESULT_COUNT defined, and I'd like to see org.apache.openjpa.persistence.OpenJPAQuery implement this interface, just as it does for QueryFlushModes. This will allow both our internal code -- through QueryHints -- and user code -- through OpenJPAQuery -- to use the constant. 3. This is much more of a matter of personal opinion, but I think the added code is over-commented. The new SelectExecutor.setExpectedResultCount method should be thoroughly documented, but IMO we don't need comments explaining what we're doing every time we invoke the method. The code speaks for itself, and over-commenting always runs the danger of the comments falling out of synch with the code. > sql optimize n rows query hint > -- > > Key: OPENJPA-168 > URL: https://issues.apache.org/jira/browse/OPENJPA-168 > Project: OpenJPA > Issue Type: New Feature >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-168.patch.txt, OPENJPA-168.patch2.txt > > > There werre various comments from Patrick, Abe and Kevin Sutter about the > code that I checked related to Optimize hint. So I have gone back and > relooked at this and wil be making some changes. At Kevin's suggestion I > will do this through a JIRA feature so that folks will have opportunity to > comment on this before the code is actually done and checked in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-175) Eager selects by PagingResultObjectProvider may not use the FetchBatchSize
[
https://issues.apache.org/jira/browse/OPENJPA-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482931
]
Abe White commented on OPENJPA-175:
---
1. Are you also going to fix InExpression to honor the DBDictionary's new in
clause limit?
2. After reviewing the patch some more, I propose the following simplified
version:
// try to find a good page size. if the known size < batch size, use
// it. if the batch size is set, then use that; if it's sorta close
// to the size, then use the size / 2 to get two full pages rather
// than a possible big one and small one
int batch = getFetchConfiguration().getFetchBatchSize();
int pageSize;
if (batch < 0)
pageSize = (int) size;
else {
if (batch == 0)
batch = 50; // reasonable default
if (size <= batch)
pageSize = (int) size;
else if (size <= batch * 2) {
if (size % 2 == 0)
pageSize = (int) (size / 2);
else
pageSize = (int) (size / 2 + 1);
} else
pageSize = batch;
}
> Eager selects by PagingResultObjectProvider may not use the FetchBatchSize
> --
>
> Key: OPENJPA-175
> URL: https://issues.apache.org/jira/browse/OPENJPA-175
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 0.9.0, 0.9.6
>Reporter: Srinivasa
> Attachments: OPENJPA-175-patch.txt, OPENJPA-175-patch.txt
>
>
> The PagingResultObjectProvider during initialization does checks to determine
> the appropriate pageSize. While this logic caps the size to 50 and addresses
> determining an appropriate page size, it doesn't always conform to the set
> batch size. For example with the size being 1000 and FetchBatchSize set to
> say 500, the page size is determined to be 50 resulting in eager selects
> happening in batches of 50 when the user expects it to be in batches of 500.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482904 ] Abe White commented on OPENJPA-168: --- > The reason for using -1 is that we want to differentiate between cases where > the user added a hint to optimize for 1 row versus where we internally > generated the value (getSingleResult,singleRelationshiptraversal etc). That makes sense, though the use case seems vanishingly small (when would the user explicitly optimize for one row but also include a to-many eager join?). How about instead of using -1 to indicate "an artificial single result", we change the setExpectedResults API on Select (or SelectExecutor if we go that route) to take an additional "boolean force" parameter that is set to true when it's a user-specified count, and false when it's an artificial expectation. Internally we can keep track of whether the expected count is forced with another bit flag among those already used in SelectImpl. When the count is not forced, we ignore it in the presence of a to-many eager join. This API seems more clear-cut to me, in addition to being more general (even if we don't necessarily need the additional generality at this point). > The fact of the matter is that the optimize clause generation for various > dictionaries is different in terms of syntax and where the clause appears in > the select string.So I am not sure if u really want to generalize the > configuration of row optimization to the base DBDictionary Fair enough -- I had forgotten that it was so different for different databases. > sql optimize n rows query hint > -- > > Key: OPENJPA-168 > URL: https://issues.apache.org/jira/browse/OPENJPA-168 > Project: OpenJPA > Issue Type: New Feature >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-168.patch.txt > > > There werre various comments from Patrick, Abe and Kevin Sutter about the > code that I checked related to Optimize hint. So I have gone back and > relooked at this and wil be making some changes. At Kevin's suggestion I > will do this through a JIRA feature so that folks will have opportunity to > comment on this before the code is actually done and checked in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-175) Eager selects by PagingResultObjectProvider may not use the FetchBatchSize
[ https://issues.apache.org/jira/browse/OPENJPA-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482821 ] Abe White commented on OPENJPA-175: --- I'll have to see the code in context once it's checked in because I'm not very good at reading patches, but it looks good to me. > Eager selects by PagingResultObjectProvider may not use the FetchBatchSize > -- > > Key: OPENJPA-175 > URL: https://issues.apache.org/jira/browse/OPENJPA-175 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.0, 0.9.6 >Reporter: Srinivasa > Attachments: OPENJPA-175-patch.txt, OPENJPA-175-patch.txt > > > The PagingResultObjectProvider during initialization does checks to determine > the appropriate pageSize. While this logic caps the size to 50 and addresses > determining an appropriate page size, it doesn't always conform to the set > batch size. For example with the size being 1000 and FetchBatchSize set to > say 500, the page size is determined to be 50 resulting in eager selects > happening in batches of 50 when the user expects it to be in batches of 500. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-177) When using NOT NULL constraint on foreign key it is not possible to use CascadeType.ALL and GeneratedId
[
https://issues.apache.org/jira/browse/OPENJPA-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482815
]
Abe White commented on OPENJPA-177:
---
OpenJPA will insert records in the order that you persist the corresponding
objects. When you persist in an order that would violate foreign key
constraints, OpenJPA attempts to insert null and then update the foreign key
value in a separate statement. If you use non-nullable constraints, though,
you must persist your objects in the correct order.
> When using NOT NULL constraint on foreign key it is not possible to use
> CascadeType.ALL and GeneratedId
> ---
>
> Key: OPENJPA-177
> URL: https://issues.apache.org/jira/browse/OPENJPA-177
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 0.9.6
> Environment: Windows XP, IBM 32-bit SDK 5.0, WebSphere 6.1
>Reporter: Daniel Gajdos
>
> When using on entity Application
> @OneToOne(cascade = CascadeType.ALL)
> @JoinColumn(name = "C_PERSON_ID", nullable=false)
> @ForeignKey
> private Person person;
> and on entity Person using generated ID, it fails on inserting Application
> because of performing db actions in this order:
> INSERT INTO T_APPLICATION (C_ID, C_APPLICATION_NUMBER, C_APPLIED_DATE,
> C_STATUS) VALUES (:1, :2, :3, :4) - here it tries to insert null value as
> C_PERSON_ID, which is not permited because of nullable=false
> declaration. This declaration creates NOT NULL constraint on C_PERSON_ID.
> INSERT INTO NSVISP.T_PERSON (C_ID, C_BIRTH_DATE, C_FIRST_NAME, C_LAST_NAME)
> VALUES (:1, :2, :3, :4)
> UPDATE NSVISP.T_APPLICATION SET C_PERSON_ID = :1 WHERE C_ID = :2
> Error reported from DB:
> org.apache.openjpa.lib.jdbc.ReportingSQLException: ORA-01400: cannot insert
> NULL into ("T_APPLICATION"."C_PERSON_ID")
> Is there any chance to change the order in which this operations are
> executed? On this type of constraint we have to insert Person before
> inserting Application and include the generated Person Id into insert
> statement for Application. Otherwise we have to deffer the NOT NULL
> constraint which can be dangerous and it is not defered initialy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
[
https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482484
]
Abe White commented on OPENJPA-132:
---
Sorry Kevin; I didn't see your comment before committing. As my resolution
comment states, though, I can back my fix out if we decide we don't like it.
> java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
>
>
> Key: OPENJPA-132
> URL: https://issues.apache.org/jira/browse/OPENJPA-132
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Reporter: Michael Dick
>Priority: Minor
> Fix For: 0.9.7
>
> Attachments: OpenJPA-132.patch.txt
>
>
> Opening JIRA report to track the following problem (posted to development
> forum
> http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
>
> I'm getting the following exception when I try to fetch an entity with a
> java.sql.Date as the id :
> java.lang.NoSuchMethodError:
> org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
> at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
> at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
> at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
> at org.apache.openjpa.kernel.StateManagerImpl.initialize
> (StateManagerImpl.java:247)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
> at
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
> at
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
> at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
> at org.apache.openjpa.kernel.DelegatingBroker.find
> (DelegatingBroker.java:169)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
> at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
> 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)
> . . .
> It's coming from the generated bytecode which expects there to be a getId
> method that returns the same type of the Id, however java.sql.Date is using
> the same ID class as java.util.Date. Do we need a separate class for
> java.sql.Date?
> Responses from Patrick and Craig follow. The consensus so far is to provide
> ID separate classes for java.sql.Date and java.util.Date.
> It looks like we either need a separate type for java.sql.Date (and
> presumably java.sql.Timestamp), or we need to change the logic to accept
> a getId() method that returns a type that is assignable from the id
> field's type.
> -Patrick
> It's probably cleaner if we have separate classes for the different
> types. That is, have the getId method in the new
> org.apache.openjpa.util.SQLDateId return the proper type
> (java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
> really the same as java.util.Date.
> -Craig
> FTR, I think that I prefer separate classes as well; it's clearer, and
> avoids any ambiguity with other subclasses in the future.
> -Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
[
https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-132.
---
Resolution: Fixed
Fixed in SVN revision 520522. We can back out if we decide to use an
alternative fix strategy in the future.
> java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
>
>
> Key: OPENJPA-132
> URL: https://issues.apache.org/jira/browse/OPENJPA-132
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Reporter: Michael Dick
>Priority: Minor
> Fix For: 0.9.7
>
> Attachments: OpenJPA-132.patch.txt
>
>
> Opening JIRA report to track the following problem (posted to development
> forum
> http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
>
> I'm getting the following exception when I try to fetch an entity with a
> java.sql.Date as the id :
> java.lang.NoSuchMethodError:
> org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
> at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
> at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
> at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
> at org.apache.openjpa.kernel.StateManagerImpl.initialize
> (StateManagerImpl.java:247)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
> at
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
> at
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
> at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
> at org.apache.openjpa.kernel.DelegatingBroker.find
> (DelegatingBroker.java:169)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
> at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
> 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)
> . . .
> It's coming from the generated bytecode which expects there to be a getId
> method that returns the same type of the Id, however java.sql.Date is using
> the same ID class as java.util.Date. Do we need a separate class for
> java.sql.Date?
> Responses from Patrick and Craig follow. The consensus so far is to provide
> ID separate classes for java.sql.Date and java.util.Date.
> It looks like we either need a separate type for java.sql.Date (and
> presumably java.sql.Timestamp), or we need to change the logic to accept
> a getId() method that returns a type that is assignable from the id
> field's type.
> -Patrick
> It's probably cleaner if we have separate classes for the different
> types. That is, have the getId method in the new
> org.apache.openjpa.util.SQLDateId return the proper type
> (java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
> really the same as java.util.Date.
> -Craig
> FTR, I think that I prefer separate classes as well; it's clearer, and
> avoids any ambiguity with other subclasses in the future.
> -Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[
https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482421
]
Abe White commented on OPENJPA-168:
---
Comments on the proposed patch:
- I don't like the whole scheme of setting the expected result count to -1 for
anything "artificial". It's confusing and unnecessary. Just set it to the
number of expected "primary" results, and the DBDictionary can invoke
sel.hasEagerJoin(true) to figure out if the expected count can be used. Or
just have the getter for the expected count always return 0 if there is an
eager to-many join (or better yet, turn -1 into a value meaning "unknown" and
have it return -1, which would then also be the default when no expected count
is set).
- I still think there should be a way to get rid of Union.is/setSingleResult by
moving the expected result property to SelectExecutor -- which both Select and
Union extend -- and taking advantage of the new expected result ("1" obviously
indicates a single result).
- If you're going to validate the value of the user-supplied hint in the JPA
QueryImpl, you might as well transform it into a Number at that point before
setting it into the FetchConfiguration. Also, I'd accept any Number, not just
an Integer (technically we should accept any whole number, but that's a pain to
implement). Then in the JDBC layer, you can just cast the hint value directly
to a Number and forgo validating it and checking for String values a second
time.
- DB2 really cares whether you use "optimize for 1 row" vs. "optimize for 1
rows"? That's ugly.
- We should probably generalize the configuration of row optimization to the
base DBDictionary with an override mechanism.
- If you're going to invoke setUnique(true) on the underlying query from the
JPA QueryImpl's getSingleResult, you need to do three things:
1. Unset it in a finally clause, because the very next call might be to
getResultList, and in general getSingleResult shouldn't have stateful side
effects.
2. Change the kernel's QueryImpl to throw an exception when unique is set but
the query doesn't return any results. Right now it allows 0 results and will
return null, which is indistinguishable from a projection on a null field that
returned 1 result.
3. Get rid of the code immediately following in getSingleResult that extracts
the value if a List is returned, because after setting the unique flag on the
underlying query, it will never return a List.
- The hint key should be a constant in the kernel's Query interface or
somewhere like that.
> sql optimize n rows query hint
> --
>
> Key: OPENJPA-168
> URL: https://issues.apache.org/jira/browse/OPENJPA-168
> Project: OpenJPA
> Issue Type: New Feature
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-168.patch.txt
>
>
> There werre various comments from Patrick, Abe and Kevin Sutter about the
> code that I checked related to Optimize hint. So I have gone back and
> relooked at this and wil be making some changes. At Kevin's suggestion I
> will do this through a JIRA feature so that folks will have opportunity to
> comment on this before the code is actually done and checked in.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482411 ] Abe White commented on OPENJPA-168: --- > when I am executing the 1st select I see 3 eagerKeys in the eagerKey map in > the debugger (dept,mgr,emps) but the selectImpl.hasEagerJoin(toMany) method > returns false.So my question is that inspite of seeing emps in the eagerKey > map how come this method returns false. Because emps is being selected via a parallel select, not a to-many join in the primary select. > sql optimize n rows query hint > -- > > Key: OPENJPA-168 > URL: https://issues.apache.org/jira/browse/OPENJPA-168 > Project: OpenJPA > Issue Type: New Feature >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-168.patch.txt > > > There werre various comments from Patrick, Abe and Kevin Sutter about the > code that I checked related to Optimize hint. So I have gone back and > relooked at this and wil be making some changes. At Kevin's suggestion I > will do this through a JIRA feature so that folks will have opportunity to > comment on this before the code is actually done and checked in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-175) Eager selects by PagingResultObjectProvider may not use the FetchBatchSize
[ https://issues.apache.org/jira/browse/OPENJPA-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482409 ] Abe White commented on OPENJPA-175: --- +1, with some caveats: - The proposed patch doesn't handle the common cases where the FetchBatchSize is -1 (unlimited) or 0 (driver default). - I'm a little nervous about defaulting the in clause limit to "unlimited" when we don't have much info on actual database limits other than Oracle. > Eager selects by PagingResultObjectProvider may not use the FetchBatchSize > -- > > Key: OPENJPA-175 > URL: https://issues.apache.org/jira/browse/OPENJPA-175 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.0, 0.9.6 >Reporter: Srinivasa Segu > Attachments: OPENJPA-175-patch.txt > > > The PagingResultObjectProvider during initialization does checks to determine > the appropriate pageSize. While this logic caps the size to 50 and addresses > determining an appropriate page size, it doesn't always conform to the set > batch size. For example with the size being 1000 and FetchBatchSize set to > say 500, the page size is determined to be 50 resulting in eager selects > happening in batches of 50 when the user expects it to be in batches of 500. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
[
https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482259
]
Abe White commented on OPENJPA-132:
---
I have a fix ready to commit that consists of about 6 lines of enhancer code to
account for Date subclasses when using DateId, just as we account for Object
subclasses when using ObjectId. The fix avoids the new type constant, new
identity class, and all the additional "case" statements for SQL dates in the
patch proposed by Michael Dick. Additionally, the fix should work with
java.sql.Time and java.sql.Timestamp too; Michael's fix will not. I believe
this is a simpler, better solution. I also have a test case for SQL date id's
ready to commit; we can use it with either my patch or Michael's. I will hold
off on committing until we resolve whose patch to use.
> java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
>
>
> Key: OPENJPA-132
> URL: https://issues.apache.org/jira/browse/OPENJPA-132
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Reporter: Michael Dick
>Priority: Minor
> Fix For: 0.9.7
>
> Attachments: OpenJPA-132.patch.txt
>
>
> Opening JIRA report to track the following problem (posted to development
> forum
> http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
>
> I'm getting the following exception when I try to fetch an entity with a
> java.sql.Date as the id :
> java.lang.NoSuchMethodError:
> org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
> at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
> at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
> at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
> at org.apache.openjpa.kernel.StateManagerImpl.initialize
> (StateManagerImpl.java:247)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
> at
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
> at
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
> at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
> at org.apache.openjpa.kernel.DelegatingBroker.find
> (DelegatingBroker.java:169)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
> at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
> 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)
> . . .
> It's coming from the generated bytecode which expects there to be a getId
> method that returns the same type of the Id, however java.sql.Date is using
> the same ID class as java.util.Date. Do we need a separate class for
> java.sql.Date?
> Responses from Patrick and Craig follow. The consensus so far is to provide
> ID separate classes for java.sql.Date and java.util.Date.
> It looks like we either need a separate type for java.sql.Date (and
> presumably java.sql.Timestamp), or we need to change the logic to accept
> a getId() method that returns a type that is assignable from the id
> field's type.
> -Patrick
> It's probably cleaner if we have separate classes for the different
> types. That is, have the getId method in the new
> org.apache.openjpa.util.SQLDateId return the proper type
> (java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
> really the same as java.util.Date.
> -Craig
> FTR, I think that I prefer separate classes as well; it's clearer, and
> avoids any ambiguity with other subclasses in the future.
> -Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-174) error when find()'ing an abstract class
[ https://issues.apache.org/jira/browse/OPENJPA-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-174. --- Resolution: Fixed Fix Version/s: 0.9.7 Only affected abstract base types with a single String id field. Fixed in SVN revision 520117. Added test case in org.apache.openjpa.persistence.inheritance.TestFindAbstractClass. > error when find()'ing an abstract class > --- > > Key: OPENJPA-174 > URL: https://issues.apache.org/jira/browse/OPENJPA-174 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.6 > Environment: Java SE 5 > Derby >Reporter: Jeffrey Blatttman > Fix For: 0.9.7 > > Attachments: abstracttest.zip, pom.zip > > > class B extends A > A is abstract > B is concrete > i have persisted an instance of B. now i try: > A a = em.find(A.class, anId); > openjpa fails with: > ... Cannot create new application identity instance for abstract class > "class A" > if i change the find to: > A a = em.find(B.class, anId); > openjpa works okay. > note that i have two test cases. one is my real model, and one is the simple > A and B class example above. my real model fails, where the simple A, B class > example works as expected. so, it's is either a side affect of some other > issue, or there is something wrong in my model and the error message is > misleading or lacking information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480920 ] Abe White commented on OPENJPA-168: --- I don't recall any way to know whether a given Select it is a top-level Select or a parallel Select. Note that if you take my advice and implement this as an ExpectedResultCount property of SelectExecutor (which can also replace the isSingleResult propertyof Union), then you don't need to know. The query/storemanager/whatever that constructs the top-level select will set the expected count based on hints / knowledge, and the dictionary will use it as needed. It won't get passed to parallel eager selects accidentally. > sql optimize n rows query hint > -- > > Key: OPENJPA-168 > URL: https://issues.apache.org/jira/browse/OPENJPA-168 > Project: OpenJPA > Issue Type: New Feature >Reporter: David Wisneski > Assigned To: David Wisneski > > There werre various comments from Patrick, Abe and Kevin Sutter about the > code that I checked related to Optimize hint. So I have gone back and > relooked at this and wil be making some changes. At Kevin's suggestion I > will do this through a JIRA feature so that folks will have opportunity to > comment on this before the code is actually done and checked in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-171) EntityManager.getReference() returns an object of a wronc class
[ https://issues.apache.org/jira/browse/OPENJPA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480510 ] Abe White commented on OPENJPA-171: --- I attempted to reproduce this in a very simple test case but failed. We'll need a user-supplied test case. As a technical aside, I'm having trouble seeing how the "T getReference(Class cls, Object id)" method could possibly return anything other than a "T" instance. > EntityManager.getReference() returns an object of a wronc class > --- > > Key: OPENJPA-171 > URL: https://issues.apache.org/jira/browse/OPENJPA-171 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.6 >Reporter: Stefano Juri > > I have a simple class system : a PersonImpl owns a set of AbstractAddresses. > An AbstractAddress can be an EMailAddressImpl or a PostalAddressImpl. All > these objects extend AbstractBusinessObject. > When I call entityManager.getReference(PersonImpl.class, "1") I get the > EMailAddressImpl object with id "1" instead of a PersonImpl object. > If I get the object with a query (select p from PersonImpl p where p.id='1') > everything is ok. > My mapping file is : > http://java.sun.com/xml/ns/persistence/orm"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm > http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"; > version="1.0"> > class="ch.admin.bit.fw2.bm.AbstractBusinessObjectImpl"> > > > >generator="TimeSeq"/> >sequence-name="time()"/> > > > > > > > > > > > > > > > > > > E > > > > > > > > > > > > P > > > > > > > > > > > > > > > > > > > > > > > > > > target-entity="ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl"> > > >/> > > > > > > > And the database creation script is : > -- > -- Create Table ADDRESS > -- > Create table ADDRESS ( > ID VARCHAR(20) NOT NULL, > DISCRIMINANT CHARACTER(1)NOT NULL, > ADDRESS_NAME VARCHAR(35) NOT NULL, > EMAIL_DOMAIN VARCHAR(50) , > EMAIL_NAME VARCHAR(50) , > FIRST_NAME VARCHAR(35) , > LAST_NAME VARCHAR(35) , > STREET VARCHAR(35) , > CITY VARCHAR(35) , > ZIPVARCHAR(10) , > COUNTRYCHARACTER(2), > VERSIONTIMESTAMP > ) > ; > -- > -- Create Primary Key PRIMARY_KEY > -- > alter table ADDRESS > add constraint PERSON_KEY > Primary Key (ID); > -- > -- Create Table PERSON > -- > Create table PERSON ( > ID VARCHAR(20) NOT NULL, > FIRST_NAME VARCHAR(35) NOT NULL, > LAST_NAME VARCHAR(35) NOT NULL, > TITLE VARCHAR(35) N
[jira] Commented: (OPENJPA-171) EntityManager.getReference() returns an object of a wronc class
[ https://issues.apache.org/jira/browse/OPENJPA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480455 ] Abe White commented on OPENJPA-171: --- It would speed things up a lot if you attached a working test case demonstrating the problem. > EntityManager.getReference() returns an object of a wronc class > --- > > Key: OPENJPA-171 > URL: https://issues.apache.org/jira/browse/OPENJPA-171 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.6 >Reporter: Stefano Juri > > I have a simple class system : a PersonImpl owns a set of AbstractAddresses. > An AbstractAddress can be an EMailAddressImpl or a PostalAddressImpl. All > these objects extend AbstractBusinessObject. > When I call entityManager.getReference(PersonImpl.class, "1") I get the > EMailAddressImpl object with id "1" instead of a PersonImpl object. > If I get the object with a query (select p from PersonImpl p where p.id='1') > everything is ok. > My mapping file is : > http://java.sun.com/xml/ns/persistence/orm"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm > http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"; > version="1.0"> > class="ch.admin.bit.fw2.bm.AbstractBusinessObjectImpl"> > > > >generator="TimeSeq"/> >sequence-name="time()"/> > > > > > > > > > > > > > > > > > > E > > > > > > > > > > > > P > > > > > > > > > > > > > > > > > > > > > > > > > > target-entity="ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl"> > > >/> > > > > > > > And the database creation script is : > -- > -- Create Table ADDRESS > -- > Create table ADDRESS ( > ID VARCHAR(20) NOT NULL, > DISCRIMINANT CHARACTER(1)NOT NULL, > ADDRESS_NAME VARCHAR(35) NOT NULL, > EMAIL_DOMAIN VARCHAR(50) , > EMAIL_NAME VARCHAR(50) , > FIRST_NAME VARCHAR(35) , > LAST_NAME VARCHAR(35) , > STREET VARCHAR(35) , > CITY VARCHAR(35) , > ZIPVARCHAR(10) , > COUNTRYCHARACTER(2), > VERSIONTIMESTAMP > ) > ; > -- > -- Create Primary Key PRIMARY_KEY > -- > alter table ADDRESS > add constraint PERSON_KEY > Primary Key (ID); > -- > -- Create Table PERSON > -- > Create table PERSON ( > ID VARCHAR(20) NOT NULL, > FIRST_NAME VARCHAR(35) NOT NULL, > LAST_NAME VARCHAR(35) NOT NULL, > TITLE VARCHAR(35) NOT NULL, > VERSIONTIMESTAMP > ) > ; > -- > -- Create Primary Key SQL060816161507820 > --
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480177 ] Abe White commented on OPENJPA-168: --- 1. I think the hint name should be more like "openjpa.hint.OptimizeResultCount". It should be "hint" and not "hints" to match the existent "openjpa.hint.OracleSelectHint". And I see no reason to tie it to SQL. 2. I don't think we need a FetchConfiguration instance variable. For find() calls and loading hollow objects we always know we're only loading one instance because we use the StoreManager.load() call internally. There are similar internal APIs used only when traversing a to-one relation. So the JDBCStoreManager or relation field strategies can set the proper expected result count into the Select directly. Much better than having to set a FetchConfiguration value and then make sure it disappears for subsequent selects. The only problem is Query.getSingleResult, because right now we execute the query as a multi-result query and then extract the one result at the JPA layer. We don't have to do it this way, though. The underlying kernel Query already has a "Unique" property you can set to indicate a single result. The property doesn't have quite the semantics we want, because it allows a query that returns 0 results whereas that's an error in JPA. We can't just change the Unique semantics because of JDO, but we could certainly make it configurable on the Query instance whether a Unique query can legally return 0 results. So if we start using the Unique property rather than extracting the single result at the JPA layer, we'll know when the user is using getSingleResult when we construct the Select, and we can again set the expected number of results directly into the Select. 3. The SelectImpl already knows when it has to-many eager joins; no need for additional state. See SelectImpl.hasEagerJoin(boolean toMany). 4. "getOptimizeClause" seems too generic. I'm also not clear on what use it has in the base DBDictionary class if you state that individual dictionaries will still have to override toSelect themselves to insert the optimization SQL. > sql optimize n rows query hint > -- > > Key: OPENJPA-168 > URL: https://issues.apache.org/jira/browse/OPENJPA-168 > Project: OpenJPA > Issue Type: New Feature >Reporter: David Wisneski > Assigned To: David Wisneski > > There werre various comments from Patrick, Abe and Kevin Sutter about the > code that I checked related to Optimize hint. So I have gone back and > relooked at this and wil be making some changes. At Kevin's suggestion I > will do this through a JIRA feature so that folks will have opportunity to > comment on this before the code is actually done and checked in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-46) true, false not case insensitive, gets null pointer exception
[ https://issues.apache.org/jira/browse/OPENJPA-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White reassigned OPENJPA-46: Assignee: Patrick Linskey > true, false not case insensitive, gets null pointer exception > - > > Key: OPENJPA-46 > URL: https://issues.apache.org/jira/browse/OPENJPA-46 > Project: OpenJPA > Issue Type: Bug > Components: query > Environment: windows xp, derby, db2 >Reporter: George Hongell > Assigned To: Patrick Linskey >Priority: Minor > Fix For: 0.9.7 > > Attachments: failureEntities.jar > > > 140 - true,false should be case insensitive - gets npe > [ FAILED 140- bucket = fvtfull, query = select e from EmpBean e where > (e.isManager = True) : >EXPECTED( > TEST140; select e from EmpBean e where (e.isManager = True) > [( class com.dw.test.EmpBean empid=2 name=andrew salary=13.1 dept=210)] > [( class com.dw.test.EmpBean empid=1 name=david salary=12.1 dept=210)] > TEST140; 2 tuples ) >ACTUAL( > TEST140; select e from EmpBean e where (e.isManager = True) > e > > null > TEST140; 1 tuple) ] > at > org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:672) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:934) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746) > ... 23 more > <4|false|0.0.0> org.apache.openjpa.persistence.ArgumentException: null > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:755) > 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: java.lang.NullPointerException > at > org.apache.openjpa.jdbc.kernel.exps.PCPath.initialize(PCPath.java:362) > at > org.apache.openjpa.jdbc.kernel.exps.CompareEqualExpression.initialize(CompareEqualExpression.java:78) > at > org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.initialize(SelectConstructor.java:166) > at > org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.newSelect(SelectConstructor.java:115) > at > org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:69) > at > org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:324) > at > org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:165) > at > org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:672) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:934) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746) > ... 23 more > 141 same > TEST141; select e from EmpBean e where (e.isManager = fAlSe) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-162) @OrderBy on @OneToMany does not allow ordering by @Id value
[
https://issues.apache.org/jira/browse/OPENJPA-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-162.
---
Resolution: Fixed
Fix Version/s: 0.9.7
Fixed in revision 514847. Test case TestIdOrderedOneMany added.
> @OrderBy on @OneToMany does not allow ordering by @Id value
> ---
>
> Key: OPENJPA-162
> URL: https://issues.apache.org/jira/browse/OPENJPA-162
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 0.9.6
> Environment: Using PostgreSQL 8.1 as the database
>Reporter: Nick Johnson
> Fix For: 0.9.7
>
>
> Using the following annotation:
>@OneToMany(mappedBy="root", fetch=FetchType.LAZY)
> @OrderBy("objectId ASC")
> private List messages;
> I get the exception "Cannot order
> "net.spatula.tally_ho.model.MessageRoot.messages" on "objectId", because that
> field is not in the default fetch group. You can only order on fields that
> will be selected when the related object is loaded."
> I should certainly hope that the primary key of the related object is going
> to be selected when the object is loaded:
> @Id
> @Column(name = "object_id")
> private long objectId;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476396 ] Abe White commented on OPENJPA-160: --- > The last time I looked at bytecode in depth (it's been a while) the field > declarations and method declarations were separate in both where they were > located in the class file and when they were executed. The names and types of your fields are defined in their own area of the class file. But code used to initialize instance field values inline is dumped into your constructor bytecode () before any constructor code you write. And code used to initialize static field values inline is dumped into your static initializer bytecode () before any static block code you write. > Reuse BrokerImpl objects > > > Key: OPENJPA-160 > URL: https://issues.apache.org/jira/browse/OPENJPA-160 > Project: OpenJPA > Issue Type: Sub-task >Reporter: Michael Dick > Assigned To: Patrick Linskey > Attachments: newprofile.jpg, openjpa-160-patch.txt, > openjpa-160-patch.txt, openjpa-160-patch.txt, perf2.jpg, perf3.jpg > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476359 ] Abe White commented on OPENJPA-160: --- FYI, at the bytecode level all field initializations take place in . A profiler would have to jump through a lot of hoops to *exclude* field initializations from overhead. This may have no bearing on the issue depending on where the bottleneck is actually occurring, but I thought I'd point it out. > Reuse BrokerImpl objects > > > Key: OPENJPA-160 > URL: https://issues.apache.org/jira/browse/OPENJPA-160 > Project: OpenJPA > Issue Type: Sub-task >Reporter: Michael Dick > Assigned To: Patrick Linskey > Attachments: newprofile.jpg, openjpa-160-patch.txt, > openjpa-160-patch.txt, perf2.jpg, perf3.jpg > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanel#action_12476352 ] Abe White commented on OPENJPA-94: -- Single quotes should work -- no need to use escaped double quotes. > 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 > Attachments: openjpa_94.zip > > > 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.
[jira] Commented: (OPENJPA-161) Overuse of synchronization in AbstractBrokerFactory
[ https://issues.apache.org/jira/browse/OPENJPA-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475374 ] Abe White commented on OPENJPA-161: --- The code in question (just after the FIXME) is still guarding against the same transaction in concurrent threads. See the "someone beat us to it" putIfAbsent call. If we agree that transactions are thread bound -- as must be the case for the rest of the patch to be correct -- no one can "beat us to it", because we're the only thread with access to that transaction. > Overuse of synchronization in AbstractBrokerFactory > --- > > Key: OPENJPA-161 > URL: https://issues.apache.org/jira/browse/OPENJPA-161 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Patrick Linskey > Attachments: openjpa-161-patch.txt > > > AbstractBrokerFactory maintains a Map> that is > guarded by synchronized blocks. These synchronized blocks should be removed > if possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-161) Overuse of synchronization in AbstractBrokerFactory
[ https://issues.apache.org/jira/browse/OPENJPA-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475369 ] Abe White commented on OPENJPA-161: --- I think the FIXME part of the patch should be removed/simplified. The patch itself contains comments like the following: // we don't need to synchronize on brokers since one JTA transaction // can never be active on multiple concurrent threads. Yet the FIXME part explicitly guards against having the same transaction on concurrent threads. If guards like this are necessary, then they need to be consistent throughout the patch. But if we agree that the comment above is correct and the same transaction can't be active on multiple threads, then the FIXME part is useless. > Overuse of synchronization in AbstractBrokerFactory > --- > > Key: OPENJPA-161 > URL: https://issues.apache.org/jira/browse/OPENJPA-161 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Patrick Linskey > Attachments: openjpa-161-patch.txt > > > AbstractBrokerFactory maintains a Map> that is > guarded by synchronized blocks. These synchronized blocks should be removed > if possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475363 ] Abe White commented on OPENJPA-160: --- +1 to Craig's comments. > Reuse BrokerImpl objects > > > Key: OPENJPA-160 > URL: https://issues.apache.org/jira/browse/OPENJPA-160 > Project: OpenJPA > Issue Type: Sub-task >Reporter: Michael Dick > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475097 ] Abe White commented on OPENJPA-151: --- +1 on the patch from me. Fixes a problem and gets rid of unneeded code baggage at the same time. The re-enhancement isn't much of an issue to me -- we've required re-enhancement for various upgrades in the past and it's never been an issue with users, surprisingly enough. > Added field in enhanced vesrion of a class is not serialized. Hence the > change in detached+serialized instances is not registered under certain > conditions. > - > > Key: OPENJPA-151 > URL: https://issues.apache.org/jira/browse/OPENJPA-151 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar > Attachments: diff.txt > > > Enhancement adds a transient byte member field pcFlags to the class. This > field is originally used to optimize field access/mutation i.e. to > short-circuit mediation via StateManager under certain conditions (e.g. when > the field is part of the default fetch group). The field is transient, > perhaps, to maintain serialization compatibility. However, later changes such > as DetachedStateManager and improved attach strategies have made the usage of > these flag redundant. > This issue is a proposal to remove this field from the enhanced classes. The > proposed change is initiated by the following observation: > 1. class A has one-to-one relation to class B > 2. an instance a of A is related to b1 of B. b2 is another instance of B. > 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized > in a remote process as a*, b1* and b2*. > 4. in the remote process a* is associated with b2* > 5. a* is merged to the original process. > The change is not persisted when OpenJPA kernel is used with a JDO facade. It > works with JPA facade. > The initial analysis shows that the reason can be attributed to pcFlags and > the optimization in enhanced classes based on to its value. Because pcFlags > is not > serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of > a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the > detached version was carrying its own StateManager). While merging the > instance a* back, it was adjudged clean while actually it was dirty. In JPA > facade, the enhancement process did not add the extra optimization for setter > and so the cloned owner instance was righly marked dirty. > Please note that if this proposal is accepted by the community, it will > require reenhancement of existing domain classes. The change will impact the > internal StateManager and PersistenceCapable API (essentally removal of > certain methods than any other behavioural change). > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475093 ] Abe White commented on OPENJPA-151: --- > Why will this require re-enhancement? We'll no longer be setting pcFlags values -- the callbacks won't even exist to do so. Instances of classes that aren't re-enhanced will therefore never get their pcFlags set to LOAD_REQUIRED as needed to ensure their StateManagers are able to intercept all field access. > Added field in enhanced vesrion of a class is not serialized. Hence the > change in detached+serialized instances is not registered under certain > conditions. > - > > Key: OPENJPA-151 > URL: https://issues.apache.org/jira/browse/OPENJPA-151 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar > Attachments: diff.txt > > > Enhancement adds a transient byte member field pcFlags to the class. This > field is originally used to optimize field access/mutation i.e. to > short-circuit mediation via StateManager under certain conditions (e.g. when > the field is part of the default fetch group). The field is transient, > perhaps, to maintain serialization compatibility. However, later changes such > as DetachedStateManager and improved attach strategies have made the usage of > these flag redundant. > This issue is a proposal to remove this field from the enhanced classes. The > proposed change is initiated by the following observation: > 1. class A has one-to-one relation to class B > 2. an instance a of A is related to b1 of B. b2 is another instance of B. > 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized > in a remote process as a*, b1* and b2*. > 4. in the remote process a* is associated with b2* > 5. a* is merged to the original process. > The change is not persisted when OpenJPA kernel is used with a JDO facade. It > works with JPA facade. > The initial analysis shows that the reason can be attributed to pcFlags and > the optimization in enhanced classes based on to its value. Because pcFlags > is not > serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of > a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the > detached version was carrying its own StateManager). While merging the > instance a* back, it was adjudged clean while actually it was dirty. In JPA > facade, the enhancement process did not add the extra optimization for setter > and so the cloned owner instance was righly marked dirty. > Please note that if this proposal is accepted by the community, it will > require reenhancement of existing domain classes. The change will impact the > internal StateManager and PersistenceCapable API (essentally removal of > certain methods than any other behavioural change). > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-150) @Column in @AttributeOverride not honoring table attribute that maps to a secondary table in mappedsuperclass entity
[
https://issues.apache.org/jira/browse/OPENJPA-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-150.
---
Resolution: Fixed
Committed suggested changes (with very minor modifications) in revision 509674.
Thanks for the fix.
> @Column in @AttributeOverride not honoring table attribute that maps to a
> secondary table in mappedsuperclass entity
>
>
> Key: OPENJPA-150
> URL: https://issues.apache.org/jira/browse/OPENJPA-150
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, sql
> Environment: Any
>Reporter: Albert Lee
>
> I have the following scenario mapping entity to 2 tables:
> - a mapped super class that has a field
> - a subclass with a pk and a field.
> - trying to map all the fields (except the pk (id) ) to a secondary table
> (SEC_TABLE2MSC)
> - use @Column in the sub-class to override (name) to the secondary table
> - use @AttributeOverride to override the field (street) in the mapped super
> class to the secondary table.
> ===
> @MappedSuperclass
> public abstract class AnnMSCMultiTable
> implements IMultiTableEntity
> {
> // @Column(table="SEC_TABLE2MSC")
> private String street;
> public String getStreet() {
> return street;
> }
>public void setStreet(String street) {
> this.street = street;
> }
> }
> ===
> @Entity
> @SecondaryTable(name="SEC_TABLE2MSC", [EMAIL PROTECTED](name="id"))
> @AttributeOverrides(
> {
> @AttributeOverride(name="street", [EMAIL
> PROTECTED](name="street", table="SEC_TABLE2MSC")),
> })
> public class AnnMSCMultiTableEnt
> extends AnnMSCMultiTable
> {
> @Id
> private int id;
> @Column(name="name2", table="SEC_TABLE2MSC")
> private String name;
> }
> ===
> From examining JPA spec, there is no specific in the @Column and
> @AttributeOverride that this should not be allow. So I believe this is a
> valid scenario.
> Using the MappingTool, the attribute override does not map the street field
> to the SEC_TABLE2MSC as I would expect:
> CREATE TABLE AnnMSCMultiTableEnt (id INTEGER NOT NULL, street VARCHAR(254),
> PRIMARY KEY (id));
> CREATE TABLE SEC_TABLE2MSC (id INTEGER, name2 VARCHAR(254));
> CREATE INDEX I_SC_TMSC_ID ON SEC_TABLE2MSC (id);
> I experiment this a little bit and the only way I can map the street field to
> SEC_TABLE2MSC is
> to add the @Column against the "street" attribute in the super class. (the
> commented @Column in the example).
> The expected SQL are:
> CREATE TABLE AnnMSCMultiTableEnt (id INTEGER NOT NULL, PRIMARY KEY (id));
> CREATE TABLE SEC_TABLE2MSC (id INTEGER, street VARCHAR(254), name2
> VARCHAR(254));
> CREATE INDEX I_SC_TMSC_ID ON SEC_TABLE2MSC (id);
> I tried to create the tables manually using the expected layout, but the
> runtime still using the incorrect tables structure. I would suspect the
> MappingTool and the runtime are using the same mapping strategy.
> Albert Lee,
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-146) Entity enhancement fails while using EmbeddedId on a MappedSuperclass
[
https://issues.apache.org/jira/browse/OPENJPA-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-146.
---
Resolution: Fixed
Resolved with revision 509632. When copying OID superclass fields for mapping
in a subclass, revert the type of the field to PC. It will re-resolve to OID
when the copied field's metadata is resolved, and in the meantime it ensures
that the copied field resolution will use the same code path as non-copied
fields.
> Entity enhancement fails while using EmbeddedId on a MappedSuperclass
> -
>
> Key: OPENJPA-146
> URL: https://issues.apache.org/jira/browse/OPENJPA-146
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Environment: openjpa 0.9.6
>Reporter: Gokhan Ergul
> Attachments: test-case.zip
>
>
> Both buildtime and runtime class enhancement fail with the following error:
> ...
> 1339 TRACE [main] openjpa.Enhance - Enhancing type "class test.B".
> Exception in thread "main" <0|false|0.9.6-incubating>
> org.apache.openjpa.util.GeneralException: null
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:350)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3711)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3661)
> at org.apache.openjpa.enhance.PCEnhancer.main(PCEnhancer.java:3633)
> Caused by: java.lang.NullPointerException
> at
> org.apache.openjpa.enhance.PCEnhancer.enhanceObjectId(PCEnhancer.java:2745)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:338)
> ... 3 more
> Test code as follows:
> test/A.java:
> --
> package test;
> import javax.persistence.*;
> import java.io.Serializable;
> @MappedSuperclass
> abstract public class A {
> @Embeddable
> public static class A_PK implements Serializable {
> @Basic
> protected int id1;
>
> @Basic
> protected String id2;
>
> public boolean equals (Object other) {
> return false;
> }
> public int hashCode () {
> return 0;
> }
> }
> @EmbeddedId
> protected A_PK pk;
> @Basic
> protected String val;
> }
> --
> test/B.java:
> --
> package test;
> import javax.persistence.Entity;
> @Entity
> public class B extends A {
> }
> --
> META-INF/persistence.xml:
> --
> http://java.sun.com/xml/ns/persistence";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm
> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
> version="1.0">
>
> test.A$A_PK
> test.A
> test.B
>
>
>
>
> value="jdbc:mysql://localhost:3306/oam?useServerPrepStmts=false"/>
> value="com.mysql.jdbc.Driver"/>
>
>
>
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-146) Entity enhancement fails while using EmbeddedId on a MappedSuperclass
[
https://issues.apache.org/jira/browse/OPENJPA-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474480
]
Abe White commented on OPENJPA-146:
---
Cancel my previous comment. Embedded PCs are handled very differently than
OIDs at runtime, and so changing the isEmbeddedPC method to encompass OIDs as
well might cause problems. I think the root of the problem has to do with
metadata resolution of mapped superclass fields (after all, EmbeddedIds in
Entities work fine, just not in MappedSuperclasses). I'll investigate further.
> Entity enhancement fails while using EmbeddedId on a MappedSuperclass
> -
>
> Key: OPENJPA-146
> URL: https://issues.apache.org/jira/browse/OPENJPA-146
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Environment: openjpa 0.9.6
>Reporter: Gokhan Ergul
> Attachments: test-case.zip
>
>
> Both buildtime and runtime class enhancement fail with the following error:
> ...
> 1339 TRACE [main] openjpa.Enhance - Enhancing type "class test.B".
> Exception in thread "main" <0|false|0.9.6-incubating>
> org.apache.openjpa.util.GeneralException: null
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:350)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3711)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3661)
> at org.apache.openjpa.enhance.PCEnhancer.main(PCEnhancer.java:3633)
> Caused by: java.lang.NullPointerException
> at
> org.apache.openjpa.enhance.PCEnhancer.enhanceObjectId(PCEnhancer.java:2745)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:338)
> ... 3 more
> Test code as follows:
> test/A.java:
> --
> package test;
> import javax.persistence.*;
> import java.io.Serializable;
> @MappedSuperclass
> abstract public class A {
> @Embeddable
> public static class A_PK implements Serializable {
> @Basic
> protected int id1;
>
> @Basic
> protected String id2;
>
> public boolean equals (Object other) {
> return false;
> }
> public int hashCode () {
> return 0;
> }
> }
> @EmbeddedId
> protected A_PK pk;
> @Basic
> protected String val;
> }
> --
> test/B.java:
> --
> package test;
> import javax.persistence.Entity;
> @Entity
> public class B extends A {
> }
> --
> META-INF/persistence.xml:
> --
> http://java.sun.com/xml/ns/persistence";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm
> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
> version="1.0">
>
> test.A$A_PK
> test.A
> test.B
>
>
>
>
> value="jdbc:mysql://localhost:3306/oam?useServerPrepStmts=false"/>
> value="com.mysql.jdbc.Driver"/>
>
>
>
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-146) Entity enhancement fails while using EmbeddedId on a MappedSuperclass
[
https://issues.apache.org/jira/browse/OPENJPA-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474474
]
Abe White commented on OPENJPA-146:
---
Looks like a good fix to me. Do you need someone to commit this for you?
> Entity enhancement fails while using EmbeddedId on a MappedSuperclass
> -
>
> Key: OPENJPA-146
> URL: https://issues.apache.org/jira/browse/OPENJPA-146
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Environment: openjpa 0.9.6
>Reporter: Gokhan Ergul
> Attachments: test-case.zip
>
>
> Both buildtime and runtime class enhancement fail with the following error:
> ...
> 1339 TRACE [main] openjpa.Enhance - Enhancing type "class test.B".
> Exception in thread "main" <0|false|0.9.6-incubating>
> org.apache.openjpa.util.GeneralException: null
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:350)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3711)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3661)
> at org.apache.openjpa.enhance.PCEnhancer.main(PCEnhancer.java:3633)
> Caused by: java.lang.NullPointerException
> at
> org.apache.openjpa.enhance.PCEnhancer.enhanceObjectId(PCEnhancer.java:2745)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:338)
> ... 3 more
> Test code as follows:
> test/A.java:
> --
> package test;
> import javax.persistence.*;
> import java.io.Serializable;
> @MappedSuperclass
> abstract public class A {
> @Embeddable
> public static class A_PK implements Serializable {
> @Basic
> protected int id1;
>
> @Basic
> protected String id2;
>
> public boolean equals (Object other) {
> return false;
> }
> public int hashCode () {
> return 0;
> }
> }
> @EmbeddedId
> protected A_PK pk;
> @Basic
> protected String val;
> }
> --
> test/B.java:
> --
> package test;
> import javax.persistence.Entity;
> @Entity
> public class B extends A {
> }
> --
> META-INF/persistence.xml:
> --
> http://java.sun.com/xml/ns/persistence";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm
> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
> version="1.0">
>
> test.A$A_PK
> test.A
> test.B
>
>
>
>
> value="jdbc:mysql://localhost:3306/oam?useServerPrepStmts=false"/>
> value="com.mysql.jdbc.Driver"/>
>
>
>
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473416
]
Abe White commented on OPENJPA-141:
---
> The two-way check in FetchConfigurationImpl was overlooked. Thank you. But,
> that brings up a new question... Do we do the two-way check in this new
> utility method (even though BrokerImpl didn't require this in the past)? Or,
> is the one-way check sufficient for FetchConfigurationImpl's usage?
It should be a one-way check and code that needs to check both directions
should invoke it twice with the arguments swapped the second time. Simple.
> There have been several viewpoints on the use of these reference types and
> what the impact would be. To be honest, at this point, all that I am looking
> for is the ability to cache these assignable types. Whether it's
> redployment-friendly or memory-friendly, I don't really care at this point.
I don't care either, so long as it's one of the two reference type combinations
I outlined that actually make sense. We can't just pick reference types
randomly.
As to whether we should use a static cache vs. a Configuration instance
cache... doesn't matter much to me. The static cache keeps the API simpler.
> Definitely beneficial over no caching of the TM whatsoever. Sorry for the
> confusion.
So the question now is whether it is beneficial over the use of an instance
variable. In normal usage, there's no reason it should be. And so we should
use an instance variable. You could code an entire app using static maps in
place of all instance variables if you really wanted to, so yes, in that sense
they're equivalent, but there are good reasons not to. Same goes for this.
And finally, I'm going to harp on something that is no longer even relevant,
because I'm sure it will come up again in API design moving forward:
==
>>> 5. Even if ImplHelper.isAssignable retains its map parameter (and per #1
>>> above I question why it should), it should just be a Map; I don't see why
>>> you'd have the method require a ConcurrentMap.
>> I did this way to be thread safe. If I only used a Map parameter, then the
>> caller would have to ensure that any updates to the Cache are thread safe.
>The caller is giving you the Map in your scheme. It's up to him whether the
>Map he's giving you is used concurrently or not. The helper method itself has
>no threading issues at all, and only requires a Map. But I agree that if we
>move to a single cache in ImplHelper it's a moot point.
That's definitely one way around it. I prefer to enforce the requirement via
the signature of the contract. ===
This is a stateless static helper method. You're not "enforcing" anything,
because the method itself has no threading concerns whatsoever. You're
*imposing* a requirement to use a certain kind of Map on a method that would
function perfectly well with anything that implements the Map interface. That
is not something a helper method should do. What if I want to use the method
from single threaded code? What if I want to use it from a method that's
already synchronized? Or what if I want to pass it a synchronized map instead
of a concurrent one? Why should a helper method that knows nothing about who
is calling it and has no threading concerns itself be forcing any concurrency
strategy on me, much less a particular one? By this reasoning, every public
method in the entire codebase should either be synchronized or should require
thread safe arguments, because someone who calls the method *might* be doing so
from multi-threaded code that is not already synchronized.
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
> Attachments: openjpa-141.txt
>
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance var
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473234
]
Abe White commented on OPENJPA-141:
---
Craig, good catch. I didn't even look at the actual assignable method code...
I was saving that for when we had settled on a caching strategy.
> >1. Why not keep a single assignable types map in ImplHelper?
> I actually thought about doing that, but then I had concerns about the size
> of the Cache.
How are two static maps going to end up being smaller overall than one combined
static map?
> Hmmm.. If I understand what you are saying, it really doesn't matter whether
> we use hard, weak, or soft keys, since the resulting cache will be hard no
> matter what -- since we're using Class objects in the cache.
No, it does matter. And the type of value references we use matters way more.
If we want a "hard cache that drops entries for classes that are redeployed",
then we should be using weak keys and hard values. If we want a "memory
sensitive" cache, then we should be using hard keys and soft values. I'm not
sure where the disconnect is coming from with these reference types.
> The benchmark is a set of primitives based on the SpecJApp application using
> the SunOne Application Server. The profiling data from this set of tests
> indicate that caching of the JNDI lookup is beneficial.
Beneficial over the suggested use of an instance variable? Or beneficial over
no caching of the TM whatsoever? There's a big difference.
> >5. Even if ImplHelper.isAssignable retains its map parameter (and per #1
> >above I question why it should), it should just be a Map; I don't see why
> >you'd have the method require a ConcurrentMap.
> I did this way to be thread safe. If I only used a Map parameter, then the
> caller would have to ensure that any updates to the Cache are thread safe.
The caller is giving you the Map in your scheme. It's up to him whether the
Map he's giving you is used concurrently or not. The helper method itself has
no threading issues at all, and only requires a Map. But I agree that if we
move to a single cache in ImplHelper it's a moot point.
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
> Attachments: openjpa-141.txt
>
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo = new ConcurrentReferenceHashMap(
> > + ReferenceMap.HARD, ReferenceMap.WEAK);
> > + _assignableTypes.put(from, assignableTo);
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + return isAssignable;
> > +}
> Th
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473172
]
Abe White commented on OPENJPA-141:
---
1. Why not keep a single assignable types map in ImplHelper?
2. I thought we had decided on the assignable types map having hard keys and
soft values. Using soft keys and hard values is odd to say the least. First,
as I mentioned in a previous note, using soft Class keys is pointless. Once a
Class is eligible for GC there's no point in keeping it in cache, so weak is
better. Second, using hard values means that other than adapting to class
redeploys, this is basically a hard cache, because the only time entries are
removed is when a Class disappears, and that only happens on redeploy. It's
not necessarily bad to make this a hard cache, but it should be discussed.
3. Why keep dedicated isAssignable methods in BrokerImpl and
FetchConfigurationImpl if all they do is delegate to ImplHelper? Why not call
ImplHelper directly?
4. Why are you using a static JNDI location -> TM cache in
JNDITransactionManager rather than just caching the TM in an instance variable?
The only time that would help performance is if you're creating a bunch of
BrokerFactories all using the same TM location. Most applications will only
use a single BrokerFactory. If your benchmarks is constantly creating
BrokerFactories, I'd question the validity of the benchmark.
5. Even if ImplHelper.isAssignable retains its map parameter (and per #1 above
I question why it should), it should just be a Map; I don't see why you'd have
the method require a ConcurrentMap.
6. #2 above applies also to the Class->base hash map in OpenJPAId.
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
> Attachments: openjpa-141.txt
>
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo = new ConcurrentReferenceHashMap(
> > + ReferenceMap.HARD, ReferenceMap.WEAK);
> > + _assignableTypes.put(from, assignableTo);
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + return isAssignable;
> > +}
> This code could be simplified a lot. Also, I don't understand what
> you're trying to do from a memory management perspective. For the
> _assignableTypes member you've got the Class keys using hard refs and
> the Map values using weak refs. No outside code references the Map
> values, so all entries should be eligible for GC pretty much
> immediately. The way reference hash maps work prevents them from
> expunging stale entries except on mutators, but still... every time a
[jira] Commented: (OPENJPA-146) Entity enhancement fails while using EmbeddedId on a MappedSuperclass
[
https://issues.apache.org/jira/browse/OPENJPA-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473122
]
Abe White commented on OPENJPA-146:
---
We don't enhance the oid class anymore, so this bug is probably fixed or at
least will manifest itself in a different way in the latest code.
> Entity enhancement fails while using EmbeddedId on a MappedSuperclass
> -
>
> Key: OPENJPA-146
> URL: https://issues.apache.org/jira/browse/OPENJPA-146
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Environment: openjpa 0.9.6
>Reporter: Gokhan Ergul
> Attachments: test-case.zip
>
>
> Both buildtime and runtime class enhancement fail with the following error:
> ...
> 1339 TRACE [main] openjpa.Enhance - Enhancing type "class test.B".
> Exception in thread "main" <0|false|0.9.6-incubating>
> org.apache.openjpa.util.GeneralException: null
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:350)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3711)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3661)
> at org.apache.openjpa.enhance.PCEnhancer.main(PCEnhancer.java:3633)
> Caused by: java.lang.NullPointerException
> at
> org.apache.openjpa.enhance.PCEnhancer.enhanceObjectId(PCEnhancer.java:2745)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:338)
> ... 3 more
> Test code as follows:
> test/A.java:
> --
> package test;
> import javax.persistence.*;
> import java.io.Serializable;
> @MappedSuperclass
> abstract public class A {
> @Embeddable
> public static class A_PK implements Serializable {
> @Basic
> protected int id1;
>
> @Basic
> protected String id2;
>
> public boolean equals (Object other) {
> return false;
> }
> public int hashCode () {
> return 0;
> }
> }
> @EmbeddedId
> protected A_PK pk;
> @Basic
> protected String val;
> }
> --
> test/B.java:
> --
> package test;
> import javax.persistence.Entity;
> @Entity
> public class B extends A {
> }
> --
> META-INF/persistence.xml:
> --
> http://java.sun.com/xml/ns/persistence";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm
> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
> version="1.0">
>
> test.A$A_PK
> test.A
> test.B
>
>
>
>
> value="jdbc:mysql://localhost:3306/oam?useServerPrepStmts=false"/>
> value="com.mysql.jdbc.Driver"/>
>
>
>
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472758
]
Abe White commented on OPENJPA-141:
---
Craig:
There doesn't appear to be any hashCode/equals performance issues. As Kevin
pointed out earlier in the thread (and I should have realized) he's only
caching Class->hash in OpenJPAId to prevent having to traverse to the base
class... apparently Class.getSuperclass() is slow. It could just as well be a
cache of Class->base Class, but given the restriction Kevin pointed out that
ConcurrentReferenceHashMaps need at least one ref type to be hard, that'd
result in a cache that would maintain refs to classes that should be dropped
due to redeployment.
Kevin:
It's unfortunate that ConcurrentReferenceHashMaps need at least one ref type to
be hard. It would have been nice to use weak Class keys and soft values for
most of the caches. As is, I guess hard keys will do... we'll rely on the
value getting GC'd to expire entries for classes that disappear due to
redeployment. Note that the "inner" maps in your map-of-maps scheme of
assignables might as well just be a normal ConcurrentHashMaps too -- the outer
map already will let inner maps drop when memory is low. I also agree with
craig about mapping to Boolean.TRUE/FALSE instead of new Object(). And I'd
still like to see the assignable logic moved to ImplHelper or some new common
helper class.
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo = new ConcurrentReferenceHashMap(
> > + ReferenceMap.HARD, ReferenceMap.WEAK);
> > + _assignableTypes.put(from, assignableTo);
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + return isAssignable;
> > +}
> This code could be simplified a lot. Also, I don't understand what
> you're trying to do from a memory management perspective. For the
> _assignableTypes member you've got the Class keys using hard refs and
> the Map values using weak refs. No outside code references the Map
> values, so all entries should be eligible for GC pretty much
> immediately. The way reference hash maps work prevents them from
> expunging stale entries except on mutators, but still... every time a
> new entry is added, all the old entries should be getting GC'd and
> removed. Same for the individual Map values, which again map a hard
> class ref to an unreferenced object value with a weak ref. Basically
> the whole map-of-maps system should never contain more than one entry
> total afte
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472506
]
Abe White commented on OPENJPA-141:
---
> Craig thinks: Weak references are supposed to be cleaned up if the referenced
> instance is not otherwise referenced. What would cause the referred classes
> to be garbage collected immediately? I don't quite understand the issue here.
No, the current code holds the Classes with hard refs, and maps them to various
values with weak refs. Nothing else refers to these weak values. Therefore
they should be eligible for GC immediately, and their map entries should be
removed on the next map mutation (reference maps only clean up their expired
entries on mutation). That's why I don't understand how the current caches are
working at all to boost performance, unless GC isn't happening very often.
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo = new ConcurrentReferenceHashMap(
> > + ReferenceMap.HARD, ReferenceMap.WEAK);
> > + _assignableTypes.put(from, assignableTo);
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + return isAssignable;
> > +}
> This code could be simplified a lot. Also, I don't understand what
> you're trying to do from a memory management perspective. For the
> _assignableTypes member you've got the Class keys using hard refs and
> the Map values using weak refs. No outside code references the Map
> values, so all entries should be eligible for GC pretty much
> immediately. The way reference hash maps work prevents them from
> expunging stale entries except on mutators, but still... every time a
> new entry is added, all the old entries should be getting GC'd and
> removed. Same for the individual Map values, which again map a hard
> class ref to an unreferenced object value with a weak ref. Basically
> the whole map-of-maps system should never contain more than one entry
> total after a GC run and a mutation.
> I'd really like to see you run your tests under a different JVM,
> because it seems to me like (a) this shouldn't be necessary in the
> first place, and (b) if this is working, it's again only because of
> some JVM particulars or GC timing particulars or testing particulars
> (I've seen profilers skew results in random ways like this) or even a
> bug in ConcurrentReferenceHashMap.
> The same goes for all the repeat logic in FetchConfigurationImpl.
> And if we keep this code or some variant of it, I strongly suggest
> moving it to a commo
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472455
]
Abe White commented on OPENJPA-141:
---
1. Each BrokerFactory has a ManagedRuntime. You can have multiple
BrokerFactories, each of which is supposed to be completely independent.
Therefore you can have multiple ManagedRuntimes, each of which is supposed to
be completely independent. Caching the TM in a static in JNDIManagedRuntime
breaks that.
2. I still don't understand how the caches were working at all with the weak
refs, unless GC just wasn't kicking in very often. Any info on this?
As to the proposed changes: there's no point in caching on Class keys with soft
refs. As soon as a Class is no longer referenced anywhere, there's no point in
keeping it around. So all Class keys should be weak refs. The corresponding
values can be soft.
3. System.identityHashCode isn't going to help with superclasses... I didn't
realize that that was the slow part.
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo = new ConcurrentReferenceHashMap(
> > + ReferenceMap.HARD, ReferenceMap.WEAK);
> > + _assignableTypes.put(from, assignableTo);
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + return isAssignable;
> > +}
> This code could be simplified a lot. Also, I don't understand what
> you're trying to do from a memory management perspective. For the
> _assignableTypes member you've got the Class keys using hard refs and
> the Map values using weak refs. No outside code references the Map
> values, so all entries should be eligible for GC pretty much
> immediately. The way reference hash maps work prevents them from
> expunging stale entries except on mutators, but still... every time a
> new entry is added, all the old entries should be getting GC'd and
> removed. Same for the individual Map values, which again map a hard
> class ref to an unreferenced object value with a weak ref. Basically
> the whole map-of-maps system should never contain more than one entry
> total after a GC run and a mutation.
> I'd really like to see you run your tests under a different JVM,
> because it seems to me like (a) this shouldn't be necessary in the
> first place, and (b) if this is working, it's again only because of
> some JVM particulars or GC timing particulars or testing particulars
> (I've seen profilers skew results in random ways like this) or even a
> bug in ConcurrentReferenceHashMap.
> The same goes for all the r
[jira] Commented: (OPENJPA-138) More performance improvements for OpenJPA (lib and kernel)
[ https://issues.apache.org/jira/browse/OPENJPA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471744 ] Abe White commented on OPENJPA-138: --- o Cache the TransactionManager in JNDIManagedRuntime +1 o Cache the Class instances for Configurations.newInstance() -1 o Cache the Type hashcodes for OpenJPAId.hashcode() Already being done as far as I can tell, unless you mean a static Class->hashcode map, in which case -1. o Cache the Type's ClassLoader instances in ObjectValue.newInstance() I have a hard time believing that Class.getClassLoader() for the few things that we dynamically create more than once via ObjectValues is a significant performance problem. o Cache the assignable "from" types and associated value "to" types in FetchConfigurationImpl.isAssignable Again, I have a hard time believing this is significant. What JVM is this that methods on Class seem to be so ridiculously slow, to the point that you want to create and maintain Maps of Maps to work around it? o Clean up the close/IllegalStateException processing in AbstractBrokerFactory and BrokerImpl (gate with TRACE) +1 o Cache the assignable "from" types and associated value "to" types in BrokerImpl.newObjectId() Same comments as for FetchConfigurationImpl.isAssignable. o Cache the brokers being created along with appropriate cleanup and reopen processing in AbstractBrokerFactory (and BrokerImpl) -1 > More performance improvements for OpenJPA (lib and kernel) > -- > > Key: OPENJPA-138 > URL: https://issues.apache.org/jira/browse/OPENJPA-138 > Project: OpenJPA > Issue Type: Sub-task > Components: kernel, lib >Reporter: Kevin Sutter > Assigned To: Kevin Sutter > > As we continue pushing OpenJPA though its paces, we're finding a few > additional tweaks that help with the performance throughput. This Issue will > be used to track this next set of improvements. I'll document more detail as > we determine the correct fixes. Several of the changes relate to caching of > objects in a hashmap instead of re-creating the objects every time we call > some of these methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-119) EntityManager.clear() should not implicitly invoke the flush operation
[
https://issues.apache.org/jira/browse/OPENJPA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470119
]
Abe White commented on OPENJPA-119:
---
I'm not saying we need to add the new detachAll method, but I don't understand
everyone's fear of breaking anything by adding new public methods. It's very
hard to break anything by adding a new public method. The only thing you can
possibly break is a non-dynamic proxy that implements the interface
(OpenJPAEntityManager) without extending the impl (EntityManagerImpl). Anyone
layering on top of OpenJPA in that fashion has to realize that their
implementation will need updating fairly often.
> 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] Commented: (OPENJPA-119) EntityManager.clear() should not implicitly invoke the flush operation
[
https://issues.apache.org/jira/browse/OPENJPA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469562
]
Abe White commented on OPENJPA-119:
---
"But, since I don't know how JDO is using the kernel, it's kind of difficult
for me to determine how to make this work for both cases"
JDO needs to flush when detachAll() is called. JPA doesn't. Rather than
changing the code out from under JDO, how about adding a boolean to the method.
At least then JDO code (and theoretically any other code using the method)
will fail to compile. That will allow us (and theoretically anyone else) to
see the incompatibility and update our code, rather than having our detach
behavior suddenly become incorrect. If we later discover a better way to do
it, we can remove the boolean and fix the compile-time problems that will again
result -- I'd much rather be getting compile time errors that I'm forced to fix
than to have to debug why an obscure unit test or user case suddenly stops
working at a later date.
In fact given the new (and correct) clear() behavior, I think we should add an
OpenJPAEntityManager.detachAll() method that retains the old behavior, because
it is actually useful in some cases. So the EntityManagerImpl would end up
using Broker.detachAll with both "true" and "false" flush flags.
> 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] Commented: (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:comment-tabpanel#action_12469481 ] Abe White commented on OPENJPA-122: --- I personally would put the _broker.assertOpen() calls before the assertNotCloseInvoked() calls, just because it seems like the sensible progression to check whether the broker is closed and then check whether it isn't closed yet but close() has been invoked and it's waiting for a transaction commit. But it makes absolutely no functional difference, so the patch looks good to me. > 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 >
[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.
[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_12468734 ] Abe White commented on OPENJPA-117: --- I don't think we should encourage use of user objects for tracking state we could trivially expose ourselves. Most of our APIs allow you to "get" anything you can "set", so I agree with Pinaki's approach of exposing the listener collection unless our internal bookkeeping mechanism in this case makes it inefficient for some reason. > 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] Commented: (OPENJPA-94) Allow MappingTool and persistence.xml to support drop-create for database schema
[ http://issues.apache.org/jira/browse/OPENJPA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461839 ] Abe White commented on OPENJPA-94: -- Note that the "SynchronizeMappings" property allows you to use all the arguments of the mappingtool. So you can try something like: buildSchema(SchemaAction=refresh, DropTables=true) Theoretically, that will drop unused columns and tables while adding any new columns and tables needed for your mappings. > Allow MappingTool and persistence.xml to support drop-create for database > schema > > > Key: OPENJPA-94 > URL: http://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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (OPENJPA-90) "ON DELETE SET NULL" is getting overridden if the foreign column is "NOT NULL"
[ http://issues.apache.org/jira/browse/OPENJPA-90?page=all ] Abe White resolved OPENJPA-90. -- Resolution: Fixed Right you are. Changed to check local columns, not foreign ones. > "ON DELETE SET NULL" is getting overridden if the foreign column is "NOT NULL" > -- > > Key: OPENJPA-90 > URL: http://issues.apache.org/jira/browse/OPENJPA-90 > Project: OpenJPA > Issue Type: Bug > Components: sql >Reporter: Markus Herzog > > "ON DELETE SET NULL" is getting overridden if the foreign column is "NOT > NULL". > This behaviour was introduced in Revision 449532 of the DBDictionary > (getForeignKeyConstraintSQL). I think this is implemented wrongly - you're > checking the wrong side of the relation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-85) Update reserved words in DBDictionaries
[ http://issues.apache.org/jira/browse/OPENJPA-85?page=comments#action_12451353 ] Abe White commented on OPENJPA-85: -- Note that the common SQL92 reserved words are maintained by the base DBDictionary, which reads from the sql-keywords.rsrc resource in the org.apache.openjpa.jdbc.sql package. > Update reserved words in DBDictionaries > --- > > Key: OPENJPA-85 > URL: http://issues.apache.org/jira/browse/OPENJPA-85 > Project: OpenJPA > Issue Type: Improvement > Components: sql >Reporter: Roger Keays > > It seems many of the DBDictionaries are a bit out of date WRT what reserved > words they define. The mysql dictionary, for example, only has 22 of the ~210 > reserved words in mysql > (http://dev.mysql.com/doc/refman/5.1/en/reserved-words.html). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (OPENJPA-73) PersistenceProviderImpl.createContainerEntityManagerFactory() doesn't work if you supply jdbc specific properties
[ http://issues.apache.org/jira/browse/OPENJPA-73?page=all ]
Abe White resolved OPENJPA-73.
--
Resolution: Fixed
Fixed by not instantiating all plugins up front in class transformer.
> PersistenceProviderImpl.createContainerEntityManagerFactory() doesn't work if
> you supply jdbc specific properties
> -
>
> Key: OPENJPA-73
> URL: http://issues.apache.org/jira/browse/OPENJPA-73
> Project: OpenJPA
> Issue Type: Bug
>Reporter: David Jencks
>
> PersistenceProviderImpl.createContainerEntityManagerFactory() doesn't work if
> you supply jdbc specific properties such as
> value="table(Table=OPENJPASEQ, Increment=100)"/>
> (or rather its string equivalent in the map argument)
> The problem is that the ClassTransformerImpl creates a
> OpenJPAConfigurationImpl which doesn't know anything about jdbc configuration
> properties such as the sequence, but it gets fed all the properties you
> supply.
> Changing the code in PersistenceProviderImpl to create a
> JDBCConfigurationImpl makes everything work: heres a patch to do this:
> Index:
> openjpa-persistence/src/main/java/org/apache/openjpa/persistence/PersistenceProviderImpl.java
> ===
> ---
> openjpa-persistence/src/main/java/org/apache/openjpa/persistence/PersistenceProviderImpl.java
>(revision 469568)
> +++
> openjpa-persistence/src/main/java/org/apache/openjpa/persistence/PersistenceProviderImpl.java
>(working copy)
> @@ -89,17 +89,17 @@
> // add enhancer
> String ctOpts = (String) Configurations.getProperty
> (CLASS_TRANSFORMER_OPTIONS, pui.getProperties());
> -pui.addTransformer(new ClassTransformerImpl(cp, ctOpts,
> +pui.addTransformer(new ClassTransformerImpl(cp, ctOpts,
> pui.getNewTempClassLoader()));
>
> -BrokerFactory factory = Bootstrap.newBrokerFactory(cp,
> +BrokerFactory factory = Bootstrap.newBrokerFactory(cp,
> pui.getClassLoader());
> return OpenJPAPersistence.toEntityManagerFactory(factory);
> } catch (Exception e) {
> throw PersistenceExceptions.toPersistenceException(e);
> }
> }
> -
> +
> /**
> * Java EE 5 class transformer.
> */
> @@ -108,10 +108,24 @@
>
> private final ClassFileTransformer _trans;
>
> -private ClassTransformerImpl(ConfigurationProvider cp, String props,
> +private ClassTransformerImpl(ConfigurationProvider cp, String props,
> final ClassLoader tmpLoader) {
> // create an independent conf for enhancement
> -OpenJPAConfiguration conf = new OpenJPAConfigurationImpl();
> +OpenJPAConfiguration conf = null;
> +try {
> +ClassLoader tccl =
> Thread.currentThread().getContextClassLoader();
> +Class clazz =
> Class.forName("org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl", true,
> tccl);
> +conf = (OpenJPAConfiguration)clazz.newInstance();
> +} catch (ClassNotFoundException e) {
> +e.printStackTrace();
> +} catch (IllegalAccessException e) {
> +e.printStackTrace();
> +} catch (InstantiationException e) {
> +e.printStackTrace();
> +}
> +if (conf == null) {
> +conf = new OpenJPAConfigurationImpl();
> +}
> cp.setInto(conf);
> // don't allow connections
> conf.setConnectionUserName(null);
> It seems to me that using a JDBCConfiguration here is not needed: what is
> needed is to ignore properties that the OpenJPAConfigurationImpl doesn't
> understand, rather than throwing an exception. We're only setting up the
> class transformer here, not the runtime configuration.
> I don't understand enough to suggest where to fix this, but given some hints
> I could make a try.
> The relevant parts of the stacktrace showing the original error is:
> Caused by: java.lang.IllegalArgumentException:
> java.lang.ClassNotFoundException: table in classloader
> org.apache.geronimo.configs/openjpa/1.2-SNAPSHOT/car
> at serp.util.Strings.toClass(Strings.java:211)
> at serp.util.Strings.toClass(Strings.java:140)
> at
> org.apache.openjpa.lib.conf.Configurations.newInstance(Configurations.java:135)
> ... 62 more
> at
> org.apache.openjpa.lib.conf.ConfigurationImpl.instantiateAll(ConfigurationImpl.java:278)
> at
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.instantiateAll(OpenJPAConfigurationImpl.java:1400)
> at
> org.apache.openjpa.persistence.PersistenceProvid
[jira] Commented: (OPENJPA-73) PersistenceProviderImpl.createContainerEntityManagerFactory() doesn't work if you supply jdbc specific properties
[
http://issues.apache.org/jira/browse/OPENJPA-73?page=comments#action_12446288 ]
Abe White commented on OPENJPA-73:
--
David -- if you can verify that things also work if you don't pre-enhance,
we'll commit the change.
> PersistenceProviderImpl.createContainerEntityManagerFactory() doesn't work if
> you supply jdbc specific properties
> -
>
> Key: OPENJPA-73
> URL: http://issues.apache.org/jira/browse/OPENJPA-73
> Project: OpenJPA
> Issue Type: Bug
>Reporter: David Jencks
>
> PersistenceProviderImpl.createContainerEntityManagerFactory() doesn't work if
> you supply jdbc specific properties such as
> value="table(Table=OPENJPASEQ, Increment=100)"/>
> (or rather its string equivalent in the map argument)
> The problem is that the ClassTransformerImpl creates a
> OpenJPAConfigurationImpl which doesn't know anything about jdbc configuration
> properties such as the sequence, but it gets fed all the properties you
> supply.
> Changing the code in PersistenceProviderImpl to create a
> JDBCConfigurationImpl makes everything work: heres a patch to do this:
> Index:
> openjpa-persistence/src/main/java/org/apache/openjpa/persistence/PersistenceProviderImpl.java
> ===
> ---
> openjpa-persistence/src/main/java/org/apache/openjpa/persistence/PersistenceProviderImpl.java
>(revision 469568)
> +++
> openjpa-persistence/src/main/java/org/apache/openjpa/persistence/PersistenceProviderImpl.java
>(working copy)
> @@ -89,17 +89,17 @@
> // add enhancer
> String ctOpts = (String) Configurations.getProperty
> (CLASS_TRANSFORMER_OPTIONS, pui.getProperties());
> -pui.addTransformer(new ClassTransformerImpl(cp, ctOpts,
> +pui.addTransformer(new ClassTransformerImpl(cp, ctOpts,
> pui.getNewTempClassLoader()));
>
> -BrokerFactory factory = Bootstrap.newBrokerFactory(cp,
> +BrokerFactory factory = Bootstrap.newBrokerFactory(cp,
> pui.getClassLoader());
> return OpenJPAPersistence.toEntityManagerFactory(factory);
> } catch (Exception e) {
> throw PersistenceExceptions.toPersistenceException(e);
> }
> }
> -
> +
> /**
> * Java EE 5 class transformer.
> */
> @@ -108,10 +108,24 @@
>
> private final ClassFileTransformer _trans;
>
> -private ClassTransformerImpl(ConfigurationProvider cp, String props,
> +private ClassTransformerImpl(ConfigurationProvider cp, String props,
> final ClassLoader tmpLoader) {
> // create an independent conf for enhancement
> -OpenJPAConfiguration conf = new OpenJPAConfigurationImpl();
> +OpenJPAConfiguration conf = null;
> +try {
> +ClassLoader tccl =
> Thread.currentThread().getContextClassLoader();
> +Class clazz =
> Class.forName("org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl", true,
> tccl);
> +conf = (OpenJPAConfiguration)clazz.newInstance();
> +} catch (ClassNotFoundException e) {
> +e.printStackTrace();
> +} catch (IllegalAccessException e) {
> +e.printStackTrace();
> +} catch (InstantiationException e) {
> +e.printStackTrace();
> +}
> +if (conf == null) {
> +conf = new OpenJPAConfigurationImpl();
> +}
> cp.setInto(conf);
> // don't allow connections
> conf.setConnectionUserName(null);
> It seems to me that using a JDBCConfiguration here is not needed: what is
> needed is to ignore properties that the OpenJPAConfigurationImpl doesn't
> understand, rather than throwing an exception. We're only setting up the
> class transformer here, not the runtime configuration.
> I don't understand enough to suggest where to fix this, but given some hints
> I could make a try.
> The relevant parts of the stacktrace showing the original error is:
> Caused by: java.lang.IllegalArgumentException:
> java.lang.ClassNotFoundException: table in classloader
> org.apache.geronimo.configs/openjpa/1.2-SNAPSHOT/car
> at serp.util.Strings.toClass(Strings.java:211)
> at serp.util.Strings.toClass(Strings.java:140)
> at
> org.apache.openjpa.lib.conf.Configurations.newInstance(Configurations.java:135)
> ... 62 more
> at
> org.apache.openjpa.lib.conf.ConfigurationImpl.instantiateAll(ConfigurationImpl.java:278)
> at
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.instantiateAll(OpenJPAConfigurationImpl.java:1400)
> at
[jira] Resolved: (OPENJPA-68) PCClassFileTransformer.isEnhanced() fails because PersistenceCapable package name is wrong
[ http://issues.apache.org/jira/browse/OPENJPA-68?page=all ]
Abe White resolved OPENJPA-68.
--
Resolution: Fixed
Thanks, fixed. (FTR, the correct name is
org/apache/openjpa/enhance/PersistenceCapable)
> PCClassFileTransformer.isEnhanced() fails because PersistenceCapable package
> name is wrong
> --
>
> Key: OPENJPA-68
> URL: http://issues.apache.org/jira/browse/OPENJPA-68
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Environment: Win32, JDK1.5, OpenJPA 0.9.0-incubating
>Reporter: Corey Klaasmeyer
>Priority: Critical
>
> On line 201, the fully qualified interface name should be
> "org/openjpa/enhance/PersistenceCapable" not
> "openjpa/enhance/PersistenceCapable":
> /**
> * Analyze the bytecode to see if the given class definition implements
> * [EMAIL PROTECTED] PersistenceCapable}.
> */
> private static boolean isEnhanced(byte[] b) {
> ConstantPoolTable table = new ConstantPoolTable(b);
> int idx = table.getEndIndex();
> idx += 6; // skip access, cls, super
> int ifaces = table.readUnsignedShort(idx);
> int clsEntry, utfEntry;
> String name;
> for (int i = 0; i < ifaces; i++) {
> idx += 2;
> clsEntry = table.readUnsignedShort(idx);
> utfEntry = table.readUnsignedShort(table.get(clsEntry));
> name = table.readString(table.get(utfEntry));
> if ("openjpa/enhance/PersistenceCapable".equals(name))
> return true;
> }
> return false;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (OPENJPA-41) transforming classes doesn't work
[ http://issues.apache.org/jira/browse/OPENJPA-41?page=all ] Abe White resolved OPENJPA-41. -- Resolution: Fixed > transforming classes doesn't work > - > > Key: OPENJPA-41 > URL: http://issues.apache.org/jira/browse/OPENJPA-41 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Environment: WinXP, Tomcat 5.5.17, Spring 2.0-RC4 >Reporter: Costin Leau > Assigned To: Marc Prud'hommeaux > Attachments: petclinic.zip, spring-tomcat-weaver.jar, > stacktrace-2.txt, stacktrace.txt > > > I've tried several versions of OpenJPA including the most recent one(svn > 4409856) to run Spring's Petclinic with class level LoadTimeWeaver on OpenJPA. > I have attached the stacktrace that I get. The same example works fine with > Toplink. > I have attached petclinic w/o some of the libs to gain space; basically add > the OpenJPA libs and deploy the war into Tomcat. Note that you'll also have > to place spring-tomcat-weaver.jar under Tomcat's server/lib (this should be > enough - if you have problems let me know or take a look at the Spring > reference documentation). > When the webapp starts, the exception pops up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (OPENJPA-13) GenerationType.IDENTITY problem with MS SQL Server
[ http://issues.apache.org/jira/browse/OPENJPA-13?page=all ]
Abe White resolved OPENJPA-13.
--
Resolution: Fixed
Resolved by converting DB-generated autoassign value to expected Java type for
column, as mapped by object field.
> GenerationType.IDENTITY problem with MS SQL Server
> --
>
> Key: OPENJPA-13
> URL: http://issues.apache.org/jira/browse/OPENJPA-13
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Environment: Microsoft SQL Server 2000
> Windows XP
> Java SE 1.5
> OpenJPA - source downloaded today (Aug 14, 2006)
>Reporter: Megan
>Priority: Critical
>
> Cannot persist entity with identity column. To reproduce, create a simple
> object with identity column
> @Entity
> @Table(name="JpaType")
> public class JpaType implements Serializable
> {
> @Id
> @GeneratedValue(strategy=GenerationType.IDENTITY)
> @Column(name="Id")
> private Integer id = null;
>
> @Column(name="Name")
> private String name = null;
>
> public Integer getId() { return id; }
> public String getName() { return name; }
> public void setName(String name) { this.name = name; }
> }
> create table JpaType (
> Id int identity(1, 1) not null
> , Name varchar(50) null
> , constraint JpaType_PK primary key (Id)
> )
> JpaType jpa = new JpaType();
> jpa.setName("Test 1");
> em.persist(jpa);
> em.flush();
> It works OK if I remove identity column (and set ID myself).
> Stack trace
> <0|true|0.9.0> org.apache.openjpa.persistence.PersistenceException:
> java.math.BigDecimal
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1576)
> at
> org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:927)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:421)
> at mytest.domain.JpaTest.testJpa(JpaTest.java:30)
> 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.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
> at
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
> at
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
> at
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
> at
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71)
> at
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
> at
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
> at
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: java.lang.ClassCastException: java.math.BigDecimal
> at mytest.domain.model.JpaType.pcReplaceField(JpaType.java)
> at
> org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:2824)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2284)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:2380)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:723)
> at
> org.apache.openjpa.kernel.StateManagerImpl.store(StateManagerImpl.java:719)
> at
> org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.setAutoAssignedValue(HandlerFieldStrategy.java:361)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:119)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:68)
> at
> org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRo
[jira] Commented: (OPENJPA-13) GenerationType.IDENTITY problem with MS SQL Server
[
http://issues.apache.org/jira/browse/OPENJPA-13?page=comments#action_12439964 ]
Abe White commented on OPENJPA-13:
--
I just committed a possible fix for this issue by changing
HandlerStrategies.setAutoAssignedValue to conver the DB-produced auto-assigned
value to the Java type the field expects for the given column. Bryan, can you
test with your SQLServer and/or MySQL driver?
> GenerationType.IDENTITY problem with MS SQL Server
> --
>
> Key: OPENJPA-13
> URL: http://issues.apache.org/jira/browse/OPENJPA-13
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Environment: Microsoft SQL Server 2000
> Windows XP
> Java SE 1.5
> OpenJPA - source downloaded today (Aug 14, 2006)
>Reporter: Megan
>Priority: Critical
>
> Cannot persist entity with identity column. To reproduce, create a simple
> object with identity column
> @Entity
> @Table(name="JpaType")
> public class JpaType implements Serializable
> {
> @Id
> @GeneratedValue(strategy=GenerationType.IDENTITY)
> @Column(name="Id")
> private Integer id = null;
>
> @Column(name="Name")
> private String name = null;
>
> public Integer getId() { return id; }
> public String getName() { return name; }
> public void setName(String name) { this.name = name; }
> }
> create table JpaType (
> Id int identity(1, 1) not null
> , Name varchar(50) null
> , constraint JpaType_PK primary key (Id)
> )
> JpaType jpa = new JpaType();
> jpa.setName("Test 1");
> em.persist(jpa);
> em.flush();
> It works OK if I remove identity column (and set ID myself).
> Stack trace
> <0|true|0.9.0> org.apache.openjpa.persistence.PersistenceException:
> java.math.BigDecimal
> at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1576)
> at
> org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:927)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:421)
> at mytest.domain.JpaTest.testJpa(JpaTest.java:30)
> 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.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
> at
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
> at
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
> at
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
> at
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71)
> at
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
> at
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
> at
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: java.lang.ClassCastException: java.math.BigDecimal
> at mytest.domain.model.JpaType.pcReplaceField(JpaType.java)
> at
> org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:2824)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2284)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:2380)
> at
> org.apache.openjpa.kernel.StateManagerImpl.storeField(StateManagerImpl.java:723)
> at
> org.apache.openjpa.kernel.StateManagerImpl.store(StateManagerImpl.java:719)
> at
> org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.setAutoAssignedValue(HandlerFieldStrategy.java:361)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:119)
> at
> org.apache.openjpa.jd
[jira] Resolved: (OPENJPA-59) Eager fetching not occuring for ToOne relationships during detachment
[ http://issues.apache.org/jira/browse/OPENJPA-59?page=all ] Abe White resolved OPENJPA-59. -- Resolution: Fixed Changed default MaxFetchDepth to -1 (unlimited). Checked in given test case. > Eager fetching not occuring for ToOne relationships during detachment > - > > Key: OPENJPA-59 > URL: http://issues.apache.org/jira/browse/OPENJPA-59 > Project: OpenJPA > Issue Type: Bug > Components: kernel > Environment: Any >Reporter: David Ezzio >Priority: Critical > Attachments: detachmentTestOpenJPA.zip > > > If there is a bidirectional onetomany relationship between parent and child > maintained with a foreign key, during detachment, the parent and children are > correctly detached, but the back reference in child to the parent is not > populated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-59) Eager fetching not occuring for ToOne relationships during detachment
[ http://issues.apache.org/jira/browse/OPENJPA-59?page=comments#action_12437637 ] Abe White commented on OPENJPA-59: -- The behavior of the test case is technically correct, because the default global MaxFetchDepth is 1. If I modify the test case to set a MaxFetchDepth of 2 in setUp, it passes. I agree that this is not necessarily user-friendly, though. So the question is: what should our default max fetch depth be? Unlimited? 2, so that at least both sides of bi-di relations are handled? Some other arbitrary number that we think is reasonable? > Eager fetching not occuring for ToOne relationships during detachment > - > > Key: OPENJPA-59 > URL: http://issues.apache.org/jira/browse/OPENJPA-59 > Project: OpenJPA > Issue Type: Bug > Components: kernel > Environment: Any >Reporter: David Ezzio >Priority: Critical > Attachments: detachmentTestOpenJPA.zip > > > If there is a bidirectional onetomany relationship between parent and child > maintained with a foreign key, during detachment, the parent and children are > correctly detached, but the back reference in child to the parent is not > populated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-24) Allow OpenJPA to be extensible
[
http://issues.apache.org/jira/browse/OPENJPA-24?page=comments#action_12436089 ]
Abe White commented on OPENJPA-24:
--
I've committed some additional work on this as I reviewed Pinaki's work. You
should now be able to extend OpenJPA by creating a ProductDerivation like so:
public class MyProductDerivation
extends AbstractProductDerivation {
public int getType() {
return TYPE_PRODUCT;
}
public boolean beforeConfigurationLoad(Configuration conf) {
Value emf = conf.getValue(EntityManagerFactoryValue.KEY);
if (emf == null)
return false;
emf.setDefault(MyEntityManagerFactoryClass.class.getName());
emf.setClassName(MyEntityManagerFactoryClass.getName());
return true;
}
}
With your custom EntityManagerFactory class (which must extend
EntityManagerFactoryImpl), you can also override newEntityManagerImpl(Broker)
to subclass the EntityManager, and using your EntityManager subclass I believe
you can act as a factory for custom QueryImpl, etc extensions. In addition to
the PersistenceProvider.createEMF methods, the static
toEntitymanagerFactory/toEntityManager methods in OpenJPAPersistence will also
correctly return your custom subclasses.
So you shouldn't need a custom ConfigurationProvider or a custom
PersistenceProvider anymore. I'll be doing some more review of this later to
be sure it actually works, barring someone else testing it and telling me it
does.
> Allow OpenJPA to be extensible
> --
>
> Key: OPENJPA-24
> URL: http://issues.apache.org/jira/browse/OPENJPA-24
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> The current OpenJPA architecture is not extendable to other implementations.
> For example, if somebody wanted to provide their own PersistenceProvider
> implementation, simply extending the
> org.apache.openjpa.PersistenceProviderImpl would not suffice due to the
> dependencies in the ConfigurationProviderImpl. The discussion for this
> improvement was started on the dev mailing list. Once it was determined that
> there was more to this request than a simple conditional or two, we decided
> to open a JIRA report.
> The complete history of this request can be found in the OpenJPA dev mailing
> list. The first message was posted by me (Kevin Sutter) on August 14, titled
> "Extending the OpenJPA Implementation". I will attempt to paraphrase the
> current state of the problem...
> We have three main players in this issue. The PersistenceProvider, the
> ConfigurationProvider, and the ProductDerivation (along with the various
> implementations of these interfaces). Currently, the ConfigurationProvider
> is in the lib and is unaware of any specific persistence requirements. The
> ProductDerivation is in the kernel and, unfortunately, is aware of
> persistence requirements, specifically the spec and store types. Abe's
> postings have indicated that we need to make these two interfaces more aware
> of each other and work with each other. We need to start with either making
> ConfigurationProvider more persistence-aware and move it into kernel, or make
> ProductDerivations less persistence-aware and move it into lib. The latter
> approach is preferred.
> After we get this re-organization of the base framework complete, we still
> have a couple of other issues ot resolve:
> * Still need the ability to extend EMF's through a ProductDerivation.
> This should be doable by adding a new PluginValue to indicate what class of
> EMF to load.
> * There is still a question as to whether we will need to provide a
> custom PersistenceProviderImpl and ConfigurationProviderImpl pair. I still
> think this will be necessary. And, one of Abe's posts indicated that this
> might help with class loading issues when multiple versions of OpenJPA-based
> implementations are available in the same system.
> I also posted these questions last Friday. (Abe has responded with some
> answers, but I wanted to get this JIRA report created before trying to
> paraphrase his answers.)
> * You mention in several places about separating away the notion of
> specs and stores. In a general sense, I understand what these are. But, can
> you elaborate on how these types are used in the ConfigurationProvider and
> ProductDerivation interfaces?
> * I've moved the ProductDerivation interface to the lib and added the
> "load" methods from the ConfigurationProvider (as described in your previous
> notes). And, I've started to clean up the implementations that depend on
> these interfaces. But, concerning the implementation of the load methods...
> Now that we need to return a ConfigurationProvider, would you expect that we
> just new up a ConfigurationProvider
[jira] Created: (OPENJPA-55) Allow executeUpdate() invocations on native queries
Allow executeUpdate() invocations on native queries --- Key: OPENJPA-55 URL: http://issues.apache.org/jira/browse/OPENJPA-55 Project: OpenJPA Issue Type: Improvement Components: query Reporter: Abe White 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-39) Cascade delete does not work with foreign key constraints
[ http://issues.apache.org/jira/browse/OPENJPA-39?page=comments#action_12434283 ] Abe White commented on OPENJPA-39: -- I implemented Craig's suggestion of always considering the child object as deleted first when cascading a delete from parent to child. So this test case will now work even with non-nullable foreign key columns. > Cascade delete does not work with foreign key constraints > - > > Key: OPENJPA-39 > URL: http://issues.apache.org/jira/browse/OPENJPA-39 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Environment: Microsoft SQL Server 2000 > Windows XP > Java SE 1.5 > OpenJPA - source downloaded Aug 28, 2006) > Show » > Microsoft SQL Server 2000 Windows XP Java SE 1.5 OpenJPA - source downloaded > today (Aug 14, 2006) >Reporter: Megan >Priority: Minor > Attachments: testcase.zip > > > Removing a parent object in OneToMany with cascade=CascadeType.ALL raises > foreign key constraints exception > JpaParent.java > @OneToMany(mappedBy="parent", cascade=CascadeType.ALL) > private Set children = new HashSet(); > JpaChild.java > @ManyToOne(optional=false) > @JoinColumn(name="ParentId", nullable=false) > private JpaParent parent = null; > // This raises the following exception. If foreign key is removed, it works > OK (Maybe I have to let OpenJPA know about foreign key constraints) > JpaParent parent = em.find(JpaParent.class, 1); > em.remove(parent); > <2|true|0.9.0-incubating-SNAPSHOT> > org.apache.openjpa.persistence.RollbackException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:371) > at openjpa.test.BaseTestCase.destroyTestCase(BaseTestCase.java:82) > 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.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) > at > org.junit.internal.runners.BeforeAndAfterRunner.runAfters(BeforeAndAfterRunner.java:65) > at > org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:37) > at > org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) > at > org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) > at > org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71) > at > org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) > at > org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) > at > org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) > at > org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Caused by: <0|true|0.9.0-incubating-SNAPSHOT> > org.apache.openjpa.persistence.PersistenceException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2028) > at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1876) > at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1772) > at > org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1706) > at > org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:76) > at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1271) > at > org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:831) > at > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:360) > ... 21 more > Caused by: <0|false|0.9.0-incubating-SNAPSHOT> > org.apache.openjpa.persistence.PersistenceException: [BEA][SQLServer JDBC > Driver][SQLServe
[jira] Resolved: (OPENJPA-39) Cascade delete does not work with foreign key constraints
[ http://issues.apache.org/jira/browse/OPENJPA-39?page=all ] Abe White resolved OPENJPA-39. -- Resolution: Won't Fix Turns out the problem is more complicated than just having a foreign key. The issue is: - OpenJPA's UpdateManager plugin does not reorder SQL. It issues SQL in the same order as the corresponding object-level operations. The SQL-reordering UpdateManager is unique to Kodo. - When you delete a parent object and the operation cascades to children, the object-level operation order is delete parent, then delete children. - Issuing the SQL in that order will violate the FK constraint. OpenJPA is smart enough to detect this and null the children record's FK columns before deleting the parent. - However, the columns in this case are non-nullable, so this strategy doesn't work. So, given that there are no plans to donate Kodo's SQL-reordering UpdateManager, the options are: 1. Use nullable foreign key columns, or 2. Delete the child objects before the parent at the object level. Also if you choose option #1, make sure to get the latest OpenJPA from SVN, as there was a critical problem with nulling the FK columns correctly that is now fixed (9/11/2006). > Cascade delete does not work with foreign key constraints > - > > Key: OPENJPA-39 > URL: http://issues.apache.org/jira/browse/OPENJPA-39 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Environment: Microsoft SQL Server 2000 > Windows XP > Java SE 1.5 > OpenJPA - source downloaded Aug 28, 2006) > Show » > Microsoft SQL Server 2000 Windows XP Java SE 1.5 OpenJPA - source downloaded > today (Aug 14, 2006) >Reporter: Megan >Priority: Minor > Attachments: testcase.zip > > > Removing a parent object in OneToMany with cascade=CascadeType.ALL raises > foreign key constraints exception > JpaParent.java > @OneToMany(mappedBy="parent", cascade=CascadeType.ALL) > private Set children = new HashSet(); > JpaChild.java > @ManyToOne(optional=false) > @JoinColumn(name="ParentId", nullable=false) > private JpaParent parent = null; > // This raises the following exception. If foreign key is removed, it works > OK (Maybe I have to let OpenJPA know about foreign key constraints) > JpaParent parent = em.find(JpaParent.class, 1); > em.remove(parent); > <2|true|0.9.0-incubating-SNAPSHOT> > org.apache.openjpa.persistence.RollbackException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:371) > at openjpa.test.BaseTestCase.destroyTestCase(BaseTestCase.java:82) > 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.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) > at > org.junit.internal.runners.BeforeAndAfterRunner.runAfters(BeforeAndAfterRunner.java:65) > at > org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:37) > at > org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) > at > org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) > at > org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71) > at > org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) > at > org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) > at > org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) > at > org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Caused by: <0|true|0.9.0-incubating-SNAPSHOT> > org.apache.openjpa.persistence.PersistenceException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at >
[jira] Commented: (OPENJPA-24) Allow OpenJPA to be extensible
[
http://issues.apache.org/jira/browse/OPENJPA-24?page=comments#action_12433153 ]
Abe White commented on OPENJPA-24:
--
The ProductDerivation interface can have a getType() and can order on that type
without having to define all the type constants itself. My usual strategy is
to define the constants that make sense for the base type, leaving big "holes"
so that subclasses can insert their own constants for proper ordering:
public interface ProductDerivation {
public static final int BASETYPE1 = 10;
public static final int BASETYPE2 = 20;
...
}
It's somewhat delicate (I usually Javadoc the base constants with their values
and the fact that they shouldn't be changed), but it's simple and IMO it's
better than the base interface containing a bunch of meaningless (to it)
constants.
> Allow OpenJPA to be extensible
> --
>
> Key: OPENJPA-24
> URL: http://issues.apache.org/jira/browse/OPENJPA-24
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> The current OpenJPA architecture is not extendable to other implementations.
> For example, if somebody wanted to provide their own PersistenceProvider
> implementation, simply extending the
> org.apache.openjpa.PersistenceProviderImpl would not suffice due to the
> dependencies in the ConfigurationProviderImpl. The discussion for this
> improvement was started on the dev mailing list. Once it was determined that
> there was more to this request than a simple conditional or two, we decided
> to open a JIRA report.
> The complete history of this request can be found in the OpenJPA dev mailing
> list. The first message was posted by me (Kevin Sutter) on August 14, titled
> "Extending the OpenJPA Implementation". I will attempt to paraphrase the
> current state of the problem...
> We have three main players in this issue. The PersistenceProvider, the
> ConfigurationProvider, and the ProductDerivation (along with the various
> implementations of these interfaces). Currently, the ConfigurationProvider
> is in the lib and is unaware of any specific persistence requirements. The
> ProductDerivation is in the kernel and, unfortunately, is aware of
> persistence requirements, specifically the spec and store types. Abe's
> postings have indicated that we need to make these two interfaces more aware
> of each other and work with each other. We need to start with either making
> ConfigurationProvider more persistence-aware and move it into kernel, or make
> ProductDerivations less persistence-aware and move it into lib. The latter
> approach is preferred.
> After we get this re-organization of the base framework complete, we still
> have a couple of other issues ot resolve:
> * Still need the ability to extend EMF's through a ProductDerivation.
> This should be doable by adding a new PluginValue to indicate what class of
> EMF to load.
> * There is still a question as to whether we will need to provide a
> custom PersistenceProviderImpl and ConfigurationProviderImpl pair. I still
> think this will be necessary. And, one of Abe's posts indicated that this
> might help with class loading issues when multiple versions of OpenJPA-based
> implementations are available in the same system.
> I also posted these questions last Friday. (Abe has responded with some
> answers, but I wanted to get this JIRA report created before trying to
> paraphrase his answers.)
> * You mention in several places about separating away the notion of
> specs and stores. In a general sense, I understand what these are. But, can
> you elaborate on how these types are used in the ConfigurationProvider and
> ProductDerivation interfaces?
> * I've moved the ProductDerivation interface to the lib and added the
> "load" methods from the ConfigurationProvider (as described in your previous
> notes). And, I've started to clean up the implementations that depend on
> these interfaces. But, concerning the implementation of the load methods...
> Now that we need to return a ConfigurationProvider, would you expect that we
> just new up a ConfigurationProviderImpl and then just call across to the
> "load" methods on the implementation? Since we want to keep the
> ProductDerivations stateless, I'm not sure how else you were expecting to
> create a ConfigurationProvider to return on these "load" methods.
> * Now that ConfigurationProvider is bare, the
> ConfigurationTestConfigurationProvider doesn't have much function. I'll need
> to take a look to see if this is even required any longer.
> * Can you shed a bit more light on the Configurations class? It doesn't
> implement nor extend any interfaces or classes, but it seems to provide many
> of the same methods as ConfigurationProvider, but as
[jira] Commented: (OPENJPA-24) Allow OpenJPA to be extensible
[ http://issues.apache.org/jira/browse/OPENJPA-24?page=comments#action_12432227 ] Abe White commented on OPENJPA-24: -- Correction: the JPA configuration provider does use globals. It looks for an openjpa.xml resource for global configuration. Just as a Kodo user could have a kodo.properties but bootstrap his runtime through JPA, he could also use openjpa.xml but bootstrap his runtime through JDO. Again, the loading of globals is independent of the runtime bootstrapping mechanism. > Allow OpenJPA to be extensible > -- > > Key: OPENJPA-24 > URL: http://issues.apache.org/jira/browse/OPENJPA-24 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Reporter: Kevin Sutter > Assigned To: Kevin Sutter > > The current OpenJPA architecture is not extendable to other implementations. > For example, if somebody wanted to provide their own PersistenceProvider > implementation, simply extending the > org.apache.openjpa.PersistenceProviderImpl would not suffice due to the > dependencies in the ConfigurationProviderImpl. The discussion for this > improvement was started on the dev mailing list. Once it was determined that > there was more to this request than a simple conditional or two, we decided > to open a JIRA report. > The complete history of this request can be found in the OpenJPA dev mailing > list. The first message was posted by me (Kevin Sutter) on August 14, titled > "Extending the OpenJPA Implementation". I will attempt to paraphrase the > current state of the problem... > We have three main players in this issue. The PersistenceProvider, the > ConfigurationProvider, and the ProductDerivation (along with the various > implementations of these interfaces). Currently, the ConfigurationProvider > is in the lib and is unaware of any specific persistence requirements. The > ProductDerivation is in the kernel and, unfortunately, is aware of > persistence requirements, specifically the spec and store types. Abe's > postings have indicated that we need to make these two interfaces more aware > of each other and work with each other. We need to start with either making > ConfigurationProvider more persistence-aware and move it into kernel, or make > ProductDerivations less persistence-aware and move it into lib. The latter > approach is preferred. > After we get this re-organization of the base framework complete, we still > have a couple of other issues ot resolve: > * Still need the ability to extend EMF's through a ProductDerivation. > This should be doable by adding a new PluginValue to indicate what class of > EMF to load. > * There is still a question as to whether we will need to provide a > custom PersistenceProviderImpl and ConfigurationProviderImpl pair. I still > think this will be necessary. And, one of Abe's posts indicated that this > might help with class loading issues when multiple versions of OpenJPA-based > implementations are available in the same system. > I also posted these questions last Friday. (Abe has responded with some > answers, but I wanted to get this JIRA report created before trying to > paraphrase his answers.) > * You mention in several places about separating away the notion of > specs and stores. In a general sense, I understand what these are. But, can > you elaborate on how these types are used in the ConfigurationProvider and > ProductDerivation interfaces? > * I've moved the ProductDerivation interface to the lib and added the > "load" methods from the ConfigurationProvider (as described in your previous > notes). And, I've started to clean up the implementations that depend on > these interfaces. But, concerning the implementation of the load methods... > Now that we need to return a ConfigurationProvider, would you expect that we > just new up a ConfigurationProviderImpl and then just call across to the > "load" methods on the implementation? Since we want to keep the > ProductDerivations stateless, I'm not sure how else you were expecting to > create a ConfigurationProvider to return on these "load" methods. > * Now that ConfigurationProvider is bare, the > ConfigurationTestConfigurationProvider doesn't have much function. I'll need > to take a look to see if this is even required any longer. > * Can you shed a bit more light on the Configurations class? It doesn't > implement nor extend any interfaces or classes, but it seems to provide many > of the same methods as ConfigurationProvider, but as statics. And, it's > dependent on having a Provider. Can you explain the relationship of this > class in the bigger picture and how you think it might be affected by thes > changes? > That's enough for the initial JIRA report. We will now track this problem > here instead of the dev mailing list. Thanks. >
[jira] Commented: (OPENJPA-24) Allow OpenJPA to be extensible
[ http://issues.apache.org/jira/browse/OPENJPA-24?page=comments#action_12432225 ] Abe White commented on OPENJPA-24: -- Globals are configuration properties that are always loaded before any explicit configuration supplied by the user, both when using dev tools and at runtime. Each configuration provider decides on whether and how it uses globals. The JPA configuration provider does not use globals. Kodo's JDO configuration provider looks for a "kodo.properties" resource in the classpath and loads anything in it. A Kodo user could theoretically have a kodo.properties with JDO properties, but request an EntityManagerFactory through Persistence. Thus the loading of globals is independent of the runtime ConfigurationProvider created by PersistenceProviderImpl or any other bootstrapping mechanism. That is reflected in the behavior Kevin noted: when loading globals we loop through all the ConfigurationProviders in the system until we find one that loads successfully, regardless of how the user is bootstrapping his runtime. > Allow OpenJPA to be extensible > -- > > Key: OPENJPA-24 > URL: http://issues.apache.org/jira/browse/OPENJPA-24 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Reporter: Kevin Sutter > Assigned To: Kevin Sutter > > The current OpenJPA architecture is not extendable to other implementations. > For example, if somebody wanted to provide their own PersistenceProvider > implementation, simply extending the > org.apache.openjpa.PersistenceProviderImpl would not suffice due to the > dependencies in the ConfigurationProviderImpl. The discussion for this > improvement was started on the dev mailing list. Once it was determined that > there was more to this request than a simple conditional or two, we decided > to open a JIRA report. > The complete history of this request can be found in the OpenJPA dev mailing > list. The first message was posted by me (Kevin Sutter) on August 14, titled > "Extending the OpenJPA Implementation". I will attempt to paraphrase the > current state of the problem... > We have three main players in this issue. The PersistenceProvider, the > ConfigurationProvider, and the ProductDerivation (along with the various > implementations of these interfaces). Currently, the ConfigurationProvider > is in the lib and is unaware of any specific persistence requirements. The > ProductDerivation is in the kernel and, unfortunately, is aware of > persistence requirements, specifically the spec and store types. Abe's > postings have indicated that we need to make these two interfaces more aware > of each other and work with each other. We need to start with either making > ConfigurationProvider more persistence-aware and move it into kernel, or make > ProductDerivations less persistence-aware and move it into lib. The latter > approach is preferred. > After we get this re-organization of the base framework complete, we still > have a couple of other issues ot resolve: > * Still need the ability to extend EMF's through a ProductDerivation. > This should be doable by adding a new PluginValue to indicate what class of > EMF to load. > * There is still a question as to whether we will need to provide a > custom PersistenceProviderImpl and ConfigurationProviderImpl pair. I still > think this will be necessary. And, one of Abe's posts indicated that this > might help with class loading issues when multiple versions of OpenJPA-based > implementations are available in the same system. > I also posted these questions last Friday. (Abe has responded with some > answers, but I wanted to get this JIRA report created before trying to > paraphrase his answers.) > * You mention in several places about separating away the notion of > specs and stores. In a general sense, I understand what these are. But, can > you elaborate on how these types are used in the ConfigurationProvider and > ProductDerivation interfaces? > * I've moved the ProductDerivation interface to the lib and added the > "load" methods from the ConfigurationProvider (as described in your previous > notes). And, I've started to clean up the implementations that depend on > these interfaces. But, concerning the implementation of the load methods... > Now that we need to return a ConfigurationProvider, would you expect that we > just new up a ConfigurationProviderImpl and then just call across to the > "load" methods on the implementation? Since we want to keep the > ProductDerivations stateless, I'm not sure how else you were expecting to > create a ConfigurationProvider to return on these "load" methods. > * Now that ConfigurationProvider is bare, the > ConfigurationTestConfigurationProvider doesn't have much function. I'll need > to take a look to see if this i
[jira] Commented: (OPENJPA-39) Cascade delete does not work with foreign key constraints
[ http://issues.apache.org/jira/browse/OPENJPA-39?page=comments#action_12432221 ] Abe White commented on OPENJPA-39: -- In the above comment, the correct annotation is org.apache.openjpa.persistence.jdbc.ForeignKey. > Cascade delete does not work with foreign key constraints > - > > Key: OPENJPA-39 > URL: http://issues.apache.org/jira/browse/OPENJPA-39 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Environment: Microsoft SQL Server 2000 > Windows XP > Java SE 1.5 > OpenJPA - source downloaded Aug 28, 2006) > Show » > Microsoft SQL Server 2000 Windows XP Java SE 1.5 OpenJPA - source downloaded > today (Aug 14, 2006) >Reporter: Megan >Priority: Minor > Attachments: testcase.zip > > > Removing a parent object in OneToMany with cascade=CascadeType.ALL raises > foreign key constraints exception > JpaParent.java > @OneToMany(mappedBy="parent", cascade=CascadeType.ALL) > private Set children = new HashSet(); > JpaChild.java > @ManyToOne(optional=false) > @JoinColumn(name="ParentId", nullable=false) > private JpaParent parent = null; > // This raises the following exception. If foreign key is removed, it works > OK (Maybe I have to let OpenJPA know about foreign key constraints) > JpaParent parent = em.find(JpaParent.class, 1); > em.remove(parent); > <2|true|0.9.0-incubating-SNAPSHOT> > org.apache.openjpa.persistence.RollbackException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:371) > at openjpa.test.BaseTestCase.destroyTestCase(BaseTestCase.java:82) > 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.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) > at > org.junit.internal.runners.BeforeAndAfterRunner.runAfters(BeforeAndAfterRunner.java:65) > at > org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:37) > at > org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) > at > org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) > at > org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71) > at > org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) > at > org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) > at > org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) > at > org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Caused by: <0|true|0.9.0-incubating-SNAPSHOT> > org.apache.openjpa.persistence.PersistenceException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2028) > at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1876) > at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1772) > at > org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1706) > at > org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:76) > at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1271) > at > org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:831) > at > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:360) > ... 21 more > Caused by: <0|false|0.9.0-incubating-SNAPSHOT> > org.apache.openjpa.persistence.PersistenceException: [BEA][SQLServer JDBC > Driver][SQLServer]DELETE statement conflicted with COLUMN REFERENCE > constraint 'JpaChild_Parent_FK'. The conflict occurred in data
[jira] Commented: (OPENJPA-39) Cascade delete does not work with foreign key constraints
[ http://issues.apache.org/jira/browse/OPENJPA-39?page=comments#action_12432220 ] Abe White commented on OPENJPA-39: -- OpenJPA has to know where the DB foreign keys are. You have a few options: - Using the org.apache.openjpa.persistence.ForeignKey annotation, and related annnotations (ElementForeignKey, etc) to tell OpenJPA exactly which relations and joins have foreign keys on them. - Setting the "openjpa.jdbc.SchemaFactory" property to "native(ForeignKeys=true)" will tell OpenJPA to read the existing schema from the DB, including foreign key locations, using JDBC schema reflection. Under this setting OpenJPA will also validate that the schema and mappings match. - Setting the "openjpa.jdbc.MappingDefaults" property to "jpa(ForeignKeyDeleteAction=restrict, JoinForeignKeyDeleteAction=restrict)" will tell OpenJPA to just assume that all relations and joins are backed by database foreign keys. The first and third options also affect schema creation, in that OpenJPA's schema creation tools will add foreign keys to to the annotated relations and joins / to all relations and joins under those settings. I'll leave this JIRA open for now in case anyone would like to comment on whether we should change the defaults. Right now the defaults are to never assume any relation or join is backed by a database foreign key, and to never create database foreign keys during schema creation. > Cascade delete does not work with foreign key constraints > - > > Key: OPENJPA-39 > URL: http://issues.apache.org/jira/browse/OPENJPA-39 > Project: OpenJPA > Issue Type: Bug > Components: jpa > Environment: Microsoft SQL Server 2000 > Windows XP > Java SE 1.5 > OpenJPA - source downloaded Aug 28, 2006) > Show » > Microsoft SQL Server 2000 Windows XP Java SE 1.5 OpenJPA - source downloaded > today (Aug 14, 2006) >Reporter: Megan >Priority: Minor > Attachments: testcase.zip > > > Removing a parent object in OneToMany with cascade=CascadeType.ALL raises > foreign key constraints exception > JpaParent.java > @OneToMany(mappedBy="parent", cascade=CascadeType.ALL) > private Set children = new HashSet(); > JpaChild.java > @ManyToOne(optional=false) > @JoinColumn(name="ParentId", nullable=false) > private JpaParent parent = null; > // This raises the following exception. If foreign key is removed, it works > OK (Maybe I have to let OpenJPA know about foreign key constraints) > JpaParent parent = em.find(JpaParent.class, 1); > em.remove(parent); > <2|true|0.9.0-incubating-SNAPSHOT> > org.apache.openjpa.persistence.RollbackException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:371) > at openjpa.test.BaseTestCase.destroyTestCase(BaseTestCase.java:82) > 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.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) > at > org.junit.internal.runners.BeforeAndAfterRunner.runAfters(BeforeAndAfterRunner.java:65) > at > org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:37) > at > org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) > at > org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) > at > org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71) > at > org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) > at > org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) > at > org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) > at > org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196
[jira] Resolved: (OPENJPA-14) PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib'
[ http://issues.apache.org/jira/browse/OPENJPA-14?page=all ] Abe White resolved OPENJPA-14. -- Resolution: Fixed Applied patch (with minor corrections). > PCEnhancer ant task requires openjpa jars to be on the system classpath or > passed into ant with '-lib' > -- > > Key: OPENJPA-14 > URL: http://issues.apache.org/jira/browse/OPENJPA-14 > Project: OpenJPA > Issue Type: Bug > Components: lib > Environment: Windows XP >Reporter: Bryan Noll > Assigned To: Bryan Noll > Attachments: OPENJPA-14.patch1, OPENJPA-14.patch2, OPENJPA-14.patch3, > OPENJPA-14.patch4 > > > Ideally, one should be able to run 'ant openjpac' (openjpac would be a > target defined in the build script that would use the PCEnhancer task) > without having to put the openjpa jars on the system classpath or having to > pass them into ant vie the '-lib' argument. Currently this is not possible. > The root of the issue can be seen from by looking at the public static > String[] getImplementors(String serviceName, ClassLoader loader) method of > the Services class. Basically, the call to > loader = Thread.currentThread().getContextClassLoader(); > returns a ClassLoader with the $ANT_HOME\lib\*.jar and > $JAVA_HOME\lib\tools.jar in it... which obviously doesn't contain > 'META-INF/services/org.apache.openjpa.conf.ProductDerivation' > The exception seen when encountering this issue: > java.lang.ExceptionInInitializerError > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:510) > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:160) > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:151) > at > org.apache.openjpa.ant.PCEnhancerTask.newConfiguration(PCEnhancerTask.java:77) > at > org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:170) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) > at org.apache.tools.ant.Task.perform(Task.java:364) > at org.apache.tools.ant.Target.execute(Target.java:341) > at org.apache.tools.ant.Target.performTasks(Target.java:369) > at > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) > at org.apache.tools.ant.Project.executeTarget(Project.java:1185) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) > at org.apache.tools.ant.Project.executeTargets(Project.java:1068) > at org.apache.tools.ant.Main.runBuild(Main.java:668) > at org.apache.tools.ant.Main.startAnt(Main.java:187) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:251) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:72) > Caused by: java.util.MissingResourceException: Your system is missing product > derivations. Product derivations provide configuration options for supported > data stores and specifications. You must have a > META-INF/services/org.apache.openjpa.conf.ProductDerivation file in your > classpath listing the available derivation classes, and some listed class > must be instantiable. Typically this file is bundled as part of the > distribution. Have you unbundled it, or unbundled its listed classes? > at > org.apache.openjpa.conf.ProductDerivations.(ProductDerivations.java:53) > ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-14) PCEnhancer ant task requires openjpa jars to be on the system classpath or passed into ant with '-lib'
[ http://issues.apache.org/jira/browse/OPENJPA-14?page=comments#action_12428815 ] Abe White commented on OPENJPA-14: -- Note that we already have an available way to set the config file or resource location: -- or -- The element also lets you specify any property directly, like: This works b/c our AbstractTask has a createConfig() method that returns the Configuration instance (in this case, an OpenJPAConfiguration or JDBCConfiguration subclass instance depending on the task), so all bean methods are settable. The element isn't required, but I agree with Patrick that it shouldn't be, given that we'll detect persistence.xml if it's available in the classpath. IMO, it would be better to fix the NPE to have a good error message than to require an explicit config file declaration. > PCEnhancer ant task requires openjpa jars to be on the system classpath or > passed into ant with '-lib' > -- > > Key: OPENJPA-14 > URL: http://issues.apache.org/jira/browse/OPENJPA-14 > Project: OpenJPA > Issue Type: Bug > Components: lib > Environment: Windows XP >Reporter: Bryan Noll > Assigned To: Bryan Noll > Attachments: OPENJPA-14.patch1, OPENJPA-14.patch2 > > > Ideally, one should be able to run 'ant openjpac' (openjpac would be a > target defined in the build script that would use the PCEnhancer task) > without having to put the openjpa jars on the system classpath or having to > pass them into ant vie the '-lib' argument. Currently this is not possible. > The root of the issue can be seen from by looking at the public static > String[] getImplementors(String serviceName, ClassLoader loader) method of > the Services class. Basically, the call to > loader = Thread.currentThread().getContextClassLoader(); > returns a ClassLoader with the $ANT_HOME\lib\*.jar and > $JAVA_HOME\lib\tools.jar in it... which obviously doesn't contain > 'META-INF/services/org.apache.openjpa.conf.ProductDerivation' > The exception seen when encountering this issue: > java.lang.ExceptionInInitializerError > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:510) > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:160) > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.(OpenJPAConfigurationImpl.java:151) > at > org.apache.openjpa.ant.PCEnhancerTask.newConfiguration(PCEnhancerTask.java:77) > at > org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:170) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) > at org.apache.tools.ant.Task.perform(Task.java:364) > at org.apache.tools.ant.Target.execute(Target.java:341) > at org.apache.tools.ant.Target.performTasks(Target.java:369) > at > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) > at org.apache.tools.ant.Project.executeTarget(Project.java:1185) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) > at org.apache.tools.ant.Project.executeTargets(Project.java:1068) > at org.apache.tools.ant.Main.runBuild(Main.java:668) > at org.apache.tools.ant.Main.startAnt(Main.java:187) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:251) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:72) > Caused by: java.util.MissingResourceException: Your system is missing product > derivations. Product derivations provide configuration options for supported > data stores and specifications. You must have a > META-INF/services/org.apache.openjpa.conf.ProductDerivation file in your > classpath listing the available derivation classes, and some listed class > must be instantiable. Typically this file is bundled as part of the > distribution. Have you unbundled it, or unbundled its listed classes? > at > org.apache.openjpa.conf.ProductDerivations.(ProductDerivations.java:53) > ... 17 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
