[jira] Commented: (OPENJPA-238) Error in XMLFileHandler, failed to load field element with type org.apace.openjpa.util.StringId.
[ https://issues.apache.org/jira/browse/OPENJPA-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496016 ] Abe White commented on OPENJPA-238: --- Custom id classes can have either a (Class,String) or just a String constructor. So the patch can't just assume a (Class,String) constructor -- it has to check to see what the class has. That's pretty ugly and still won't cover certain cases, but it'll work for this user and previous users. If we really want to make a proper solution, we'd write out the class of the entity and the stringified oid instead of the class of the oid and the stringified oid. Then in fromXMLString we'd check to see if relMeta uses datastore identity and if so construct a LongId from the stored entity class and string. If not we'd use PCRegistry.newObjectId(Class,String). We'd also need the old processing for old XML files... we could detect an old file by maybe adding a new version attribute to the top-level element -- old files will be missing the version attribute. > Error in XMLFileHandler, failed to load field element with type > org.apace.openjpa.util.StringId. > > > Key: OPENJPA-238 > URL: https://issues.apache.org/jira/browse/OPENJPA-238 > Project: OpenJPA > Issue Type: Bug > Components: xml store >Reporter: Catalina Wei > Attachments: XMLFileHandler.java.patch > > > Problem reported by Ngo, Anh (full description with attachments can be found > in openjpa-dev mails, subject title: xml store help? > In evaluating openJPA to use for our current project. It works fine for our > need with database. But I am having problem with the XMLStoreManager. I > have two simple objects - Customer and User. Customer can have multiple > users. I look at the object store in xml file. It stored like this: > > > > version="0"> > > "1" > > > "customer1" > > > > org.apache.openjpa.util.StringId:1 > > > org.apache.openjpa.util.StringId:2 > > > > > > Shoud the Users element store User object? The XMLStoreManager failed to > load data in because it doest not know how to create this object: >org.apache.openjpa.util.StringId:1 > > Please help... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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-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.
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.
[jira] Commented: (OPENJPA-236) No apparent way to generate all required SQL within a class derived from FullClassStrategy
[ https://issues.apache.org/jira/browse/OPENJPA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494086 ] Abe White commented on OPENJPA-236: --- One-way inverse-key-based relations are not a typical case, given that they aren't even supported in standard JPA. You might need to use a custom field mapping in conjunction with the custom class mapping. > No apparent way to generate all required SQL within a class derived from > FullClassStrategy > -- > > Key: OPENJPA-236 > URL: https://issues.apache.org/jira/browse/OPENJPA-236 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.7 >Reporter: David Ezzio > Attachments: OpenJPABugCustomSQL.zip > > > FullClassStrategy has several optional methods for overriding OpenJPA's > generation of SQL. However, in a simple case, there is no apparent way to > generate the required SQL within a class derived from FullClassStrategy. > The model consists of two classes, BizA which has a one-way, one-to-many > relationship to BizB. The relationship is mapped with an inverse key within > the BizB table. > The custom class strategy BizBMapping attempts to insert a BizB record and is > able to do so, provided that it is not contained within a BizA collection. > Otherwise, the attempt to persist a BizA with a contained BizB yields a SQL > exception because OpenJPA generates additional SQL that conflicts with the > SQL generated within BizBMapping.customInsert. Even if OpenJPA did not > generate conflicting insert statement, there is no apparent way to get the > value for the A_ID column within the BizBMapping.customInsert method. > This issue is critical for users who want to substitute their own SQL (such > as calls to stored procedures) for all of the OpenJPA generated SQL. > Synopsis of the output log: > INSERT INTO BIZB (ID, INFO) VALUES (?, ?) [params=(String) B22047141, > (String) random] > INSERT INTO BizA (id, info) VALUES (?, ?) [params=(String) A32968849, > (String) random] > INSERT INTO BizB (A_ID) VALUES (?) [params=(String) A32968849] > SQLException: Column 'ID' cannot accept a NULL value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-51) bad sql pushdown, sub select is missing from clause
[
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494070
]
Abe White commented on OPENJPA-51:
--
Yes, the test was passing before. Have you tried against a to-one relation
rather than a to-many?
Perhaps it was never working against a to-many.
> bad sql pushdown, sub select is missing from clause
> ---
>
> Key: OPENJPA-51
> URL: https://issues.apache.org/jira/browse/OPENJPA-51
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, db2, derby
>Reporter: George Hongell
> Assigned To: David Wisneski
> Fix For: 0.9.8
>
> Attachments: failureEntities.jar, SelectImpl.java.patch
>
>
> 451 - bad sql pushdown sub select is missing from clause
> TEST451; select e from EmpBean e where e.empid > any (select e1.empid from
> DeptBean d, in(d.emps) e1 where d.no = 200)
> 28344 TRACE [main] openjpa.jdbc.SQL - [0 ms]
> executing prepstmnt 81790176 SELECT t0.empid, t0.bonus, t2.deptno, t2.budget,
> t2.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street,
> t3.city, t3.state, t3.zip, t0.isManager, t0.name, t0.salary, t4.street,
> t4.city, t4.state, t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON
> t0.dept_deptno = t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street =
> t3.street LEFT OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE
> (t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
> s/b
> select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
> t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
> WHERE t1.empid > ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
> ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
> 200}
> <0|false|0.0.0> org.apache.openjpa.persistence.PersistenceException: Syntax
> error: Encountered "WHERE" at line 1, column 520. {SELECT t2.empid, t2.bonus,
> t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
> t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
> t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
> INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
> t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
> t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
> t5.street WHERE (t2.empid > ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
> AS BIGINT) = CAST(? AS BIGINT)} [code=3, state=42X01]
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
> at
> org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:37)
> at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
> at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
> at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
> at
> com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at
> junit.extensions.jfunc.Testle
[jira] Reopened: (OPENJPA-51) bad sql pushdown, sub select is missing from clause
[
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White reopened OPENJPA-51:
--
I have to reopen this, as the fix is causing a regression in our test suite.
Given an entity EntityA with a field "b" of type EntityB, the following JPQL:
select a from EntityA a where
exists (select b from a.b b where b.intfield = 1)
or
exists (select b from a.b b where b.intfield = 0)
is getting translated to:
SELECT t1.ID, t1.TYP, t1.A FROM ENTITYA t1 WHERE (
EXISTS (SELECT t0.ID FROM ENTITYB t0 WHERE t0.INTFIELD = 1 AND t1.B = t0.ID))
OR
EXISTS (SELECT t2.ID FROM ENTITYB t2, ENTITYA t3 WHERE t2.INTFIELD = 0 AND
t3.B = t2.ID))
)
Notice that the first correlated subselect is fine, but the second has lost its
correlation -- it creates a new alias for EntityA's table.
> bad sql pushdown, sub select is missing from clause
> ---
>
> Key: OPENJPA-51
> URL: https://issues.apache.org/jira/browse/OPENJPA-51
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, db2, derby
>Reporter: George Hongell
> Assigned To: David Wisneski
> Fix For: 0.9.8
>
> Attachments: failureEntities.jar, SelectImpl.java.patch
>
>
> 451 - bad sql pushdown sub select is missing from clause
> TEST451; select e from EmpBean e where e.empid > any (select e1.empid from
> DeptBean d, in(d.emps) e1 where d.no = 200)
> 28344 TRACE [main] openjpa.jdbc.SQL - [0 ms]
> executing prepstmnt 81790176 SELECT t0.empid, t0.bonus, t2.deptno, t2.budget,
> t2.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street,
> t3.city, t3.state, t3.zip, t0.isManager, t0.name, t0.salary, t4.street,
> t4.city, t4.state, t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON
> t0.dept_deptno = t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street =
> t3.street LEFT OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE
> (t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
> s/b
> select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
> t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
> WHERE t1.empid > ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
> ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
> 200}
> <0|false|0.0.0> org.apache.openjpa.persistence.PersistenceException: Syntax
> error: Encountered "WHERE" at line 1, column 520. {SELECT t2.empid, t2.bonus,
> t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
> t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
> t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
> INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
> t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
> t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
> t5.street WHERE (t2.empid > ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
> AS BIGINT) = CAST(? AS BIGINT)} [code=3, state=42X01]
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
> at
> org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:37)
> at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
> at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
> at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
> at
> com.ibm.ws.query.u
[jira] Commented: (OPENJPA-51) bad sql pushdown, sub select is missing from clause
[
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493200
]
Abe White commented on OPENJPA-51:
--
OK, I see. You still shouldn't be using a fixed array. Use a BitSet.
As to the rest... as I said before, I don't remember how this stuff works. So
it could be wrong
and I wouldn't know it without doing more code-diving than I have time for.
It's our fault for
not having enough tests checked into OpenJPA. So after changing it to use a
BitSet,
assuming it passes all your tests, I'd vote to commit it. Once that happens
we'll see how it
fairs against our more extensive Kodo test suite.
> bad sql pushdown, sub select is missing from clause
> ---
>
> Key: OPENJPA-51
> URL: https://issues.apache.org/jira/browse/OPENJPA-51
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, db2, derby
>Reporter: George Hongell
> Assigned To: David Wisneski
> Fix For: 0.9.8
>
> Attachments: failureEntities.jar, openjpa-51.patch,
> SelectImpl.java.patch, SelectImpl.java.patch
>
>
> 451 - bad sql pushdown sub select is missing from clause
> TEST451; select e from EmpBean e where e.empid > any (select e1.empid from
> DeptBean d, in(d.emps) e1 where d.no = 200)
> 28344 TRACE [main] openjpa.jdbc.SQL - [0 ms]
> executing prepstmnt 81790176 SELECT t0.empid, t0.bonus, t2.deptno, t2.budget,
> t2.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street,
> t3.city, t3.state, t3.zip, t0.isManager, t0.name, t0.salary, t4.street,
> t4.city, t4.state, t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON
> t0.dept_deptno = t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street =
> t3.street LEFT OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE
> (t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
> s/b
> select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
> t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
> WHERE t1.empid > ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
> ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
> 200}
> <0|false|0.0.0> org.apache.openjpa.persistence.PersistenceException: Syntax
> error: Encountered "WHERE" at line 1, column 520. {SELECT t2.empid, t2.bonus,
> t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
> t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
> t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
> INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
> t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
> t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
> t5.street WHERE (t2.empid > ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
> AS BIGINT) = CAST(? AS BIGINT)} [code=3, state=42X01]
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
> at
> org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:37)
> at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
> at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
> at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
> at
> com.ibm.ws.query.tests.JFLoop
[jira] Commented: (OPENJPA-51) bad sql pushdown, sub select is missing from clause
[
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493172
]
Abe White commented on OPENJPA-51:
--
No, this is no better. And now you've changed the meaning of the code.
Before, the remove-from-parent
logic was based on the key to the last call to findAlias. Now it's based on
the key to any previous call to findAlias
(so long as 0 <= alias <= 16 ??!!). The fact that you changed the meaning of
the patch seemingly without intent
and still feel it is correct doesn't give me any confidence in it.
p.s. The boolean array is pointless since you never flip the
boolean values -- you only ever set to true that I see, and then test if any
index is true later. So you could just as
easily get by with a single boolean where you "|=" its value each time.
p.p.s. I notice that you also have a "boolean removed = false"
local declared in one method and you never change its value, making the local
pointless too, unless
you meant to assign it a new value based on something somewhere.
> bad sql pushdown, sub select is missing from clause
> ---
>
> Key: OPENJPA-51
> URL: https://issues.apache.org/jira/browse/OPENJPA-51
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, db2, derby
>Reporter: George Hongell
> Assigned To: David Wisneski
> Fix For: 0.9.8
>
> Attachments: failureEntities.jar, openjpa-51.patch,
> SelectImpl.java.patch
>
>
> 451 - bad sql pushdown sub select is missing from clause
> TEST451; select e from EmpBean e where e.empid > any (select e1.empid from
> DeptBean d, in(d.emps) e1 where d.no = 200)
> 28344 TRACE [main] openjpa.jdbc.SQL - [0 ms]
> executing prepstmnt 81790176 SELECT t0.empid, t0.bonus, t2.deptno, t2.budget,
> t2.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street,
> t3.city, t3.state, t3.zip, t0.isManager, t0.name, t0.salary, t4.street,
> t4.city, t4.state, t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON
> t0.dept_deptno = t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street =
> t3.street LEFT OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE
> (t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
> s/b
> select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
> t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
> WHERE t1.empid > ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
> ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
> 200}
> <0|false|0.0.0> org.apache.openjpa.persistence.PersistenceException: Syntax
> error: Encountered "WHERE" at line 1, column 520. {SELECT t2.empid, t2.bonus,
> t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
> t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
> t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
> INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
> t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
> t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
> t5.street WHERE (t2.empid > ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
> AS BIGINT) = CAST(? AS BIGINT)} [code=3, state=42X01]
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
> at
> org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:37)
> at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
> at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
> at
> org.apache.openjpa.persiste
[jira] Commented: (OPENJPA-51) bad sql pushdown, sub select is missing from clause
[
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493126
]
Abe White commented on OPENJPA-51:
--
I don't remember how any of that stuff works at all. However, the following
line in findAlias is suspect:
_removeAliasFromParent = key.toString().contains(":");
findAlias is called a lot with different keys. Setting a member field that is
used in other methods based
on whether the latest key happens to match a certain criteria seems like it
could lead to arbitrary
results in different circumstances. If there is a continuous thread of logic
that links the last call to
findAlias with the other methods where _removeAliasFromParent is used, it needs
to be make more
explicit.
> bad sql pushdown, sub select is missing from clause
> ---
>
> Key: OPENJPA-51
> URL: https://issues.apache.org/jira/browse/OPENJPA-51
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, db2, derby
>Reporter: George Hongell
> Assigned To: David Wisneski
> Fix For: 0.9.8
>
> Attachments: failureEntities.jar, openjpa-51.patch
>
>
> 451 - bad sql pushdown sub select is missing from clause
> TEST451; select e from EmpBean e where e.empid > any (select e1.empid from
> DeptBean d, in(d.emps) e1 where d.no = 200)
> 28344 TRACE [main] openjpa.jdbc.SQL - [0 ms]
> executing prepstmnt 81790176 SELECT t0.empid, t0.bonus, t2.deptno, t2.budget,
> t2.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street,
> t3.city, t3.state, t3.zip, t0.isManager, t0.name, t0.salary, t4.street,
> t4.city, t4.state, t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON
> t0.dept_deptno = t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street =
> t3.street LEFT OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE
> (t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
> s/b
> select t1.empid FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno =
> t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno
> WHERE t1.empid > ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5
> ON t4.deptno = t5.dept_deptno WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int
> 200}
> <0|false|0.0.0> org.apache.openjpa.persistence.PersistenceException: Syntax
> error: Encountered "WHERE" at line 1, column 520. {SELECT t2.empid, t2.bonus,
> t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime,
> t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager,
> t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0
> INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean
> t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON
> t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street =
> t5.street WHERE (t2.empid > ANY((SELECT t1.empid FROM WHERE (CAST(t0.deptno
> AS BIGINT) = CAST(? AS BIGINT)} [code=3, state=42X01]
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
> at
> org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
> at
> org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:37)
> at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
> at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
> at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
> at
> com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
> at
&
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?
>> 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: 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: [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) > Map,Collection> of fields known not to be > available in a given class. > It may also be beneficial to maintain a cache of which fields *are* present > in a given class, but this issue is being filed as a result of a demonstrated > performance hit during deployment due to the lack of a negative cache. If we > obtain quantitative data indicating that a positive cache would be useful, we > might want to implement such a thing at that time. > Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: > domainName > at > java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown > Source) > at > org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101) > at > org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object; > (ApplicationIds.java:89) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios
[ https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491038 ] Abe White commented on OPENJPA-219: --- If we're going to cache, I don't see why we wouldn't cache the declared fields/methods rather than the nonexistent ones. It would be a simple matter of keeping a Class->Set cache, where the Set is the names of the fields/methods returned by Class.getDeclaredFields/Methods(). Then we'd have both a positive (set.contains(x)) and negative (!set.contains(x)) cache. I'd also like to see some explicit control over whether requests to find a field/method cause cache additions. It might be that we always want caching now, but it's such a general class that I can imagine naïvely using the Reflection class's helper methods on one-off random field/method requests in the future without remembering the memory consequences. If all use results in caching, that could be bad. So I'd like us to either add separate caching methods or a boolean parameter to the existing methods. And either way, we need to revisit our current use of Reflection to decide which version to use in the current code. > Reflection: negative caching would be beneficial in redeployment scenarios > -- > > Key: OPENJPA-219 > URL: https://issues.apache.org/jira/browse/OPENJPA-219 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6, 0.9.7 >Reporter: Patrick Linskey > Fix For: 0.9.8 > > Attachments: OPENJPA-219.patch > > > In a variety of situations, OpenJPA searches class hierarchies for fields. > These searches invoke Class.getDeclaredField() in order to find non-public > fields. This method throws an exception when it fails to find the specified > field, and the exception creation is, as ever, slow. > It would be useful to create a static (and thus per-classloader) > Map,Collection> of fields known not to be > available in a given class. > It may also be beneficial to maintain a cache of which fields *are* present > in a given class, but this issue is being filed as a result of a demonstrated > performance hit during deployment due to the lack of a negative cache. If we > obtain quantitative data indicating that a positive cache would be useful, we > might want to implement such a thing at that time. > Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: > domainName > at > java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown > Source) > at > org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101) > at > org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object; > (ApplicationIds.java:89) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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: [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: [jira] Resolved: (OPENJPA-134) Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER
> I have verified this fix with EagerFetchMode parallel and join. > However, > there is an outstanding problem for the following query with inner > join > fetch while left join fetch generates correct SQL; the inner join > fetch > generates extra unneeded left join: I think this is a separate issue. Thanks for filing a separate JIRA on it. 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.
[jira] Resolved: (OPENJPA-214) Need to support floating point primary keys
[ https://issues.apache.org/jira/browse/OPENJPA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-214. --- Resolution: Fixed Assignee: (was: Abe White) Support float/Float and double/Double primary key fields in single-field identity handling. Fixed in revision 527648. > Need to support floating point primary keys > --- > > Key: OPENJPA-214 > URL: https://issues.apache.org/jira/browse/OPENJPA-214 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 0.9.7 >Reporter: Kevin Sutter > Fix For: 0.9.8 > > > Dain first reported this problem on the dev mailing list: > http://www.nabble.com/Float-primary-key--tf3557137.html > >My response: > >Okay, I looked at the spec a bit closer and it looks like we need to allow > >for floats as primary keys: > >"The primary key (or field or property of a composite primary key) should be > >one of the following types: > >any Java primitive type; any primitive wrapper type; java.lang.String; > >java.util.Date; > >java.sql.Date. In general, however, approximate numeric types (e.g., > >floating point types) should > >never be used in primary keys." > >Although the spec clearly recommends against the use of floating points, > >floats are a primitive type (or the Float wrapper) and need to be allowed. > >With no >special "AllowStupidApproximatePrimaryKeys" flag. :-) > >Am I trying to read too much into the spec or Dain's request? This seems to > >be something that we need to support. > >>Abe's response: > >>Given the spec section you quoted, you're definitely right. It's something > >>we need to support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-214) Need to support floating point primary keys
[ https://issues.apache.org/jira/browse/OPENJPA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White reassigned OPENJPA-214: - Assignee: Abe White > Need to support floating point primary keys > --- > > Key: OPENJPA-214 > URL: https://issues.apache.org/jira/browse/OPENJPA-214 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 0.9.7 >Reporter: Kevin Sutter > Assigned To: Abe White > Fix For: 0.9.8 > > > Dain first reported this problem on the dev mailing list: > http://www.nabble.com/Float-primary-key--tf3557137.html > >My response: > >Okay, I looked at the spec a bit closer and it looks like we need to allow > >for floats as primary keys: > >"The primary key (or field or property of a composite primary key) should be > >one of the following types: > >any Java primitive type; any primitive wrapper type; java.lang.String; > >java.util.Date; > >java.sql.Date. In general, however, approximate numeric types (e.g., > >floating point types) should > >never be used in primary keys." > >Although the spec clearly recommends against the use of floating points, > >floats are a primitive type (or the Float wrapper) and need to be allowed. > >With no >special "AllowStupidApproximatePrimaryKeys" flag. :-) > >Am I trying to read too much into the spec or Dain's request? This seems to > >be something that we need to support. > >>Abe's response: > >>Given the spec section you quoted, you're definitely right. It's something > >>we need to support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-134) Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER
[ https://issues.apache.org/jira/browse/OPENJPA-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-134. --- Resolution: Fixed Assignee: (was: Abe White) Fixed the most egregious issue, which was the cyclic fetching of eager bidirectional relations. Changed to cut off SELECTs when we're traversing the back-ptr to the owning side of a relation we've already fetched. I'm not convinced all the other issues mentioned are bugs given the eager fetch settings used. Please open new JIRAs for any individual issues that you believe remain. Fixed in revision 527565. > Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER > - > > Key: OPENJPA-134 > URL: https://issues.apache.org/jira/browse/OPENJPA-134 > Project: OpenJPA > Issue Type: Bug > Components: sql >Reporter: Catalina Wei > Fix For: 0.9.8 > > > Running JPAConfiguration default setting for EagerFetchMode > (FetchModeValue.EAGER_PARALLEL), > the SQL generated is sub-optimal. > Consider the following entities: > lineitems( OneToMany ) > Order <===> OrderItem > order ( ManyToOne ) > Case 1: why not combining 2 SQL to 1 SQL ? > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o > 2173 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1299336562 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr FROM Order t0 > 2213 demo TRACE [main] openjpa.jdbc.SQL - > [40 ms] spent > 2223 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1406424020 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t1.order_oid, t1.part_partno, > t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = t1.order_oid > ORDER BY t0.oid ASC > Case 2: extra unneeded LEFT OUTER JOIN, if eliminated, the selection aliase > t2 should change to t1: > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o left join fetch o.lineitems > 2403 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1500797300 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, > t2.cost, t2.part_partno, t2.quantity FROM Order t0 LEFT OUTER JOIN OrderItem > t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN OrderItem t2 ON t0.oid = > t2.order_oid ORDER BY t2.order_oid ASC > Case 3: why not generating 1 SQL ? > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o > 2343 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 384833264 SELECT t0.oid, t0.version, t0.amount, > t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr FROM Order > t0 > 2383 demo TRACE [main] openjpa.jdbc.SQL - > [40 ms] spent > 2393 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1722705582 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t2.oid, t2.version, t2.amount, > t2.customer_countryCode, t2.customer_id, t2.delivered, t2.shipaddr, > t1.part_partno, t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = > t1.order_oid LEFT OUTER JOIN Order t2 ON t1.order_oid = t2.oid ORDER BY > t0.oid ASC > 2393 demo TRACE [main] openjpa.jdbc.SQL - > [0 ms] spent > 3134 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 950548648 > SELECT t0.lid, t0.version, t0.cost, t1.oid, t1.version, t1.amount, > t1.customer_countryCode, t1.customer_id, t1.delivered, t1.shipaddr, > t0.part_partno, t0.quantity FROM OrderItem t0 LEFT OUTER JOIN Order t1 ON > t0.order_oid = t1.oid WHERE t0.order_oid = ? [params=(int) 88] > 3134 demo TRACE [main] openjpa.jdbc.SQL - > [0 ms] spent > Case 4: duplicate selections and redundant joins > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o left join fetch o.lineitems > 2273 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1565154634 > SELECT t0.o
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: 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: 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: 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.
[jira] Commented: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used
[
https://issues.apache.org/jira/browse/OPENJPA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487816
]
Abe White commented on OPENJPA-201:
---
I'm sorry, but I don't understand what you're trying to accomplish. You say
that Winery maps to two tables, but I don't see any SecondaryTable defined for
it. You give the results of various annotations, but I don't know what the
actual schema looks like or what relations you want mapped to what columns.
> Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if
> the table argument is used
> -
>
> Key: OPENJPA-201
> URL: https://issues.apache.org/jira/browse/OPENJPA-201
> Project: OpenJPA
> Issue Type: Bug
> Environment: 0.9.7-incubating-SNAPSHOT
>Reporter: George Hongell
>Priority: Minor
> Attachments: Wine.java, Winery.java
>
>
> @Entity
> @Table(name="CxWine")
> public class Wine {
> @Id
> private Integer wineid;
> ...
> @ManyToOne()
> @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="WINERYID",
> table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID", table="cxWINERY")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="wineryid")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID")
> private Winery winery;
> ...
> }
> generates
> 2744 cxwineTour TRACE [main] openjpa.jdbc.SQL - 98698722> executing stmnt 1325027066 CREATE TABLE CxWine (wineid INTEGER NOT
> NULL, cost SMALLINT, description VARCHAR(254), minimumHoldYears INTEGER,
> rating SMALLINT, stockCount INTEGER, type VARCHAR(20), version INTEGER,
> alcoholPercent DOUBLE, ava VARCHAR(40), bottler VARCHAR(40), brandName
> VARCHAR(40), labelWineClass VARCHAR(20), labelWineColor VARCHAR(20),
> estateBottled SMALLINT, hasSulfites SMALLINT, labelid INTEGER, mlContents
> INTEGER, qualityDesignation VARCHAR(40), vineyardName VARCHAR(40), vintage
> TIMESTAMP, wineName VARCHAR(40), winery_wineryid INTEGER, PRIMARY KEY
> (wineid))
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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_12487565
]
Abe White commented on OPENJPA-201:
---
The primary table for what entity? The primary table for the entity shown in
your example is clearly "CxWine", but the JoinColumn references a table
"cxWINERY". That table doesn't appear anywhere else in the example code. So
if it's not the entity's table and it's not a secondary table, then it's not a
valid mapping.
If you mean it's the primary table of the related entity, then that is not
supported by vanilla JPA. The JPA spec does not support one-sided relations
based on an inverse foreign key. You'd have to make the relation a two-sided
relation and use "mappedBy" on the side that doesn't own the foreign key.
OpenJPA does actually support one-sided inverse-key relations, however. We can
go over its support in OpenJPA, but first I'd like confirmation that that's the
intent. It doesn't seem likely that each Winery record contains a foreign key
to a single Wine record, so maybe I'm on the wrong track.
> Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if
> the table argument is used
> -
>
> Key: OPENJPA-201
> URL: https://issues.apache.org/jira/browse/OPENJPA-201
> Project: OpenJPA
> Issue Type: Bug
> Environment: 0.9.7-incubating-SNAPSHOT
>Reporter: George Hongell
>Priority: Minor
>
> @Entity
> @Table(name="CxWine")
> public class Wine {
> @Id
> private Integer wineid;
> ...
> @ManyToOne()
> @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="WINERYID",
> table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID", table="cxWINERY")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="wineryid")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID")
> private Winery winery;
> ...
> }
> generates
> 2744 cxwineTour TRACE [main] openjpa.jdbc.SQL - 98698722> executing stmnt 1325027066 CREATE TABLE CxWine (wineid INTEGER NOT
> NULL, cost SMALLINT, description VARCHAR(254), minimumHoldYears INTEGER,
> rating SMALLINT, stockCount INTEGER, type VARCHAR(20), version INTEGER,
> alcoholPercent DOUBLE, ava VARCHAR(40), bottler VARCHAR(40), brandName
> VARCHAR(40), labelWineClass VARCHAR(20), labelWineColor VARCHAR(20),
> estateBottled SMALLINT, hasSulfites SMALLINT, labelid INTEGER, mlContents
> INTEGER, qualityDesignation VARCHAR(40), vineyardName VARCHAR(40), vintage
> TIMESTAMP, wineName VARCHAR(40), winery_wineryid INTEGER, PRIMARY KEY
> (wineid))
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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.
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.
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.
[jira] Commented: (OPENJPA-201) Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if the table argument is used
[
https://issues.apache.org/jira/browse/OPENJPA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487321
]
Abe White commented on OPENJPA-201:
---
Is the named table defined as a SecondaryTable anywhere? How is OpenJPA
supposed to know what to do with it? (This would still be a bug either way,
but I'm curious whether it's a "need better mapping validation" bug or a "not
functioning correctly" bug.)
> Mapping Tool ignores the @JoinColumn annotation in a @ManyToOne mapping if
> the table argument is used
> -
>
> Key: OPENJPA-201
> URL: https://issues.apache.org/jira/browse/OPENJPA-201
> Project: OpenJPA
> Issue Type: Bug
> Environment: 0.9.7-incubating-SNAPSHOT
>Reporter: George Hongell
>Priority: Minor
>
> @Entity
> @Table(name="CxWine")
> public class Wine {
> @Id
> private Integer wineid;
> ...
> @ManyToOne()
> @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="WINERYID",
> table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID",
> referencedColumnName="WINERYID", table="cxWinery")
> //ignored @JoinColumn(name="NEW_WINERY_WINERYID", table="cxWINERY")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID", referencedColumnName="wineryid")
> //ok @JoinColumn(name="NEW_WINERY_WINERYID")
> private Winery winery;
> ...
> }
> generates
> 2744 cxwineTour TRACE [main] openjpa.jdbc.SQL - 98698722> executing stmnt 1325027066 CREATE TABLE CxWine (wineid INTEGER NOT
> NULL, cost SMALLINT, description VARCHAR(254), minimumHoldYears INTEGER,
> rating SMALLINT, stockCount INTEGER, type VARCHAR(20), version INTEGER,
> alcoholPercent DOUBLE, ava VARCHAR(40), bottler VARCHAR(40), brandName
> VARCHAR(40), labelWineClass VARCHAR(20), labelWineColor VARCHAR(20),
> estateBottled SMALLINT, hasSulfites SMALLINT, labelid INTEGER, mlContents
> INTEGER, qualityDesignation VARCHAR(40), vineyardName VARCHAR(40), vintage
> TIMESTAMP, wineName VARCHAR(40), winery_wineryid INTEGER, PRIMARY KEY
> (wineid))
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-202) after invoking LRS processing in a client by calling an @LRS annotated relationship, the next em.clear()/em.close() gets org.apache.openjpa.persistence.InvalidStateExcep
[ https://issues.apache.org/jira/browse/OPENJPA-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-202. --- Resolution: Fixed Fix Version/s: 0.9.7 Changed detach process to never detach LRS fields. In the future we might consider enhancements like detaching write-only proxies for LRS fields. The only way to fully detach an LRS field, though, would be to read it all into memory, which would defeat the purpose. Fixed in revision 526253. > after invoking LRS processing in a client by calling an @LRS annotated > relationship, the next em.clear()/em.close() gets > org.apache.openjpa.persistence.InvalidStateException: You cannot transfer > large result set fields from one object or field to another > -- > > Key: OPENJPA-202 > URL: https://issues.apache.org/jira/browse/OPENJPA-202 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.7 > Environment: 0.9.7-incubating-SNAPSHOT >Reporter: George Hongell > Fix For: 0.9.7 > > Attachments: lrsBugWineryTest.zip > > > after invoking LRS processing in a client by calling an @LRS annotated > relationship, the next em.clear()/em.close() gets > org.apache.openjpa.persistence.InvalidStateException: You cannot transfer > large result set fields from one object or field to another > <4|false|0.9.7-incubating-SNAPSHOT> > org.apache.openjpa.persistence.InvalidStateException: You cannot transfer > large result set fields from one object or field to another. > at > org.apache.openjpa.util.AbstractLRSProxyCollection.setOwner(AbstractLRSProxyCollection.java:77) > at > org.apache.openjpa.kernel.DetachManager$DetachFieldManager.reproxy(DetachManager.java:523) > at > org.apache.openjpa.kernel.DetachManager.detachInternal(DetachManager.java:431) > at > org.apache.openjpa.kernel.DetachManager.detachAll(DetachManager.java:299) > at > org.apache.openjpa.kernel.BrokerImpl.detachAllInternal(BrokerImpl.java:3150) > at org.apache.openjpa.kernel.BrokerImpl.detachAll(BrokerImpl.java:3123) > at > org.apache.openjpa.kernel.DelegatingBroker.detachAll(DelegatingBroker.java:1136) > at > org.apache.openjpa.persistence.EntityManagerImpl.clear(EntityManagerImpl.java:868) > at > com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.testLargeResultSetAnnotation(BugWineryTest.java:902) > at > com.ibm.websphere.ejb3sample.winetour.bug.BugWineryTest.main(BugWineryTest.java:146) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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...
> +/**
> + * The isolation level for queries issued to the database.
> This overrides
> + * the persistence-unit-wide
> openjpa.jdbc.TransactionIsolation
> + * value.
> + *
> + * Must 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.
> + *
> + * @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] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487085 ] Abe White commented on OPENJPA-182: --- > I know that Oracle allows you to add a FOR UPDATE clause to a query, and > this affects the results of that query. In Sun appserver CMP we use this to > set exclusive locks on rows where we want pessimistic locking behavior just > for certain tables. Again, this is exactly what our existing lock levels and APIs do. > db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS > -- > > Key: OPENJPA-182 > URL: https://issues.apache.org/jira/browse/OPENJPA-182 > Project: OpenJPA > Issue Type: New Feature > Components: jdbc > Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-182.patch, openJPA182.patch > > > A while back we changed the syntax of update locking from FOR UPDATE OF to > WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because > 1. if isolation=serializable is configured, then the syntax should be WITH > RR USE AND KEEP UDPATE LOCKS > 2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND > KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 > only supports read or exclusive locks. > 3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses. > So we change supportsLockingWithSelectRange = true in the > AbstractDB2Dictionary class and change the DB2Dictionary to append the > correct LOCKS syntax depending on vendor, release and isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows
[
https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487078
]
Abe White commented on OPENJPA-203:
---
If we don't want the subclasses to have to unset the lock value in case of
exception, another option would be to have lock() delegate to lockInternal for
setting the lock value, but to unset the lock value itself on error:
int oldValue = getLockValue(sm);
try {
lockInternal(...);
} catch (RuntimeException re) {
setLockValue(sm, oldValue);
throw re;
}
> Pessimistic Lock Manager not locking the rows
> --
>
> Key: OPENJPA-203
> URL: https://issues.apache.org/jira/browse/OPENJPA-203
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 0.9.0, 0.9.6
> Environment: ran against Oracle
>Reporter: Srinivasa
> Attachments: NotesAndDiff.txt, testcase.zip
>
>
> With pessimistic lock manager multiple EMs are able to modify the same
> object concurrently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487000 ] Abe White commented on OPENJPA-182: --- > Hopefully, this will be useful for applications where there are "hot" tables > that require pessimistic locking even though the rest of the application does > better with optimistic. That's what our lock levels and lock APIs are for. I'm still not clear on what this is adding to the mix for most DBs. > db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS > -- > > Key: OPENJPA-182 > URL: https://issues.apache.org/jira/browse/OPENJPA-182 > Project: OpenJPA > Issue Type: New Feature > Components: jdbc > Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-182.patch, openJPA182.patch > > > A while back we changed the syntax of update locking from FOR UPDATE OF to > WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because > 1. if isolation=serializable is configured, then the syntax should be WITH > RR USE AND KEEP UDPATE LOCKS > 2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND > KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 > only supports read or exclusive locks. > 3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses. > So we change supportsLockingWithSelectRange = true in the > AbstractDB2Dictionary class and change the DB2Dictionary to append the > correct LOCKS syntax depending on vendor, release and isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-203) Pessimistic Lock Manager not locking the rows
[ https://issues.apache.org/jira/browse/OPENJPA-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486999 ] Abe White commented on OPENJPA-203: --- Looks good. Although I think I'd prefer to make lockInternal() responsible for setting the lock level rather than having to set it and unset it so that lock() can set it again... it's just too ugly. So instead we just remove the setting of the lock level in lock() and make VersionLockManager only unset the lock level in its lockInternal if an exception occurs. PessimisticLockManager wouldn't have to change (outside of the changes already in your patch) because it delegates to super.lockInternal already, so the lock level would get set appropriately. > Pessimistic Lock Manager not locking the rows > -- > > Key: OPENJPA-203 > URL: https://issues.apache.org/jira/browse/OPENJPA-203 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 0.9.0, 0.9.6 > Environment: ran against Oracle >Reporter: Srinivasa > Attachments: NotesAndDiff.txt, testcase.zip > > > With pessimistic lock manager multiple EMs are able to modify the same > object concurrently. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486987 ] Abe White commented on OPENJPA-182: --- What is setting the isolation level this way actually doing? For anything other than DB2 right now, it looks like it doesn't do anything. And even for DB2, it's unclear to me exactly what the isolation level hint is doing, and why the information can't be gleaned from the global setting or the connection. It seems very misleading to me to have a setIsolationLevel API (or generic "IsolationLevel" hint) that doesn't actually change the connection's isolation level. If we can determine that this API is actually useful for more than DB2, and if we can name it appropriately for what it actually does, then I like Patrick's proposal of a FetchPlan API. The fact that all FetchPlan properties can be expressed as hints should make everyone happy. But if this is just a DB2 thing, then we should rename the hint to have a DB2-specific name and be done with it IMO. > db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS > -- > > Key: OPENJPA-182 > URL: https://issues.apache.org/jira/browse/OPENJPA-182 > Project: OpenJPA > Issue Type: New Feature > Components: jdbc > Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-182.patch, openJPA182.patch > > > A while back we changed the syntax of update locking from FOR UPDATE OF to > WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because > 1. if isolation=serializable is configured, then the syntax should be WITH > RR USE AND KEEP UDPATE LOCKS > 2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND > KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 > only supports read or exclusive locks. > 3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses. > So we change supportsLockingWithSelectRange = true in the > AbstractDB2Dictionary class and change the DB2Dictionary to append the > correct LOCKS syntax depending on vendor, release and isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
> ... for certain values of "our". I think that it's important that we > discuss API decisions as a group, as they have significant impacts on > the OpenJPA product moving forward. This is especially important when > there are dissenting views on a particular API decision, as is the > case > here. I agree with Patrick. API decisions need to be better thought out. For example, even if we decide as a group to use hints in this case, the names of the hints are important. The current hint names you chose are inconsistent with other OpenJPA hints in naming style and capitalization. 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: 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: Forced getter/setter access
> I meant "tuned" as in not including columns in the SQL update "set" > clause if they weren't really changed by the app (even if a setter > was called, the old and new values may be the same). We detect when you're setting a field/property to the same value it already has. That doesn't require a state snapshot or comparisons at flush time. It just requires passing the current value along with the new value to the internal method that is responsible for "dirtying" the object. 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: 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: new site look
On Apr 3, 2007, at 1:16 PM, Marc Prud'hommeaux wrote: > Hiram- > >> I'm the guy that put the original ActiveMQ design together. If >> you want >> I'll tweak it some more for you guys. Perhaps change the color >> scheme? Or >> do you just want a better integrated banner/logo? > > Personally, I think it would be fantastic if we had someone with > clear design talent making improvements to the site. I had tried to > tweak the colors initially so it didn't look like such an obvious > copy of the ActiveMQ site, but I have lousy color sense, and > everything I tried wound up looking garish. > > So, +1 from me for making any improvements you like! +1 from me too 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=rev&rev=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=diff&rev=525006&r1=525005&r2=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=diff&rev=525006&r1=525005&r2=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 +=sche
[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.
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.
Re: [jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
> The spec says in 3.2.4.1 p. 52: Any Version columns used by the > entity must be checked by the persistence runtime implementation > during the merge operation and/or at flush or commit time. > > So, one could agree with Abe (the and/or is the key). > > Reading about it further, the spec says in 9.1.17 p. 178: "The > version is used to ensure integrity when performing the merge > operation and for optimistic concurrency control." and there's > nothing about flush/commit time. > > Also, verifying it against RI (which is alas TopLink Essentials) > leads to the same conclusion and it seems that it's only OpenJPA > who thinks differently. I wish I could give it a shot with other > JPA providers than OpenJPA, TopLink and Hibernate (but would that > change anything?). OK, then read the 4th paragraph of section 3.4.2. Also, note the fact that the TCK doesn't test for exception on merge. It doesn't matter how other implementations work, OpenJPA is completely correct according to the spec. 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: Using DDL generation in a Java EE environment?
> If you just want a "fresh" database view for the mapping tool, such > that the mapping tool thinks that the database has no schema > defined, then you can specify the "-SchemaFactory" flag to be "file > (my-schema.xml)", where my-schema.xml file is a schema definition file The "build" schema action also pretends there is no existing database, though it will still connect. 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] Assigned: (OPENJPA-134) Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER
[ https://issues.apache.org/jira/browse/OPENJPA-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White reassigned OPENJPA-134: - Assignee: Abe White > Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER > - > > Key: OPENJPA-134 > URL: https://issues.apache.org/jira/browse/OPENJPA-134 > Project: OpenJPA > Issue Type: Bug > Components: sql >Reporter: Catalina Wei > Assigned To: Abe White > Fix For: 0.9.7 > > > Running JPAConfiguration default setting for EagerFetchMode > (FetchModeValue.EAGER_PARALLEL), > the SQL generated is sub-optimal. > Consider the following entities: > lineitems( OneToMany ) > Order <===> OrderItem > order ( ManyToOne ) > Case 1: why not combining 2 SQL to 1 SQL ? > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o > 2173 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1299336562 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr FROM Order t0 > 2213 demo TRACE [main] openjpa.jdbc.SQL - > [40 ms] spent > 2223 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1406424020 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t1.order_oid, t1.part_partno, > t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = t1.order_oid > ORDER BY t0.oid ASC > Case 2: extra unneeded LEFT OUTER JOIN, if eliminated, the selection aliase > t2 should change to t1: > = > Order.lineitmes(EAGER): > OrderItem.order(LAZY): > Executing query: select o from Order o left join fetch o.lineitems > 2403 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1500797300 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, > t2.cost, t2.part_partno, t2.quantity FROM Order t0 LEFT OUTER JOIN OrderItem > t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN OrderItem t2 ON t0.oid = > t2.order_oid ORDER BY t2.order_oid ASC > Case 3: why not generating 1 SQL ? > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o > 2343 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 384833264 SELECT t0.oid, t0.version, t0.amount, > t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr FROM Order > t0 > 2383 demo TRACE [main] openjpa.jdbc.SQL - > [40 ms] spent > 2393 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1722705582 > SELECT t0.oid, t1.lid, t1.version, t1.cost, t2.oid, t2.version, t2.amount, > t2.customer_countryCode, t2.customer_id, t2.delivered, t2.shipaddr, > t1.part_partno, t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = > t1.order_oid LEFT OUTER JOIN Order t2 ON t1.order_oid = t2.oid ORDER BY > t0.oid ASC > 2393 demo TRACE [main] openjpa.jdbc.SQL - > [0 ms] spent > 3134 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 950548648 > SELECT t0.lid, t0.version, t0.cost, t1.oid, t1.version, t1.amount, > t1.customer_countryCode, t1.customer_id, t1.delivered, t1.shipaddr, > t0.part_partno, t0.quantity FROM OrderItem t0 LEFT OUTER JOIN Order t1 ON > t0.order_oid = t1.oid WHERE t0.order_oid = ? [params=(int) 88] > 3134 demo TRACE [main] openjpa.jdbc.SQL - > [0 ms] spent > Case 4: duplicate selections and redundant joins > == > Order.lineitmes(EAGER): > OrderItem.order(EAGER): > Executing query: select o from Order o left join fetch o.lineitems > 2273 demo TRACE [main] openjpa.jdbc.SQL - > executing prepstmnt 1565154634 > SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, > t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, > t2.cost, t3.oid, t3.version, t3.amount, t3.customer_countryCode, > t3.customer_id, t3.delivered, t3.shipaddr, t2.part_partno, t2.quantity FROM > Order t0 LEFT OUTER JOIN OrderItem t1 ON t0.oid = t1.order_oid LEFT OUTER > JOIN OrderItem t2 ON t0.oid = t2.order_oid LEFT OUTER JOIN Order t3 ON > t2.order_oid = t3.oid ORDER BY t2.order_oid ASC -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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] 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: 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 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] Commented: (OPENJPA-187) MEMBER OF query fails on OpenJPA, but works fine with TopLink and Hibernate EM
[
https://issues.apache.org/jira/browse/OPENJPA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484899
]
Abe White commented on OPENJPA-187:
---
Does it work if you actually look up the "Apache OpenEJB" Projekt instance
through the EntityManager rather than constructing a new one? It might be that
OpenJPA is recognizing that the given Projekt isn't actually persistent.
> MEMBER OF query fails on OpenJPA, but works fine with TopLink and Hibernate EM
> --
>
> Key: OPENJPA-187
> URL: https://issues.apache.org/jira/browse/OPENJPA-187
> Project: OpenJPA
> Issue Type: Bug
> Components: query
>Affects Versions: 0.9.7
>Reporter: Jacek Laskowski
>
> What's wrong with the following query?
> Query query = em.createQuery("SELECT DISTINCT o FROM Osoba o WHERE :projekt
> MEMBER OF o.projekty");
> query.setParameter("projekt", new Projekt("Apache OpenEJB",
> RodzajProjektu.OTWARTY));
> List osoby = query.getResultList();
> assert osoby.size() == 1 : "Otrzymano " + osoby.size();
> where Projekt is an entity where @Id is of type String (the first input
> parameter in the two-param constructor above).
> TopLink 2.0 BUILD 40 and Hibernate EntityManager 3.3.0.GA work fine whereas
> OpenJPA 0.9.7-SNAPSHOT finishes with the java.lang.AssertionError error (it's
> the test itself actually, but since the query returns 0 elements the issue
> originates in OpenJPA).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-181) ClassCastException when executing bulk delete on an entity that owns a OneToOne with a Cascade.DELETE when DataCache is on
[
https://issues.apache.org/jira/browse/OPENJPA-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-181.
---
Resolution: Fixed
Fix Version/s: 0.9.7
Fixed in SVN revision 523046. See test case added to TestBulkJPQLAndDataCache.
> ClassCastException when executing bulk delete on an entity that owns a
> OneToOne with a Cascade.DELETE when DataCache is on
> --
>
> Key: OPENJPA-181
> URL: https://issues.apache.org/jira/browse/OPENJPA-181
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 0.9.7
>Reporter: Jonathan Feinberg
> Fix For: 0.9.7
>
>
> Given an entity class A which owns a OneToOne entity of class B, and given a
> cascade on that OneToOne that includes DELETE, an attempt to bulk-delete A
> when using the DataCache results in a stack trace like the following:
> java.lang.ClassCastException:
> org.apache.openjpa.datacache.QueryCacheStoreQuery cannot be cast to
> org.apache.openjpa.kernel.ExpressionStoreQuery
> at
> org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:674)
> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:979)
> at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1005)
> ... 28 more
> The proximate cause for the bug is that when the JDBCStoreQuery does this:
> private Table getTable(FieldMapping fm, Table table) {
> if (fm.getCascadeDelete() != ValueMetaData.CASCADE_NONE)
> return INVALID;
> it causes "isSingleTableMapping" to be considered false, which in turn
> permits executeBulkOperation to return null. Meanwhile, back in
> DataStoreExecutor:
>public Number executeDelete(StoreQuery q, Object[] params) {
> Number num = ((ExpressionStoreQuery) q).executeDelete(this, _meta,
> _metas, _subs, _facts, _exps, params);
> if (num == null)
> return q.getContext().deleteInMemory(this, params); // <-
> now we have come here because executeDelete punted
> return num;
> }
> So deleteInMemory gets called in QueryImpl:
>public Number deleteInMemory(StoreQuery.Executor executor,
> Object[] params) {
> try {
> Object o = execute(executor, params);
> , but a DataStoreExecutor doesn't know how to execute the
> QueryCacheStoreQuery that it gets.
> Somehwere, something is too unwrapped, or not wrapped enough. Good luck!
> Workaround:
> If A owns B, then instead of cascade=CascadeType.ALL, you can
> @Entity
> class A {
> B myThing;
> @OneToOne(cascade = { CascadeType.PERSIST, CascadeType.MERGE,
> CascadeType.REFRESH })
>B getMyThing() { return myThing; }
> }
> @Entity
> class B {
> A owner;
> @ForeignKey(deleteAction=ForeignKeyAction.CASCADE)
> A getOwner() { return owner; }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484474 ] Abe White commented on OPENJPA-168: --- Something is wrong with my email system so instead of replying to the SVN commit message, I'm posting my comments on the commit of this patch here. I didn't go through the entire commit, but what I saw looked really good. There are, however, a few problems I'd like to see fixed: 1. The formatting is messed up (in that it is unlike all our other formatting) in many places. Indentation is off, spaces are missing before opening braces or added before line-ending semicolons, etc. Can you change the formatting to be consistent with the rest of the codebase? 2. The point of making the optimize hint string a static constant is not only to avoid typo errors when we use it internally, but also to make it available to users. In this way it is exactly like the constants in org.apache.openjpa.kernel.QueryFlushModes, for example. I'd like to see the constant removed from AbstractStoreQuery. Instead, I'd like to see an org.apache.openjpa.kernel.QueryHints interface with a HINT_RESULT_COUNT defined, and I'd like to see org.apache.openjpa.persistence.OpenJPAQuery implement this interface, just as it does for QueryFlushModes. This will allow both our internal code -- through QueryHints -- and user code -- through OpenJPAQuery -- to use the constant. 3. This is much more of a matter of personal opinion, but I think the added code is over-commented. The new SelectExecutor.setExpectedResultCount method should be thoroughly documented, but IMO we don't need comments explaining what we're doing every time we invoke the method. The code speaks for itself, and over-commenting always runs the danger of the comments falling out of synch with the code. > sql optimize n rows query hint > -- > > Key: OPENJPA-168 > URL: https://issues.apache.org/jira/browse/OPENJPA-168 > Project: OpenJPA > Issue Type: New Feature >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-168.patch.txt, OPENJPA-168.patch2.txt > > > There werre various comments from Patrick, Abe and Kevin Sutter about the > code that I checked related to Optimize hint. So I have gone back and > relooked at this and wil be making some changes. At Kevin's suggestion I > will do this through a JIRA feature so that folks will have opportunity to > comment on this before the code is actually done and checked in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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.
Re: Shared classloader and subclasses
I see. Here's a proposal: in the MetaDataRepository's implementation of the RegisterClassListener interface, the repository only registers the given class if either the user has not specified a persistent types list (which we allow and in which case we attempt to lazily discover persistent types), or if the class name appears in the list. That way if you follow JPA guidelines and specify your persistent class list properly, subclasses left off the list won't even get registered with the metadata repository. That sounds about right. I tried something similar using MetaDataFactory.getPersistentTypeNames(), but this method requires a classloader to be passed to it. Using the thread's classloader didn't seem right (and didn't work anyway). Is there another way to find this list? Good point. I guess we can't exclude the classes in the register class listener method itself, but we can do so when we processRegisteredClasses(). This method is only ever called from places where we have the proper classloader (the same one we pass to getPersistentTypeNames()). ___ 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_12482931
]
Abe White commented on OPENJPA-175:
---
1. Are you also going to fix InExpression to honor the DBDictionary's new in
clause limit?
2. After reviewing the patch some more, I propose the following simplified
version:
// try to find a good page size. if the known size < batch size, use
// it. if the batch size is set, then use that; if it's sorta close
// to the size, then use the size / 2 to get two full pages rather
// than a possible big one and small one
int batch = getFetchConfiguration().getFetchBatchSize();
int pageSize;
if (batch < 0)
pageSize = (int) size;
else {
if (batch == 0)
batch = 50; // reasonable default
if (size <= batch)
pageSize = (int) size;
else if (size <= batch * 2) {
if (size % 2 == 0)
pageSize = (int) (size / 2);
else
pageSize = (int) (size / 2 + 1);
} else
pageSize = batch;
}
> Eager selects by PagingResultObjectProvider may not use the FetchBatchSize
> --
>
> Key: OPENJPA-175
> URL: https://issues.apache.org/jira/browse/OPENJPA-175
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 0.9.0, 0.9.6
>Reporter: Srinivasa
> Attachments: OPENJPA-175-patch.txt, OPENJPA-175-patch.txt
>
>
> The PagingResultObjectProvider during initialization does checks to determine
> the appropriate pageSize. While this logic caps the size to 50 and addresses
> determining an appropriate page size, it doesn't always conform to the set
> batch size. For example with the size being 1000 and FetchBatchSize set to
> say 500, the page size is determined to be 50 resulting in eager selects
> happening in batches of 50 when the user expects it to be in batches of 500.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482904 ] Abe White commented on OPENJPA-168: --- > The reason for using -1 is that we want to differentiate between cases where > the user added a hint to optimize for 1 row versus where we internally > generated the value (getSingleResult,singleRelationshiptraversal etc). That makes sense, though the use case seems vanishingly small (when would the user explicitly optimize for one row but also include a to-many eager join?). How about instead of using -1 to indicate "an artificial single result", we change the setExpectedResults API on Select (or SelectExecutor if we go that route) to take an additional "boolean force" parameter that is set to true when it's a user-specified count, and false when it's an artificial expectation. Internally we can keep track of whether the expected count is forced with another bit flag among those already used in SelectImpl. When the count is not forced, we ignore it in the presence of a to-many eager join. This API seems more clear-cut to me, in addition to being more general (even if we don't necessarily need the additional generality at this point). > The fact of the matter is that the optimize clause generation for various > dictionaries is different in terms of syntax and where the clause appears in > the select string.So I am not sure if u really want to generalize the > configuration of row optimization to the base DBDictionary Fair enough -- I had forgotten that it was so different for different databases. > sql optimize n rows query hint > -- > > Key: OPENJPA-168 > URL: https://issues.apache.org/jira/browse/OPENJPA-168 > Project: OpenJPA > Issue Type: New Feature >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-168.patch.txt > > > There werre various comments from Patrick, Abe and Kevin Sutter about the > code that I checked related to Optimize hint. So I have gone back and > relooked at this and wil be making some changes. At Kevin's suggestion I > will do this through a JIRA feature so that folks will have opportunity to > comment on this before the code is actually done and checked in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-175) Eager selects by PagingResultObjectProvider may not use the FetchBatchSize
[ https://issues.apache.org/jira/browse/OPENJPA-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482821 ] Abe White commented on OPENJPA-175: --- I'll have to see the code in context once it's checked in because I'm not very good at reading patches, but it looks good to me. > Eager selects by PagingResultObjectProvider may not use the FetchBatchSize > -- > > Key: OPENJPA-175 > URL: https://issues.apache.org/jira/browse/OPENJPA-175 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.0, 0.9.6 >Reporter: Srinivasa > Attachments: OPENJPA-175-patch.txt, OPENJPA-175-patch.txt > > > The PagingResultObjectProvider during initialization does checks to determine > the appropriate pageSize. While this logic caps the size to 50 and addresses > determining an appropriate page size, it doesn't always conform to the set > batch size. For example with the size being 1000 and FetchBatchSize set to > say 500, the page size is determined to be 50 resulting in eager selects > happening in batches of 50 when the user expects it to be in batches of 500. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-177) When using NOT NULL constraint on foreign key it is not possible to use CascadeType.ALL and GeneratedId
[
https://issues.apache.org/jira/browse/OPENJPA-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482815
]
Abe White commented on OPENJPA-177:
---
OpenJPA will insert records in the order that you persist the corresponding
objects. When you persist in an order that would violate foreign key
constraints, OpenJPA attempts to insert null and then update the foreign key
value in a separate statement. If you use non-nullable constraints, though,
you must persist your objects in the correct order.
> When using NOT NULL constraint on foreign key it is not possible to use
> CascadeType.ALL and GeneratedId
> ---
>
> Key: OPENJPA-177
> URL: https://issues.apache.org/jira/browse/OPENJPA-177
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 0.9.6
> Environment: Windows XP, IBM 32-bit SDK 5.0, WebSphere 6.1
>Reporter: Daniel Gajdos
>
> When using on entity Application
> @OneToOne(cascade = CascadeType.ALL)
> @JoinColumn(name = "C_PERSON_ID", nullable=false)
> @ForeignKey
> private Person person;
> and on entity Person using generated ID, it fails on inserting Application
> because of performing db actions in this order:
> INSERT INTO T_APPLICATION (C_ID, C_APPLICATION_NUMBER, C_APPLIED_DATE,
> C_STATUS) VALUES (:1, :2, :3, :4) - here it tries to insert null value as
> C_PERSON_ID, which is not permited because of nullable=false
> declaration. This declaration creates NOT NULL constraint on C_PERSON_ID.
> INSERT INTO NSVISP.T_PERSON (C_ID, C_BIRTH_DATE, C_FIRST_NAME, C_LAST_NAME)
> VALUES (:1, :2, :3, :4)
> UPDATE NSVISP.T_APPLICATION SET C_PERSON_ID = :1 WHERE C_ID = :2
> Error reported from DB:
> org.apache.openjpa.lib.jdbc.ReportingSQLException: ORA-01400: cannot insert
> NULL into ("T_APPLICATION"."C_PERSON_ID")
> Is there any chance to change the order in which this operations are
> executed? On this type of constraint we have to insert Person before
> inserting Application and include the generated Person Id into insert
> statement for Application. Otherwise we have to deffer the NOT NULL
> constraint which can be dangerous and it is not defered initialy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Shared classloader and subclasses
In the case above, another webapp has loaded the forums module, causing this webapp to look for the mappings in that module even though they aren't available. I had difficulty trying to figure out how to restrict which subclasses are 'seen'. Ideally I think it'd be done in the MetaDataRepository#register() method, but no metadata seems to be available at this time. I see. Here's a proposal: in the MetaDataRepository's implementation of the RegisterClassListener interface, the repository only registers the given class if either the user has not specified a persistent types list (which we allow and in which case we attempt to lazily discover persistent types), or if the class name appears in the list. That way if you follow JPA guidelines and specify your persistent class list properly, subclasses left off the list won't even get registered with the metadata repository. ___ 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_12482484
]
Abe White commented on OPENJPA-132:
---
Sorry Kevin; I didn't see your comment before committing. As my resolution
comment states, though, I can back my fix out if we decide we don't like it.
> java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
>
>
> Key: OPENJPA-132
> URL: https://issues.apache.org/jira/browse/OPENJPA-132
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Reporter: Michael Dick
>Priority: Minor
> Fix For: 0.9.7
>
> Attachments: OpenJPA-132.patch.txt
>
>
> Opening JIRA report to track the following problem (posted to development
> forum
> http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
>
> I'm getting the following exception when I try to fetch an entity with a
> java.sql.Date as the id :
> java.lang.NoSuchMethodError:
> org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
> at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
> at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
> at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
> at org.apache.openjpa.kernel.StateManagerImpl.initialize
> (StateManagerImpl.java:247)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
> at
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
> at
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
> at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
> at org.apache.openjpa.kernel.DelegatingBroker.find
> (DelegatingBroker.java:169)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
> at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke (Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> . . .
> It's coming from the generated bytecode which expects there to be a getId
> method that returns the same type of the Id, however java.sql.Date is using
> the same ID class as java.util.Date. Do we need a separate class for
> java.sql.Date?
> Responses from Patrick and Craig follow. The consensus so far is to provide
> ID separate classes for java.sql.Date and java.util.Date.
> It looks like we either need a separate type for java.sql.Date (and
> presumably java.sql.Timestamp), or we need to change the logic to accept
> a getId() method that returns a type that is assignable from the id
> field's type.
> -Patrick
> It's probably cleaner if we have separate classes for the different
> types. That is, have the getId method in the new
> org.apache.openjpa.util.SQLDateId return the proper type
> (java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
> really the same as java.util.Date.
> -Craig
> FTR, I think that I prefer separate classes as well; it's clearer, and
> avoids any ambiguity with other subclasses in the future.
> -Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
[
https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-132.
---
Resolution: Fixed
Fixed in SVN revision 520522. We can back out if we decide to use an
alternative fix strategy in the future.
> java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
>
>
> Key: OPENJPA-132
> URL: https://issues.apache.org/jira/browse/OPENJPA-132
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Reporter: Michael Dick
>Priority: Minor
> Fix For: 0.9.7
>
> Attachments: OpenJPA-132.patch.txt
>
>
> Opening JIRA report to track the following problem (posted to development
> forum
> http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
>
> I'm getting the following exception when I try to fetch an entity with a
> java.sql.Date as the id :
> java.lang.NoSuchMethodError:
> org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
> at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
> at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
> at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
> at org.apache.openjpa.kernel.StateManagerImpl.initialize
> (StateManagerImpl.java:247)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
> at
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
> at
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
> at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
> at org.apache.openjpa.kernel.DelegatingBroker.find
> (DelegatingBroker.java:169)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
> at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke (Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> . . .
> It's coming from the generated bytecode which expects there to be a getId
> method that returns the same type of the Id, however java.sql.Date is using
> the same ID class as java.util.Date. Do we need a separate class for
> java.sql.Date?
> Responses from Patrick and Craig follow. The consensus so far is to provide
> ID separate classes for java.sql.Date and java.util.Date.
> It looks like we either need a separate type for java.sql.Date (and
> presumably java.sql.Timestamp), or we need to change the logic to accept
> a getId() method that returns a type that is assignable from the id
> field's type.
> -Patrick
> It's probably cleaner if we have separate classes for the different
> types. That is, have the getId method in the new
> org.apache.openjpa.util.SQLDateId return the proper type
> (java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
> really the same as java.util.Date.
> -Craig
> FTR, I think that I prefer separate classes as well; it's clearer, and
> avoids any ambiguity with other subclasses in the future.
> -Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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] Commented: (OPENJPA-168) sql optimize n rows query hint
[
https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482421
]
Abe White commented on OPENJPA-168:
---
Comments on the proposed patch:
- I don't like the whole scheme of setting the expected result count to -1 for
anything "artificial". It's confusing and unnecessary. Just set it to the
number of expected "primary" results, and the DBDictionary can invoke
sel.hasEagerJoin(true) to figure out if the expected count can be used. Or
just have the getter for the expected count always return 0 if there is an
eager to-many join (or better yet, turn -1 into a value meaning "unknown" and
have it return -1, which would then also be the default when no expected count
is set).
- I still think there should be a way to get rid of Union.is/setSingleResult by
moving the expected result property to SelectExecutor -- which both Select and
Union extend -- and taking advantage of the new expected result ("1" obviously
indicates a single result).
- If you're going to validate the value of the user-supplied hint in the JPA
QueryImpl, you might as well transform it into a Number at that point before
setting it into the FetchConfiguration. Also, I'd accept any Number, not just
an Integer (technically we should accept any whole number, but that's a pain to
implement). Then in the JDBC layer, you can just cast the hint value directly
to a Number and forgo validating it and checking for String values a second
time.
- DB2 really cares whether you use "optimize for 1 row" vs. "optimize for 1
rows"? That's ugly.
- We should probably generalize the configuration of row optimization to the
base DBDictionary with an override mechanism.
- If you're going to invoke setUnique(true) on the underlying query from the
JPA QueryImpl's getSingleResult, you need to do three things:
1. Unset it in a finally clause, because the very next call might be to
getResultList, and in general getSingleResult shouldn't have stateful side
effects.
2. Change the kernel's QueryImpl to throw an exception when unique is set but
the query doesn't return any results. Right now it allows 0 results and will
return null, which is indistinguishable from a projection on a null field that
returned 1 result.
3. Get rid of the code immediately following in getSingleResult that extracts
the value if a List is returned, because after setting the unique flag on the
underlying query, it will never return a List.
- The hint key should be a constant in the kernel's Query interface or
somewhere like that.
> sql optimize n rows query hint
> --
>
> Key: OPENJPA-168
> URL: https://issues.apache.org/jira/browse/OPENJPA-168
> Project: OpenJPA
> Issue Type: New Feature
>Reporter: David Wisneski
> Assigned To: David Wisneski
> Attachments: OPENJPA-168.patch.txt
>
>
> There werre various comments from Patrick, Abe and Kevin Sutter about the
> code that I checked related to Optimize hint. So I have gone back and
> relooked at this and wil be making some changes. At Kevin's suggestion I
> will do this through a JIRA feature so that folks will have opportunity to
> comment on this before the code is actually done and checked in.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482411 ] Abe White commented on OPENJPA-168: --- > when I am executing the 1st select I see 3 eagerKeys in the eagerKey map in > the debugger (dept,mgr,emps) but the selectImpl.hasEagerJoin(toMany) method > returns false.So my question is that inspite of seeing emps in the eagerKey > map how come this method returns false. Because emps is being selected via a parallel select, not a to-many join in the primary select. > sql optimize n rows query hint > -- > > Key: OPENJPA-168 > URL: https://issues.apache.org/jira/browse/OPENJPA-168 > Project: OpenJPA > Issue Type: New Feature >Reporter: David Wisneski > Assigned To: David Wisneski > Attachments: OPENJPA-168.patch.txt > > > There werre various comments from Patrick, Abe and Kevin Sutter about the > code that I checked related to Optimize hint. So I have gone back and > relooked at this and wil be making some changes. At Kevin's suggestion I > will do this through a JIRA feature so that folks will have opportunity to > comment on this before the code is actually done and checked in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-175) Eager selects by PagingResultObjectProvider may not use the FetchBatchSize
[ https://issues.apache.org/jira/browse/OPENJPA-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482409 ] Abe White commented on OPENJPA-175: --- +1, with some caveats: - The proposed patch doesn't handle the common cases where the FetchBatchSize is -1 (unlimited) or 0 (driver default). - I'm a little nervous about defaulting the in clause limit to "unlimited" when we don't have much info on actual database limits other than Oracle. > Eager selects by PagingResultObjectProvider may not use the FetchBatchSize > -- > > Key: OPENJPA-175 > URL: https://issues.apache.org/jira/browse/OPENJPA-175 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.0, 0.9.6 >Reporter: Srinivasa Segu > Attachments: OPENJPA-175-patch.txt > > > The PagingResultObjectProvider during initialization does checks to determine > the appropriate pageSize. While this logic caps the size to 50 and addresses > determining an appropriate page size, it doesn't always conform to the set > batch size. For example with the size being 1000 and FetchBatchSize set to > say 500, the page size is determined to be 50 resulting in eager selects > happening in batches of 50 when the user expects it to be in batches of 500. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
[
https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482259
]
Abe White commented on OPENJPA-132:
---
I have a fix ready to commit that consists of about 6 lines of enhancer code to
account for Date subclasses when using DateId, just as we account for Object
subclasses when using ObjectId. The fix avoids the new type constant, new
identity class, and all the additional "case" statements for SQL dates in the
patch proposed by Michael Dick. Additionally, the fix should work with
java.sql.Time and java.sql.Timestamp too; Michael's fix will not. I believe
this is a simpler, better solution. I also have a test case for SQL date id's
ready to commit; we can use it with either my patch or Michael's. I will hold
off on committing until we resolve whose patch to use.
> java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
>
>
> Key: OPENJPA-132
> URL: https://issues.apache.org/jira/browse/OPENJPA-132
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Reporter: Michael Dick
>Priority: Minor
> Fix For: 0.9.7
>
> Attachments: OpenJPA-132.patch.txt
>
>
> Opening JIRA report to track the following problem (posted to development
> forum
> http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
>
> I'm getting the following exception when I try to fetch an entity with a
> java.sql.Date as the id :
> java.lang.NoSuchMethodError:
> org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
> at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
> at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
> at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
> at org.apache.openjpa.kernel.StateManagerImpl.initialize
> (StateManagerImpl.java:247)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
> at
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
> at
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
> at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
> at org.apache.openjpa.kernel.DelegatingBroker.find
> (DelegatingBroker.java:169)
> at
> org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
> at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke (Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> . . .
> It's coming from the generated bytecode which expects there to be a getId
> method that returns the same type of the Id, however java.sql.Date is using
> the same ID class as java.util.Date. Do we need a separate class for
> java.sql.Date?
> Responses from Patrick and Craig follow. The consensus so far is to provide
> ID separate classes for java.sql.Date and java.util.Date.
> It looks like we either need a separate type for java.sql.Date (and
> presumably java.sql.Timestamp), or we need to change the logic to accept
> a getId() method that returns a type that is assignable from the id
> field's type.
> -Patrick
> It's probably cleaner if we have separate classes for the different
> types. That is, have the getId method in the new
> org.apache.openjpa.util.SQLDateId return the proper type
> (java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
> really the same as java.util.Date.
> -Craig
> FTR, I think that I prefer separate classes as well; it's clearer, and
> avoids any ambiguity with other subclasses in the future.
> -Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-174) error when find()'ing an abstract class
[ https://issues.apache.org/jira/browse/OPENJPA-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White resolved OPENJPA-174. --- Resolution: Fixed Fix Version/s: 0.9.7 Only affected abstract base types with a single String id field. Fixed in SVN revision 520117. Added test case in org.apache.openjpa.persistence.inheritance.TestFindAbstractClass. > error when find()'ing an abstract class > --- > > Key: OPENJPA-174 > URL: https://issues.apache.org/jira/browse/OPENJPA-174 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.6 > Environment: Java SE 5 > Derby >Reporter: Jeffrey Blatttman > Fix For: 0.9.7 > > Attachments: abstracttest.zip, pom.zip > > > class B extends A > A is abstract > B is concrete > i have persisted an instance of B. now i try: > A a = em.find(A.class, anId); > openjpa fails with: > ... Cannot create new application identity instance for abstract class > "class A" > if i change the find to: > A a = em.find(B.class, anId); > openjpa works okay. > note that i have two test cases. one is my real model, and one is the simple > A and B class example above. my real model fails, where the simple A, B class > example works as expected. so, it's is either a side affect of some other > issue, or there is something wrong in my model and the error message is > misleading or lacking information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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-168) sql optimize n rows query hint
[ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480920 ] Abe White commented on OPENJPA-168: --- I don't recall any way to know whether a given Select it is a top-level Select or a parallel Select. Note that if you take my advice and implement this as an ExpectedResultCount property of SelectExecutor (which can also replace the isSingleResult propertyof Union), then you don't need to know. The query/storemanager/whatever that constructs the top-level select will set the expected count based on hints / knowledge, and the dictionary will use it as needed. It won't get passed to parallel eager selects accidentally. > sql optimize n rows query hint > -- > > Key: OPENJPA-168 > URL: https://issues.apache.org/jira/browse/OPENJPA-168 > Project: OpenJPA > Issue Type: New Feature >Reporter: David Wisneski > Assigned To: David Wisneski > > There werre various comments from Patrick, Abe and Kevin Sutter about the > code that I checked related to Optimize hint. So I have gone back and > relooked at this and wil be making some changes. At Kevin's suggestion I > will do this through a JIRA feature so that folks will have opportunity to > comment on this before the code is actually done and checked in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-171) EntityManager.getReference() returns an object of a wronc class
[ https://issues.apache.org/jira/browse/OPENJPA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480510 ] Abe White commented on OPENJPA-171: --- I attempted to reproduce this in a very simple test case but failed. We'll need a user-supplied test case. As a technical aside, I'm having trouble seeing how the "T getReference(Class cls, Object id)" method could possibly return anything other than a "T" instance. > EntityManager.getReference() returns an object of a wronc class > --- > > Key: OPENJPA-171 > URL: https://issues.apache.org/jira/browse/OPENJPA-171 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.6 >Reporter: Stefano Juri > > I have a simple class system : a PersonImpl owns a set of AbstractAddresses. > An AbstractAddress can be an EMailAddressImpl or a PostalAddressImpl. All > these objects extend AbstractBusinessObject. > When I call entityManager.getReference(PersonImpl.class, "1") I get the > EMailAddressImpl object with id "1" instead of a PersonImpl object. > If I get the object with a query (select p from PersonImpl p where p.id='1') > everything is ok. > My mapping file is : > http://java.sun.com/xml/ns/persistence/orm"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm > http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"; > version="1.0"> > class="ch.admin.bit.fw2.bm.AbstractBusinessObjectImpl"> > > > >generator="TimeSeq"/> >sequence-name="time()"/> > > > > > > > > > > > > > > > > > > E > > > > > > > > > > > > P > > > > > > > > > > > > > > > > > > > > > > > > > > target-entity="ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl"> > > >/> > > > > > > > And the database creation script is : > -- > -- Create Table ADDRESS > -- > Create table ADDRESS ( > ID VARCHAR(20) NOT NULL, > DISCRIMINANT CHARACTER(1)NOT NULL, > ADDRESS_NAME VARCHAR(35) NOT NULL, > EMAIL_DOMAIN VARCHAR(50) , > EMAIL_NAME VARCHAR(50) , > FIRST_NAME VARCHAR(35) , > LAST_NAME VARCHAR(35) , > STREET VARCHAR(35) , > CITY VARCHAR(35) , > ZIPVARCHAR(10) , > COUNTRYCHARACTER(2), > VERSIONTIMESTAMP > ) > ; > -- > -- Create Primary Key PRIMARY_KEY > -
[jira] Commented: (OPENJPA-171) EntityManager.getReference() returns an object of a wronc class
[ https://issues.apache.org/jira/browse/OPENJPA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480455 ] Abe White commented on OPENJPA-171: --- It would speed things up a lot if you attached a working test case demonstrating the problem. > EntityManager.getReference() returns an object of a wronc class > --- > > Key: OPENJPA-171 > URL: https://issues.apache.org/jira/browse/OPENJPA-171 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 0.9.6 >Reporter: Stefano Juri > > I have a simple class system : a PersonImpl owns a set of AbstractAddresses. > An AbstractAddress can be an EMailAddressImpl or a PostalAddressImpl. All > these objects extend AbstractBusinessObject. > When I call entityManager.getReference(PersonImpl.class, "1") I get the > EMailAddressImpl object with id "1" instead of a PersonImpl object. > If I get the object with a query (select p from PersonImpl p where p.id='1') > everything is ok. > My mapping file is : > http://java.sun.com/xml/ns/persistence/orm"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm > http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"; > version="1.0"> > class="ch.admin.bit.fw2.bm.AbstractBusinessObjectImpl"> > > > >generator="TimeSeq"/> >sequence-name="time()"/> > > > > > > > > > > > > > > > > > > E > > > > > > > > > > > > P > > > > > > > > > > > > > > > > > > > > > > > > > > target-entity="ch.admin.bit.fw2.demo.bm.address.AbstractAddressImpl"> > > >/> > > > > > > > And the database creation script is : > -- > -- Create Table ADDRESS > -- > Create table ADDRESS ( > ID VARCHAR(20) NOT NULL, > DISCRIMINANT CHARACTER(1)NOT NULL, > ADDRESS_NAME VARCHAR(35) NOT NULL, > EMAIL_DOMAIN VARCHAR(50) , > EMAIL_NAME VARCHAR(50) , > FIRST_NAME VARCHAR(35) , > LAST_NAME VARCHAR(35) , > STREET VARCHAR(35) , > CITY VARCHAR(35) , > ZIPVARCHAR(10) , > COUNTRYCHARACTER(2), > VERSIONTIMESTAMP > ) > ; > -- > -- Create Primary Key PRIMARY_KEY > -- > alter table ADDRESS > add constraint PERSON_KEY > Primary Key (ID); > -- > -- Create Table PERSON > -
[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: 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.
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] Assigned: (OPENJPA-46) true, false not case insensitive, gets null pointer exception
[ https://issues.apache.org/jira/browse/OPENJPA-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe White reassigned OPENJPA-46: Assignee: Patrick Linskey > true, false not case insensitive, gets null pointer exception > - > > Key: OPENJPA-46 > URL: https://issues.apache.org/jira/browse/OPENJPA-46 > Project: OpenJPA > Issue Type: Bug > Components: query > Environment: windows xp, derby, db2 >Reporter: George Hongell > Assigned To: Patrick Linskey >Priority: Minor > Fix For: 0.9.7 > > Attachments: failureEntities.jar > > > 140 - true,false should be case insensitive - gets npe > [ FAILED 140- bucket = fvtfull, query = select e from EmpBean e where > (e.isManager = True) : >EXPECTED( > TEST140; select e from EmpBean e where (e.isManager = True) > [( class com.dw.test.EmpBean empid=2 name=andrew salary=13.1 dept=210)] > [( class com.dw.test.EmpBean empid=1 name=david salary=12.1 dept=210)] > TEST140; 2 tuples ) >ACTUAL( > TEST140; select e from EmpBean e where (e.isManager = True) > e > > null > TEST140; 1 tuple) ] > at > org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:672) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:934) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746) > ... 23 more > <4|false|0.0.0> org.apache.openjpa.persistence.ArgumentException: null > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:755) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712) > at > org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512) > at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216) > at > org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254) > at > com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187) > at > com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536) > at > com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591) > at > com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at > junit.extensions.jfunc.TestletWrapper.runBare(TestletWrapper.java:116) > at > junit.extensions.jfunc.TestletWrapper$1.protect(TestletWrapper.java:106) > at junit.framework.TestResult.runProtected(Unknown Source) > at junit.extensions.jfunc.TestletWrapper.run(TestletWrapper.java:109) > at junit.framework.TestSuite.runTest(Unknown Source) > at junit.framework.TestSuite.run(Unknown Source) > at junit.extensions.jfunc.JFuncSuite.run(JFuncSuite.java:134) > at junit.extensions.jfunc.textui.JFuncRunner.doRun(JFuncRunner.java:76) > at junit.extensions.jfunc.textui.JFuncRunner.start(JFuncRunner.java:398) > at junit.extensions.jfunc.textui.JFuncRunner.main(JFuncRunner.java:218) > Caused by: java.lang.NullPointerException > at > org.apache.openjpa.jdbc.kernel.exps.PCPath.initialize(PCPath.java:362) > at > org.apache.openjpa.jdbc.kernel.exps.CompareEqualExpression.initialize(CompareEqualExpression.java:78) > at > org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.initialize(SelectConstructor.java:166) > at > org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.newSelect(SelectConstructor.java:115) > at > org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:69) > at > org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:324) > at > org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:165) > at > org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:672) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:934) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746) > ... 23 more > 141 same > TEST141; select e from EmpBean e where (e.isManager = fAlSe) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: @Dependent annotation vs cascade=ALL
First, dependent should be compared to cascade=REMOVE rather than (or in addition to) cascade=ALL. cascade=REMOVE means "when I remove this parent instance immediately cascade the remove operation to the referenced instance(s)". It's a very simple and naïve implementation and its behavior is mandated by the JPA spec. Dependent means "at the end of the transaction if the referenced instance(s) are no longer referenced by this parent and have not been assigned to any other parent, remove it/them". It's much smarter / more subtle. For example if you null a dependent relation but don't delete the parent, the referenced instance(s) will still be deleted at the end of the transaction, because they are no longer referenced by the parent (unless of course you assign them to some other parent in the same transaction). p.s. Note that dependent != db garbage collection. A dependent instance that is severed from its parent is deleted at the end of the transaction unless assigned to another instance in the same transaction -- we don't search the db to find out if any other parent not involved in the transaction references the dependent instance before deleting it.___ 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 List messages;
> I get the exception "Cannot order
> "net.spatula.tally_ho.model.MessageRoot.messages" on "objectId", because that
> field is not in the default fetch group. You can only order on fields that
> will be selected when the related object is loaded."
> I should certainly hope that the primary key of the related object is going
> to be selected when the object is loaded:
> @Id
> @Column(name = "object_id")
> private long objectId;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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: r512906 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/conf/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-project/src/doc/manual/
+public Object newInstance(String clsName, Class type,
Configuration conf,
+boolean fatal) {
+if (BrokerImpl.class.getName().equals(clsName)) {
+// This is not synchronized. If there are concurrent
invocations
+// while _templateBroker is null, we'll just end up
with extra
+// template brokers, which will get safely garbage
collected.
+if (_templateBroker == null)
+_templateBroker = (BrokerImpl) super.newInstance(
+clsName, type, conf, fatal);
+try {
+return _templateBroker.clone();
+} catch (CloneNotSupportedException e) {
+throw new InternalException(e);
+}
+} else {
+return super.newInstance(clsName, type, conf, fatal);
+}
+}
+}
Don't we want FinalizingBrokerImpls to clone too? And possible
subclasses? How about:
Cloneable _templateBroker = null;
boolean _templateTried = false;
...
if (!_templateTried) {
Object broker = super.newInstance(clsName, type, conf, false);
if (broker instanceof Cloneable)
_templateBroker = (Cloneable) broker;
_templateTried = true;
}
if (_templateBroker != null) {
return _templateBroker.clone...
}
return super.newInstance...
And for completeness we should set _templateTrid to false on set/
setString.
___
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-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476396 ] Abe White commented on OPENJPA-160: --- > The last time I looked at bytecode in depth (it's been a while) the field > declarations and method declarations were separate in both where they were > located in the class file and when they were executed. The names and types of your fields are defined in their own area of the class file. But code used to initialize instance field values inline is dumped into your constructor bytecode () before any constructor code you write. And code used to initialize static field values inline is dumped into your static initializer bytecode () before any static block code you write. > Reuse BrokerImpl objects > > > Key: OPENJPA-160 > URL: https://issues.apache.org/jira/browse/OPENJPA-160 > Project: OpenJPA > Issue Type: Sub-task >Reporter: Michael Dick > Assigned To: Patrick Linskey > Attachments: newprofile.jpg, openjpa-160-patch.txt, > openjpa-160-patch.txt, openjpa-160-patch.txt, perf2.jpg, perf3.jpg > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476359 ] Abe White commented on OPENJPA-160: --- FYI, at the bytecode level all field initializations take place in . A profiler would have to jump through a lot of hoops to *exclude* field initializations from overhead. This may have no bearing on the issue depending on where the bottleneck is actually occurring, but I thought I'd point it out. > Reuse BrokerImpl objects > > > Key: OPENJPA-160 > URL: https://issues.apache.org/jira/browse/OPENJPA-160 > Project: OpenJPA > Issue Type: Sub-task >Reporter: Michael Dick > Assigned To: Patrick Linskey > Attachments: newprofile.jpg, openjpa-160-patch.txt, > openjpa-160-patch.txt, perf2.jpg, perf3.jpg > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-94) Allow MappingTool and persistence.xml to support drop-create for database schema
[ https://issues.apache.org/jira/browse/OPENJPA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476352 ] Abe White commented on OPENJPA-94: -- Single quotes should work -- no need to use escaped double quotes. > Allow MappingTool and persistence.xml to support drop-create for database > schema > > > Key: OPENJPA-94 > URL: https://issues.apache.org/jira/browse/OPENJPA-94 > Project: OpenJPA > Issue Type: New Feature >Reporter: Shay Banon > Attachments: openjpa_94.zip > > > Currently, in the persistence context, one can define: > > Which causes OpenJPA to build the database schema based on the mapping > defined. Currently, there is no way to define it to drop tables if they > exists before creating the database schema. This is very useful for tests > that drop (if exists) and creates new tables for each test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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-161) Overuse of synchronization in AbstractBrokerFactory
[ https://issues.apache.org/jira/browse/OPENJPA-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475374 ] Abe White commented on OPENJPA-161: --- The code in question (just after the FIXME) is still guarding against the same transaction in concurrent threads. See the "someone beat us to it" putIfAbsent call. If we agree that transactions are thread bound -- as must be the case for the rest of the patch to be correct -- no one can "beat us to it", because we're the only thread with access to that transaction. > Overuse of synchronization in AbstractBrokerFactory > --- > > Key: OPENJPA-161 > URL: https://issues.apache.org/jira/browse/OPENJPA-161 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Patrick Linskey > Attachments: openjpa-161-patch.txt > > > AbstractBrokerFactory maintains a Map> that is > guarded by synchronized blocks. These synchronized blocks should be removed > if possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-161) Overuse of synchronization in AbstractBrokerFactory
[ https://issues.apache.org/jira/browse/OPENJPA-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475369 ] Abe White commented on OPENJPA-161: --- I think the FIXME part of the patch should be removed/simplified. The patch itself contains comments like the following: // we don't need to synchronize on brokers since one JTA transaction // can never be active on multiple concurrent threads. Yet the FIXME part explicitly guards against having the same transaction on concurrent threads. If guards like this are necessary, then they need to be consistent throughout the patch. But if we agree that the comment above is correct and the same transaction can't be active on multiple threads, then the FIXME part is useless. > Overuse of synchronization in AbstractBrokerFactory > --- > > Key: OPENJPA-161 > URL: https://issues.apache.org/jira/browse/OPENJPA-161 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Patrick Linskey > Attachments: openjpa-161-patch.txt > > > AbstractBrokerFactory maintains a Map> that is > guarded by synchronized blocks. These synchronized blocks should be removed > if possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475363 ] Abe White commented on OPENJPA-160: --- +1 to Craig's comments. > Reuse BrokerImpl objects > > > Key: OPENJPA-160 > URL: https://issues.apache.org/jira/browse/OPENJPA-160 > Project: OpenJPA > Issue Type: Sub-task >Reporter: Michael Dick > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475097 ] Abe White commented on OPENJPA-151: --- +1 on the patch from me. Fixes a problem and gets rid of unneeded code baggage at the same time. The re-enhancement isn't much of an issue to me -- we've required re-enhancement for various upgrades in the past and it's never been an issue with users, surprisingly enough. > Added field in enhanced vesrion of a class is not serialized. Hence the > change in detached+serialized instances is not registered under certain > conditions. > - > > Key: OPENJPA-151 > URL: https://issues.apache.org/jira/browse/OPENJPA-151 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar > Attachments: diff.txt > > > Enhancement adds a transient byte member field pcFlags to the class. This > field is originally used to optimize field access/mutation i.e. to > short-circuit mediation via StateManager under certain conditions (e.g. when > the field is part of the default fetch group). The field is transient, > perhaps, to maintain serialization compatibility. However, later changes such > as DetachedStateManager and improved attach strategies have made the usage of > these flag redundant. > This issue is a proposal to remove this field from the enhanced classes. The > proposed change is initiated by the following observation: > 1. class A has one-to-one relation to class B > 2. an instance a of A is related to b1 of B. b2 is another instance of B. > 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized > in a remote process as a*, b1* and b2*. > 4. in the remote process a* is associated with b2* > 5. a* is merged to the original process. > The change is not persisted when OpenJPA kernel is used with a JDO facade. It > works with JPA facade. > The initial analysis shows that the reason can be attributed to pcFlags and > the optimization in enhanced classes based on to its value. Because pcFlags > is not > serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of > a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the > detached version was carrying its own StateManager). While merging the > instance a* back, it was adjudged clean while actually it was dirty. In JPA > facade, the enhancement process did not add the extra optimization for setter > and so the cloned owner instance was righly marked dirty. > Please note that if this proposal is accepted by the community, it will > require reenhancement of existing domain classes. The change will impact the > internal StateManager and PersistenceCapable API (essentally removal of > certain methods than any other behavioural change). > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475093 ] Abe White commented on OPENJPA-151: --- > Why will this require re-enhancement? We'll no longer be setting pcFlags values -- the callbacks won't even exist to do so. Instances of classes that aren't re-enhanced will therefore never get their pcFlags set to LOAD_REQUIRED as needed to ensure their StateManagers are able to intercept all field access. > Added field in enhanced vesrion of a class is not serialized. Hence the > change in detached+serialized instances is not registered under certain > conditions. > - > > Key: OPENJPA-151 > URL: https://issues.apache.org/jira/browse/OPENJPA-151 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar > Attachments: diff.txt > > > Enhancement adds a transient byte member field pcFlags to the class. This > field is originally used to optimize field access/mutation i.e. to > short-circuit mediation via StateManager under certain conditions (e.g. when > the field is part of the default fetch group). The field is transient, > perhaps, to maintain serialization compatibility. However, later changes such > as DetachedStateManager and improved attach strategies have made the usage of > these flag redundant. > This issue is a proposal to remove this field from the enhanced classes. The > proposed change is initiated by the following observation: > 1. class A has one-to-one relation to class B > 2. an instance a of A is related to b1 of B. b2 is another instance of B. > 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized > in a remote process as a*, b1* and b2*. > 4. in the remote process a* is associated with b2* > 5. a* is merged to the original process. > The change is not persisted when OpenJPA kernel is used with a JDO facade. It > works with JPA facade. > The initial analysis shows that the reason can be attributed to pcFlags and > the optimization in enhanced classes based on to its value. Because pcFlags > is not > serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of > a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the > detached version was carrying its own StateManager). While merging the > instance a* back, it was adjudged clean while actually it was dirty. In JPA > facade, the enhancement process did not add the extra optimization for setter > and so the cloned owner instance was righly marked dirty. > Please note that if this proposal is accepted by the community, it will > require reenhancement of existing domain classes. The change will impact the > internal StateManager and PersistenceCapable API (essentally removal of > certain methods than any other behavioural change). > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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.
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.
[jira] Resolved: (OPENJPA-150) @Column in @AttributeOverride not honoring table attribute that maps to a secondary table in mappedsuperclass entity
[
https://issues.apache.org/jira/browse/OPENJPA-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-150.
---
Resolution: Fixed
Committed suggested changes (with very minor modifications) in revision 509674.
Thanks for the fix.
> @Column in @AttributeOverride not honoring table attribute that maps to a
> secondary table in mappedsuperclass entity
>
>
> Key: OPENJPA-150
> URL: https://issues.apache.org/jira/browse/OPENJPA-150
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, sql
> Environment: Any
>Reporter: Albert Lee
>
> I have the following scenario mapping entity to 2 tables:
> - a mapped super class that has a field
> - a subclass with a pk and a field.
> - trying to map all the fields (except the pk (id) ) to a secondary table
> (SEC_TABLE2MSC)
> - use @Column in the sub-class to override (name) to the secondary table
> - use @AttributeOverride to override the field (street) in the mapped super
> class to the secondary table.
> ===
> @MappedSuperclass
> public abstract class AnnMSCMultiTable
> implements IMultiTableEntity
> {
> // @Column(table="SEC_TABLE2MSC")
> private String street;
> public String getStreet() {
> return street;
> }
>public void setStreet(String street) {
> this.street = street;
> }
> }
> ===
> @Entity
> @SecondaryTable(name="SEC_TABLE2MSC", [EMAIL PROTECTED](name="id"))
> @AttributeOverrides(
> {
> @AttributeOverride(name="street", [EMAIL
> PROTECTED](name="street", table="SEC_TABLE2MSC")),
> })
> public class AnnMSCMultiTableEnt
> extends AnnMSCMultiTable
> {
> @Id
> private int id;
> @Column(name="name2", table="SEC_TABLE2MSC")
> private String name;
> }
> ===
> From examining JPA spec, there is no specific in the @Column and
> @AttributeOverride that this should not be allow. So I believe this is a
> valid scenario.
> Using the MappingTool, the attribute override does not map the street field
> to the SEC_TABLE2MSC as I would expect:
> CREATE TABLE AnnMSCMultiTableEnt (id INTEGER NOT NULL, street VARCHAR(254),
> PRIMARY KEY (id));
> CREATE TABLE SEC_TABLE2MSC (id INTEGER, name2 VARCHAR(254));
> CREATE INDEX I_SC_TMSC_ID ON SEC_TABLE2MSC (id);
> I experiment this a little bit and the only way I can map the street field to
> SEC_TABLE2MSC is
> to add the @Column against the "street" attribute in the super class. (the
> commented @Column in the example).
> The expected SQL are:
> CREATE TABLE AnnMSCMultiTableEnt (id INTEGER NOT NULL, PRIMARY KEY (id));
> CREATE TABLE SEC_TABLE2MSC (id INTEGER, street VARCHAR(254), name2
> VARCHAR(254));
> CREATE INDEX I_SC_TMSC_ID ON SEC_TABLE2MSC (id);
> I tried to create the tables manually using the expected layout, but the
> runtime still using the incorrect tables structure. I would suspect the
> MappingTool and the runtime are using the same mapping strategy.
> Albert Lee,
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-146) Entity enhancement fails while using EmbeddedId on a MappedSuperclass
[
https://issues.apache.org/jira/browse/OPENJPA-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-146.
---
Resolution: Fixed
Resolved with revision 509632. When copying OID superclass fields for mapping
in a subclass, revert the type of the field to PC. It will re-resolve to OID
when the copied field's metadata is resolved, and in the meantime it ensures
that the copied field resolution will use the same code path as non-copied
fields.
> Entity enhancement fails while using EmbeddedId on a MappedSuperclass
> -
>
> Key: OPENJPA-146
> URL: https://issues.apache.org/jira/browse/OPENJPA-146
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Environment: openjpa 0.9.6
>Reporter: Gokhan Ergul
> Attachments: test-case.zip
>
>
> Both buildtime and runtime class enhancement fail with the following error:
> ...
> 1339 TRACE [main] openjpa.Enhance - Enhancing type "class test.B".
> Exception in thread "main" <0|false|0.9.6-incubating>
> org.apache.openjpa.util.GeneralException: null
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:350)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3711)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3661)
> at org.apache.openjpa.enhance.PCEnhancer.main(PCEnhancer.java:3633)
> Caused by: java.lang.NullPointerException
> at
> org.apache.openjpa.enhance.PCEnhancer.enhanceObjectId(PCEnhancer.java:2745)
> at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:338)
> ... 3 more
> Test code as follows:
> test/A.java:
> --
> package test;
> import javax.persistence.*;
> import java.io.Serializable;
> @MappedSuperclass
> abstract public class A {
> @Embeddable
> public static class A_PK implements Serializable {
> @Basic
> protected int id1;
>
> @Basic
> protected String id2;
>
> public boolean equals (Object other) {
> return false;
> }
> public int hashCode () {
> return 0;
> }
> }
> @EmbeddedId
> protected A_PK pk;
> @Basic
> protected String val;
> }
> --
> test/B.java:
> --
> package test;
> import javax.persistence.Entity;
> @Entity
> public class B extends A {
> }
> --
> META-INF/persistence.xml:
> --
> http://java.sun.com/xml/ns/persistence";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm
> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
> version="1.0">
>
> test.A$A_PK
> test.A
> test.B
>
>
>
>
> value="jdbc:mysql://localhost:3306/oam?useServerPrepStmts=false"/>
> value="com.mysql.jdbc.Driver"/>
>
>
>
> --
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
