from:"Patrick Linskey \(JIRA\)"

[jira] Commented: (OPENJPA-235) SQL reordering to avoid non-nullable foreign key constraint violations

2007-05-25 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499200
]

Patrick Linskey commented on OPENJPA-235:
-

Hi,

Attach the patch to the JIRA and one of those of us with TCK access will run it
against the TCK.

SQL reordering to avoid non-nullable foreign key constraint violations
--

Key: OPENJPA-235
URL: https://issues.apache.org/jira/browse/OPENJPA-235
Project: OpenJPA
Issue Type: Improvement
Components: kernel
Reporter: Reece Garrett
Assigned To: Patrick Linskey
Fix For: 0.9.8

Attachments: openjpa-235-test.jar, sqlreorder.patch

OpenJPA does not do any SQL statement re-ordering in order to resolve foreign
key constraints. Instead, objects are always inserted in the order in which
the user persists the instances. 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.
This improvement re-orders SQL statements as follows:
1. First, all insert statements execute. Inserts which have foreign keys with
non-nullable constraints execute AFTER the foreign keys which they depend on
have been inserted since no deferred update is possible.
2. Next, all update statements execute. No reordering is necessary.
3. Finally, all delete statements execute. Like inserts, deletes execute in
an order which does not violate non-nullable foreign key constraints.
If a circular foreign key reference is found during the re-ordering process
then re-ordering halts and the remaining unordered statements are left as is.
There is nothing that can be done about the circular reference (other than
fixing the schema) and the resulting SQL statements will not succeed.
The net effect is that users do not need to worry about the persistence order
of their objects regardless of non-nullable foreign key constraints. The only
class modified was
org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager. I have included a
patch which includes my modifications to OperationOrderUpdateManager and test
cases. The test cases I have provided fail on the current trunk but pass with
my modifications. I have also verified that I did not break anything by using
maven to run all test cases with my modifications in place.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-242) JCache (JSR 107) support in the OpenJPA DataCache

2007-05-25 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499202
 ] 

Patrick Linskey commented on OPENJPA-242:
-

With a small amount of work, we could abstract away the needs of QueryCache and 
DataCache such that you only needed to implement one interface to add support 
for a new cache. I prefer taking that approach, because the amount of work 
needed would then be pretty trivial, and that would benefit all configurations.

 JCache (JSR 107) support in the OpenJPA DataCache
 -

 Key: OPENJPA-242
 URL: https://issues.apache.org/jira/browse/OPENJPA-242
 Project: OpenJPA
  Issue Type: New Feature
  Components: datacache
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Marc Prud'hommeaux
Priority: Minor

 JSR 107 (JCache: http://jcp.org/en/jsr/detail?id=107 ) support would enable 
 OpenJPA to integrate its data cache with supporting products in a transparent 
 way. This would allow us to support the popular EHCache 1.3 and other JSR 107 
 compliant caching layers.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-130) Streaming LOB support

2007-05-21 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497601
 ] 

Patrick Linskey commented on OPENJPA-130:
-

Ignacio Andreu will be working on this issue for the Google Summer of Code 
project. It would seem that JIRA only allows me to assign issues to committers, 
so I'm assigning it to myself to keep it out of the unassigned queue.

 Streaming LOB support
 -

 Key: OPENJPA-130
 URL: https://issues.apache.org/jira/browse/OPENJPA-130
 Project: OpenJPA
  Issue Type: New Feature
  Components: datacache, jdbc, jpa, kernel
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
 Fix For: 1.1.0


 BLOB and CLOB fields can only be mapped in their entirety in OpenJPA. It 
 would be nice to support fields of type java.io.InputStream (for BLOBs) and 
 java.io.Reader (for CLOBs).
 The usage pattern could look like so:
 @Entity
 public class Employee {
 ...
 private InputStream photoStream;
 public void setPhotoStream(InputStream in) {
 photoStream = in;
 }
 public InputStream getPhotoStream() {
 return photoStream;
 }
 }
 So, when the user wants to provide a stream, she will set the InputStream 
 field, and when the user wants to obtain a stream, she will use the field.
 The behavior of such an implementation would be a bit different than how 
 other fields work, in that if the user set the stream and then consumed it 
 within a single transaction, presumably no data would be written out to the 
 database at commit time. But that is the nature of streams.
 (FTR, I think that I stole this idea from an email Craig Russell sent out 
 years ago.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-243) IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process

2007-05-21 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497624
]

Patrick Linskey commented on OPENJPA-243:
-

The plugin as of r540340 integrates the OpenJPA enhancer with IntelliJ IDEA's
build process.

It requires IntelliJ IDEA 7.0M1 or more recent. It also requires a recent build
of OpenJPA, due to classloader issues in the PCEnhancer. The plugin does not
currently validate that it has a satisfactory OpenJPA version.

The plugin does not bundle OpenJPA jars inside it; this is intentional. In
order to use the plugin, you must have OpenJPA in your module's classpath
(which is already a requirement for running any tests with OpenJPA). The plugin
will pick up the OpenJPA version in your module and use it. If OpenJPA is not
available in the classpath, the plugin should gracefully short-circuit.

The plugin will run the enhancer on all persistent types (@Entity,
@MappedSuperclass, @Embeddable) in certain of the persistence units in the
module being compiled. It will only run on persistence units that either do not
define a persistence provider or specify the OpenJPA persistence provider.

IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process
-

Key: OPENJPA-243
URL: https://issues.apache.org/jira/browse/OPENJPA-243
Project: OpenJPA
Issue Type: New Feature
Components: kernel, third-party
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Environment: IntelliJ IDEA 7.0M1, OpenJPA 0.9.8-SNAPSHOT
Reporter: Patrick Linskey
Assigned To: Patrick Linskey
Fix For: 0.9.8

Attachments: OpenJPA-0.1.zip

It would be nice if OpenJPA's enhancer could be automatically invoked when
compiling persistent types in IntelliJ IDEA.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-243) IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process

2007-05-21 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497626
 ] 

Patrick Linskey commented on OPENJPA-243:
-

One missing instruction from the previous comment: the 0.1 plugin piggy-backs 
on top of the IntelliJ IDEA 7 JPA facet. So, you must have your module set up 
to use a JPA facet in order for the OpenJPA plugin to run on the classes in the 
module.

 IntelliJ IDEA plugin to integrate OpenJPA enhancer into build process
 -

 Key: OPENJPA-243
 URL: https://issues.apache.org/jira/browse/OPENJPA-243
 Project: OpenJPA
  Issue Type: New Feature
  Components: kernel, third-party
Affects Versions: 0.9.0, 0.9.6, 0.9.7
 Environment: IntelliJ IDEA 7.0M1, OpenJPA 0.9.8-SNAPSHOT
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OpenJPA-0.1.zip


 It would be nice if OpenJPA's enhancer could be automatically invoked when 
 compiling persistent types in IntelliJ IDEA.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-194) Correct suffixes of build artifacts to elimiate '-all' and '-project'

2007-05-06 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493962
 ] 

Patrick Linskey commented on OPENJPA-194:
-

I think that it's more common to see things like 'openjpa-0.9.7-source.zip' 
than 'openjpa-source-0.9.7.zip', isn't it?

 Correct suffixes of build artifacts to elimiate '-all' and '-project'
 -

 Key: OPENJPA-194
 URL: https://issues.apache.org/jira/browse/OPENJPA-194
 Project: OpenJPA
  Issue Type: Sub-task
  Components: build / infrastructure
Affects Versions: 0.9.0, 0.9.6
Reporter: Marc Prud'hommeaux
 Assigned To: Marc Prud'hommeaux
Priority: Minor
 Fix For: 0.9.8

 Attachments: OpenJPA-194-1.patch.txt, OPENJPA-194.patch


 The aggregate jar that is built with OpenJPA is currently named 
 openjpa-all-0.9.7-VERSION.jar. It would be nice to change this to be just 
 openjpa-0.9.7-VERSION.jar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (OPENJPA-235) SQL reordering to avoid non-nullable foreign key constraint violations

2007-05-04 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Patrick Linskey reassigned OPENJPA-235:
---

Assignee: Patrick Linskey

SQL reordering to avoid non-nullable foreign key constraint violations
--

Key: OPENJPA-235
URL: https://issues.apache.org/jira/browse/OPENJPA-235
Project: OpenJPA
Issue Type: Improvement
Components: kernel
Reporter: Reece Garrett
Assigned To: Patrick Linskey
Fix For: 0.9.8

Attachments: sqlreorder.patch

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-235) SQL reordering to avoid non-nullable foreign key constraint violations

2007-05-04 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Patrick Linskey resolved OPENJPA-235.
-

Resolution: Fixed

SQL reordering to avoid non-nullable foreign key constraint violations
--

Key: OPENJPA-235
URL: https://issues.apache.org/jira/browse/OPENJPA-235
Project: OpenJPA
Issue Type: Improvement
Components: kernel
Reporter: Reece Garrett
Assigned To: Patrick Linskey
Fix For: 0.9.8

Attachments: sqlreorder.patch

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-226) Change openjpa.DetachState 'fgs' setting to 'fetch-groups'

2007-04-27 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-226.
-

Resolution: Fixed

 Change openjpa.DetachState 'fgs' setting to 'fetch-groups'
 --

 Key: OPENJPA-226
 URL: https://issues.apache.org/jira/browse/OPENJPA-226
 Project: OpenJPA
  Issue Type: Improvement
  Components: docs, kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
Priority: Minor
 Fix For: 0.9.8

 Attachments: OPENJPA-226.patch


 The configuration setting openjpa.DetachState: fgs is a bit obtuse. It 
 would be nicer if this were openjpa.DetachState: fetch-groups.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider

2007-04-27 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-230:


Attachment: OPENJPA-230.patch

It'd be nice to not have to synchronize. What about if we made the threads 
non-daemon, and just call setRunning(false) instead? See attached 
(completely-untested) patch.

Also, I think that that boolean should be volatile to ensure thread-safety.

 Handle guaranteed delivery of Data Cache events on normal JVM termination 
 using TCPRemoteCommitProvider
 ---

 Key: OPENJPA-230
 URL: https://issues.apache.org/jira/browse/OPENJPA-230
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Vikram Bhatia
Priority: Minor
 Attachments: OPENJPA-230.patch, soln.diff


 When an application is commiting a transaction and then terminating, often 
 not all events regarding Data Cache are dispatched by the 
 TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting 
 until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. 
 In this way some cache synchronization is lost.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-230) Handle guaranteed delivery of Data Cache events on normal JVM termination using TCPRemoteCommitProvider

2007-04-27 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-230:


Attachment: OPENJPA-230.patch

Good point -- _keepRunning is a bit too abrupt.

How does this work?

 Handle guaranteed delivery of Data Cache events on normal JVM termination 
 using TCPRemoteCommitProvider
 ---

 Key: OPENJPA-230
 URL: https://issues.apache.org/jira/browse/OPENJPA-230
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Vikram Bhatia
Priority: Minor
 Attachments: OPENJPA-230.patch, OPENJPA-230.patch, reproducer.zip, 
 soln.diff


 When an application is commiting a transaction and then terminating, often 
 not all events regarding Data Cache are dispatched by the 
 TCPRemoteCommitProvider. It seems that the JVM on termination is not waiting 
 until TCPRemoteCommitProvider has dispatched all events regarding Data Cache. 
 In this way some cache synchronization is lost.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-229) OpenJPA fails with MappedSuperclasses and Entities with the same short names

2007-04-26 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-229.
-

Resolution: Fixed

 OpenJPA fails with MappedSuperclasses and Entities with the same short names
 

 Key: OPENJPA-229
 URL: https://issues.apache.org/jira/browse/OPENJPA-229
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
 Environment: WindowsXP SP2 full updates 2007-04-25, Informix 10, Java 
 1.6.0
Reporter: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OPENJPA-229.patch


 When running the test case from OPENJPA-228 (after a few modifications to get 
 it working), I get the exception included below. If I change the 'Article' 
 mapped superclass to be named 'ArticleBase', things work.
 It looks like this is happening because multiple classes are registering for 
 the same alias. We should change the enhancer to not register aliases for 
 mapped superclasses.
 Exception in thread main 0.0.0 nonfatal user error 
 org.apache.openjpa.persistence.ArgumentException: 0
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:517)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
   at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)
   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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
 Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
   at org.apache.openjpa.jdbc.kernel.exps.PCPath.appendTo(PCPath.java:636)
   at 
 org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:62)
   at 
 org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:58)
   at 
 org.apache.openjpa.jdbc.sql.DBDictionary.appendCast(DBDictionary.java:2486)
   at 
 org.apache.openjpa.jdbc.sql.DBDictionary.comparison(DBDictionary.java:2443)
   at 
 org.apache.openjpa.jdbc.kernel.exps.CompareExpression.appendTo(CompareExpression.java:75)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.buildWhere(SelectConstructor.java:238)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:79)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:330)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:169)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:677)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:985)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
   ... 11 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-228) Could not locate metadata for the class using alias

2007-04-25 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491537
 ] 

Patrick Linskey commented on OPENJPA-228:
-

I haven't run it yet, but a couple of things look suspicious:

1. You've got multiple @Entity classes called Article. The spec says that if an 
entity name is not specified, the name defaults to the short name of the entity.

2. Given that you're listing your persistent types, you should also list the 
generated classes as well. I think that this shouldn't be causing this problem, 
but it feels like it's best practice to list all or none of the classes.

 Could not locate metadata for the class using alias
 ---

 Key: OPENJPA-228
 URL: https://issues.apache.org/jira/browse/OPENJPA-228
 Project: OpenJPA
  Issue Type: Bug
Affects Versions: 0.9.6, 0.9.7
 Environment: WindowsXP SP2 full updates 2007-04-25, Informix 10, Java 
 1.6.0
Reporter: Tom
 Attachments: bm.zip


 This: 
   List lArticles = lEntityManager.createQuery(select a from 
 Article a where a.iArticlenr  103).getResultList(); // where articlenr  103
 Results in:
 Exception in thread main 0.9.7-incubating fatal user error 
 org.apache.openjpa.persistence.ArgumentException: Could not locate metadata 
 for the class using alias Article. Registered alias mappings: 
 {Article=null}
   at 
 org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:348)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:167)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:145)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:214)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:184)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:177)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBuilder.java:64)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1671)
   at 
 org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:55)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:148)
   at 
 org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:649)
   at 
 org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:630)
   at 
 org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:596)
   at 
 org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:658)
   at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1483)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:123)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:219)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
   at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OPENJPA-228) Could not locate metadata for the class using alias

2007-04-25 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey closed OPENJPA-228.
---

Resolution: Fixed

Persistent classes were not enhanced prior to use. Added a better error message 
in r532273.

 Could not locate metadata for the class using alias
 ---

 Key: OPENJPA-228
 URL: https://issues.apache.org/jira/browse/OPENJPA-228
 Project: OpenJPA
  Issue Type: Bug
Affects Versions: 0.9.6, 0.9.7
 Environment: WindowsXP SP2 full updates 2007-04-25, Informix 10, Java 
 1.6.0
Reporter: Tom
 Attachments: bm.zip


 This: 
   List lArticles = lEntityManager.createQuery(select a from 
 Article a where a.iArticlenr  103).getResultList(); // where articlenr  103
 Results in:
 Exception in thread main 0.9.7-incubating fatal user error 
 org.apache.openjpa.persistence.ArgumentException: Could not locate metadata 
 for the class using alias Article. Registered alias mappings: 
 {Article=null}
   at 
 org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:348)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:167)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:145)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:214)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:184)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:177)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBuilder.java:64)
   at 
 org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1671)
   at 
 org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:55)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:148)
   at 
 org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:649)
   at 
 org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:630)
   at 
 org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:596)
   at 
 org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:658)
   at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1483)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:123)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:219)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
   at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-229) OpenJPA fails with MappedSuperclasses and Entities with the same short names

2007-04-25 Thread Patrick Linskey (JIRA)

OpenJPA fails with MappedSuperclasses and Entities with the same short names


 Key: OPENJPA-229
 URL: https://issues.apache.org/jira/browse/OPENJPA-229
 Project: OpenJPA
  Issue Type: Bug
Affects Versions: 0.9.6, 0.9.7
 Environment: WindowsXP SP2 full updates 2007-04-25, Informix 10, Java 
1.6.0
Reporter: Tom


This: 

List lArticles = lEntityManager.createQuery(select a from 
Article a where a.iArticlenr  103).getResultList(); // where articlenr  103

Results in:

Exception in thread main 0.9.7-incubating fatal user error 
org.apache.openjpa.persistence.ArgumentException: Could not locate metadata for 
the class using alias Article. Registered alias mappings: {Article=null}
at 
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:348)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:167)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:145)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:214)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:184)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:177)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBuilder.java:64)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1671)
at 
org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:55)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:148)
at 
org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:649)
at 
org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:630)
at 
org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:596)
at 
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:658)
at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1483)
at 
org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:123)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:219)
at 
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-229) OpenJPA fails with MappedSuperclasses and Entities with the same short names

2007-04-25 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-229:


  Component/s: kernel
Fix Version/s: 0.9.8
  Description: 
When running the test case from OPENJPA-228 (after a few modifications to get 
it working), I get the exception included below. If I change the 'Article' 
mapped superclass to be named 'ArticleBase', things work.

It looks like this is happening because multiple classes are registering for 
the same alias. We should change the enhancer to not register aliases for 
mapped superclasses.

Exception in thread main 0.0.0 nonfatal user error 
org.apache.openjpa.persistence.ArgumentException: 0
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
at 
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:517)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
at 
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at org.apache.openjpa.jdbc.kernel.exps.PCPath.appendTo(PCPath.java:636)
at 
org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:62)
at 
org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:58)
at 
org.apache.openjpa.jdbc.sql.DBDictionary.appendCast(DBDictionary.java:2486)
at 
org.apache.openjpa.jdbc.sql.DBDictionary.comparison(DBDictionary.java:2443)
at 
org.apache.openjpa.jdbc.kernel.exps.CompareExpression.appendTo(CompareExpression.java:75)
at 
org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.buildWhere(SelectConstructor.java:238)
at 
org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:79)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:330)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:169)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:677)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:985)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
... 11 more


  was:
This: 

List lArticles = lEntityManager.createQuery(select a from 
Article a where a.iArticlenr  103).getResultList(); // where articlenr  103

Results in:

Exception in thread main 0.9.7-incubating fatal user error 
org.apache.openjpa.persistence.ArgumentException: Could not locate metadata for 
the class using alias Article. Registered alias mappings: {Article=null}
at 
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:348)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:167)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:145)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:214)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:184)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:177)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$500(JPQLExpressionBuilder.java:64)
at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1671)
at 
org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:55)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:148)
at 
org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:649)
at 
org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:630)
at 
org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:596)
at 
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:658)
at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1483)
at

[jira] Updated: (OPENJPA-229) OpenJPA fails with MappedSuperclasses and Entities with the same short names

2007-04-25 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-229:


Attachment: OPENJPA-229.patch

This fixes the problem by changing the enhancer to not register aliases for 
types that are not mapped, as determined by a call to ClassMetaData.isMapped(). 
Thoughts?

 OpenJPA fails with MappedSuperclasses and Entities with the same short names
 

 Key: OPENJPA-229
 URL: https://issues.apache.org/jira/browse/OPENJPA-229
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
 Environment: WindowsXP SP2 full updates 2007-04-25, Informix 10, Java 
 1.6.0
Reporter: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OPENJPA-229.patch


 When running the test case from OPENJPA-228 (after a few modifications to get 
 it working), I get the exception included below. If I change the 'Article' 
 mapped superclass to be named 'ArticleBase', things work.
 It looks like this is happening because multiple classes are registering for 
 the same alias. We should change the enhancer to not register aliases for 
 mapped superclasses.
 Exception in thread main 0.0.0 nonfatal user error 
 org.apache.openjpa.persistence.ArgumentException: 0
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:517)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
   at nl.reinders.bm.BMTestOpenJPA.main(BMTestOpenJPA.java:41)
   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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
 Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
   at org.apache.openjpa.jdbc.kernel.exps.PCPath.appendTo(PCPath.java:636)
   at 
 org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:62)
   at 
 org.apache.openjpa.jdbc.kernel.exps.FilterValueImpl.appendTo(FilterValueImpl.java:58)
   at 
 org.apache.openjpa.jdbc.sql.DBDictionary.appendCast(DBDictionary.java:2486)
   at 
 org.apache.openjpa.jdbc.sql.DBDictionary.comparison(DBDictionary.java:2443)
   at 
 org.apache.openjpa.jdbc.kernel.exps.CompareExpression.appendTo(CompareExpression.java:75)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.buildWhere(SelectConstructor.java:238)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:79)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:330)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:169)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:677)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:985)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
   ... 11 more

-- 
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

2007-04-24 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491316
 ] 

Patrick Linskey commented on OPENJPA-219:
-

 another way to approach this would be not to cache at all,
 and just iterate over getDeclaredFields/Methods() looking for a match

Good point. That would certainly be a better approach. It looks like 
Class.getDeclaredFields() will be a bit slower, since more memory copying 
happens (the array is copied before being returned -- bummer that those APIs 
don't use collections), but that might not be noticeable in the benchmark.

 Reflection: negative caching would be beneficial in redeployment scenarios
 --

 Key: OPENJPA-219
 URL: https://issues.apache.org/jira/browse/OPENJPA-219
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OPENJPA-219.patch


 In a variety of situations, OpenJPA searches class hierarchies for fields. 
 These searches invoke Class.getDeclaredField() in order to find non-public 
 fields. This method throws an exception when it fails to find the specified 
 field, and the exception creation is, as ever, slow.
 It would be useful to create a static (and thus per-classloader) 
 MapWeakReferenceClass,CollectionString of fields known not to be 
 available in a given class.
 It may also be beneficial to maintain a cache of which fields *are* present 
 in a given class, but this issue is being filed as a result of a demonstrated 
 performance hit during deployment due to the lack of a negative cache. If we 
 obtain quantitative data indicating that a positive cache would be useful, we 
 might want to implement such a thing at that time.
 Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: 
 domainName
  at 
 java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown
  Source)
  at 
 org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101)
  at 
 org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object;
 (ApplicationIds.java:89)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios

2007-04-24 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey reassigned OPENJPA-219:
---

Assignee: Patrick Linskey

 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
 Assigned To: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OPENJPA-219-NoLeak.patch, OPENJPA-219.patch


 In a variety of situations, OpenJPA searches class hierarchies for fields. 
 These searches invoke Class.getDeclaredField() in order to find non-public 
 fields. This method throws an exception when it fails to find the specified 
 field, and the exception creation is, as ever, slow.
 It would be useful to create a static (and thus per-classloader) 
 MapWeakReferenceClass,CollectionString of fields known not to be 
 available in a given class.
 It may also be beneficial to maintain a cache of which fields *are* present 
 in a given class, but this issue is being filed as a result of a demonstrated 
 performance hit during deployment due to the lack of a negative cache. If we 
 obtain quantitative data indicating that a positive cache would be useful, we 
 might want to implement such a thing at that time.
 Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: 
 domainName
  at 
 java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown
  Source)
  at 
 org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101)
  at 
 org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object;
 (ApplicationIds.java:89)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios

2007-04-24 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491458
 ] 

Patrick Linskey commented on OPENJPA-219:
-

How does this compare to the leaky-patch version?

 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-NoLeak.patch, OPENJPA-219.patch


 In a variety of situations, OpenJPA searches class hierarchies for fields. 
 These searches invoke Class.getDeclaredField() in order to find non-public 
 fields. This method throws an exception when it fails to find the specified 
 field, and the exception creation is, as ever, slow.
 It would be useful to create a static (and thus per-classloader) 
 MapWeakReferenceClass,CollectionString of fields known not to be 
 available in a given class.
 It may also be beneficial to maintain a cache of which fields *are* present 
 in a given class, but this issue is being filed as a result of a demonstrated 
 performance hit during deployment due to the lack of a negative cache. If we 
 obtain quantitative data indicating that a positive cache would be useful, we 
 might want to implement such a thing at that time.
 Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: 
 domainName
  at 
 java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown
  Source)
  at 
 org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101)
  at 
 org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object;
 (ApplicationIds.java:89)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-226) Change openjpa.DetachState 'fgs' setting to 'fetch-groups'

2007-04-24 Thread Patrick Linskey (JIRA)

Change openjpa.DetachState 'fgs' setting to 'fetch-groups'
--

 Key: OPENJPA-226
 URL: https://issues.apache.org/jira/browse/OPENJPA-226
 Project: OpenJPA
  Issue Type: Improvement
  Components: docs, kernel
Affects Versions: 0.9.6, 0.9.0, 0.9.7
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
Priority: Minor
 Fix For: 0.9.8


The configuration setting openjpa.DetachState: fgs is a bit obtuse. It would 
be nicer if this were openjpa.DetachState: fetch-groups.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-226) Change openjpa.DetachState 'fgs' setting to 'fetch-groups'

2007-04-24 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-226:


Attachment: OPENJPA-226.patch

Here's a patch that does this. Thoughts?

 Change openjpa.DetachState 'fgs' setting to 'fetch-groups'
 --

 Key: OPENJPA-226
 URL: https://issues.apache.org/jira/browse/OPENJPA-226
 Project: OpenJPA
  Issue Type: Improvement
  Components: docs, kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey
Priority: Minor
 Fix For: 0.9.8

 Attachments: OPENJPA-226.patch


 The configuration setting openjpa.DetachState: fgs is a bit obtuse. It 
 would be nicer if this were openjpa.DetachState: fetch-groups.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.

2007-04-18 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489761
 ] 

Patrick Linskey commented on OPENJPA-221:
-

What happens if, without your patch, you set the DBDictionary 
'StoreCharsAsNumbers' property to false?

persistence
  persistence-unit name=...
...
properties
  property name=openjpa.jdbc.DBDictionary 
value=StoreCharsAsNumbers=false/
/properties
  /persistence-unit
/persistence

 DerbyDictionary doesn't describe a working mapping for char fields.
 ---

 Key: OPENJPA-221
 URL: https://issues.apache.org/jira/browse/OPENJPA-221
 Project: OpenJPA
  Issue Type: Bug
  Components: sql
Affects Versions: 0.9.7
Reporter: David Jencks
 Attachments: OPENJPA-221.patch


 If a class has a char field mapped to CHAR or CHAR(1) in a derby database, 
 the derby dictionary sets up a mapping to an integer column which doesn't 
 work.  openjpa tries to store e.g. the string 97 for the char 'a' which 
 results in a truncation error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-221) DerbyDictionary doesn't describe a working mapping for char fields.

2007-04-18 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489820
]

Patrick Linskey commented on OPENJPA-221:
-

It's not surprising that the OpenJPA tests storeCharsAsNumbers to be true.

I was referring to your test environment. Rather than changing the default
behavior of the DerbyDictionary in code, it seems more appropriate to use the
built-in configuration option to toggle it for your application.

It sounds like you're reluctant to do this since you don't have easy access to
modify the persistence.xml files. Happily, if you drop a file conforming to the
persistence.xml schema into META-INF/openjpa.xml, OpenJPA will load the
settings in the properties in the first PU in that file as defaults for all PUs.

What happens if you put the DBDictionary stanza that I mentioned earlier into a
META-INF/openjpa.xml file?

DerbyDictionary doesn't describe a working mapping for char fields.
---

Key: OPENJPA-221
URL: https://issues.apache.org/jira/browse/OPENJPA-221
Project: OpenJPA
Issue Type: Bug
Components: sql
Affects Versions: 0.9.7
Reporter: David Jencks
Attachments: OPENJPA-221.patch

If a class has a char field mapped to CHAR or CHAR(1) in a derby database,
the derby dictionary sets up a mapping to an integer column which doesn't
work. openjpa tries to store e.g. the string 97 for the char 'a' which
results in a truncation error.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios

2007-04-17 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-219:


Attachment: OPENJPA-219.patch

I think that this patch should fix the issue, but haven't tested it yet. I only 
replaced the getDeclaredField() cases that were iterating through superclasses.

 Reflection: negative caching would be beneficial in redeployment scenarios
 --

 Key: OPENJPA-219
 URL: https://issues.apache.org/jira/browse/OPENJPA-219
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Patrick Linskey
 Fix For: 0.9.8

 Attachments: OPENJPA-219.patch


 In a variety of situations, OpenJPA searches class hierarchies for fields. 
 These searches invoke Class.getDeclaredField() in order to find non-public 
 fields. This method throws an exception when it fails to find the specified 
 field, and the exception creation is, as ever, slow.
 It would be useful to create a static (and thus per-classloader) 
 MapWeakReferenceClass,CollectionString of fields known not to be 
 available in a given class.
 It may also be beneficial to maintain a cache of which fields *are* present 
 in a given class, but this issue is being filed as a result of a demonstrated 
 performance hit during deployment due to the lack of a negative cache. If we 
 obtain quantitative data indicating that a positive cache would be useful, we 
 might want to implement such a thing at that time.
 Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: 
 domainName
  at 
 java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown
  Source)
  at 
 org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101)
  at 
 org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object;
 (ApplicationIds.java:89)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-17 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489558
]

Patrick Linskey commented on OPENJPA-182:
-

Some comments:

1. I don't think that we should be doing work on resolved issues. So, this
should be re-opened, or (preferably) a new issue should be opened for this new
bug.

2. The patch you attached does not use OpenJPA-style formatting. We don't have
a style guide spelled out as well as we probably should, but we always put
spaces after commas, we indent 4 spaces on continuation lines, and we put a
space between an 'if' and the open paren.

3. It's a shame to have to do all this code duplication between DBDictionary
and DB2Dictionary. To what extent can we refactor DBDictionary's methods to
make this concept work out better for DB2Dictionary?

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

Key: OPENJPA-182
URL: https://issues.apache.org/jira/browse/OPENJPA-182
Project: OpenJPA
Issue Type: New Feature
Components: jdbc
Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
Reporter: David Wisneski
Fix For: 0.9.7

Attachments: JIRA182-subselect.patch, OPENJPA-182.patch,
OPENJPA-182.patch, openJPA182.patch, openjpa182TestCase.jar

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-212) Constructor expression permits no other expressions in SELECT clause

2007-04-10 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487948
 ] 

Patrick Linskey commented on OPENJPA-212:
-

You don't have a test case handy for this by any chance, do you?

 Constructor expression permits no other expressions in SELECT clause
 

 Key: OPENJPA-212
 URL: https://issues.apache.org/jira/browse/OPENJPA-212
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Affects Versions: 0.9.7
Reporter: Jacek Laskowski

 It seems that it's impossible to run a query with constructor expression 
 beside other expressions in SELECT clause. Take a look at the following test 
 that finishes with ClassCastException when the first element of resultQuery 
 is returned (the 2nd line of the snippet).  Am I doing something plain wrong?
 It doesn't work with Hibernate EntityManager 3.3.1, either yet TopLink 
 Essentials 2.0 BUILD 40 runs fine.
   Query query = em.createQuery(SELECT NEW 
 pl.jaceklaskowski.jpa.PewnaKlasa(p.nazwa, o.imie, o.nazwisko, o.numer), o, 
 p.nazwa FROM Projekt p JOIN p.chair o);
   ListObject[] resultQuery = query.getResultList();
   final Object[] firstElementInQueryResult = resultQuery.get(0);
   assert firstElementInQueryResult.length == 3;
   final Object firstElement = resultQuery.get(0)[0];
   assert firstElement instanceof PewnaKlasa;
   final Object secondElement = resultQuery.get(0)[1];
   assert secondElement instanceof Osoba;
   final Object thirdElement = resultQuery.get(0)[2];
   assert thirdElement instanceof String;
 The exception is as follows (the line number is different though as the test 
 above is incomplete - no class, imports and alike are shown):
 java.lang.ClassCastException: pl.jaceklaskowski.jpa.PewnaKlasa
 at 
 pl.jaceklaskowski.jpa.OpenJPATest.testConstructorExpr(OpenJPATest.java:19)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-91) java.lang.VerifyError on websphere after application reload

2007-04-10 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487950
 ] 

Patrick Linskey commented on OPENJPA-91:


 Hi, Patrick, what kind of DB2 driver info we should put into the config? 
 DB2 connection pool driver class name?

It depends on how you want the configuration to be structured. If you already 
have a data source defined within the application server, then you should 
provide its JNDI name. Otherwise, you can either provide direct connection URL 
/ driver name / user credential information to OpenJPA, or provide a pooling 
data source configuration.

 java.lang.VerifyError on websphere after application reload
 ---

 Key: OPENJPA-91
 URL: https://issues.apache.org/jira/browse/OPENJPA-91
 Project: OpenJPA
  Issue Type: Bug
 Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in 
 Rational Developer 7 ( Websphere 6.1 test environment ) connected to Oracle 
 9.2 database.
 OS: WinXP SP2
Reporter: Anders Monrad
Priority: Minor
 Fix For: 0.9.8


 Hi ..
 Not sure if this is a bug or just the way websphere reacts to openjpa. 
 I have a small test program using OpenJPA against an Oracle database. I am 
 running this program in the Websphere 6.1 test environment included with 
 Rational Developer 7. This is all working just fine. But when I make changes 
 to some ressource in the application, the chagnes are automatically published 
 to the test environment and the app is restarted. After this I get the 
 Exception below, whenever I try to access an EntityManager. 
 If I restart the entire server, the app is running fine again. So I guess 
 this is related to restarting the application.
 Caused by: java.lang.VerifyError: class loading constraint violated (class: 
 org/apache/openjpa/kernel/BrokerImpl method: 
 newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;)
  at pc: 0
   at java.lang.J9VMInternals.verifyImpl(Native Method)
   at java.lang.J9VMInternals.verify(J9VMInternals.java:59)
   at java.lang.J9VMInternals.initialize(J9VMInternals.java:120)
   at java.lang.Class.forNameImpl(Native Method)
   at java.lang.Class.forName(Class.java:131)
   at 
 org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65)
   at 
 org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:182)
   at 
 org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.init(JDBCConfigurationImpl.java:110)
   at 
 org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.init(JDBCConfigurationImpl.java:100)
   at 
 org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.init(JDBCConfigurationImpl.java:91)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newInstance(JDBCBrokerFactory.java:55)
   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 org.apache.openjpa.kernel.Bootstrap.invokeFactory(Bootstrap.java:117)
   at 
 org.apache.openjpa.kernel.Bootstrap.newBrokerFactory(Bootstrap.java:57)
   at 
 org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:70)
   at 
 org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:78)
   at 
 javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
   at 
 javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60)
   at 
 util.EntityManagerFactoryHelper.getEntityManagerFactory(EntityManagerFactoryHelper.java:22)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-211) CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 0.96/0.97

2007-04-09 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487650
 ] 

Patrick Linskey commented on OPENJPA-211:
-

Provided that meth is a static method, this method should run with no problem.

The code here is bootstrapping code to create new BrokerFactories; one 
(woefully-underdocumented) part of the BrokerFactory contract is that 
implementations must have static newInstance() and getInstance() methods.

 CLONE -java.lang.VerifyError on websphere 6.1 with Spring 2.0.3 and OpenJpa 
 0.96/0.97
 -

 Key: OPENJPA-211
 URL: https://issues.apache.org/jira/browse/OPENJPA-211
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Affects Versions: 0.9.6
 Environment: Using OpenJPA (openjpa-all-0.9.6-incubating.jar) in 
 Rational Developer 7 ( Websphere 6.1 test environment ) connected to DB2 V9.1.
 OS: WinXP SP2
Reporter: david zhang
Priority: Blocker
 Fix For: 0.9.8

 Attachments: applicationContext.xml, mytestdata.jar, persistence.xml


 Hi, if I use the OpenJPA shipped with Spring 2.0.3, I got the following error 
 when start application:
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'entityManagerFactory' defined in ServletContext resource 
 [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested 
 exception is java.lang.VerifyError: class loading constraint violated (class: 
 org/apache/openjpa/kernel/BrokerImpl method: 
 newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;)
  at pc: 0
 Caused by: 
 java.lang.VerifyError: class loading constraint violated (class: 
 org/apache/openjpa/kernel/BrokerImpl method: 
 newQueryImpl(Ljava/lang/String;Lorg/apache/openjpa/kernel/StoreQuery;)Lorg/apache/openjpa/kernel/QueryImpl;)
  at pc: 0
   at java.lang.J9VMInternals.verifyImpl(Native Method)
   at java.lang.J9VMInternals.verify(J9VMInternals.java:59)
   at java.lang.J9VMInternals.initialize(J9VMInternals.java:120)
   at java.lang.Class.forNameImpl(Native Method)
   at java.lang.Class.forName(Class.java:131)
   at 
 org.apache.openjpa.conf.OpenJPAConfigurationImpl.class$(OpenJPAConfigurationImpl.java:65)
   at 
 org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:182)
   at 
 org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:154)
   at 
 org.apache.openjpa.conf.OpenJPAConfigurationImpl.init(OpenJPAConfigurationImpl.java:145)
   at 
 org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:114)
   at 
 org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.init(PersistenceProviderImpl.java:106)
   at 
 org.apache.openjpa.persistence.PersistenceProviderImpl.createContainerEntityManagerFactory(PersistenceProviderImpl.java:92)
   at 
 org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:214)
   at 
 org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:251)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1143)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1110)
   at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:431)
   at 
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:254)
   at 
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:144)
   at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:251)
   at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:163)
   at 
 org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:244)
   at 
 org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:233)
   at 
 org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:205)
   at 
 org.springframework.beans.factory.BeanFactoryUtils.beanOfTypeIncludingAncestors(BeanFactoryUtils.java:292)
   at

[jira] Updated: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-06 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Patrick Linskey updated OPENJPA-182:

Attachment: OPENJPA-182.patch

Remove forUpdate from DBDictionary.toOperation()'s signature; use a null check
on forUpdateClause instead.

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

Attachments: OPENJPA-182.patch, OPENJPA-182.patch, openJPA182.patch,
openjpa182TestCase.jar

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-06 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Patrick Linskey resolved OPENJPA-182.
-

Resolution: Fixed
Assignee: (was: David Wisneski)

I think that, aside from documentation and DB2 test cases and impls for other
data stores, we can put this issue to rest.

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

Attachments: OPENJPA-182.patch, OPENJPA-182.patch, openJPA182.patch,
openjpa182TestCase.jar

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-184) use DB2 Diagnostic interface to report extended error diagnostics on SQL Exception

2007-04-06 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487365
 ] 

Patrick Linskey commented on OPENJPA-184:
-

Is this issue still open?

 use DB2 Diagnostic interface to report extended error diagnostics on SQL 
 Exception
 --

 Key: OPENJPA-184
 URL: https://issues.apache.org/jira/browse/OPENJPA-184
 Project: OpenJPA
  Issue Type: New Feature
 Environment: DB2 database
Reporter: David Wisneski

 When using DB2 database and the SQLException occurs 
 if the SQLException instance supports the DB2Diagnosable interface, 
 extended error information from the SQLCA will be written to the SQL channel. 
 The message format produced by DB2Diagnosable writer is
  
SQLCA OUTPUT[Errp=SQLDMISR, Errd=[-2146893819, 5, 0, 0, -957, 0]]
 Errp is the name of the DB2 module that detected the error and Errd are 6 
 integers of diagnostic information, SQLWARN are 6 characters 
 of warning flags..  Often this additional information can be used by an 
 administrator in doing problem determination.
 This message will be appended to the persistence exception error message 
 already created by OpenJPA
 and it will be written to SQL logging channel (if active).
 DB2Dictionary class is modified to use java reflection on the SQLException 
 instance to determine 
 if it supports DB2Diagnosble methods getErrp and if so 
 it invokes the methods to retrieve Errp and Errd fields, formats and logs the 
 error message.
 Reflection is used so that the DB2Dictionary does not contain any compile 
 time or runtime 
 dependency on the DB2 jdbc driver.  If the DB2Diagnosable methods do not 
 exist on the SQLException
 instance,  no extended error information is logged.  
 org.apache.openjpa.jdbc.sql.SQLException class is modified so in the event of 
 an exception 
 if the Dictionary is DB2, to call the Dictionary routines above.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-05 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487046
]

Patrick Linskey 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.

Not really -- the lock levels allow the user to configure how locking should
happen, not what the isolation level should be for the locks.

I don't know about what levels of support non-DB2 databases have for per-query
isolation level configuration. Does anyone have any experience with this in
other databases?

Oh, and regardless, we should change the base DBDictionary to throw an
exception if this FetchPlan setting is set but not serviceable.

One thing that we should test: I'm not convinced that the lock level override
in the DB2Dictionary code is necessary. It's possible that the LockManager will
already take into account the current JDBCFetchConfiguration's lock level
settings when specifying the forUpdate setting for the toSelect() clause. Some
test cases will make it easy to figure out the answer to this question.

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-05 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487086
]

Patrick Linskey 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.

The current patches in this issue encompass two separate bits of functionality:

1. an update-override setting. (In the context of my patch, I'm not convinced
that this is necessary, since I suspect that the code that calls toSelect()
might set the forUpdate boolean based on the values in the
JDBCFetchConfiguration anyways.)

2. an isolation-override setting.

Currently, this patch implements all of this only in the DB2Dictionary. As of
right now, the first feature is something that is useful for all sorts of
databases, via syntax like Oracle's SELECT ... FOR UPDATE. However, we only
know how to implement the second feature for DB2, and not for any other
database. In Oracle, ALTER SESSION can be used to change the isolation level
of a given session, but I'm not sure of the semantics of this operation. I
believe that Abe's question is: Do other databases (Sybase? Derby?) also have
semantics for changing the isolation level of a particular query?

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-204) Nesting of Emebedded in Embeddable element

2007-04-05 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-204.
-

Resolution: Won't Fix

This is a limitation of the JPA spec. From section 9.1.34: 

specOnly Basic, Column, Lob, Temporal, and Enumerated mapping annotations may 
portably be used to map the persistent fields or properties of classes 
annotated as Embeddable./spec

OpenJPA supports embedded fields in embeddable instances, as well as various 
other usages of embedded things, but those are extensions to the spec. Due to 
OPENJPA-125, you can only configure nested embeddeds via annotations currently.

Marking this as WNF, although in some ways it might be better closed as a 
duplicate of OPENJPA-125, since once we resolve OPENJPA-125, there will be a 
way to do this in XML (albeit not the spec-defined XML).

Note that the JPA spec team defines the orm.xsd; OpenJPA is just an 
implementation of that spec. So, we can't change the orm.xsd. I believe, 
however, that this is an issue that the JPA 2 spec team will probably consider.

 Nesting of Emebedded in Embeddable element
 --

 Key: OPENJPA-204
 URL: https://issues.apache.org/jira/browse/OPENJPA-204
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
Affects Versions: 0.9.6
Reporter: sharath.h

 Hi,
  
 In orm_1_0.xsd or orm-xsd.rsrc files under the xsd:complexType 
 name=embeddable-attributes the xsd:element name=embedded 
 type=orm:embeddedminOccurs=0 maxOccurs=unbounded/ is not present.
  
 Please let me know if there is any valid reason behind it.Was the embedded 
 element in embeddable-attributes was accidently missed out?
  
 I faced the issue when i tried the example something like as shown below:
  
 class A
 {
   int id;
   B objB;
   
 }
  
 class B
 {
   String str1;
   Date d;
   C objC;
 }
  
 class C
 {
String str2;
 }
  
 I wanted to persist object A into a single table by having object B as 
 embedded and object B inturn having object C as embedded.
 My corresponding orm mapping file is as shown below:
  
 ?xml version=1.0 encoding=UTF-8?
 entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
 xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm orm_1_0.xsd 
 version=1.0
  
 entity class=A
 table name=TableA/
 attributes 
 id name=id
  column name=ID/   
 /id  
 embedded name=objB/
 /attributes
 /entity
  
 embeddable class=B  
 attributes  
 basic name=str1
column name=COL2/
 /basic 
 basic name=d
column name=DateCol/
 /basic
 embedded name=objC/
 /embeddable
 embeddable class=C  
 attributes 
 basic name=str2
column name=COL3/
 /basic 
 /embeddable
 /entity-mappings
  
 This was not possible due to orm schema restriction.
  
  
  
 Thanks,
 Regards,
 Sharath.H

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-205) JPA2 Follow-Up

2007-04-05 Thread Patrick Linskey (JIRA)

JPA2 Follow-Up
--

 Key: OPENJPA-205
 URL: https://issues.apache.org/jira/browse/OPENJPA-205
 Project: OpenJPA
  Issue Type: Improvement
  Components: jpa
Reporter: Patrick Linskey


This is an umbrella issue for all the issues that we should be tracking for the 
JPA2 specification. As issues are incorporated into the JPA2 specification or 
otherwise dismissed by the expert group, they may be removed from this umbrella 
issue as well, to reduce the number of issues in this umbrella.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-05 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487099
]

Patrick Linskey commented on OPENJPA-182:
-

Between Ritika's SQLServer email on the dev list and Mike's Sybase research, it
sounds like this feature is supported by enough databases that I think it's
useful to expose as an API, rather than just a DB2-specific hint.

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-04 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Patrick Linskey updated OPENJPA-182:

Attachment: OPENJPA-182.patch

For the sake of discussion, I've attached an alternate patch that uses a new
JDBCFetchPlan.setIsolationLevel() instead of a hint for isolation level, and
uses JDBCFetchConfiguration.getReadLockLevel() to determine whether or not to
do a SELECT ... FOR UPDATE.

If the read lock level is set to LockLevels.LEVEL_WRITE, then the FOR UPDATE is
included; if the read lock level is set to LockLevels.LEVEL_READ, then no FOR
UPDATE is used. If the read lock level is LockLevels.LEVEL_NONE, then the
default behavior is used. (This is possibly not the best use of LEVEL_NONE --
I'm not sure if LEVEL_NONE means 'default' or something else. But for the
purposes of demonstration, it seemed expedient to use it. Adding a new
LEVEL_DEFAULT constant might make more sense.)

Also, I directly reused the java.sql.Connection constants, which is possibly
non-ideal; we might want to discuss making our own constants. Or not.

So, in this model, if there were a test case for this stuff, I would have
changed the test case to do:

Query q = em.createQuery(...);
JDBCFetchPlan plan = (JDBCFetchPlan) ((OpenJPAQuery) query).getFetchPlan();
plan.setIsolationLevel(Connection.TRANSACTION_SERIALIZABLE);
plan.setReadLockMode(LockModeType.WRITE); // force a FOR UPDATE
List l = q.getResultList();

Note also that this model allows the isolation level and read lock mode to be
configured on the EM itself, for use in find() calls and relationship lookups,
and as the default settings for the fetch plans of queries created from the EM.

Finally, I replicated the logic in DB2Dictionary, but I noticed that sometimes
the logic checked for serializable and sometimes it checked for
read-uncommitted. I preserved these checks, but was this intentional? I'm not
all that clear about what the optimizations are, so just wanted to ensure that
that wasn't a typo.

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-04 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486819
]

Patrick Linskey commented on OPENJPA-182:
-

In the hint-based approach, you could set the hints on a particular query.

In my approach, you could configure the FetchPlan for a particular query (get
the Query's fetch plan), or for a particular entity manager (get the EM's fetch
plan). To do different fetch plans for different queries, you'd just set the
different query fetch plans differently.

Query fetch plans are a copy-on-write semantic -- they start off just
delegating through to the EM's fetch plan, and if you make changes, then they
immediately make a copy of the EM's fetch plan, and remain isolated from the
EM's fetch plan from then on out.

If you wanted to do different isolation levels for different find() calls or
different relationship traversals, in my impl, you'd need to set the EM's fetch
plan, do the work, then set it back. In the hint-based impl, you would not be
able to do any configuration for find() or relationship traversals.

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-04-04 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486821
]

Patrick Linskey commented on OPENJPA-182:
-

It's probably worth noting that everything in the FetchPlan is configurable via
the Query.setHint() APIs. My earlier theoretical test case would become:

Query q = em.createQuery(...);
q.setHint(openjpa.FetchPlan.IsolationLevel,
Connection.TRANSACTION_SERIALIZABLE);
q.setHint(openjpa.FetchPlan.ReadLockMode, LockModeType.WRITE);
List l = q.getResultList();

In other words, if we use the patch that I attached (or something like it), we
will end up with strong typing, API alignment with similar concepts, and
dynamic accessibility both in terms of Query.setHint() and @QueryHints
annotations / query-hint XML.

db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation

2007-04-02 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486065
 ] 

Patrick Linskey commented on OPENJPA-197:
-

I'm a bit confused. Where did Hibernate and Toplink fail? The only merge() call 
that I see is guarded by a check that should fail for any non-OpenJPA 
implementation.

Also, do you see any difference in behavior if you perform the em.merge() call 
inside the transaction? 

Finally, and you test case seems to handle this properly, my interpretation of 
the spec is that it does not require that the optimistic lock check happen 
during merge() -- it can happen at a later time instead. It should fail during 
your em.flush() call at the latest, however.

 @Version property doesn't ensure integrity when performing the merge operation
 --

 Key: OPENJPA-197
 URL: https://issues.apache.org/jira/browse/OPENJPA-197
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
Affects Versions: 0.9.7
Reporter: Jacek Laskowski

 See the simple test case:
 {
 Query query = em.createQuery(SELECT o FROM Osoba o WHERE o.imie 
 = 'Jacek' AND o.nazwisko = 'Laskowski');
 final Osoba osoba = (Osoba) query.getSingleResult();
 final Long numerOsoby = osoba.getNumer(); // numer is the pk
 long wersja = osoba.getWersja(); // wersja is a versioned property
 {
 EntityTransaction tx = em.getTransaction();
 tx.begin();
 Osoba osobaWersja0 = em.find(Osoba.class, numerOsoby);
 assert osobaWersja0.getWersja() == wersja;
 osobaWersja0.setImie(change);
 em.flush();
 wersja++;
 assert osobaWersja0.getWersja() == wersja;
 tx.commit();
 assert osobaWersja0.getWersja() == wersja;
 em.refresh(osobaWersja0);
 assert osobaWersja0.getWersja() == wersja;
 }
 {
 em.clear(); // osoba is now detached
 final String noweImie = Yet another name change;
 osoba.setImie(noweImie);
 EntityTransaction tx = em.getTransaction();
 tx.begin();
 Osoba osobaWersja1 = em.find(Osoba.class, numerOsoby);
 osobaWersja1.setImie(and another);
 tx.commit(); // change is on its way to database
 wersja++;
 assert osobaWersja1.getWersja() == wersja;
 assert osobaWersja1.getWersja() != osoba.getWersja();
 if 
 (em.getClass().getCanonicalName().equals(org.apache.openjpa.persistence.EntityManagerImpl))
  {
 Osoba osobaPoMerge = em.merge(osoba);
 assert osobaPoMerge.getImie().equals(osoba.getImie());
 assert osobaPoMerge.getImie().equals(noweImie);
 em.getTransaction().begin();
 try {
 em.flush();
 assert false;
 } catch (/* OptimisticLock */Exception oczekiwano) {
 em.getTransaction().rollback();
 }
 }
 }
 }
 It works fine with Apache OpenJPA 0.9.7-SNAPSHOT with the sources on the past 
 Friday. Hibernate EntityManager 3.3.1 and TopLink Essentials 2.0 BUILD 40 
 throw exception as the detached entity is merged  to em. According to the 
 spec 9.1.17 Version Annotation p. 178 (and the javadoc - 
 http://java.sun.com/javaee/5/docs/api/javax/persistence/Version.html - too):
 The Version annotation specifies the version field or property of an entity 
 class that serves as its optimistic lock value. The version is used to ensure 
 integrity when performing the merge operation and for optimistic concurrency 
 control.
 So, I think that it's a bug in OpenJPA.
 BTW, I'm still unable to send emails to open-jpa-dev. Who should I contact to 
 in order to fix it?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation

2007-04-02 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486091
 ] 

Patrick Linskey commented on OPENJPA-197:
-

Note that  there are significant performance impacts to doing the check at 
merge() time.

Is there any reason why you need a check to happen at merge() time? Is it 
sufficient to just follow the merge() call with a flush()? Alternately, how 
about a call to OpenJPAEntityManager.validateChanges()?

 @Version property doesn't ensure integrity when performing the merge operation
 --

 Key: OPENJPA-197
 URL: https://issues.apache.org/jira/browse/OPENJPA-197
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
Affects Versions: 0.9.7
Reporter: Jacek Laskowski

 See the simple test case:
 {
 Query query = em.createQuery(SELECT o FROM Osoba o WHERE o.imie 
 = 'Jacek' AND o.nazwisko = 'Laskowski');
 final Osoba osoba = (Osoba) query.getSingleResult();
 final Long numerOsoby = osoba.getNumer(); // numer is the pk
 long wersja = osoba.getWersja(); // wersja is a versioned property
 {
 EntityTransaction tx = em.getTransaction();
 tx.begin();
 Osoba osobaWersja0 = em.find(Osoba.class, numerOsoby);
 assert osobaWersja0.getWersja() == wersja;
 osobaWersja0.setImie(change);
 em.flush();
 wersja++;
 assert osobaWersja0.getWersja() == wersja;
 tx.commit();
 assert osobaWersja0.getWersja() == wersja;
 em.refresh(osobaWersja0);
 assert osobaWersja0.getWersja() == wersja;
 }
 {
 em.clear(); // osoba is now detached
 final String noweImie = Yet another name change;
 osoba.setImie(noweImie);
 EntityTransaction tx = em.getTransaction();
 tx.begin();
 Osoba osobaWersja1 = em.find(Osoba.class, numerOsoby);
 osobaWersja1.setImie(and another);
 tx.commit(); // change is on its way to database
 wersja++;
 assert osobaWersja1.getWersja() == wersja;
 assert osobaWersja1.getWersja() != osoba.getWersja();
 if 
 (em.getClass().getCanonicalName().equals(org.apache.openjpa.persistence.EntityManagerImpl))
  {
 Osoba osobaPoMerge = em.merge(osoba);
 assert osobaPoMerge.getImie().equals(osoba.getImie());
 assert osobaPoMerge.getImie().equals(noweImie);
 em.getTransaction().begin();
 try {
 em.flush();
 assert false;
 } catch (/* OptimisticLock */Exception oczekiwano) {
 em.getTransaction().rollback();
 }
 }
 }
 }
 It works fine with Apache OpenJPA 0.9.7-SNAPSHOT with the sources on the past 
 Friday. Hibernate EntityManager 3.3.1 and TopLink Essentials 2.0 BUILD 40 
 throw exception as the detached entity is merged  to em. According to the 
 spec 9.1.17 Version Annotation p. 178 (and the javadoc - 
 http://java.sun.com/javaee/5/docs/api/javax/persistence/Version.html - too):
 The Version annotation specifies the version field or property of an entity 
 class that serves as its optimistic lock value. The version is used to ensure 
 integrity when performing the merge operation and for optimistic concurrency 
 control.
 So, I think that it's a bug in OpenJPA.
 BTW, I'm still unable to send emails to open-jpa-dev. Who should I contact to 
 in order to fix it?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-57) persistence_1_0.xsd is missing

2007-04-02 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-57.


   Resolution: Won't Fix
Fix Version/s: (was: 0.9.8)
   0.9.7

If the user does not specify an XSD, OpenJPA doesn't require that the XSD is 
present to parse files. Since OpenJPA does not need the file to be around, and 
the legality of distributing it is in question, I'm marking this as 
will-not-fix. The linked-to Spring forum issue seems to be due to a dependency 
in the Spring codebase; let's let them decide whether they want to ship the XSD 
or make it optional.

 persistence_1_0.xsd is missing
 --

 Key: OPENJPA-57
 URL: https://issues.apache.org/jira/browse/OPENJPA-57
 Project: OpenJPA
  Issue Type: Improvement
Reporter: Stefan Arentz
 Fix For: 0.9.7


 It seems to be common that JPA providers include persistence_1_0.xsd in one 
 of the distribution jars. I'm not sure if this is according to the spec but 
 some tools such as Spring already depend on that behaviour.
 This is probably mostly relevant for using JPA in a J2SE environment as I 
 think the xsd is probably provided by the app server.
 Discussion on the Spring forum about this:
  
 http://forum.springframework.org/showthread.php?t=26209highlight=persistence_1_0.xsd
  S.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS

2007-03-29 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485103
 ] 

Patrick Linskey commented on OPENJPA-182:
-

Wow... that's a lot more DB2 locking knowledge than I've ever seen in one 
place. Neat.

Some comments on the patch:

1. How does the openjpa.hint.updateClause hint differ from the value of the 
forUpdate flag passed in to the DBDictionary call? It looks like the existing 
OpenJPA per-transaction read / write lock level configuration could be used 
instead.

2. Is openjpa.hint.isolationLevel really a hint, or more of a rule? Again, I 
have a hunch that maybe we could do something with the read / write lock 
levels, or maybe some other means of controlling isolation level. In any event, 
it seems like isolation level isn't really a hint, but rather is more of a rule.

3. You introduced a number of public boolean fields for determining what type 
of DB2 instance is being used. Based on code inspection, it looks like you 
expect that it should always be possible to automatically determine the type; 
maybe these should be private fields instead? We only have public fields in 
DBDictionaries for user-configurable settings. Also, since it looks like only 
one of the booleans can meaningfully be true, I'd rather see a single private 
db2ServerType field that will be set to one of several symbolic constant 
values. This will let you replace the if-else block with a switch block if you 
prefer that sort of thing, also.

 db2 update lock syntax  WITH isolation USE AND KEEP UPDATE LOCKS
 --

 Key: OPENJPA-182
 URL: https://issues.apache.org/jira/browse/OPENJPA-182
 Project: OpenJPA
  Issue Type: New Feature
  Components: jdbc
 Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux
Reporter: David Wisneski
 Assigned To: David Wisneski
 Attachments: 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] Resolved: (OPENJPA-186) Build failure of OpenJPA sources from trunk

2007-03-29 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-186.
-

Resolution: Fixed

Sorry about that -- I don't think that many of us run 'mvn install' all that 
often.

I just removed the line that tries to invoke the tck in r523613; hopefully, you 
should now be able to build successfully. I was just able to run a 'mvn clean 
install' without issue.

 Build failure of OpenJPA sources from trunk
 ---

 Key: OPENJPA-186
 URL: https://issues.apache.org/jira/browse/OPENJPA-186
 Project: OpenJPA
  Issue Type: Bug
  Components: build / infrastructure
Affects Versions: 0.9.7
Reporter: Jacek Laskowski
 Assigned To: Marc Prud'hommeaux
 Fix For: 0.9.7

 Attachments: OPENJPA-186-builderror-2.txt, 
 OPENJPA-186.buildfailure.txt, OPENJPA-186.patch


 (I have sent it to the mailing list on March 26th, but it didn't get through)
 As I'm not alone with the build failure, see 
 http://www.nabble.com/error-building-openjpa-tf3478705.html, here goes the 
 issue report.
 I've been trying to build OpenJPA source from trunk for a couple of days and 
 no joy so far. Anything missing?
 [EMAIL PROTECTED] /cygdrive/c/oss/openjpa
 $ svn up
 At revision 522565.
 [EMAIL PROTECTED] /cygdrive/c/oss/openjpa
 $ svn status
 [EMAIL PROTECTED] /cygdrive/c/oss/openjpa
 $ mvn clean install
 [INFO] Executing tasks
 [echo] Revision: 406193:522097
 [INFO] Executed tasks
 [INFO] [antrun:run {execution: delete sun.misc.Perf}]
 [INFO] Executing tasks
 [INFO] Executed tasks
 [INFO] [resources:testResources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:testCompile]
 [INFO] Compiling 33 source files to
 c:\oss\openjpa\openjpa-lib\target\test-classes
 [INFO] [surefire:test]
 [INFO] Surefire report directory:
 c:\oss\openjpa\openjpa-lib\target\surefire-reports
 [INFO] Building jar: 
 c:\DOCUME~1\JLASKO~1\LOCALS~1\Temp\surefirebooter30238.jar
 java.lang.NoClassDefFoundError: 
 org/apache/maven/surefire/booter/SurefireBooter
 Exception in thread main
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] There are test failures.
 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 16 seconds
 [INFO] Finished at: Mon Mar 26 19:16:09 CEST 2007
 [INFO] Final Memory: 21M/254M
 [INFO] 
 
 [EMAIL PROTECTED] /cygdrive/c/oss/openjpa
 $ mvn -v
 Maven version: 2.0.5
 [EMAIL PROTECTED] /cygdrive/c/oss/openjpa
 $ java -version
 java version 1.5.0_11
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
 Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-184) use DB2 Diagnostic interface to report extended error diagnostics on SQL Exception

2007-03-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-184:



 This message will be appended to the persistence exception 
 error message already created by OpenJPA and it will be written 
 to SQL logging channel (if active).

I've found that doing logging and then throwing the same content in an 
exception becomes confusing. I'd prefer to see the core code only throw the 
exception. I believe that we discussed putting code in place that always logs 
all exceptions at OpenJPA's boundaries a while ago; I prefer that solution for 
people that can't manage to get exceptions logged / handled properly by their 
own frameworks. Thoughts?

 org.apache.openjpa.jdbc.sql.SQLException class is modified so 
 in the event of an exception if the Dictionary is DB2, to call the Dictionary 
 routines above.

I'd prefer not to see DB2-specific logic put into SQLException. How about 
changing SQLException to always call some new method in DBDictionary, and just 
only do something in the method in DB2Dictionary?

 use DB2 Diagnostic interface to report extended error diagnostics on SQL 
 Exception
 --

 Key: OPENJPA-184
 URL: https://issues.apache.org/jira/browse/OPENJPA-184
 Project: OpenJPA
  Issue Type: New Feature
 Environment: DB2 database
Reporter: David Wisneski

 When using DB2 database and the SQLException occurs 
 if the SQLException instance supports the DB2Diagnosable interface, 
 extended error information from the SQLCA will be written to the SQL channel. 
 The message format produced by DB2Diagnosable writer is
  
SQLCA OUTPUT[Errp=SQLDMISR, Errd=[-2146893819, 5, 0, 0, -957, 0]]
 Errp is the name of the DB2 module that detected the error and Errd are 6 
 integers of diagnostic information, SQLWARN are 6 characters 
 of warning flags..  Often this additional information can be used by an 
 administrator in doing problem determination.
 This message will be appended to the persistence exception error message 
 already created by OpenJPA
 and it will be written to SQL logging channel (if active).
 DB2Dictionary class is modified to use java reflection on the SQLException 
 instance to determine 
 if it supports DB2Diagnosble methods getErrp and if so 
 it invokes the methods to retrieve Errp and Errd fields, formats and logs the 
 error message.
 Reflection is used so that the DB2Dictionary does not contain any compile 
 time or runtime 
 dependency on the DB2 jdbc driver.  If the DB2Diagnosable methods do not 
 exist on the SQLException
 instance,  no extended error information is logged.  
 org.apache.openjpa.jdbc.sql.SQLException class is modified so in the event of 
 an exception 
 if the Dictionary is DB2, to call the Dictionary routines above.

-- 
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

2007-03-26 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484288
]

Patrick Linskey commented on OPENJPA-168:
-

2. I don't think we need a FetchConfiguration instance variable.

My understanding is that you can often provide hints about how many results
might be returned, as well as whether one or many results will be loaded. So it
seems like we might want to expose some way for the user to specify for an
arbitrary query (or relation load) that they expect n records to be returned.

4. getOptimizeClause seems too generic.

Agreed. The optimizations tend to get tucked into different parts of the SQL
statement; this probably will end up needing to be significantly different for
different db back-ends.

sql optimize n rows query hint
--

Key: OPENJPA-168
URL: https://issues.apache.org/jira/browse/OPENJPA-168
Project: OpenJPA
Issue Type: New Feature
Reporter: David Wisneski
Assigned To: David Wisneski
Attachments: OPENJPA-168.patch.txt, OPENJPA-168.patch2.txt

There werre various comments from Patrick, Abe and Kevin Sutter about the
code that I checked related to Optimize hint. So I have gone back and
relooked at this and wil be making some changes. At Kevin's suggestion I
will do this through a JIRA feature so that folks will have opportunity to
comment on this before the code is actually done and checked in.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-183) OpenJPAEntityManager large transaction APIs should take class arguments to narrow behavior

2007-03-26 Thread Patrick Linskey (JIRA)

OpenJPAEntityManager large transaction APIs should take class arguments to 
narrow behavior
--

 Key: OPENJPA-183
 URL: https://issues.apache.org/jira/browse/OPENJPA-183
 Project: OpenJPA
  Issue Type: Improvement
  Components: datacache
Reporter: Patrick Linskey


OpenJPAEntityManager.setLargeTransaction() and 
OpenJPAEntityManager.setPopulateDataCache() control how a given transaction 
uses the data cache. These APIs (and in particular, setLargeTransaction()) 
would benefit from being per-class (or per-class-hierarchy) instead of being 
global to all classes in a transaction.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-172) DSRA9250E: Operation setTransactionIsolation is not allowed during a global transaction for Shareable Connections.

2007-03-25 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-172:


Fix Version/s: (was: 0.9.6)
   0.9.7

0.9.6 is released; moving the fix version to 0.9.7 to reflect the best-case 
reality.

  DSRA9250E: Operation setTransactionIsolation is not allowed during a global 
 transaction for Shareable Connections.
 ---

 Key: OPENJPA-172
 URL: https://issues.apache.org/jira/browse/OPENJPA-172
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
Affects Versions: 0.9.6
 Environment: Websphere 6.1 for zos and DB2 zos V8
Reporter: Ritika Maheshwari
 Fix For: 0.9.7


 My persistence.xml looks like following
 ***
 ?xml version=1.0 ?
 persistence xmlns=http://java.sun.com/xml/ns/persistence;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  version=1.0
 persistence-unit name=dwtest transaction-type=JTA
 providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
non-jta-data-sourcejdbc/ErwwDS/non-jta-data-source 
classejb.jpa.test.Customer/class 
 classejb.jpa.test.District/class
 classejb.jpa.test.Warehouse/class
 classejb.jpa.test.History/class
classejb.jpa.test.Item/class
   classejb.jpa.test.Neworders/class
   classejb.jpa.test.Orderline/class
 classejb.jpa.test.Orders/class
   classejb.jpa.test.Stock/class
 properties
   
  property name=openjpa.LockManager value=pessimistic/
 property name=openjpa.ReadLockLevel value=read/
 property name=openjpa.WriteLockLevel value=write/
 property name=openjpa.LockTimeout value=3/
  property name=openjpa.FetchBatchSize value=1 /
  property name=openjpa.jdbc.TransactionIsolation value=read-committed / 
   property name=openjpa.Log value=DefaultLevel=WARN, Runtime=INFO, 
 Tool=INFO,SQL=TRACE/
   
 /properties
 /persistence-unit
 /persistence
 ***
 The Orderline entity looks like following
 *
 @Entity
 @IdClass(ejb.jpa.test.OrderlineId.class)
 @SequenceGenerator(name=mysequence,sequenceName=ORDER_ID)
 public  class Orderline implements Serializable{
   
   @Id
   @GeneratedValue(strategy=GenerationType.SEQUENCE,generator=mysequence)
   java.lang.Integer ol_o_id =  null;
   @Id
   java.lang.String ol_d_id = null;
   @Id
   java.lang.String ol_w_id = null;
   @Id
   java.lang.Short ol_number = null;
   java.lang.String ol_i_id = null;
   java.sql.Timestamp ol_delivery_d = null;
   java.lang.String ol_supply_w_id = null;
   java.lang.Short ol_quantity = null;
   java.math.BigDecimal ol_amount = null;
   java.sql.Timestamp itime = null;
   java.lang.String ol_dist_info = null;
   @ManyToOne(fetch=FetchType.LAZY)
   @JoinColumns({
   @JoinColumn(name=ol_o_id, referencedColumnName=o_id),
 @JoinColumn(name=ol_d_id, referencedColumnName=o_d_id),
 @JoinColumn(name=ol_w_id, referencedColumnName=o_w_id)
})
Orders orders = null;
   @ManyToOne(fetch=FetchType.LAZY)
   @JoinColumns({
   @JoinColumn(name=ol_i_id, referencedColumnName=s_i_id),
 @JoinColumn(name=ol_supply_w_id, referencedColumnName=s_w_id)
 
})
Stock stock = null;
 *
 Now if I run the following client 
 UserTransaction ut = null;
   ClientEJB  facade = null;
   EntityManager em = null;
   try {
   Hashtable parms = new Hashtable();
   parms.put(  Context.INITIAL_CONTEXT_FACTORY,
   com.ibm.websphere.naming.WsnInitialContextFactory);
   InitialContext ctx = new InitialContext(parms);
   ut = (UserTransaction) ctx.lookup(java:comp/UserTransaction); 
  ut.begin();
   em = getFactory().createEntityManager (); 

try {
   OpenJPAEntityManager kem = OpenJPAPersistence.cast (em);
   kem.getFetchPlan().setReadLockMode(LockModeType.WRITE);
stock = (Stock)kem.find(Stock.class,stockKey);

[jira] Created: (OPENJPA-169) Queries against dirty extents and flushing: should provide an option to set savepoint, flush, query, rollback to savepoint

2007-03-12 Thread Patrick Linskey (JIRA)

Queries against dirty extents and flushing: should provide an option to set 
savepoint, flush, query, rollback to savepoint
--

 Key: OPENJPA-169
 URL: https://issues.apache.org/jira/browse/OPENJPA-169
 Project: OpenJPA
  Issue Type: Improvement
Reporter: Patrick Linskey


When issuing a JPQL query after changing data that is involved in the access 
path of the query, OpenJPA must either flush before querying (and therefore 
obtain a Connection), or load all instances of the potentially-dirty classes 
into memory and evaluate the query in memory.

Now that OpenJPA supports savepoints, we should provide an option to set 
savepoint, flush, query, and then roll the savepoint back.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-170) Constrain types to be flushed

2007-03-12 Thread Patrick Linskey (JIRA)

Constrain types to be flushed
-

 Key: OPENJPA-170
 URL: https://issues.apache.org/jira/browse/OPENJPA-170
 Project: OpenJPA
  Issue Type: Improvement
Reporter: Patrick Linskey


When invoking EntityManager.flush(), all dirty instances are flushed. This can 
be inconvenient when working in an application with multiple distinct modules 
that may need to flush for query purposes.

OpenJPA should provide an OpenJPAEntityManager.flush(Class... classesToFlush) 
API that limits the flushes to just the specified classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-167) Named queries and no listed entities: bad error message

2007-03-10 Thread Patrick Linskey (JIRA)

Named queries and no listed entities: bad error message
---

 Key: OPENJPA-167
 URL: https://issues.apache.org/jira/browse/OPENJPA-167
 Project: OpenJPA
  Issue Type: Bug
  Components: diagnostics
Affects Versions: 0.9.0, 0.9.6
Reporter: Patrick Linskey


When executing a named query without having declared any persistent types, I 
get the following:

4|true|0.0.0 org.apache.openjpa.persistence.ArgumentException: There is no 
query with the name SimpleXml.findAll defined for any of the known persistent 
classes: null.
at 
org.apache.openjpa.meta.MetaDataRepository.getQueryMetaData(MetaDataRepository.java:1494)
at 
org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery(EntityManagerImpl.java:767)
at 
org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery(EntityManagerImpl.java:62)
at 
org.apache.openjpa.persistence.xml.TestSimpleXmlEntity.testNamedQueryInXmlNamedEntity(TestSimpleXmlEntity.java:12)


This message should read No persistent classes were listed in 
path-to-persistence.xml, and auto-class-scanning is not configured, so no 
named queries can be found. You can configure auto-class-scanning by 
auto-class-scan info here or something along those lines.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-35) In-memory Delete operation fails with active DataCache

2007-03-10 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-35.


   Resolution: Fixed
Fix Version/s: (was: 0.9.7)

 In-memory Delete operation fails with active DataCache
 --

 Key: OPENJPA-35
 URL: https://issues.apache.org/jira/browse/OPENJPA-35
 Project: OpenJPA
  Issue Type: Bug
  Components: datacache, query
Affects Versions: 0.9.0, 0.9.6
 Environment: Only happens when DataCache is active
   property name=openjpa.DataCache
 value=true/
   property name=openjpa.RemoteCommitProvider 
 value=sjvm/
Reporter: Pinaki Poddar
Priority: Critical
 Attachments: openjpa-35.test.zip, openjpa-35.trace.txt


 Delete through query such as 
   Query query = em.createQuery(DELETE FROM Node n);
   query.executeUpdate();
 fails with following exception (only when DataCache is active)
 Exception in thread main 4|false|0.0.0 
 org.apache.openjpa.persistence.ArgumentException: 
 org.apache.openjpa.datacache.QueryCacheStoreQuery
   at 
 org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1029)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeDelete(ExpressionStoreQuery.java:665)
   at 
 org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeDelete(QueryCacheStoreQuery.java:348)
   at org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1012)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:768)
   at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:831)
   at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:827)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.deleteAll(DelegatingQuery.java:544)
   at 
 org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:299)
   at control.Test.clear(Test.java:87)
   at control.Test.run(Test.java:37)
   at control.Test.main(Test.java:178)
 Caused by: java.lang.ClassCastException: 
 org.apache.openjpa.datacache.QueryCacheStoreQuery
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:651)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:949)
   at 
 org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1018)
   ... 11 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-35) In-memory Delete operation fails with active DataCache

2007-03-10 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-35:
---

Fix Version/s: 0.9.7

 In-memory Delete operation fails with active DataCache
 --

 Key: OPENJPA-35
 URL: https://issues.apache.org/jira/browse/OPENJPA-35
 Project: OpenJPA
  Issue Type: Bug
  Components: datacache, query
Affects Versions: 0.9.0, 0.9.6
 Environment: Only happens when DataCache is active
   property name=openjpa.DataCache
 value=true/
   property name=openjpa.RemoteCommitProvider 
 value=sjvm/
Reporter: Pinaki Poddar
Priority: Critical
 Fix For: 0.9.7

 Attachments: openjpa-35.test.zip, openjpa-35.trace.txt


 Delete through query such as 
   Query query = em.createQuery(DELETE FROM Node n);
   query.executeUpdate();
 fails with following exception (only when DataCache is active)
 Exception in thread main 4|false|0.0.0 
 org.apache.openjpa.persistence.ArgumentException: 
 org.apache.openjpa.datacache.QueryCacheStoreQuery
   at 
 org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1029)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeDelete(ExpressionStoreQuery.java:665)
   at 
 org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeDelete(QueryCacheStoreQuery.java:348)
   at org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1012)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:768)
   at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:831)
   at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:827)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.deleteAll(DelegatingQuery.java:544)
   at 
 org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:299)
   at control.Test.clear(Test.java:87)
   at control.Test.run(Test.java:37)
   at control.Test.main(Test.java:178)
 Caused by: java.lang.ClassCastException: 
 org.apache.openjpa.datacache.QueryCacheStoreQuery
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:651)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:949)
   at 
 org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1018)
   ... 11 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-71) Caching primitive array types consumes excessive memory

2007-03-09 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-71:
---

Fix Version/s: 0.9.7
Affects Version/s: 0.9.0
   0.9.6

 Caching primitive array types consumes excessive memory
 ---

 Key: OPENJPA-71
 URL: https://issues.apache.org/jira/browse/OPENJPA-71
 Project: OpenJPA
  Issue Type: Bug
  Components: datacache
Affects Versions: 0.9.0, 0.9.6
Reporter: Roger Keays
 Fix For: 0.9.7


 As reported on the mailing list: 
 http://www.nabble.com/cached-byte---consumes-excessive-memory-tf2543098.html 
 , in org.apache.openjpa.AbstractPCData#toData() an ArrayList is used to cache 
 all types of arrays, including arrays of primitives. This can use excessively 
 large amounts of memory because of the wrappers required for each element in 
 the array. In one test case, a 7MB byte[] consumed 127MB when converted to a 
 cached ArrayList.
 AbstractPCData needs to be fixed to handle simple arrays.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-71) Caching primitive array types consumes excessive memory

2007-03-08 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-71.


   Resolution: Fixed
Fix Version/s: (was: 0.9.7)

 Caching primitive array types consumes excessive memory
 ---

 Key: OPENJPA-71
 URL: https://issues.apache.org/jira/browse/OPENJPA-71
 Project: OpenJPA
  Issue Type: Bug
  Components: datacache
Reporter: Roger Keays

 As reported on the mailing list: 
 http://www.nabble.com/cached-byte---consumes-excessive-memory-tf2543098.html 
 , in org.apache.openjpa.AbstractPCData#toData() an ArrayList is used to cache 
 all types of arrays, including arrays of primitives. This can use excessively 
 large amounts of memory because of the wrappers required for each element in 
 the array. In one test case, a 7MB byte[] consumed 127MB when converted to a 
 cached ArrayList.
 AbstractPCData needs to be fixed to handle simple arrays.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-46) true, false not case insensitive, gets null pointer exception

2007-03-08 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-46.


   Resolution: Fixed
Fix Version/s: (was: 0.9.7)
 Assignee: (was: 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
Priority: Minor
 Attachments: failureEntities.jar


 140 - true,false should be case insensitive - gets npe
   [ FAILED 140- bucket = fvtfull, query = select e from EmpBean e where 
 (e.isManager = True)  : 
EXPECTED(
  TEST140; select e from EmpBean e where (e.isManager = True) 
 [( class com.dw.test.EmpBean  empid=2 name=andrew salary=13.1 dept=210)]
 [( class com.dw.test.EmpBean  empid=1 name=david salary=12.1 dept=210)]
  TEST140; 2 tuples ) 
ACTUAL(
  TEST140; select e from EmpBean e where (e.isManager = True) 
  e   
  
 null 
  TEST140; 1 tuple) ]
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:672)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:934)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
   ... 23 more
 4|false|0.0.0 org.apache.openjpa.persistence.ArgumentException: null
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:755)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
   at 
 com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at 
 junit.extensions.jfunc.TestletWrapper.runBare(TestletWrapper.java:116)
   at 
 junit.extensions.jfunc.TestletWrapper$1.protect(TestletWrapper.java:106)
   at junit.framework.TestResult.runProtected(Unknown Source)
   at junit.extensions.jfunc.TestletWrapper.run(TestletWrapper.java:109)
   at junit.framework.TestSuite.runTest(Unknown Source)
   at junit.framework.TestSuite.run(Unknown Source)
   at junit.extensions.jfunc.JFuncSuite.run(JFuncSuite.java:134)
   at junit.extensions.jfunc.textui.JFuncRunner.doRun(JFuncRunner.java:76)
   at junit.extensions.jfunc.textui.JFuncRunner.start(JFuncRunner.java:398)
   at junit.extensions.jfunc.textui.JFuncRunner.main(JFuncRunner.java:218)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.openjpa.jdbc.kernel.exps.PCPath.initialize(PCPath.java:362)
   at 
 org.apache.openjpa.jdbc.kernel.exps.CompareEqualExpression.initialize(CompareEqualExpression.java:78)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.initialize(SelectConstructor.java:166)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.newSelect(SelectConstructor.java:115)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:69)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:324)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:165)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:672)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:934)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
   ... 23 more
 141 same
  TEST141; select e from EmpBean e where (e.isManager = fAlSe) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-80) Bad Escaping for LIKE in MySQL

2007-03-06 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-80.


Resolution: Fixed

 Bad Escaping for LIKE in MySQL
 --

 Key: OPENJPA-80
 URL: https://issues.apache.org/jira/browse/OPENJPA-80
 Project: OpenJPA
  Issue Type: Bug
  Components: query
 Environment: openJPA 0.9.7 
 MySQL 5.0.15
Reporter: Jakob Braeuchi
 Fix For: 0.9.7


 the following query :
 em.createQuery(select k from KategorieGruppe k  where k.bezeichnung like ?1 
 order by k.bezeichnung asc);
 generates an sql-statement with a bad escaping character '\' for MySQL :
 SELECT t0.id, t0.bezeichnung FROM ekv2kategoriegruppe t0 WHERE 
 (t0.bezeichnung LIKE ? ESCAPE '\') ORDER BY t0.bezeichnung ASC
 the correct escaping would be '\\'.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OPENJPA-163) @OneToOne should not be legal as back-pointer of @OneToMany

2007-03-06 Thread Patrick Linskey (JIRA)

@OneToOne should not be legal as back-pointer of @OneToMany
---

 Key: OPENJPA-163
 URL: https://issues.apache.org/jira/browse/OPENJPA-163
 Project: OpenJPA
  Issue Type: Improvement
  Components: diagnostics, jpa
Affects Versions: 0.9.6, 0.9.0
Reporter: Patrick Linskey
Priority: Minor
 Fix For: 0.9.7


According to the JPA spec, the opposite side of a @OneToMany must be a 
@ManyToOne. OpenJPA allows a @OneToOne to be used instead. This does not seem 
to add any value, and reduces portability of client applications.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-164) Need better logging on Java field type to SQL type mapping and exceptions

2007-03-06 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-164:


  Component/s: jdbc
   diagnostics
Fix Version/s: 0.9.7
Affects Version/s: 0.9.0
   0.9.6

 Need better logging on Java field type to SQL type mapping and exceptions
 -

 Key: OPENJPA-164
 URL: https://issues.apache.org/jira/browse/OPENJPA-164
 Project: OpenJPA
  Issue Type: Improvement
  Components: diagnostics, jdbc
Affects Versions: 0.9.0, 0.9.6
Reporter: Nick Johnson
 Fix For: 0.9.7


 When a Java field and its corresponding SQL field are of incompatible types 
 (as can happen with programming errors), OpenJPA presently just wraps the 
 exception thrown by the JDBC driver.  For example, if the type is declared as 
 long in Java but boolean in PostgreSQL, a PostgreSQL error that the value f 
 is not compatible with the type BigDecimal.
 The problem is that there's no indication of which mapped class is 
 responsible for the exception, which can be a problem for a class with many 
 relationships.  Any of the related classes could have caused the problem.
 Better logging (probably at level TRACE) around calls to resultSet.getX would 
 greatly help in debugging these problems.  Just knowing the classname and the 
 field name the JDBC get is being called for would be tremendously helpful.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-162) @OrderBy on @OneToMany does not allow ordering by @Id value

2007-03-05 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478122
 ] 

Patrick Linskey commented on OPENJPA-162:
-

I believe that the issue is that the field is not in the current fetch 
configuration; i.e., it's a lazy relationship. The ID field will clearly be 
part of the instance that is selected , but when you're selecting Messages, not 
Threads (or whatever it is that contains Messages).

What happens if you just say '@OrderBy' and leave out the string argument? 
According to 9.1.28 of the spec, if you just specify @OrderBy and nothing else, 
the ordering will be ascending by the pk of the associated records, which 
happens to be what you want.

 @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

 Using the following annotation:
@OneToMany(mappedBy=root, fetch=FetchType.LAZY)
 @OrderBy(objectId ASC)
 private ListMessage messages;
 I get the exception Cannot order 
 net.spatula.tally_ho.model.MessageRoot.messages on objectId, because that 
 field is not in the default fetch group.  You can only order on fields that 
 will be selected when the related object is loaded.
 I should certainly hope that the primary key of the related object is going 
 to be selected when the object is loaded:
 @Id
 @Column(name = object_id)
 private long objectId;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects

2007-02-28 Thread Patrick Linskey (JIRA)


[ 
https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476629
 ] 

Patrick Linskey commented on OPENJPA-160:
-

K... IMO, we should get rid of the finalizer in the default config, and create 
a new FinalizingBrokerImpl that has a finalizer, that can optionally be used by 
developers. I think that we should make that the default, and then let 
appserver providers (who are the most likely to definitely control resources 
correctly) turn the finalization off.

 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-clone-patch.txt, 
 openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, 
 openjpa-160-patch.txt, perf2.jpg, perf3.jpg, profile_clonepatch.jpg, 
 profile_explicitclass.jpg




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-160) Reuse BrokerImpl objects

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-160:


Attachment: openjpa-160-finalization-and-cloning-patch.txt

- moved BrokerImpl.finalize() to new FinalizingBrokerImpl subtype
- retained clone() logic
- made FinalizingBrokerImpl the default
- added alias for BrokerImpl called 'non-finalizing'

Frameworks that guarantee that EM.close() will be invoked should set the 
openjpa.BrokerImpl property to 'non-finalizing'.

 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-clone-patch.txt, 
 openjpa-160-finalization-and-cloning-patch.txt, openjpa-160-patch.txt, 
 openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, 
 perf2.jpg, perf3.jpg, profile_clonepatch.jpg, profile_explicitclass.jpg




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-160) Reuse BrokerImpl objects

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-160.
-

Resolution: Fixed

Hopefully, we can put this to rest now.

 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-clone-patch.txt, 
 openjpa-160-finalization-and-cloning-patch.txt, openjpa-160-patch.txt, 
 openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, 
 perf2.jpg, perf3.jpg, profile_clonepatch.jpg, profile_explicitclass.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

2007-02-28 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476736
]

Patrick Linskey commented on OPENJPA-160:
-

1. I really think we're going just a bit too fast here. I wasn't able to
comment
on the discussion because I've been in meetings all morning, and it's really
tough to find the issue resolved, a patch committed, and I never had a
chance.
I also notice that just minutes after the commit, Abe had a comment that
resulted in another change. For issues that attract this kind of attention, I
think a little more time is probably needed to reach closure.

IIRC, we're operating in a commit-then-review mode in OpenJPA. This issue has
been very experimental by nature up earlier today, so I was providing patches
to find something that worked. Once we got there, I committed, Abe reviewed, we
changed it. Seems pretty much exactly like how we've handled other issues,
except that we did a bunch of code-collaboration along the way.

2. I'd like to reopen the discussion of which BrokerImpl should be the
default.
In general, I like performance options to be the default. It makes the out
of
the box experience better because users don't need to find, much less read,
the relevant part of the documentation. Well-behaved applications don't need
the finalizer. Small applications running in short-lived vms don't need it.

Personally, I prefer more forgiving defaults when possible, so that people
don't get bitten when they're just playing around with things. Also, if we
decide to change our defaults, I think that we should include
openjpa.DataCache, openjpa.QueryCache, and possibly other things listed in the
optimization guide in such a change.

Any other opinions?

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-clone-patch.txt,
openjpa-160-finalization-and-cloning-patch.txt, openjpa-160-patch.txt,
openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt,
perf2.jpg, perf3.jpg, profile_clonepatch.jpg, profile_explicitclass.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

2007-02-28 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476749
]

Patrick Linskey commented on OPENJPA-160:
-

The extra day would have allowed Abe to get his comments recognized
and Craig would have been able to voice his default action concern.

I guess I fail to see the problem. Craig has voiced his default action
concern, and Abe did get his comments recognized. IMO, the real issue here is
whether we want to do review-then-commit or commit-then-review. Unless there is
some known way to say this issue needs to be review-then-commit, this problem
will just keep on repeating itself.

Personally, I like to get changes off of my local machine and into svn as soon
as I can, as I've found that letting changes linger is problematic.

Remember that (modulo svn's issues with David's checkin) we have history here.
Just checking something in doesn't mean that it's necessarily done.

But, having good performance out of the box is a benefit -- not only for the
customer, but also for all of us so that we don't have to explain why we're
protecting the customer from him/herself.

It's worth noting that in this situation, it's not a performance issue per se,
but rather a scalability issue, since it only crops up under heavily-concurrent
usage patterns. I'd expect that anyone doing that type of coding and not using
an appserver would be reading through the optimization guide in detail.

Which brings up an interesting possibility: we could set the value differently
if the entry point is from
PersistenceProvider.createContainerEntityManagerFactory(), since an appserver
really really should be managing resources correctly.

Reuse BrokerImpl objects

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-125) OpenJPA-specific metadata cannot be specified in XML descriptors

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-125:


Affects Version/s: 1.0.0

 OpenJPA-specific metadata cannot be specified in XML descriptors
 

 Key: OPENJPA-125
 URL: https://issues.apache.org/jira/browse/OPENJPA-125
 Project: OpenJPA
  Issue Type: New Feature
  Components: jpa
Affects Versions: 1.0.0
Reporter: Patrick Linskey
Priority: Critical

 OpenJPA includes a number of annotations that extend the behavior of the JPA 
 specification. Currently, these annotations cannot be specified in an XML 
 descriptor. We must create an XSD that allows XML-based configuration of 
 these settings.
 Additionally, to address OPENJPA-87, we should come up with a good story for 
 when only spec-level XML is used and OpenJPA annotations are also used. 
 Currently, as reported in OPENJPA-87, such a configuration causes us to 
 ignore the OpenJPA annotations.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-35) In-memory Delete operation fails with active DataCache

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-35:
---

Fix Version/s: 0.9.7
Affects Version/s: 0.9.6

 In-memory Delete operation fails with active DataCache
 --

 Key: OPENJPA-35
 URL: https://issues.apache.org/jira/browse/OPENJPA-35
 Project: OpenJPA
  Issue Type: Bug
  Components: datacache, query
Affects Versions: 0.9.0, 0.9.6
 Environment: Only happens when DataCache is active
   property name=openjpa.DataCache
 value=true/
   property name=openjpa.RemoteCommitProvider 
 value=sjvm/
Reporter: Pinaki Poddar
Priority: Critical
 Fix For: 0.9.7

 Attachments: openjpa-35.test.zip, openjpa-35.trace.txt


 Delete through query such as 
   Query query = em.createQuery(DELETE FROM Node n);
   query.executeUpdate();
 fails with following exception (only when DataCache is active)
 Exception in thread main 4|false|0.0.0 
 org.apache.openjpa.persistence.ArgumentException: 
 org.apache.openjpa.datacache.QueryCacheStoreQuery
   at 
 org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1029)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeDelete(ExpressionStoreQuery.java:665)
   at 
 org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeDelete(QueryCacheStoreQuery.java:348)
   at org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1012)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:768)
   at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:831)
   at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:827)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.deleteAll(DelegatingQuery.java:544)
   at 
 org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:299)
   at control.Test.clear(Test.java:87)
   at control.Test.run(Test.java:37)
   at control.Test.main(Test.java:178)
 Caused by: java.lang.ClassCastException: 
 org.apache.openjpa.datacache.QueryCacheStoreQuery
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:651)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:949)
   at 
 org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1018)
   ... 11 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-125) OpenJPA-specific metadata cannot be specified in XML descriptors

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-125:


Fix Version/s: 1.0.0
Affects Version/s: (was: 1.0.0)
   0.9.7
   0.9.6
   0.9.0

 OpenJPA-specific metadata cannot be specified in XML descriptors
 

 Key: OPENJPA-125
 URL: https://issues.apache.org/jira/browse/OPENJPA-125
 Project: OpenJPA
  Issue Type: New Feature
  Components: jpa
Affects Versions: 0.9.0, 0.9.6, 0.9.7
Reporter: Patrick Linskey
Priority: Critical
 Fix For: 1.0.0


 OpenJPA includes a number of annotations that extend the behavior of the JPA 
 specification. Currently, these annotations cannot be specified in an XML 
 descriptor. We must create an XSD that allows XML-based configuration of 
 these settings.
 Additionally, to address OPENJPA-87, we should come up with a good story for 
 when only spec-level XML is used and OpenJPA annotations are also used. 
 Currently, as reported in OPENJPA-87, such a configuration causes us to 
 ignore the OpenJPA annotations.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-35) In-memory Delete operation fails with active DataCache

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-35:
---

Affects Version/s: 0.9.0

 In-memory Delete operation fails with active DataCache
 --

 Key: OPENJPA-35
 URL: https://issues.apache.org/jira/browse/OPENJPA-35
 Project: OpenJPA
  Issue Type: Bug
  Components: datacache, query
Affects Versions: 0.9.0, 0.9.6
 Environment: Only happens when DataCache is active
   property name=openjpa.DataCache
 value=true/
   property name=openjpa.RemoteCommitProvider 
 value=sjvm/
Reporter: Pinaki Poddar
Priority: Critical
 Fix For: 0.9.7

 Attachments: openjpa-35.test.zip, openjpa-35.trace.txt


 Delete through query such as 
   Query query = em.createQuery(DELETE FROM Node n);
   query.executeUpdate();
 fails with following exception (only when DataCache is active)
 Exception in thread main 4|false|0.0.0 
 org.apache.openjpa.persistence.ArgumentException: 
 org.apache.openjpa.datacache.QueryCacheStoreQuery
   at 
 org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1029)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeDelete(ExpressionStoreQuery.java:665)
   at 
 org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeDelete(QueryCacheStoreQuery.java:348)
   at org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1012)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:768)
   at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:831)
   at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:827)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.deleteAll(DelegatingQuery.java:544)
   at 
 org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:299)
   at control.Test.clear(Test.java:87)
   at control.Test.run(Test.java:37)
   at control.Test.main(Test.java:178)
 Caused by: java.lang.ClassCastException: 
 org.apache.openjpa.datacache.QueryCacheStoreQuery
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:651)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:949)
   at 
 org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1018)
   ... 11 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-89) Bulk delete fails to delete owned many-to-many relationship (entry remains in join table)

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-89:
---

Fix Version/s: 0.9.7

 Bulk delete fails to delete owned many-to-many relationship (entry remains in 
 join table)
 -

 Key: OPENJPA-89
 URL: https://issues.apache.org/jira/browse/OPENJPA-89
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
 Environment: Using Apache Derby (10.2.1.6)
Reporter: David Ezzio
 Fix For: 0.9.7

 Attachments: BugOJPA-89.zip


 When executing the statement 
 em.createQuery(delete from Subject).executeUpdate();
 where Subject is in a many-to-many relationship with Book, and Subject owns 
 the relationship, one expects that the corresponding entry in the 
 SUBJECT_BOOK table would be deleted.  This happens when bulk deleting 
 one-to-many relationships that are mapped with a join table, as well as for 
 *-to-one relationships mapped with a foreign key.  It also happens when 
 individually deleting objects.  However, it does not happen when bulk 
 deleting the owning side of a many-to-many relationship.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-135) join fetch not returning duplicate references which not conforming to ejb3.0 spec

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-135:


Fix Version/s: 0.9.7

 join fetch not returning duplicate references which not conforming to ejb3.0 
 spec
 -

 Key: OPENJPA-135
 URL: https://issues.apache.org/jira/browse/OPENJPA-135
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
Reporter: Catalina Wei
 Fix For: 0.9.7


 In the description in EJB 3.0 JPA spec,  section 4.4.5.3, the following query 
 example
 SELECT d
 FROM Department d LEFT JOIN FETCH d.employees
 WHERE d.deptno = 1
 The spec says this query returns 5 references to the department 1 entity if 
 department 1 has 5 employees.
 The same query running with openjpa code, it returns only 1 reference to 
 department 1 entity.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-17) bad sql with missing subquery produced with query with nested subqueries

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-17:
---

Fix Version/s: 0.9.7

 bad sql with missing subquery produced with query with nested subqueries
 

 Key: OPENJPA-17
 URL: https://issues.apache.org/jira/browse/OPENJPA-17
 Project: OpenJPA
  Issue Type: Bug
Reporter: David Wisneski
 Fix For: 0.9.7


 EJBQL:  select c from Customer c where +
exists ( select o from Order o where o.delivered=false and + 
exists ( select c from LineItem c where c.product.backorder 0));
 SQL generated :   Note that the second EXISTS() subquery is missing. 
 DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLE
 RRMC: );red = ? AND EXISTS (;query_expr_body {prepstmnt 1454528178 SELECT 
 t3.id, t3.name, t3.rating FROM Customer t3 W
 HERE (EXISTS (SELECT t0.oid FROM Order t0 WHERE (t0.delivered = ? AND EXISTS 
 ( [params=(int) 0]} [code=-104, state=4
 2601]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-148) Parsing exception while using an exploded archive

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-148:


Fix Version/s: 0.9.7

 Parsing exception while using an exploded archive
 ---

 Key: OPENJPA-148
 URL: https://issues.apache.org/jira/browse/OPENJPA-148
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
 Environment: Sun JDK 5.0 / EasyBeans / OpenJPA snapshot 0.9.7
Reporter: Florent BENOIT
 Fix For: 0.9.7

 Attachments: debug_traces_directorymode.txt, 
 debug_traces_filemode_working.txt, stacktrace-error.txt, steps.txt


 This happens when using OpenJPA as persistence provider for the EasyBeans 
 ObjectWeb container.
 The error is happening with exploded archive.
 Exploded means that there is a directory, named entitybean.jar with a 
 folder META-INF which contains a file named persistence.xml, and other 
 directories/files for the classes.
 It seems that when using this mode, OpenJPA is trying to parse the directory 
 inputstream (which is failing).
 This exception is not occuring if a jar file is used instead of the 
 exploded mode, but the exploded mode is the default mode for EasyBeans.
 Note also that this exception don't occur by using Hibernate Entity Manager 
 or Oracle TopLink Essentials as persistence provider.
 I will attach to this issue a stack trace (with the exploded directory) which 
 fails and at the end with a jar file (which work)
 And 4 steps used to reproduce this problem

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-134) Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-134:


Fix Version/s: 0.9.7

 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.7


 Running JPAConfiguration default setting for EagerFetchMode 
 (FetchModeValue.EAGER_PARALLEL), 
 the SQL generated is sub-optimal.
 Consider the following entities:
  lineitems( OneToMany ) 
 Order  === OrderItem
 order ( ManyToOne )
 Case 1:  why not combining 2 SQL to 1 SQL ?
 =
 Order.lineitmes(EAGER):
 OrderItem.order(LAZY):
 Executing query: select o from Order o
 2173  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 
 executing prepstmnt 1299336562 
 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, 
 t0.customer_id, t0.delivered, t0.shipaddr FROM Order t0
 2213  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 
 [40 ms] spent
 2223  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 
 executing prepstmnt 1406424020 
 SELECT t0.oid, t1.lid, t1.version, t1.cost, t1.order_oid, t1.part_partno, 
 t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = t1.order_oid 
 ORDER BY t0.oid ASC
 Case 2: extra unneeded LEFT OUTER JOIN,  if eliminated, the selection aliase 
 t2 should change to t1:
 =
 Order.lineitmes(EAGER):
 OrderItem.order(LAZY):
 Executing query: select o from Order o left join fetch o.lineitems
 2403  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1314410072 
 executing prepstmnt 1500797300 
 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, 
 t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, 
 t2.cost, t2.part_partno, t2.quantity FROM Order t0 LEFT OUTER JOIN OrderItem 
 t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN OrderItem t2 ON t0.oid = 
 t2.order_oid ORDER BY t2.order_oid ASC
 Case  3: why not generating 1 SQL ?
 ==
 Order.lineitmes(EAGER):
 OrderItem.order(EAGER):
 Executing query: select o from Order o
 2343  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 
 executing prepstmnt 384833264 SELECT t0.oid, t0.version, t0.amount, 
 t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr FROM Order 
 t0
 2383  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 
 [40 ms] spent
 2393  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 
 executing prepstmnt 1722705582 
 SELECT t0.oid, t1.lid, t1.version, t1.cost, t2.oid, t2.version, t2.amount, 
 t2.customer_countryCode, t2.customer_id, t2.delivered, t2.shipaddr, 
 t1.part_partno, t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = 
 t1.order_oid LEFT OUTER JOIN Order t2 ON t1.order_oid = t2.oid ORDER BY 
 t0.oid ASC
 2393  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 
 [0 ms] spent
 3134  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 
 executing prepstmnt 950548648 
 SELECT t0.lid, t0.version, t0.cost, t1.oid, t1.version, t1.amount, 
 t1.customer_countryCode, t1.customer_id, t1.delivered, t1.shipaddr, 
 t0.part_partno, t0.quantity FROM OrderItem t0 LEFT OUTER JOIN Order t1 ON 
 t0.order_oid = t1.oid WHERE t0.order_oid = ? [params=(int) 88]
 3134  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1318342292 
 [0 ms] spent
 Case 4:  duplicate selections and redundant joins
 ==
 Order.lineitmes(EAGER):
 OrderItem.order(EAGER):
 Executing query: select o from Order o left join fetch o.lineitems
 2273  demo  TRACE  [main] openjpa.jdbc.SQL - t 1094730048, conn 1307463150 
 executing prepstmnt 1565154634 
 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, 
 t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, 
 t2.cost, t3.oid, t3.version, t3.amount, t3.customer_countryCode, 
 t3.customer_id, t3.delivered, t3.shipaddr, t2.part_partno, t2.quantity FROM 
 Order t0 LEFT OUTER JOIN OrderItem t1 ON t0.oid = t1.order_oid LEFT OUTER 
 JOIN OrderItem t2 ON t0.oid = t2.order_oid LEFT OUTER JOIN Order t3 ON 
 t2.order_oid = t3.oid ORDER BY t2.order_oid ASC

-- 
This

[jira] Updated: (OPENJPA-49) bad sql pushdown, should use inner joins but has no joins, just uses first entity

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-49:
---

Fix Version/s: 0.9.7

 bad sql pushdown, should use inner joins but has no joins, just uses first 
 entity
 -

 Key: OPENJPA-49
 URL: https://issues.apache.org/jira/browse/OPENJPA-49
 Project: OpenJPA
  Issue Type: Bug
  Components: query
 Environment: Windows xp, db2, derby
Reporter: George Hongell
 Fix For: 0.9.7

 Attachments: failureEntities.jar


 182 bad pushdown, should use inner joins but has no joins, just uses first 
 entity
  TEST182; select count(e) from EmpBean e, DeptBean d, EmpBean e1 
 15469  TRACE  [main] openjpa.jdbc.SQL - t 1094861122, conn 295440796 [0 ms] 
 executing prepstmnt 582099634 SELECT COUNT(t0.empid) FROM EmpBean t0
 s/b
 select count(t0) FROM EmpBean t0 ,DeptBean t1 ,EmpBean t2 
   [ FAILED 182- bucket = fvtfull, query = select count(e) from EmpBean e, 
 DeptBean d, EmpBean e1  : 
EXPECTED(
  TEST182; select count(e) from EmpBean e, DeptBean d, EmpBean e1 
 [500]
  TEST182; 1 tuple ) 
ACTUAL(
  TEST182; select count(e) from EmpBean e, DeptBean d, EmpBean e1 
 count(e) 
  
10
  TEST182; 1 tuple) ]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-142) Entity name is ignored when specified in the orm.xml file

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-142:


Fix Version/s: 0.9.7

 Entity name is ignored when specified in the orm.xml file
 -

 Key: OPENJPA-142
 URL: https://issues.apache.org/jira/browse/OPENJPA-142
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
Reporter: Marc Prud'hommeaux
 Fix For: 0.9.7

 Attachments: Tests-JPA-1.zip


 The XMLPersistenceMetaDataParser ignores the name attriburte of an entity 
 element, and instead always uses the default alias. For example, with the 
 following declaration in the orm.xml file:
entity name=Foo class=mypackage.Bar
 the entity will be aliased to Bar, rather than to Foo.
 Original report by Dain Sundstrom on the open-jpa-dev mailing list:
 I'm using 0.9.6 and it appears the OpenJPA is ignoring the entity name when 
 processing queries.  In stead it seems to always choose the class name for 
 the schema name of the bean.  For example, I have the following bean declared 
 in my entity mappings:
 entity name=BasicCmp2Bean 
 class=org.apache.openejb.test.entity.cmp.BasicCmp2Bean_BasicCmp2Bean
 descriptionBasicCmp2Bean/description
 attributes
 id name=id/
 basic name=firstName/
 basic name=lastName/
 /attributes
 /entity
 The following query does not work:
 SELECT o FROM BasicCmp2Bean o WHERE o.lastName = ?1
 But this one does:
 SELECT o FROM BasicCmp2Bean_BasicCmp2Bean o WHERE o.lastName = ?1
 When the query fails, I get this message (reformatted a bit with ** added to 
 important entries):
 ERROR - The bean instances business method encountered a system exception: 
 Could not locate metadata for the class using alias BasicCmp2Bean. 
 Registered alias mappings: {
 AllowedOperationsCmp2Bean_AOBasicCmp2Bean=
   [class 
 org.apache.openejb.test.entity.cmp.AllowedOperationsCmp2Bean_AOBasicCmp2Bean],
 AllowedOperationsCmpBean=
   [class org.apache.openejb.test.entity.cmp.AllowedOperationsCmpBean],
 ContextLookupCmpBean=
   [class org.apache.openejb.test.entity.cmp.ContextLookupCmpBean],
 Employee=
   [class org.apache.openejb.test.entity.cmp2.Employee],
 ManyOwningSideBean_ManyOwningSideBean=
   [class 
 org.apache.openejb.test.entity.cmr.cmrmapping.ManyOwningSideBean_ManyOwningSideBean],
 **BasicCmp2Bean_BasicCmp2Bean=
   [class org.apache.openejb.test.entity.cmp.BasicCmp2Bean_BasicCmp2Bean],
 EncCmpBean=
   [class org.apache.openejb.test.entity.cmp.EncCmpBean],
 BBean_OneToOneB=
   [class org.apache.openejb.test.entity.cmr.onetoone.BBean_OneToOneB],
 OneOwningSideBean_OneOwningSideBean=
   [class 
 org.apache.openejb.test.entity.cmr.cmrmapping.OneOwningSideBean_OneOwningSideBean],
 ABean_OneToOneA=
   [class org.apache.openejb.test.entity.cmr.onetoone.ABean_OneToOneA],
 **BasicCmp2Bean=null,
 RmiIiopCmpBean=
   [class org.apache.openejb.test.entity.cmp.RmiIiopCmpBean],
 ABean_OneToManyA=
   [class org.apache.openejb.test.entity.cmr.onetomany.ABean_OneToManyA],
 OneInverseSideBean_OneInverseSideBean=
   [class 
 org.apache.openejb.test.entity.cmr.cmrmapping.OneInverseSideBean_OneInverseSideBean],
 BBean_OneToManyB=
   [class org.apache.openejb.test.entity.cmr.onetomany.BBean_OneToManyB],
 RmiIiopCmp2Bean_Cmp2_RMI_IIOP_Bean=
   [class 
 org.apache.openejb.test.entity.cmp.RmiIiopCmp2Bean_Cmp2_RMI_IIOP_Bean],
 EncCmp2Bean_EncCmp2Bean=
   [class org.apache.openejb.test.entity.cmp.EncCmp2Bean_EncCmp2Bean],
 BasicCmpBean=
   [class org.apache.openejb.test.entity.cmp.BasicCmpBean]}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-26) JPQL parser failed to handle unary operations in arithmetic comparisons, eg. where -(e.salary+10) -10

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-26:
---

Fix Version/s: 0.9.7

 JPQL parser failed to handle unary operations in arithmetic comparisons, eg. 
 where -(e.salary+10)  -10
 ---

 Key: OPENJPA-26
 URL: https://issues.apache.org/jira/browse/OPENJPA-26
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Reporter: Catalina Wei
 Fix For: 0.9.7


 Negation only works for numeric literals, should be generalized to arithmetic 
 expressions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-152) Warn or throw an exception when a persistence unit has multiple named queries with the same name

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-152:


Fix Version/s: 0.9.7

 Warn or throw an exception when a persistence unit has multiple named queries 
 with the same name
 

 Key: OPENJPA-152
 URL: https://issues.apache.org/jira/browse/OPENJPA-152
 Project: OpenJPA
  Issue Type: Improvement
  Components: jpa
Reporter: Dain Sundstrom
 Fix For: 0.9.7


 The JPA spec makes it quite easy for uses to create multiple named queries 
 with the same name.  The problem stems from named queries being declared as 
 part of an entity either via annotations or nested xml, but the name space 
 for these queries is not scoped to the entity but scoped to the whole 
 persistence unit.  This problem is compounded due to the ease at which the 
 persistence unit is easily expanded with orm.xml files and with annotated 
 beans.
 I propose that we throw a deployment exception when the combined entity 
 mapping xml files and listed classes contain multiple named queries with the 
 same name.   If after deployment, we discover another annotate bean that 
 creates a conflict, we should log a ERROR and take extra cautions to not 
 override the existing in place query with the newly discovered one, as this 
 could drastically change the behavior of an application at runtime.
 Alternatively, we could just log warnings, but I would prefer a deployment 
 exception as it guarantees I'm not running with a randomly selected set or 
 queries.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-75) error message for missing query id var needs improvement

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-75:
---

Fix Version/s: 0.9.7

 error message for missing query id var needs improvement
 

 Key: OPENJPA-75
 URL: https://issues.apache.org/jira/browse/OPENJPA-75
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Reporter: David Wisneski
 Fix For: 0.9.7


 the query is 
 select sum(loginCount), sum(logoutCount) from AccountEntity as a where 
 a.accountProfile.userID like 'uid:%' 
 loginCount and logoutCount are declared in a MappedSuperClass.
 the correct query is 
 select sum(a.loginCount), sum(a.logoutCount) from AccountEntity as a where 
 a.accountProfile.userID like 'uid:%' 
 Rather than a syntax error, a ArgumentException was thrown.  (see below)
 Also the user would like to see a better error message in the case of a field 
 name using wrong upper/lower case.
 In other words, if the query was 
 where  a.userid = ...
 and what he intended was 
where a.userId = ...
 then the message should say   userid undefined.  DId you mean userId? 
 Also if a state field is inherited but declared private and hence not 
 visible, then error message should read 
   a.userId invalid because it is not visible rather than a.userId not 
 defined.
   4|false|0.9.0-incubating-SNAPSHOT 
 org.apache.openjpa.persistence.ArgumentException: null
 [11/3/06 12:47:04:734 CST] 003c SystemOut O 
 4|false|0.9.0-incubating-SNAPSHOT 
 org.apache.openjpa.persistence.ArgumentException: null
 [11/3/06 12:47:04:734 CST] 003c SystemOut O   at 
 org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:755)
 [11/3/06 12:47:04:734 CST] 003c SystemOut O   at 
 org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
 [11/3/06 12:47:04:734 CST] 003c SystemOut O   at 
 org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
 [11/3/06 12:47:04:734 CST] 003c SystemOut O   at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
 [11/3/06 12:47:04:734 CST] 003c SystemOut O   at 
 org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
 [11/3/06 12:47:04:734 CST] 003c SystemOut O   at 
 org.apache.openjpa.persistence.QueryImpl.getSingleResult(QueryImpl.java:271)
 [11/3/06 12:47:04:734 CST] 003c SystemOut O   at 
 org.apache.geronimo.samples.daytrader.ejb3.TradeJPA.resetTrade(TradeJPA.java:1864)
 while running a JPA query.  The code for it looks like the following:
   q = em.createQuery(select sum(loginCount), sum(logoutCount) from 
 AccountEntity as a where a.accountProfile.userID like 'uid:%');
   Object[] rs = (Object[]) q.getSingleResult();

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-113) when you specify columm table=empbean in the xml file entity id or basic type when empbean is the default table name, the mapping tool generates extra foreign key fiel

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-113:


Fix Version/s: 0.9.7

 when you specify columm table=empbean  in the xml file entity id or basic 
 type when empbean is the default table name, the mapping tool generates extra 
 foreign key field (eg.EmpBean_empid) in the table produced.
 -

 Key: OPENJPA-113
 URL: https://issues.apache.org/jira/browse/OPENJPA-113
 Project: OpenJPA
  Issue Type: Bug
 Environment: windows xp, openjpa_097_incubating
Reporter: George Hongell
 Fix For: 0.9.7


 when you specify columm table=empbean  in the xml file entity id or basic 
 type when empbean is the default table name, the mapping tool generates extra 
 foreign key field (eg.EmpBean_empid) in the table produced. This causes a 
 SQL0203 (A reference to column name is ambiguous) on empid when you try to 
 persist this entity.
 entity name=EmpBean class=EmpBean access=FIELD
 attributes
 id name=empid
column name=empid nullable=false 
 column-definition=integer /
 /id
 basic name=name fetch=EAGER
 column length=40/
 /basic
 basic name=salary fetch=EAGER 
 column name=salary table=empbean/
 /basic
 basic name=bonus fetch=EAGER
 /basic
  basic name=isManager fetch=EAGER
  /basic
  basic name=execLevel fetch=EAGER
  /basic
 basic name=hireDate fetch=EAGER
  /basic
 basic name=hireTime fetch=EAGER
  /basic
 basic name=hireTimestamp fetch=EAGER
  /basic
many-to-one name=dept 
 target-entity=com.ibm.ws.query.entities.xml.DeptBean fetch=EAGER
/many-to-one
one-to-many name=manages target-entity=DeptBean fetch=LAZY 
 mapped-by=mgr
 cascadecascade-remove//cascade
 /one-to-many
  
one-to-one name=home target-entity=AddressBean fetch=EAGER
/one-to-one
  
 one-to-one name=work target-entity=AddressBean fetch=EAGER
/one-to-one
 
 many-to-many name=tasks target-entity=TaskBean fetch=LAZY 
 mapped-by=emps
 /many-to-many
 /attributes
 /entity
 4787  mdd  TRACE  [main] openjpa.jdbc.SQL - t 1094861122, conn 1274432502 
 executing stmnt 1129857880 CREATE TABLE EmpBean (empid INTEGER NOT NULL, 
 bonus DOUBLE, execLevel INTEGER, hireDate DATE, hireTime TIME, hireTimestamp 
 TIMESTAMP, isManager SMALLINT, name VARCHAR(40), EmpBean_empid INTEGER, 
 salary DOUBLE, dept_deptno INTEGER, home_street VARCHAR(40), work_street 
 VARCHAR(40), PRIMARY KEY (empid))

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-18) bulk update to Entity with secondary table mapping produces BAD SQL

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-18:
---

Fix Version/s: 0.9.7

 bulk update to Entity with secondary table mapping produces BAD SQL
 ---

 Key: OPENJPA-18
 URL: https://issues.apache.org/jira/browse/OPENJPA-18
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Reporter: David Wisneski
 Fix For: 0.9.7


 EJBQL:update TwoTable t set  t.k1 = t.j2+1, t.j2= t.k1+1
 TwoTable is mapped to primary and secondary table,  tj1, tj2 are fields in 
 primary table,  tk1, tk2 are fields in secondary table.  
 Generated SQL from the trace shows: 
 DB2 SQL error: SQLCODE: -206, SQLSTATE: 42703, SQLERRMC: J2 {prepstmnt 
 238685754 UPDATE ttk SET k1 = (j2 + ?), j2 = (k1 + ?) WHERE id IN (SELECT 
 DISTINCT t0.id FROM ttk t0  INNER JOIN ttj t1 ON t0.id = t1.TwoTable_id) 
 [params=(long) 1, (long) 1]} [code=-206, state=42703]
 Note that  column j2 is not a column of take ttk which is the secondary 
 table.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-28) groupby clause of a subquery incorrectly duplicated in the main query in the generated SQL

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-28:
---

Fix Version/s: 0.9.7

 groupby clause of a subquery incorrectly duplicated in the main query in the 
 generated SQL
 --

 Key: OPENJPA-28
 URL: https://issues.apache.org/jira/browse/OPENJPA-28
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Reporter: Catalina Wei
 Fix For: 0.9.7


 JPquery: select e.name, e.salary from EmpBean e where (e.name = Any(select 
 e1.name from EmpBean e1 group by e1.name )) order by e.name 
 generated pushdown SQL:
 SELECT t0.name, t0.salary, t1.name FROM EmpBean t0 JOIN EmpBean t1 ON (1 = 1) 
 WHERE (t0.name = ANY((SELECT t2.name FROM EmpBean t2 GROUP BY t2.name))) 
 GROUP BY t1.name ORDER BY t0.name ASC
 correct pushdown SQL should be:
 SELECT t0.name, t0.salary, t1.name FROM EmpBean t0 JOIN EmpBean t1 ON (1 = 1) 
 WHERE (t0.name = ANY((SELECT t2.name FROM EmpBean t2 GROUP BY t2.name))) 
 ORDER BY t0.name ASC

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-51) bad sql pushdown, sub select is missing from clause

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-51:
---

Fix Version/s: 0.9.7

 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
 Fix For: 0.9.7

 Attachments: failureEntities.jar


 451 - bad sql pushdown sub select is missing from clause
  TEST451; select e from EmpBean e where e.empid  any (select e1.empid from 
 DeptBean d, in(d.emps) e1 where d.no = 200) 
 28344  TRACE  [main] openjpa.jdbc.SQL - t 1094861122, conn 295440796 [0 ms] 
 executing prepstmnt 81790176 SELECT t0.empid, t0.bonus, t2.deptno, t2.budget, 
 t2.name, t0.execLevel, t0.hireDate, t0.hireTime, t0.hireTimestamp, t3.street, 
 t3.city, t3.state, t3.zip, t0.isManager, t0.name, t0.salary, t4.street, 
 t4.city, t4.state, t4.zip FROM EmpBean t0 LEFT OUTER JOIN DeptBean t2 ON 
 t0.dept_deptno = t2.deptno LEFT OUTER JOIN AddressBean t3 ON t0.home_street = 
 t3.street LEFT OUTER JOIN AddressBean t4 ON t0.work_street = t4.street WHERE 
 (t0.empid = ANY((SELECT t1.deptno FROM DeptBean t1)))
 s/b
 select t1.empid  FROM DeptBean t0 INNER JOIN EmpBean t1 ON t0.deptno = 
 t1.dept_deptno LEFT OUTER JOIN DeptBean t3 ON t1.dept_deptno = t3.deptno 
 WHERE t1.empid  ANY((SELECT t5.empid FROM DeptBean t4 INNER JOIN EmpBean t5 
 ON t4.deptno = t5.dept_deptno  WHERE (CAST(t4.deptno AS BIGINT) = ?))) {int 
 200}
 0|false|0.0.0 org.apache.openjpa.persistence.PersistenceException: Syntax 
 error: Encountered WHERE at line 1, column 520. {SELECT t2.empid, t2.bonus, 
 t3.deptno, t3.budget, t3.name, t2.execLevel, t2.hireDate, t2.hireTime, 
 t2.hireTimestamp, t4.street, t4.city, t4.state, t4.zip, t2.isManager, 
 t2.name, t2.salary, t5.street, t5.city, t5.state, t5.zip FROM DeptBean t0 
 INNER JOIN EmpBean t1 ON t0.deptno = t1.dept_deptno LEFT OUTER JOIN DeptBean 
 t3 ON t2.dept_deptno = t3.deptno LEFT OUTER JOIN AddressBean t4 ON 
 t2.home_street = t4.street LEFT OUTER JOIN AddressBean t5 ON t2.work_street = 
 t5.street WHERE (t2.empid  ANY((SELECT t1.empid FROM  WHERE (CAST(t0.deptno 
 AS BIGINT) = CAST(? AS BIGINT)} [code=3, state=42X01]
   at 
 org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3713)
   at 
 org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
   at 
 org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
   at 
 org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
   at 
 org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:152)
   at 
 org.apache.openjpa.lib.rop.EagerResultList.init(EagerResultList.java:37)
   at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1161)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:936)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
   at 
 com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at 
 junit.extensions.jfunc.TestletWrapper.runBare(TestletWrapper.java:116)
   at 
 junit.extensions.jfunc.TestletWrapper$1.protect(TestletWrapper.java:106)
   at junit.framework.TestResult.runProtected(Unknown Source)
   at junit.extensions.jfunc.TestletWrapper.run(TestletWrapper.java:109)
   at junit.framework.TestSuite.runTest(Unknown Source)
   at junit.framework.TestSuite.run(Unknown Source)
   at junit.extensions.jfunc.JFuncSuite.run(JFuncSuite.java:134)
   at

[jira] Updated: (OPENJPA-80) Bad Escaping for LIKE in MySQL

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-80:
---

Fix Version/s: 0.9.7

 Bad Escaping for LIKE in MySQL
 --

 Key: OPENJPA-80
 URL: https://issues.apache.org/jira/browse/OPENJPA-80
 Project: OpenJPA
  Issue Type: Bug
  Components: query
 Environment: openJPA 0.9.7 
 MySQL 5.0.15
Reporter: Jakob Braeuchi
 Fix For: 0.9.7


 the following query :
 em.createQuery(select k from KategorieGruppe k  where k.bezeichnung like ?1 
 order by k.bezeichnung asc);
 generates an sql-statement with a bad escaping character '\' for MySQL :
 SELECT t0.id, t0.bezeichnung FROM ekv2kategoriegruppe t0 WHERE 
 (t0.bezeichnung LIKE ? ESCAPE '\') ORDER BY t0.bezeichnung ASC
 the correct escaping would be '\\'.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-78) Automatic runtime enhancement only works when the class is listed in the first persistence-unit

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-78:
---

Fix Version/s: 0.9.7

 Automatic runtime enhancement only works when the class is listed in the 
 first persistence-unit
 ---

 Key: OPENJPA-78
 URL: https://issues.apache.org/jira/browse/OPENJPA-78
 Project: OpenJPA
  Issue Type: Bug
  Components: kernel
Reporter: Marc Prud'hommeaux
 Fix For: 0.9.7


 When multiple persistence-units are defined in the persistence.xml, only the 
 first one is examined when looking for classes to enhance when using the 
 automatic runtime enhancement (e.g., using the -javaagent:openjpa.jar 
 argument). So if the project uses the following persistence.xml:
 persistence xmlns=http://java.sun.com/xml/ns/persistence; version=1.0
 persistence-unit name=unit1 transaction-type=RESOURCE_LOCAL
 classunit1.SomeClass/class
 /persistence-unit
 persistence-unit name=unit2 transaction-type=RESOURCE_LOCAL
 classunit2.SomeClass/class
 /persistence-unit
 /persistence
 In this example, when unit1.SomeClass is loaded, it will be enhanced, but 
 unit2.SomeClass won't ever be enhanced.
 The only workaround is to list all of your persistent classes in an initial 
 entry in the persistence-unit.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-9) PCEnhancer not processing multiple PU's defined within a single persistence.xml file

2007-02-28 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Patrick Linskey updated OPENJPA-9:
--

Fix Version/s: 0.9.7

PCEnhancer not processing multiple PU's defined within a single
persistence.xml file

Key: OPENJPA-9
URL: https://issues.apache.org/jira/browse/OPENJPA-9
Project: OpenJPA
Issue Type: Bug
Components: jpa
Reporter: Kevin Sutter
Fix For: 0.9.7

From a discussion with Patrick on the dev mailing list...
=
Me: According to the JPA spec, we can define multiple persistence-units in a
single persistence.xml file. But, when I try to use this persistence.xml
file as input to the PCEnhancer, it is only processing the first
persistence-unit that is defined. I traced through the code and found that
this is the case. When the persistence.xml file is processed, a null name
is passed in for the desired persistence-unit (in the
ConfigurationProviderImpl.load method) and, thus, only the first one defined
is returned and used by the PCEnhancer.
Patrick: IMO, the correct behavior should be:
- PCEnhancer run with no arguments should load all the PUs in the
classpath, find the OpenJPA (or unspecified) PUs, and run against all
the classes defined by those PUs (including auto-scanning for PUs so
configured).
- The developer should not need to specify META-INF/persistence.xml when
invoking the PCEnhancer.
- We may want to provide a means to specify specific PUs to process. For
example:
java ...PCEnhancer -p META-INF/persistence.xml#foo
or maybe just
java ...PCEnhancer -p #foo
for shorthand.
Regardless, the current behavior seems wrong, and it seems that the best
initial change would be to make PCEnhancer load all the PUs (the first
bullet above), which means manually loading the META-INF/persistence.xml
resources and finding the ones that are OpenJPA PUs, rather than relying
on the javax.persistence.Persistence helper method to load them.
=
Writing this bug report so as not to lose track of this problem.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-46) true, false not case insensitive, gets null pointer exception

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-46:
---

Fix Version/s: 0.9.7

 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
 Fix For: 0.9.7

 Attachments: failureEntities.jar


 140 - true,false should be case insensitive - gets npe
   [ FAILED 140- bucket = fvtfull, query = select e from EmpBean e where 
 (e.isManager = True)  : 
EXPECTED(
  TEST140; select e from EmpBean e where (e.isManager = True) 
 [( class com.dw.test.EmpBean  empid=2 name=andrew salary=13.1 dept=210)]
 [( class com.dw.test.EmpBean  empid=1 name=david salary=12.1 dept=210)]
  TEST140; 2 tuples ) 
ACTUAL(
  TEST140; select e from EmpBean e where (e.isManager = True) 
  e   
  
 null 
  TEST140; 1 tuple) ]
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:672)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:934)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
   ... 23 more
 4|false|0.0.0 org.apache.openjpa.persistence.ArgumentException: null
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:755)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
   at 
 com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at 
 junit.extensions.jfunc.TestletWrapper.runBare(TestletWrapper.java:116)
   at 
 junit.extensions.jfunc.TestletWrapper$1.protect(TestletWrapper.java:106)
   at junit.framework.TestResult.runProtected(Unknown Source)
   at junit.extensions.jfunc.TestletWrapper.run(TestletWrapper.java:109)
   at junit.framework.TestSuite.runTest(Unknown Source)
   at junit.framework.TestSuite.run(Unknown Source)
   at junit.extensions.jfunc.JFuncSuite.run(JFuncSuite.java:134)
   at junit.extensions.jfunc.textui.JFuncRunner.doRun(JFuncRunner.java:76)
   at junit.extensions.jfunc.textui.JFuncRunner.start(JFuncRunner.java:398)
   at junit.extensions.jfunc.textui.JFuncRunner.main(JFuncRunner.java:218)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.openjpa.jdbc.kernel.exps.PCPath.initialize(PCPath.java:362)
   at 
 org.apache.openjpa.jdbc.kernel.exps.CompareEqualExpression.initialize(CompareEqualExpression.java:78)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.initialize(SelectConstructor.java:166)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.newSelect(SelectConstructor.java:115)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:69)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:324)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:165)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:672)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:934)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
   ... 23 more
 141 same
  TEST141; select e from EmpBean e where (e.isManager = fAlSe) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-143) Problems with Single Table Inheritance Strategy (and Discriminator Type of Integer)

2007-02-28 Thread Patrick Linskey (JIRA)

[
https://issues.apache.org/jira/browse/OPENJPA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Patrick Linskey updated OPENJPA-143:

Fix Version/s: 0.9.7

Problems with Single Table Inheritance Strategy (and Discriminator Type of
Integer)
---

Key: OPENJPA-143
URL: https://issues.apache.org/jira/browse/OPENJPA-143
Project: OpenJPA
Issue Type: Bug
Components: jpa
Reporter: Kevin Sutter
Fix For: 0.9.7

Using the @DiscriminatorType of Integer with Single Table Inheritance, I've
come across two problems...
o The @DiscriminatorValue seems to be required on abstract classes in the
hierarchy. This should not be required. Actually, according to section
9.1.31 of the spec, this annotation should only be required on concrete
classes. But, without this annotation, I am getting an exception about not
being able to cast a String to an Int.
o This exception that I am receiving with a missing @DiscriminatorValue
would indicate that the default value being provided by OpenJPA is a String
all the time instead of basing the default the value off of the
DiscriminatorType of Integer. This is further described in Table 21 of
section 9.1.31 of the spec.
As described, I have a workaround by specifying a @DiscriminatorValue on the
abstract class, but these seem to be real problems that need to be addressed.
Thus, this defect.
Kevin

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-112) Native queries and named parameters: poor error message

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-112:


Fix Version/s: 0.9.7

 Native queries and named parameters: poor error message
 ---

 Key: OPENJPA-112
 URL: https://issues.apache.org/jira/browse/OPENJPA-112
 Project: OpenJPA
  Issue Type: Bug
 Environment: windows xp, openjpa_097_incubating
Reporter: Patrick Linskey
 Fix For: 0.9.7


 native queries fail when use named parameters
  int parm3 = 100;
 String sql = SELECT deptno,budget,NAME,MGR_EMPID,REPORTSTO_DEPTNO FROM 
 DeptBean WHERE deptno = :deptno ;
 Query getDept = _em.createNativeQuery(sql,DeptBean.class
 getDept.setParameter(deptno,parm3);
 ListDeptBean rl = (getDept.getResultList());
 4|false|0.9.7-incubating-SNAPSHOT 
 org.apache.openjpa.persistence.ArgumentException: The parameter name or 
 position deptno passed to execute() is not valid.  All map keys must be a 
 declared parameter name or a number matching the parameter position. 
   at 
 org.apache.openjpa.kernel.QueryImpl.toParameterArray(QueryImpl.java:897)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:825)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:763)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:520)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:224)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:264)
   at 
 com.ibm.ws.query.tests.JUNamedNativeQueryTest.testSelectDeptBean2(JUNamedNativeQueryTest.java:514)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at junit.framework.TestCase.runTest(Unknown Source)
   at junit.framework.TestCase.runBare(Unknown Source)
   at junit.framework.TestResult$1.protect(Unknown Source)
   at junit.framework.TestResult.runProtected(Unknown Source)
   at junit.framework.TestResult.run(Unknown Source)
   at junit.framework.TestCase.run(Unknown Source)
   at junit.framework.TestSuite.runTest(Unknown Source)
   at junit.framework.TestSuite.run(Unknown Source)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-83) Bad SQL for Subselect BETWEEN

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-83:
---

Fix Version/s: 0.9.7

 Bad SQL for Subselect BETWEEN
 -

 Key: OPENJPA-83
 URL: https://issues.apache.org/jira/browse/OPENJPA-83
 Project: OpenJPA
  Issue Type: Bug
  Components: query
 Environment: openJPA 0.9.7
 MySQL 5.0.15
Reporter: Jakob Braeuchi
 Fix For: 0.9.7


 the following query generates an sql with no table in the FROM-clause of the 
 subselct:
 em.createQuery(select k from Kauf k where  +
 ((select sum(p.betrag) from Posten p where p.kauf = k) between :betrVon and 
 :betrBis)  +
 order by k.datum asc);
 SELECT t1.id, t1.bemerkung, t1.datum, t2.id, t2.idEinkauferAlt, t2.name
 FROM ekv2kauf t1 LEFT OUTER JOIN ekv2einkaufer t2 ON t1.idEinkaufer = t2.id
 WHERE ((SELECT SUM(t0.betrag) FROM WHERE (t0.idKauf = t1.id)) = ? AND 
 (SELECT SUM(t0.betrag) FROM WHERE (t0.idKauf = t1.id)) = ?) ORDER BY 
 t1.datum ASC
 [params=(double) 1800.0, (double) 3000.0]
 when i use the query without BETWEEN it works:
 em.createQuery(select k from Kauf k where  +
 ((select sum(p.betrag) from Posten p where p.kauf = k)  :betr)  +
 order by k.datum asc);
 SELECT t1.id, t1.bemerkung, t1.datum, t2.id, t2.idEinkauferAlt, t2.name
 FROM ekv2kauf t1 LEFT OUTER JOIN ekv2einkaufer t2 ON t1.idEinkaufer = t2.id
 WHERE ((SELECT SUM(t0.betrag) FROM ekv2posten t0 WHERE (t0.idKauf = t1.id))  
 ?)
 ORDER BY t1.datum ASC
 [params=(double) 1800.0]
 when i rewrite the query using groupby / having it also works, but the 
 generated sql does not use BETWEEN:
 em.createQuery(select p.kauf from Posten p  +
 group by p.kauf  +
 having sum(p.betrag) between :betrVon and :betrBis  +
 order by p.kauf.datum asc);
 SELECT t1.id, t1.bemerkung, t1.datum, t1.idEinkaufer
 FROM ekv2posten t0 INNER JOIN ekv2kauf t1 ON t0.idKauf = t1.id
 GROUP BY t1.id, t1.bemerkung, t1.datum, t1.idEinkaufer
 HAVING SUM(t0.betrag) = ? AND SUM(t0.betrag) = ?
 ORDER BY t1.datum ASC
 [params=(double) 1800.0, (double) 3000.0]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-57) persistence_1_0.xsd is missing

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-57:
---

Fix Version/s: 0.9.7

 persistence_1_0.xsd is missing
 --

 Key: OPENJPA-57
 URL: https://issues.apache.org/jira/browse/OPENJPA-57
 Project: OpenJPA
  Issue Type: Improvement
Reporter: Stefan Arentz
 Fix For: 0.9.7


 It seems to be common that JPA providers include persistence_1_0.xsd in one 
 of the distribution jars. I'm not sure if this is according to the spec but 
 some tools such as Spring already depend on that behaviour.
 This is probably mostly relevant for using JPA in a J2SE environment as I 
 think the xsd is probably provided by the app server.
 Discussion on the Spring forum about this:
  
 http://forum.springframework.org/showthread.php?t=26209highlight=persistence_1_0.xsd
  S.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-132:


Fix Version/s: 0.9.7

 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
 Fix For: 0.9.7


 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] Updated: (OPENJPA-22) locate substring queries fail both db2 derby, cannot use parameter markers in expression ?-?

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-22:
---

Fix Version/s: 0.9.7

 locate  substring queries fail both db2  derby, cannot use parameter 
 markers in expression ?-?
 

 Key: OPENJPA-22
 URL: https://issues.apache.org/jira/browse/OPENJPA-22
 Project: OpenJPA
  Issue Type: Bug
  Components: query
Reporter: David Wisneski
 Fix For: 0.9.7


 EJB Q::   SELECT d.name FROM DeptBean d WHERE SUBSTRING(d.name,1,10) = 'Dept' 
   
  
 DB2 SQL error: SQLCODE: -417, SQLSTATE: 42609, SQLERRMC: null {prepstmnt 
 1662018320 SELECT t0.name FROM DeptBean t0
 WHERE (SUBSTR(CAST((t0.name) AS VARCHAR(1000)), CAST(((? - ?)) AS INTEGER) + 
 1, CAST(((? + (? - ?))) AS INTEGER) - CAST(((?
 - ?)) AS INTEGER)) = ?) [params=(long) 1, (int) 1, (long) 10, (long) 1, (int) 
 1, (long) 1, (int) 1, (String) Dept]}
 [code=-417, state=42609]
 EJB QL SELECT e.name FROM EmpBean e WHERE LOCATE('10',e.name,5)  0 
 DB2 SQL error: SQLCODE: -417, SQLSTATE: 42609, SQLERRMC: null 
 {prepstmnt 1217808534 SELECT t0.name FROM EmpBean t0 WHERE
 (((LOCATE(CAST((?) AS VARCHAR(1000)), CAST((t0.name) AS VARCHAR(1000)), 
 CAST(((? - ?)) AS INTEGER) + 1) - 1) + ?) 
 ?) [params=(String) 10, (long) 5, (int) 1, (int) 1, (long) 0]} [code=-417, 
 state=42609]
  TEST411; 1 tuple
 I am not sure why OpenJPA generates the sql expression ?-?.  The proper SQL 
 should be 
 SELECT t0.name FROM DeptBean t0  WHERE  substr (to.name, CAST ((?) as 
 INTEGER),  CAST ((?) as INTEGER)   with parm values ( Integer 1,  Integer 10)
 Although it helps query reuse to replace literals with parm markers and then 
 pass the literal values as parm values,  this is not always 
 best in a system like DB2 which uses distribution statistics and cost based 
 optimization to compute the sql access path.  The better sql would 
 simply be 
 SELECT t0.name FROM DeptBean t0  WHERE  substr (to.name,1, 10)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OPENJPA-153) WebSphere and non-jta-data-source and default ManagedRuntime

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-153.
-

Resolution: Fixed

I believe that the only remaining issue here is captured in OPENJPA-149.

 WebSphere and non-jta-data-source and default ManagedRuntime
 

 Key: OPENJPA-153
 URL: https://issues.apache.org/jira/browse/OPENJPA-153
 Project: OpenJPA
  Issue Type: Improvement
  Components: jdbc
 Environment: WebSphere 6.1
Reporter: Patrick Linskey

 See OPENJPA-144. It would seem that in a WebSphere environment, when 
 specifying a non-jta-data-source, the JDBC connection that OpenJPA looks up 
 does not permit calls to Connection.commit(). This, in conjunction with 
 OPENJPA-149, means that in a default configuration, OpenJPA cannot use 
 non-JTA data sources in a WebSphere environment.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-147) T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-147:


Fix Version/s: 1.0.0

 T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is 
 interface
 -

 Key: OPENJPA-147
 URL: https://issues.apache.org/jira/browse/OPENJPA-147
 Project: OpenJPA
  Issue Type: Bug
  Components: jpa
Reporter: Pinaki Poddar
 Fix For: 1.0.0

 Attachments: iface.trace.1.txt, iface.trace.2.txt, iface.trace.3.txt, 
 iface.trace.4.txt, IPerson.java, TestInterface.java


 According to JavaDoc, OpenJPAEntityManager.createInstance() method 
public T T createInstance(ClassT cls);
  behaves as follows:
 Create a new instance of type codecls/code. If codecls/code is
   an interface or an abstract class whose abstract methods follow the
   JavaBeans convention, this method will create a concrete implementation
   according to the metadata that defines the class
 The method fails when T is an interface. The failure may be due to incorrect 
 user configuration, however, further
 information on this extension method is not available in OpenJPA 
 documentation.
 Firstly, how to specify metadata for a interface that has bean-style methods? 
 Possibilities are:
 a) Annotating the Java interface definition with @Entity 
 b) Specifying in classorg.acme.IPerson/class in persistence.xml
 Either of the above fails. a) fails at parsing b) fails with no metadata 
 There may be a correct but undocumented way of specifying a managed 
 interface. If that is the case, then this JIRA report should be treated as a 
 documentation bug. 
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-145) support Java5 wildcard on OpenJPA

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-145:


Fix Version/s: 1.0.0

 support Java5 wildcard on OpenJPA
 -

 Key: OPENJPA-145
 URL: https://issues.apache.org/jira/browse/OPENJPA-145
 Project: OpenJPA
  Issue Type: Improvement
  Components: jpa, kernel
 Environment: OPENJPA 0.95
Reporter: yun teng
 Fix For: 1.0.0


 This enhancement request is to support  Java 5 wildcard on OpenJPA. The java 
 5 widecard is defined at 
 http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeArguments.html#Wildcards
 Currently, iusing java 5 widecard annotation in OpenJPA will cause 
 org.apache.openjpa.persistence.ArgumentException
 for example
 package parent;
 public Class Account {
 ...
 @OneToMany(mappedBy=account, cascade={CascadeType.ALL})
   private Set? extends AccountPerson accountPersonCollection; ...}
 public Class AccountPerson{...}
 __
 package child;
 public Class Account extend parent.Account {
 }
 public Class AccountPerson{..}
  
 In such case, the parent.Account has relationship to parent.AccountPerson, 
 while child.Account has relationship to child.AccountPerson. Now if I do not 
 use wildcard, my test passed.  If I use wildcard, Java compile and Kodo 
 enhancement all worked fine.  But at runtime, I got the following exception
 766  TRACE  [main] openjpa.MetaData - Resolving field
 [EMAIL PROTECTED]
 ion.
 766  WARN   [main] openjpa.MetaData - OpenJPA cannot map field
 com.psi.vida.platform.entity.pojo.Account.accountPersonCollection
 efficiently.  It is of an unsupported type. The field value will be 
 serialized to a BLOB by default. 4|true|0.9.5-incubating
 org.apache.openjpa.persistence.ArgumentException: Errors encountered while 
 resolving metadata.  See nested exceptions for details.
   at 
 org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.ja
 va:500)
   at 
 org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepositor
 y.java:284)
   at 
 org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepositor
 y.java:519)
   at 
 org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.ja
 va:480)
   at 
 org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepositor
 y.java:284)
   at
 org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2343)
   at
 org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2196)
   at kodo.kernel.KodoBroker.persist(KodoBroker.java:155)
   at 
 org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java
 :991)
   at 
 org.apache.openjpa.persistence.EntityManagerImpl.persist(EntityManagerIm
 pl.java:486)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
 a:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
 Impl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManag
 erInvocationHandler.invoke(SharedEntityManagerCreator.java:176)
   at $Proxy5.persist(Unknown Source)
   at 
 com.psi.vida.platform.util.VidaEntityManager.saveNew(VidaEntityManager.j
 ava:160)
   at 
 com.psi.vida.platform.util.VidaEntityManager.save(VidaEntityManager.java
 :114)
   at 
 com.psi.vida.platform.util.VidaEntityManagerTest.testSave(VidaEntityMana
 gerTest.java:50)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
 a:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
 Impl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at junit.framework.TestCase.runTest(TestCase.java:154)
   at junit.framework.TestCase.runBare(TestCase.java:127)
   at 
 org.springframework.test.ConditionalTestCase.runBare(ConditionalTestCase
 .java:69)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:118)
   at junit.framework.TestSuite.runTest(TestSuite.java:208)
   at junit.framework.TestSuite.run(TestSuite.java:203)
   at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTe
 stRunner.java:421)
   at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUni
 tTestRunner.java:912)
   at

[jira] Resolved: (OPENJPA-93) Sequence generation in a JTA environment should not require non-JTA datasource

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-93.


Resolution: Fixed

The feature works, but OPENJPA-149 currently prevents it from working in a 
WebSphere environment in a default configuration. See OPENJPA-149 for a 
workaround.

 Sequence generation in a JTA environment should not require non-JTA datasource
 --

 Key: OPENJPA-93
 URL: https://issues.apache.org/jira/browse/OPENJPA-93
 Project: OpenJPA
  Issue Type: New Feature
  Components: jdbc
Reporter: Patrick Linskey
 Assigned To: Patrick Linskey

 When obtaining non-transactional sequence numbers in a JTA environment when 
 no non-jta-data-source or JDBC connection information is supplied, OpenJPA 
 should suspend the current transaction, perform the sequence maintenance in a 
 new transaction, commit, and resume the suspended transaction.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-84) Escape sql reserved words in column names

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-84:
---

Fix Version/s: 1.0.0

 Escape sql reserved words in column names
 -

 Key: OPENJPA-84
 URL: https://issues.apache.org/jira/browse/OPENJPA-84
 Project: OpenJPA
  Issue Type: Improvement
  Components: sql
Reporter: Roger Keays
 Fix For: 1.0.0


 OpenJPA does not escape reserved words in SQL queries when they are used as 
 column names. To escape a reserved name you just put it in quotes:
 INSERT INTO FB_PRIVILEGES (comment, inheritable, level, role, type, username, 
 item_uuid) ...
 on oracle, becomes 
 INSERT INTO FB_PRIVILEGES (comment, inheritable, level, role, type, 
 username, item_uuid) ...
 Looking at the code in DBDictionary, it appears that the escaping is done for 
 table and sequence names by appending a numeral to the name. There isn't 
 really any good reason to do this instead of quoting the identifier.
 table.name identifiers would have to be escaped as table.name if both 
 table and name were reserved words.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OPENJPA-71) Caching primitive array types consumes excessive memory

2007-02-28 Thread Patrick Linskey (JIRA)


 [ 
https://issues.apache.org/jira/browse/OPENJPA-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey updated OPENJPA-71:
---

Fix Version/s: 0.9.7

What happens if openjpa.DynamicDataStructs is enabled?

 Caching primitive array types consumes excessive memory
 ---

 Key: OPENJPA-71
 URL: https://issues.apache.org/jira/browse/OPENJPA-71
 Project: OpenJPA
  Issue Type: Bug
  Components: datacache
Reporter: Roger Keays
 Fix For: 0.9.7


 As reported on the mailing list: 
 http://www.nabble.com/cached-byte---consumes-excessive-memory-tf2543098.html 
 , in org.apache.openjpa.AbstractPCData#toData() an ArrayList is used to cache 
 all types of arrays, including arrays of primitives. This can use excessively 
 large amounts of memory because of the wrappers required for each element in 
 the array. In one test case, a 7MB byte[] consumed 127MB when converted to a 
 cached ArrayList.
 AbstractPCData needs to be fixed to handle simple arrays.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

1 2 3 >

1 - 100 of 219 matches

Mail list logo