[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 extent 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: ?xml version=1.0 encoding=UTF-8? extent object class=net.iss.mss.jpa.examples.remedy.Customer oid=1 version=0 field name=customerId 1 /field field name=customerName customer1 /field field name=users element org.apache.openjpa.util.StringId:1 /element element org.apache.openjpa.util.StringId:2 /element /field /object /extent 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.
Re: Bug when persisting two related objects
Are the two types related by inheritance? If two classes in an inheritance hierarchy use the same id class, then every instance of both classes must have a distinct id value. If you want instances in inheritance-related classes to be able to have the same id values, then you must use different id classes for different classes in the inheritance hierarchy. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [jira] Commented: (OPENJPA-236) No apparent way to generate all required SQL within a class derived from FullClassStrategy
It's possible that I'm stumbling around in the dark. If so, it would be great if you could shine a light on the issue. Just make it a two-sided relation, as is required by standard JPA. Problem solved. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [jira] Commented: (OPENJPA-51) bad sql pushdown, sub select is missing from clause
You are right, the code before theispatch (SelectImpl.java revision 52881) worked for to-one relation, but never worked for to-many relation. Do you have any idea of fixing this problem? Your patch broke it, so I assume you'll either roll back the patch or fix it. As I said, I don't remember the details of the table aliasing, and unfortunately I don't have time to dig into it now. So I won't be able to help. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-51) bad sql pushdown, sub select is missing from clause
[
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494070
]
Abe White commented on OPENJPA-51:
--
Yes, the test was passing before. Have you tried against a to-one relation
rather than a to-many?
Perhaps it was never working against a to-many.
bad sql pushdown, sub select is missing from clause
---
Key: OPENJPA-51
URL: https://issues.apache.org/jira/browse/OPENJPA-51
Project: OpenJPA
Issue Type: Bug
Components: query
Environment: Windows xp, db2, derby
Reporter: George Hongell
Assigned To: David Wisneski
Fix For: 0.9.8
Attachments: failureEntities.jar, SelectImpl.java.patch
451 - bad sql pushdown sub select is missing from clause
TEST451; select e from EmpBean e where e.empid any (select e1.empid from
DeptBean d, in(d.emps) e1 where d.no = 200)
28344 TRACE [main] openjpa.jdbc.SQL - t 1094861122, conn 295440796 [0 ms]
executing prepstmnt 81790176 SELECT t0.empid, t0.bonus, t2.deptno, t2.budget,
t2.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street,
t3.city, t3.state, t3.zip, t0.isManager, t0.name, t0.salary, t4.street,
t4.city, t4.state, t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON
t0.dept_deptno = t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street =
t3.street LEFT OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE
(t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
s/b
select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
WHERE t1.empid ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
200}
0|false|0.0.0 org.apache.openjpa.persistence.PersistenceException: Syntax
error: Encountered WHERE at line 1, column 520. {SELECT t2.empid, t2.bonus,
t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
t5.street WHERE (t2.empid ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
AS BIGINT) = CAST(? AS BIGINT)} [code=3, state=42X01]
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
at
org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
at
org.apache.openjpa.lib.rop.EagerResultList.init(EagerResultList.java:37)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
at
com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
junit.extensions.jfunc.TestletWrapper.runBare(TestletWrapper.java:116)
at
junit.extensions.jfunc.TestletWrapper$1.protect(TestletWrapper.java:106)
at junit.framework.TestResult.runProtected(Unknown Source)
at junit.extensions.jfunc.TestletWrapper.run(TestletWrapper.java:109)
at junit.framework.TestSuite.runTest(Unknown
[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] 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 - t 1094861122, conn 295440796 [0 ms]
executing prepstmnt 81790176 SELECT t0.empid, t0.bonus, t2.deptno, t2.budget,
t2.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street,
t3.city, t3.state, t3.zip, t0.isManager, t0.name, t0.salary, t4.street,
t4.city, t4.state, t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON
t0.dept_deptno = t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street =
t3.street LEFT OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE
(t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
s/b
select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
WHERE t1.empid ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
200}
0|false|0.0.0 org.apache.openjpa.persistence.PersistenceException: Syntax
error: Encountered WHERE at line 1, column 520. {SELECT t2.empid, t2.bonus,
t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
t5.street WHERE (t2.empid ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
AS BIGINT) = CAST(? AS BIGINT)} [code=3, state=42X01]
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
at
org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
at
org.apache.openjpa.lib.rop.EagerResultList.init(EagerResultList.java:37)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
at
com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke
[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 - t 1094861122, conn 295440796 [0 ms]
executing prepstmnt 81790176 SELECT t0.empid, t0.bonus, t2.deptno, t2.budget,
t2.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street,
t3.city, t3.state, t3.zip, t0.isManager, t0.name, t0.salary, t4.street,
t4.city, t4.state, t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON
t0.dept_deptno = t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street =
t3.street LEFT OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE
(t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
s/b
select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
WHERE t1.empid ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
200}
0|false|0.0.0 org.apache.openjpa.persistence.PersistenceException: Syntax
error: Encountered WHERE at line 1, column 520. {SELECT t2.empid, t2.bonus,
t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
t5.street WHERE (t2.empid ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
AS BIGINT) = CAST(? AS BIGINT)} [code=3, state=42X01]
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
at
org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
at
org.apache.openjpa.lib.rop.EagerResultList.init(EagerResultList.java:37)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
at
com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
[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 - t 1094861122, conn 295440796 [0 ms]
executing prepstmnt 81790176 SELECT t0.empid, t0.bonus, t2.deptno, t2.budget,
t2.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street,
t3.city, t3.state, t3.zip, t0.isManager, t0.name, t0.salary, t4.street,
t4.city, t4.state, t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON
t0.dept_deptno = t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street =
t3.street LEFT OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE
(t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
s/b
select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
WHERE t1.empid ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
200}
0|false|0.0.0 org.apache.openjpa.persistence.PersistenceException: Syntax
error: Encountered WHERE at line 1, column 520. {SELECT t2.empid, t2.bonus,
t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
t5.street WHERE (t2.empid ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
AS BIGINT) = CAST(? AS BIGINT)} [code=3, state=42X01]
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
at
org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
at
org.apache.openjpa.lib.rop.EagerResultList.init(EagerResultList.java:37)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
at
com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
at
com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43
Re: How to debug object retrieveal in JPA?
Actually I am doing the clear, once I got rid of it the exception disappeared. SO IMHO no bug No, you're clearing a list. Craig is referring to the pcClearFields call. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: How to debug object retrieveal in JPA?
Caused by: java.lang.NullPointerException at java.util.ArrayList.addAll(ArrayList.java:472) at ca.BidSpec.emall.user.Person.pcsetPhoneNumbers(Person.java:727) at ca.BidSpec.emall.user.Person.pcClearFields(Person.java) at ca.BidSpec.emall.user.Person.pcNewInstance(Person.java) at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:121) There you go. OpenJPA is clearing the instance state as part of its initialization routine, and that's causing a NullPointerException in your setter at Person.java line 727. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: How to debug object retrieveal in JPA?
ca.BidSpec.emall.user.Person.pcsetPhoneNumbers(Person.java:727) I had read this and assumed that it was an OpenJPA-generated method, but if so, there shouldn't be a line number. Did you reverse-compile your classes at some point and change the synthetic interception methods? That is the original method with a new name. As the documentation states, the getters and setters used in property access may appear with a pc prefix in stack traces under OpenJPA. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [jira] Updated: (OPENJPA-229) OpenJPA fails with MappedSuperclasses and Entities with the same short names
Any thoughts about this patch? It changes how @Embeddable and @MappedSuperclass classes are enhanced. I'd be a little nervous about NPEs registering a null alias, but it seems that it's been tested so apparently that's fine. The only thing that might be missing is to put an if (alias != null) block around the code where we add a registered class's alias to the alias map in MetaDataRepository.processRegisteredClass(). Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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) MapWeakReferenceClass,CollectionString 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.
Re: [jira] Commented: (OPENJPA-134) Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER
I did notice that my lazy scenarios are almost 50% slower now, but looking at the sql dumps it appears that we were fetching eagerly even in those scenarios and this (or another JIRA?) seems to have fixed that functional error. Does that seem like something your changes would resolve? Did you run into anything that would cause an eager fetch even when lazy was specified? I had no intention of fixing any lazy loading behavior. The fact that you're seeing different behavior makes me nervous. Can you post details on the entities and the test case so we can determine for sure whether the new or old behavior is correct? ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Problem trying to persist an entity into Derby from a Web App deployed to Geronimo
It sounds like you're never starting or committing a transaction. You're persisting outside of a transaction, which just means that the object will be cached until the next transaction, waiting for a flush/ commit to be inserted into the database. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: OPENJPA-134 and the 0.9.7 release
Generally in favor of including this performance patch with the release. Just a few questions: 1. How good is the patch? Has it been put through whatever extensive Unit Tests tests anyone has? As others have said, it does pass the OpenJPA test suite, but unfortunately that isn't saying all that much. AFAIK it hasn't been put through the old Kodo test suite. Of course I always think my code is correct, but it'd be nice if someone could put it through whatever performance tests prompted the bug report in the first place (the whole suite, not just the particular cases with extra joins). If I did screw up the fix, it probably wouldn't break anything functional, but would instead result in less optimal SQL than before. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Float primary key?
I believe that OpenJPA will allow float pk fields, it's just that there's no built-in id class for them (see util.LongId, ShortId, etc). So you'd have to either add a built-in id class and alter OpenJPA's internal code to use it appropriately, or create your own id class and use it via the @IdClass annotation, as you would for a compound pk. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Float primary key?
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. Given the spec section you quoted, you're definitely right. It's something we need to support. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: How to set the type of the DB-field using @Externalizer
I'm trying to use the @Externalizer annotation but have problems with the resulting type of the DB-field - it's always a byte-array. You shouldn't need the @Type annotation -- the type will be inferred from the return type of the externalizer method. Are you dropping the database table in between attempts? It's possible that if your first attempt resulted in a byte array column because of some misconfiguration, OpenJPA will think it is supposed to reuse that column on subsequent mapping attempts, because technically it can fit anything in a byte-array column. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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 - t 1094861122, conn
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.
Re: How to set the type of the DB-field using @Externalizer
I can't reproduce this. When I leave out the @Persistent annotation on the field or replace it with @Basic, I do indeed end up with a binary column. But if I correctly include the @Persistent annotation along with the @Externalizer, I get a varchar column. Can you narrow down your entity to the smallest possible class that exhibits the problem and post it to the list so we can try to reproduce the error? Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Three minor issues with the OpenJPA User's Guide.
OpenJPA expands the available ordering syntax. See ??? in the Reference Guide for details. I'm assuming this should be referring to our Large Result Set capabilities. LRS capabilities don't affect OrderBy. The note should be removed -- OpenJPA does not expand the OrderBy syntax. (Kodo does, and I believe this is an accidental holdover from Kodo.) Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [jira] Resolved: (OPENJPA-208) NoResultException and NonUniqueResultException are not thrown when expected
Went ahead and restored the previous behavior where the QueryImpl itself checks for non-uniqueness and throws the expected exception. That breaks the single result optimization that was added for OPENJPA-168 when getSingleResult() is called. There was a reason we moved the validation to the kernel. The previous code was correct. You need to use the hard way of creating new exception types. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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 - t 1094861122, conn
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.
Re: svn commit: r525997 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/ openjpa-jdbc/src/main/resource
Comments inline...
+/**
+ * pThe isolation level for queries issued to the database.
This overrides
+ * the persistence-unit-wide
codeopenjpa.jdbc.TransactionIsolation/code
+ * value./p
+ *
+ * pMust be one of [EMAIL PROTECTED] Connection#TRANSACTION_NONE},
+ * [EMAIL PROTECTED] Connection#TRANSACTION_READ_UNCOMMITTED},
+ * [EMAIL PROTECTED] Connection#TRANSACTION_READ_COMMITTED},
+ * [EMAIL PROTECTED] Connection#TRANSACTION_REPEATABLE_READ},
+ * [EMAIL PROTECTED] Connection#TRANSACTION_SERIALIZABLE},
+ * or -1 for the default connection level specified by the
context in
+ * which this fetch configuration is being used./p
+ *
+ * @since 0.9.7
+ */
+public int getIsolationLevel();
Why is this setting called IsolationLevel where our global setting
is called TransactionIsolation? Shouldn't this local setting just
be called Isolation for consistency? Same with the FetchPlan facade.
public Set joins = null;
+public int isolationLevel = -1;
The FetchConfiguration interface defines a DEFAULT constant. The doc
on this constant is: Constant to revert any setting back to its
default value. We should either change all the places where we're
using -1 to use DEFAULT or at least change the setIsolation setter to
look for DEFAULT and translate it to -1.
+public JDBCFetchConfiguration setIsolationLevel(int level) {
+if (level != -1
+ level != Connection.TRANSACTION_NONE
+ level != Connection.TRANSACTION_READ_UNCOMMITTED
+ level != Connection.TRANSACTION_READ_COMMITTED
+ level != Connection.TRANSACTION_REPEATABLE_READ
+ level != Connection.TRANSACTION_SERIALIZABLE)
+throw new IllegalArgumentException(
+_loc.get(bad-level, Integer.valueOf
(level)).getMessage());
Switch statement...
+/**
+ * Get the update clause for the query based on the
+ * updateClause and isolationLevel hints
+ */
+protected String getForUpdateClause(JDBCFetchConfiguration fetch,
+boolean forUpdate) {
+if (fetch.getIsolationLevel() != -1)
+throw new IllegalStateException(_loc.get(
+isolation-level-config-not-supported, getClass
().getName())
+.getMessage());
+else
+return forUpdateClause;
}
Any reason we aren't using our own InvalidStateException (extends
UserException)?
if (forUpdate !simulateLocking) {
assertSupport(supportsSelectForUpdate,
SupportsSelectForUpdate);
-if (forUpdateClause != null)
-buf.append( ).append(forUpdateClause);
+if (this.forUpdateClause != null)
+buf.append( ).append(this.forUpdateClause);
}
Why are we passing a new forUpdateClause param to this method if
we're going to ignore it and use our forUpdateClause member?
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
[jira] 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-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 - t 1094861122, conn
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.
Re: svn commit: r525997 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/ openjpa-jdbc/src/main/resource
Why is this setting called IsolationLevel where our global setting is called TransactionIsolation? Shouldn't this local setting just be called Isolation for consistency? Same with the FetchPlan facade. Personally, I feel that 'IsolationLevel' is a more-well-known term for the concept. I'm fine with either name, though. Does anyone else have an opinion on this? I think get/setIsolation would be more consistent with the global TransactionIsolation property. I doubt the lack of a Level suffix is going to hurt. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: OPENJPA-182: reuse Connection constants or create our own?
I think that JDBCFetchPlan should take a Java 5 enum, and JDBCFetchConfiguration should use the Connection values. Certainly JDBCFetchConfiguration should use the Connection values. I personally have never had a problem with symbolic constants for settings, but enums for the FetchPlan are cool too. So long as the JPA QueryImpl parses the enum value and its string form correctly when using it as a hint. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation 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 isolation 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-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 isolation 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 isolation 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.
Re: why not an EntityExistsException was thrown?
an pluggable exception factory (in open-jpa) might make this approach a little easier See DBDictionary.newStoreException(...). Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: svn commit: r525006 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/ openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
I see several possible problems with this commit. Are there tests
for this functionality checked in?
1. The property and logic for using the DefaultSchemaName are defined
in MappingInfo, but the default schema name is only ever set into
ClassMappingInfos. Not FieldMappingInfos, DiscriminatorMappingInfos,
etc.
2. MappingInfo uses the default schema name sometimes (line 445) but
ignores it other times (line 469).
3. It should not be necessary to prepend the schema name to the table
name in PersistenceMappingDefaults. The schema is already known.
Was that code added based on any testing? If so, perhaps it is
because of problem #2 above.
4. The XMLPersistenceMappingParser should not override the endClass
(String) method. It already overrides the endClassMapping
(ClassMetaData) method, which is a much more efficient place to set
the needed info. You could also do it in the startClassMapping method.
I'm happy to fix things myself, but I don't see any tests in the
commit to verify my fixes.
On Apr 2, 2007, at 9:48 PM, [EMAIL PROTECTED] wrote:
Author: mikedd
Date: Mon Apr 2 19:48:10 2007
New Revision: 525006
URL: http://svn.apache.org/viewvc?view=revrev=525006
Log:
OpenJPA-179 store defaultSchemaName in ClassMapping
Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/meta/MappingInfo.java
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java
incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/XMLPersistenceMappingParser.java
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/meta/MappingInfo.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/meta/MappingInfo.java?
view=diffrev=525006r1=525005r2=525006
==
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/meta/MappingInfo.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/meta/MappingInfo.java Mon Apr 2 19:48:10 2007
@@ -21,6 +21,7 @@
import java.util.Collections;
import java.util.List;
+import org.apache.commons.lang.StringUtils;
import org.apache.openjpa.jdbc.conf.JDBCConfiguration;
import org.apache.openjpa.jdbc.schema.Column;
import org.apache.openjpa.jdbc.schema.ColumnIO;
@@ -69,6 +70,7 @@
private boolean _canFK = true;
private int _join = JOIN_NONE;
private ColumnIO _io = null;
+private String _defaultSchemaName = null;
/**
* Mapping strategy name.
@@ -439,6 +441,9 @@
if (schema == null) {
schemaName = Schemas.getNewTableSchema
((JDBCConfiguration)
repos.getConfiguration());
+if(StringUtils.isEmpty(schemaName)) {
+ schemaName = _defaultSchemaName;
+}
schema = group.getSchema(schemaName);
if (schema == null)
schema = group.addSchema(schemaName);
@@ -1764,4 +1769,12 @@
public void populate(Table local, Table foreign, Column col,
Object target, boolean inverse, int pos, int cols);
}
+
+public String getDefaultSchemaName() {
+return _defaultSchemaName;
+}
+
+public void setDefaultSchemaName(String schemaName) {
+_defaultSchemaName = schemaName;
+}
}
Modified: incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/
java/org/apache/openjpa/persistence/jdbc/
PersistenceMappingDefaults.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/
PersistenceMappingDefaults.java?
view=diffrev=525006r1=525005r2=525006
==
--- incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java
(original)
+++ incubator/openjpa/trunk/openjpa-persistence-jdbc/src/main/java/
org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java
Mon Apr 2 19:48:10 2007
@@ -15,6 +15,7 @@
*/
package org.apache.openjpa.persistence.jdbc;
+import org.apache.commons.lang.StringUtils;
import org.apache.openjpa.jdbc.meta.ClassMapping;
import org.apache.openjpa.jdbc.meta.Discriminator;
import org.apache.openjpa.jdbc.meta.FieldMapping;
@@ -114,17 +115,31 @@
@Override
public String getTableName(ClassMapping cls, Schema schema) {
+String name = ;
+
+if(StringUtils.isNotEmpty(schema.getName())) {
+name +=schema.getName() + '.';
+}
+
if (cls.getTypeAlias() != null)
-return
Re: Build failure with autoboxing
This is strange. Autoboxing turned off somehow? I must be doing something wrong. ... /Users/clr/openjpa/openjpa/trunk/openjpa-jdbc/src/main/java/org/ apache/openjpa/jdbc/sql/DB2Dictionary.java:[242,31] incompatible types Stuff if kernel needs to be 1.4-compatible. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
The DB2Dictionary class doesn't compile with 1.4 due to autoboxing. Can you please fix this? And I'd like to see all those hints defined as static constants on the dictionary class and named for DB2 (if they're that specific) and capitalized while you're at it -- see OracleDictionary.SELECT_HINT for a template. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Index already exists exception
Note that I don't think OpenJPA reads index names from the existing schema by default, so if you're adding fields or classes these might be plain old naming conflicts due to truncation based on database name length limits. There is a readSchema option on the mapping tool that forces it to read index and foreign key names and so forth, but it slows the tool down a lot for some DBs with slow schema reflection. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
Hibernate and TopLink will fail once you get rid of the if statement. It's because according to the spec (and my understanding) merge should rise exception when the versioned property is outdated. No, the exception can be deferred until flush/commit. Read section 3.2.4.1. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] 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 - t 1094730048, conn 1318342292 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 - t 1094730048, conn 1318342292 [40 ms] spent 2223 demo TRACE [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 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 - t 1094730048, conn 1314410072 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 - t 1094730048, conn 1318342292 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 - t 1094730048, conn 1318342292 [40 ms] spent 2393 demo TRACE [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 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 - t 1094730048, conn 1318342292 [0 ms] spent 3134 demo TRACE [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 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 - t 1094730048, conn 1318342292 [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 - t 1094730048, conn 1307463150 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
Re: MappingTool help
I am trying to use MappingTool with a JDO file named package.jdo to generate the package-mysql.orm and create the tables in my database, the orm file is created succesfully with one exception, the table name is not what i expected with subsequent call to the MappingTool. The mapping tool is designed to avoid using existing tables and columns when mapping previously-unmapped portions of your object model. Apparently you're deleting the mapping file periodically, so every run the tool thinks the model is unmapped -- how could it know otherwise? So either start over and stop deleting your mapping file all the time, or if you want the table to be named something specific, just stick the table='XXX' attribute on the class element in your package.jdo file. The tool will see the mapping instruction and carry it over to the mapping file. I believe the docs cover all this in more detail. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] 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.
Re: composite ID based on one side of a bidirectional one-many relationship
the book field in the PageId class must be of type String to match the primary key field type of Book was i mistaken when i understood you to say that Page could have a PK field of type Book? No, you weren't mistaken. But as I said, the book field in the Page*Id* class must match the pk type of the relation. Check the example in the docs. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] 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.
Re: Shared classloader and subclasses
I've committed an equivalent patch to 0.9.7 in SVN revision 522623.
Can you confirm whether this fixes your problem and, if so, close any
CR you might have opened on this?
This works for me :) Here's a patch for 0.9.6 source. I've gone for
the
simplest solution, but it might be improved by looping over pcNames
instead
of _registered (?).
http://www.nabble.com/file/7398/openjpa-diff openjpa-diff
Index: MetaDataRepository.java
===
--- MetaDataRepository.java
(.../tags/0.9.6/openjpa-kernel/src/main/java/org/apache/openjpa/meta)
(revision 3)
+++ MetaDataRepository.java
(.../branches/0.9.6-ninthavenue/openjpa-kernel/src/main/java/org/
apache/openjpa/meta)
(working copy)
@@ -302,7 +302,7 @@
return null;
// check cache
-processRegisteredClasses();
+processRegisteredClasses(envLoader);
List classList = (List) _aliases.get(alias);
// multiple classes may have been defined with the same
alias: we
@@ -928,7 +928,7 @@
}
// check cache
-processRegisteredClasses();
+processRegisteredClasses(envLoader);
Class cls = (Class) _oids.get(oid.getClass());
if (cls != null)
return getMetaData(cls, envLoader, mustExist);
@@ -944,7 +944,7 @@
// if still not match, register any classes that look
similar to
the
// oid class and check again
resolveIdentityClass(oid);
-if (processRegisteredClasses().length 0) {
+if (processRegisteredClasses(envLoader).length 0) {
cls = (Class) _oids.get(oid.getClass());
if (cls != null)
return getMetaData(cls, envLoader, mustExist);
@@ -1262,7 +1262,7 @@
* Parses the metadata for all registered classes.
*/
private void loadRegisteredClassMetaData(ClassLoader envLoader) {
-Class[] reg = processRegisteredClasses();
+Class[] reg = processRegisteredClasses(envLoader);
for (int i = 0; i reg.length; i++) {
try {
getMetaData(reg[i], envLoader, false);
@@ -1276,7 +1276,7 @@
/**
* Updates our datastructures with the latest registered classes.
*/
-Class[] processRegisteredClasses() {
+Class[] processRegisteredClasses(ClassLoader envLoader) {
if (_registered.isEmpty())
return EMPTY_CLASSES;
@@ -1289,9 +1289,18 @@
}
Collection failed = null;
+Collection pcNames = getPersistentTypeNames(false,
envLoader);
for (int i = 0; i reg.length; i++) {
try {
-processRegisteredClass(reg[i]);
+
+/*
+ * Only process classes known to this
MetaDataRepository,
+ * since _registered contains all classes loaded by
+ * PCRegistry.
+ */
+if (pcNames.contains(reg[i].getName())) {
+processRegisteredClass(reg[i]);
+}
} catch (Throwable t) {
if (!_conf.getRetryClassRegistration())
throw new
MetaDataException(_loc.get(error-registered,
Index: ClassMetaData.java
===
--- ClassMetaData.java
(.../tags/0.9.6/openjpa-kernel/src/main/java/org/apache/openjpa/meta)
(revision 4)
+++ ClassMetaData.java
(.../branches/0.9.6-ninthavenue/openjpa-kernel/src/main/java/org/
apache/openjpa/meta)
(working copy)
@@ -309,7 +309,7 @@
if (_owner != null)
return _repos.EMPTY_CLASSES;
-_repos.processRegisteredClasses();
+_repos.processRegisteredClasses(getEnvClassLoader());
if (_subs == null) {
Collection subs = _repos.getPCSubclasses(_type);
_subs = (Class[]) subs.toArray(new Class[subs.size()]);
--
View this message in context: http://www.nabble.com/Shared-
classloader-and-subclasses-tf3431312.html#a9655900
Sent from the open-jpa-dev mailing list archive at Nabble.com.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
[jira] Commented: (OPENJPA-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-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-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-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.
Re: Shared classloader and subclasses
AFIACT, the problem is that the openjpa.enhance.PCRegistry class uses static fields to store Meta information. When the second instance is loaded, the PCRegistry has been initialized, but doesn't contain that instance's subclasses and an exception is thrown The PCRegistry has to use static members because each persistent class registers itself with the registry in its static initializer. There is no way for a persistent class to access a specific registry instance when it is loaded into the JVM. I don't think the proposed patch is viable, because there are cases where we lazily-load metadata, and we don't want to leave out subclasses just because we haven't parsed their metadata yet. What is the exception you're seeing? ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] 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-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.
Re: Performance declined dramatically during a series of delete operation
EM.flush() doesn't help. :-( On 3/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: Have you tried incrementally calling EM.flush() during the course of your transaction? Also, for deleting that many records, you may want to look at using JPQL's bulk delete APIs. Do you have the data cache enabled? Have you tried to enable large transaction mode along with the incremental flushing? http:// incubator.apache.org/openjpa/docs/latest/javadoc/index.html ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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] 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_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 : entity-mappings xmlns=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 mapped-superclass class=ch.admin.bit.fw2.bm.AbstractBusinessObjectImpl attributes id name=id column name=ID / generated-value strategy=SEQUENCE generator=TimeSeq/ sequence-generator name=TimeSeq sequence-name=time()/ /id version name=version / /attributes /mapped-superclass entity class=ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl table name=ADDRESS/table inheritance strategy=SINGLE_TABLE/ discriminator-column name=DISCRIMINANT length=1/ attributes basic name=addressName column name=ADDRESS_NAME/ /basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.address.EMailAddressImpl discriminator-valueE/discriminator-value attributes basic name=domain column name=EMAIL_DOMAIN/ /basic basic name=name column name=EMAIL_NAME/ /basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.address.PostalAddressImpl discriminator-valueP/discriminator-value attributes basic name=firstName column name=FIRST_NAME/ /basic basic name=lastName column name=LAST_NAME/ /basic basic name=street/basic basic name=country/basic basic name=zip/basic basic name=city/basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.person.PersonImpl table name=PERSON / attributes basic name=title / basic name=firstName column name=FIRST_NAME / /basic basic name=lastName column name=LAST_NAME / /basic one-to-many name=addresses target-entity=ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl join-table name=PERS_ADDR join-column name=ID_PERSON / inverse-join-column name=ID_ADDRESS / /join-table /one-to-many /attributes /entity /entity-mappings 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
[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(ClassT 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 : entity-mappings xmlns=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 mapped-superclass class=ch.admin.bit.fw2.bm.AbstractBusinessObjectImpl attributes id name=id column name=ID / generated-value strategy=SEQUENCE generator=TimeSeq/ sequence-generator name=TimeSeq sequence-name=time()/ /id version name=version / /attributes /mapped-superclass entity class=ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl table name=ADDRESS/table inheritance strategy=SINGLE_TABLE/ discriminator-column name=DISCRIMINANT length=1/ attributes basic name=addressName column name=ADDRESS_NAME/ /basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.address.EMailAddressImpl discriminator-valueE/discriminator-value attributes basic name=domain column name=EMAIL_DOMAIN/ /basic basic name=name column name=EMAIL_NAME/ /basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.address.PostalAddressImpl discriminator-valueP/discriminator-value attributes basic name=firstName column name=FIRST_NAME/ /basic basic name=lastName column name=LAST_NAME/ /basic basic name=street/basic basic name=country/basic basic name=zip/basic basic name=city/basic /attributes /entity entity class=ch.admin.bit.fw2.demo.bm.person.PersonImpl table name=PERSON / attributes basic name=title / basic name=firstName column name=FIRST_NAME / /basic basic name=lastName column name=LAST_NAME / /basic one-to-many name=addresses target-entity=ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl join-table name=PERS_ADDR join-column name=ID_PERSON / inverse-join-column name=ID_ADDRESS / /join-table /one-to-many /attributes /entity /entity-mappings 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
Re: Can @JoinTable be used in combination with @ManyToOne?
Can I map a many to one association through a join table (association table)? You can't use a join table, but you can put your many-one foreign key column(s) in a secondary table, which amounts to the same thing. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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.
Re: @Dependent annotation vs cascade=ALL
Thanks, Abe. This explanation helps a great deal. Should we update the documentation with some of this information? As far as I can tell the documentation on cascade=DELETE and the documentation on the Dependent metadata extension already contains everything I said. Feel free to change it, though. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] 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 ListMessage 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.
Re: OpenJPA Transaction configuration
If you set the version field of an instance to a non-default value, OpenJPA assumes the instance was detached, or that you're actively trying to make it behave as a detached instance. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: svn commit: r510281 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-persistence/src/main/java
What's the word on this issue? Last record I have is: Okay, I think we need to back out these last two changes and revert back to revision 509885. Dave needs to go back to the drawing board for this db2 optimization change, probably create a JIRA report for this proposed change, and use the design discussion associated with the JIRA process to get the proper fix in place. But that doesn't seem to have happened. And just so they don't get lost, here were my responses to Patrick's suggestions: 3. OpenJPA does support a means of passing Oracle hints along through to the DBDictionary. Should we be trying to reuse some of the capabilities here? +1 4. In the following snippets, I'd rather if we used 'Integer.valueOf (1)' or, better yet, a symbolic constant, instead of creating new integer all the time. +fetch.setHint(openjpa.hint.optimize, new Integer(1)); + _query.getFetchConfiguration(). + setHint(openjpa.hint.optimize, new Integer(1)); Use serp.util.Numbers.valueOf(x). But actually I think both of these calls have to be more thoroughly re-thought. The FetchConfiguration is around for the life of the Broker/Query, and you're setting a hint on it that only applies to the very next call. What about all the other uses of the Broker or possible other executions of the Query? 5. I don't like the name 'openjpa.hint.optimize', as it's a bit ambiguous as to what's being optimized. I don't really know what 'optimize for' does, so I'm just guessing here, but how about 'openjpa.ExpectedRecordCount'? +1 But should be openjpa.hint.XXX -- see OracleDictionary.SELECT_HINT. I think we should move all this to a SelectExecutor.ExpectedResultCount property. It could replace the current Union.isSingleResult property. The user can set an expected result count via the Query hint API, and it will get set into the Select. In cases where a query range is set the property will return the max - min of the range. And in cases where we know there's only one result like find() calls (actually JDBCStoreManager.load) we can use the property directly internally. The DBDictionary can then ask the Select for the expected count and do what it wants with it when creating the SQL. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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: property name=openjpa.jdbc.SynchronizeMappings value=buildSchema / 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-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 init. A profiler would have to jump through a lot of hoops to *exclude* field initializations from init 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-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 (init) before any constructor code you write. And code used to initialize static field values inline is dumped into your static initializer bytecode (clinit) 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_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-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 MapTransaction,ListBroker 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.
Re: svn commit: r510281 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-persistence/src/main/java
3. OpenJPA does support a means of passing Oracle hints along through to the DBDictionary. Should we be trying to reuse some of the capabilities here? +1 4. In the following snippets, I'd rather if we used 'Integer.valueOf (1)' or, better yet, a symbolic constant, instead of creating new integer all the time. +fetch.setHint(openjpa.hint.optimize, new Integer(1)); + _query.getFetchConfiguration(). + setHint(openjpa.hint.optimize, new Integer(1)); Use serp.util.Numbers.valueOf(x). But actually I think both of these calls have to be more thoroughly re-thought. The FetchConfiguration is around for the life of the Broker/Query, and you're setting a hint on it that only applies to the very next call. What about all the other uses of the Broker or possible other executions of the Query? 5. I don't like the name 'openjpa.hint.optimize', as it's a bit ambiguous as to what's being optimized. I don't really know what 'optimize for' does, so I'm just guessing here, but how about 'openjpa.ExpectedRecordCount'? +1 But should be openjpa.hint.XXX -- see OracleDictionary.SELECT_HINT. I think we should move all this to a SelectExecutor.ExpectedResultCount property. It could replace the current Union.isSingleResult property. The user can set an expected result count via the Query hint API, and it will get set into the Select. In cases where a query range is set the property will return the max - min of the range. And in cases where we know there's only one result like find() calls (actually JDBCStoreManager.load) we can use the property directly internally. The DBDictionary can then ask the Select for the expected count and do what it wants with it when creating the SQL. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: svn commit: r510336 - /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java
Okay, I think we need to back out these last two changes and revert back to revision 509885. Dave needs to go back to the drawing board for this db2 optimization change, probably create a JIRA report for this proposed change, and use the design discussion associated with the JIRA process to get the proper fix in place. +1 ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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:
--
persistence xmlns=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
persistence-unit name=TestService transaction-type=RESOURCE_LOCAL
classtest.A$A_PK/class
classtest.A/class
classtest.B/class
properties
property name=openjpa.Log value=DefaultLevel=TRACE/
property name=openjpa.ConnectionUserName value=test/
property name=openjpa.ConnectionPassword value=test/
property name=openjpa.ConnectionURL
value=jdbc:mysql://localhost:3306/oam?useServerPrepStmts=false/
property name=openjpa.ConnectionDriverName
value=com.mysql.jdbc.Driver/
/properties
/persistence-unit
/persistence
--
--
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:
--
persistence xmlns=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
persistence-unit name=TestService transaction-type=RESOURCE_LOCAL
classtest.A$A_PK/class
classtest.A/class
classtest.B/class
properties
property name=openjpa.Log value=DefaultLevel=TRACE/
property name=openjpa.ConnectionUserName value=test/
property name=openjpa.ConnectionPassword value=test/
property name=openjpa.ConnectionURL
value=jdbc:mysql://localhost:3306/oam?useServerPrepStmts=false/
property name=openjpa.ConnectionDriverName
value=com.mysql.jdbc.Driver/
/properties
/persistence-unit
/persistence
--
--
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:
--
persistence xmlns=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
persistence-unit name=TestService transaction-type=RESOURCE_LOCAL
classtest.A$A_PK/class
classtest.A/class
classtest.B/class
properties
property name=openjpa.Log value=DefaultLevel=TRACE/
property name=openjpa.ConnectionUserName value=test/
property name=openjpa.ConnectionPassword value=test/
property name=openjpa.ConnectionURL
value=jdbc:mysql://localhost:3306/oam?useServerPrepStmts=false/
property name=openjpa.ConnectionDriverName
value=com.mysql.jdbc.Driver/
/properties
/persistence-unit
/persistence
--
--
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.
Re: svn commit: r507643 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/kernel/AbstractBrokerFactory.java openjpa-lib/src/main/java/org/apache/openjpa/lib/conf/Configura
This change is causing problems in an application server environment. I pulled in this change this morning, re-built, and tried our perf benchmark (SunOne with OpenJPA) and I get the following exception: Sorry about that. I'll revert it ASAP. I have a vague notion of what might be causing it -- I'll try to reproduce it with a standalone test case and fix it before checking in that code again. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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 variable, but not
statically. Nothing should prevent someone having
[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:
--
persistence xmlns=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
persistence-unit name=TestService transaction-type=RESOURCE_LOCAL
classtest.A$A_PK/class
classtest.A/class
classtest.B/class
properties
property name=openjpa.Log value=DefaultLevel=TRACE/
property name=openjpa.ConnectionUserName value=test/
property name=openjpa.ConnectionPassword value=test/
property name=openjpa.ConnectionURL
value=jdbc:mysql://localhost:3306/oam?useServerPrepStmts=false/
property name=openjpa.ConnectionDriverName
value=com.mysql.jdbc.Driver/
/properties
/persistence-unit
/persistence
--
--
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_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
new entry is added, all the old entries should be getting GC'd and
removed. Same for the individual Map values, which
[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;
+}
This code could be simplified a lot. Also, I don't understand what
you're trying to do from a memory management perspective
Re: AW: Using @GeneratedValue for IDs on already existing tables
does openJPA provide the strategy to re-generate another value for the PK or do we have to manually deal with this case? http://incubator.apache.org/openjpa/docs/latest/manual/ manual.html#ref_guide_sequence ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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 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
Re: Open letter from an OpenJPA performance perspective
I doubt anyone has done much performance analysis of stock OpenJPA, especially without caching. BEA's performance efforts obviously focus on Kodo instead. Which is why we all appreciate the performance work you're doing now, even if we (well, mostly just me) might harp on the details. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: pessimistic locking
We'd also have to set the LockManager property to pessimistic to get database locks. And just to build on what Patrick is saying: OpenJPA can do locking within optimistic transactions on individual instances, but you have to set a lock level on the FetchPlan in code, which I don't think we can do in this benchmark. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Do mapped superclasses work at all in OpenJPA?
Secondly, are we parsing the XML file multiple times? The only way for the first warning to be fired is if OpenJPA has read my entity mappings, but the exception that is thrown later is a SAX exception which implies that OpenJPA is reading the file again. Sounds like an inefficient startup algorithm that we should fix. Issue #3? We might be parsing it multiple times, but for different reasons and with different parsers. Are you listing entities in an orm.xml and then pointing at that orm.xml / relying on the default location? IIRC (and that's a fairly big if), the first parse is more of a string scan looking for class names than a real XML parse, and is done with a subclass of ClassArgParser. This is one of those things that made sense for the way the metadata system warmed up, then we changed some stuff or the spec changed or both, and it no longer makes much sense. I had it on my list of things to redo, but it got pushed off because it hadn't caused enough problems to justify the effort. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: svn commit: r506230 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/ee/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-kernel/src/main/java/org/apac
==
--- 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 common place like ImplHelper.
+/**
+ * Generate the hashcode for this Id. Cache the type's
generated hashcode
+ * so that it doesn't have to be generated each time.
+ */
public int hashCode() {
if (_typeHash == 0) {
-Class base = type;
-while (base.getSuperclass() != null
- base.getSuperclass() != Object.class)
-base = base.getSuperclass();
-_typeHash = base.hashCode();
+Integer typeHashInt = (Integer) _typeCache.get(type);
+if (typeHashInt == null) {
+Class base = type;
+Class superclass = base.getSuperclass();
+while (superclass != null superclass !=
Object.class) {
+base = base.getSuperclass();
+superclass = base.getSuperclass();
+}
+_typeHash = base.hashCode();
+_typeCache.put(type, new Integer(_typeHash));
+} else {
+_typeHash = typeHashInt.intValue();
+}
}
return _typeHash ^ idHash();
}
Once again, you're mapping a hard Class ref to a value with no
outside references held in a weak ref. Once again that means the
entry should be immediately eligible for GC, and therefore should be
removed on the next mutation of the cache, subject to GC timing. And
again I'd like to know what your JVM is doing to make Class.hashCode
take an appreciable amount of time. Aren't Class instances supposed
to be singletons? What if we just used System.identityHashCode(cls)?
Modified:
Re: svn commit: r506230 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/ee/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-kernel/src/main/java/org/apac
Thanks for the feedback. I know that we have been running with both the IBM and Sun JDK's, but let me get together with my performance team and discuss your concerns. We will try to provide more concrete data on these updates. Cool. Maybe I'll learn something about weak refs and the implementation of java.lang.Class from them, because right now I'm thoroughly confused about how those caches are helping. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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 repeat logic in FetchConfigurationImpl.
And if we keep this code or some variant of it, I strongly suggest
moving it to a common
[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 common place like ImplHelper.
+/**
+ * Generate the hashcode for this Id. Cache the type's
generated hashcode
+ * so
Re: Exceptions thrown from callbacks
I think if a user throws an exception in a callback outside of a commit operation, we should simply rethrow it to the user after we clean up our internal state. Presumably, the specific runtime exception has meaning to the user's code, and we don't add much value in wrapping the exception. I might think differently if the spec allowed/required us to continue after catching the first exception thrown from a callback, but it explicitly says that the first exception aborts the operation. From 3.5.6, No further lifecycle callback methods will be invoked after a runtime exception is thrown. I can go either way on it, but I think Craig's reasoning is sound. +1 ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: ReverseMappingTool doesn't include table/column names in entities
This sounds like something that was fixed a while ago. What version of OpenJPA are you using? ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-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.
Re: Unknown primary key
Sadly, not currently. OpenJPA domain model extensions are not currently available in XML form. See OPENJPA-87 for a related issue. While this is true, I believe if you just don't declare any @Id fields we'll probably default to datastore identity automatically. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: ReverseMappingTool doesn't include table/column names in entities
I upgraded to openjpa-0.9.7-incubating-SNAPSHOT and still get the same results. By the way, thanks for your help so far. I get table and column names when I run the tool. Are you sure you aren't looking at old output? Can someone else attempt to reproduce this problem? ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: EntityManager.clear() semantics
Basically, if we have dirtied the Persistence Context, then do a flush() followed by the detachAllInternal(). I don't think the clear() should be doing this flush() operation. Any disagreement? I agree. But note that just removing the flush call won't work for a couple of reasons: it's needed by JDO, and we'll just flush later in the DetachManager when we detect a dirty instance. So just a warning that it isn't quite as trivial a fix as it might appear to be. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_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-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468770 ] Abe White commented on OPENJPA-117: --- I don't see why listeners are some special case that require more isolation than all of the other state we expose. There are tons of things you can do with a broker,etc to screw other users of that broker,etc. I don't see how this is unique. That said, I also think the proposed use case is weak. I'd question the quality of an application that had code paths that could result in the same listener being added twice. Adding listeners should generally either be done as an initialization step or as a temporary step where the listener is removed immediately following a specific action. It's hard to imagine a scenario where listeners are added so haphazardly that duplicates could occur. I'd be interested to hear a more concrete use case. Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection Key: OPENJPA-117 URL: https://issues.apache.org/jira/browse/OPENJPA-117 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Priority: Minor Currently TransactionListeners can be added/removed to a broker but the list of transaction listeners registered to a particular broker is not available. Such a collection can be made available in read-only mode so a caller can determine whether to add a new listener or not, or whether a particular listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Mappings for non-existant classes
Is this the way it is supposed to work? Yes. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: openjpa logging
Since the time that we implemented that, we added logic (the RuntimeExceptionTranslator interface and its implementors) that takes care of translating from internal exception types to spec-defined exception types across the board. We certainly could move the logic for logging at the trace level from BrokerImpl.afterCompletion() to that boundary code. Since we (try to) guarantee that all exceptions that make it to the user pass through the PersistenceExceptions class for translation, that would be a nice uniform place to do the work. Exception translation isn't 100%, though. For example, when someone grabs the Connection from us and uses it, we don't do any exception translation. I don't mind logging exceptions in trace mode, but I do think it's very difficult to maintain complete coverage without any duplicate exceptions being logged. And I still feel that given our strategy of always nesting the original exception as the cause of the exception we throw to the user, it's mostly unnecessary. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
