Re: Preliminary design for supporting OpenJPA annotations in XML metadata.

Patrick- That's precisely what I had envisioned. In theory, all we'd need to do is provide a means to override the mechanism by which we obtain the annotations, and it might just magically work. This does presume that the hierarchy of the JPA-standard annotations matches the hierarchy of

RE: Preliminary design for supporting OpenJPA annotations in XML metadata.

Patrick, I did something similar (but not quite the same) for some JPA prototyping some months back. I wrote a tool that would introspect the JPA annotation classes, and for each one (e.g. "interface Xyz"), would spit out an 'equivalent' class XyzMetaData. For example: package com.sybase.jpa.me

Re: Preliminary design for supporting OpenJPA annotations in XML metadata.

I haven't read David and Marc's most recent emails, but here's an idea that I've been toying with in terms of unifying annotation and XML parsing: annotations are interfaces, so presumably we can create new instances of types that implement them somehow. (Maybe the JVM prevents this; I haven't tes

Re: unenhanced class support

Hi, I attached my current patch to OPENJPA-293. There are a number of open issues in the patch marked by '#' marks -- I'd appreciate another set of eyes on those items in particular, and on the patch in general. Aside from that, I'm planning to run the CTS without enhancement on at some poin

[jira] Updated: (OPENJPA-293) OpenJPA should not require managed type enhancement

[ https://issues.apache.org/jira/browse/OPENJPA-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey updated OPENJPA-293: Attachment: OPENJPA-293.patch Patch to make enhancement optional. This feature is pretty e

[jira] Created: (OPENJPA-293) OpenJPA should not require managed type enhancement

OpenJPA should not require managed type enhancement --- Key: OPENJPA-293 URL: https://issues.apache.org/jira/browse/OPENJPA-293 Project: OpenJPA Issue Type: New Feature Components: do

Re: Preliminary design for supporting OpenJPA annotations in XML metadata.

David- I think that sums up the pros and cons pretty well. My only 2 comments: persistence-xxx and jdbc-xxx where xxx is the simple name of the annotation I'd vote for just "xxx" and "jdbc-xxx" (due to a strong dislike for over-long XML names). b) the annotations do not contain any info

Re: Preliminary design for supporting OpenJPA annotations in XML metadata.

Hi Marc and Patrick, Thanks for your early feedback. Let's see if I understand the important points: 1. Leverage the information in the OpenJPA annotations to autogenerate the XSD document. The XSD schema will have an XML element per annotation. Use some aliases (I'm thinking persistence-xxx a

Re: [jira] Commented: (OPENJPA-263) Introducing getAll(List) method for data cache to be called by loadAll() will allow data cache plug-ins to leverage the advantage of any third-party cache that prov

Yes, the objects with map field relationship is also implemnted and will go thru getAll(). Thx. On 7/20/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/OPENJPA-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125

[jira] Created: (OPENJPA-292) Extra JOIN on eager bi-directional relationship

Extra JOIN on eager bi-directional relationship --- Key: OPENJPA-292 URL: https://issues.apache.org/jira/browse/OPENJPA-292 Project: OpenJPA Issue Type: Bug Affects Versions: 1.0.0

RE: Please Help: Kodo wraps JDOUserException jdoPreStore() with FatalDataStoreException forcing transaction rollback

Hello Patrick, Thank you for your reply. Could you guys at least help me to convince BEA support that this behavior is not in compliance with specs? As it is they keep saying it works per specs and refuse to do anything. Aren't you and Neelan still Kodo program/tech managers? An email from yo

Re: Please Help: Kodo wraps JDOUserException jdoPreStore() with FatalDataStoreException forcing transaction rollback

Hi, Sadly, nothing that happens in this community has any impact on Kodo 3. OpenJPA is only used in Kodo 4.1 and newer. I believe that this behavior is different in Kodo 4.1 at least -- the fatal-ness of an exception is separate from its type now. It looks like in OpenJPA, we setRollbackOnly whe

Please Help: Kodo wraps JDOUserException jdoPreStore() with FatalDataStoreException forcing transaction rollback

Hello everyone, I noticed that at some point in Kodo 3.x its behavior changed. Now it catches any exception including JDOUserException thrown in jdoPreStore() and wraps it in FatalDataStoreException which forces transaction rollback and preventing further retry. JDOUserException is a retriable

[jira] Commented: (OPENJPA-266) Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable

[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515020 ] Patrick Linskey commented on OPENJPA-266: - Agreed. Additionally, it is already trivial for vendors to repack

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

[ https://issues.apache.org/jira/browse/OPENJPA-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514991 ] Kevin Sutter commented on OPENJPA-172: -- Craig, This issue is related to OPENJPA-149, but it's not quite the sam

[jira] Commented: (OPENJPA-266) Add Extensibility: Change "private" field/method to "protected" or "public" in OpenJPA classes to be extendable

[ https://issues.apache.org/jira/browse/OPENJPA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514987 ] Michael Dick commented on OPENJPA-266: -- The last change regarding DBDictionaries looks like it's a good start,