Thank you, Albert, for your experimentation. The updated schema definition
(openjpa_orm_1_0.xsd) and the example openjpa_orm.xml seems to be what we
are looking for. I guess the only concern is whether we can count on other
JPA implementations to ignore this extra schema definition and just
I think that this is because it's still scanning the repository. I'm
guessing that once that's done, things will settle down.
We used to use FishEye for Kodo source browsing; it's awesome.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
Firstly, thanks for putting this together.
I don't think that portability is a huge problem. I agree with the three
scenarios that Albert mentioned, but I think that we can refine #1:
1) if an application wants to be fully portable between providers, the
standard orm.xsd must be specified.
Matthieu-
My only other guess is that you might not actually be using your
ManagedRuntime setting, because we might need it to be a String (the
fully-qualified class name of your ManagedRuntime implementation),
rather than an actual instance of the class. Can you try specifying
the class
Thanks for all the options, I'll try that.
On 1/24/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Matthieu-
My only other guess is that you might not actually be using your
ManagedRuntime setting, because we might need it to be a String (the
fully-qualified class name of your ManagedRuntime
@SqlResultSetMappings fails in mapping tool with java.lang.ArrayStoreException
--
Key: OPENJPA-107
URL: https://issues.apache.org/jira/browse/OPENJPA-107
Project: OpenJPA
@AttributeOverrides fails in mapping tool with java.lang.ArrayStoreException
Key: OPENJPA-108
URL: https://issues.apache.org/jira/browse/OPENJPA-108
Project: OpenJPA
every NativeQuery using SqlResultSetMapping fails at runtime with There is no
query result mapping for null with name xxx when the entity is persisted in
a different method than the method doing the query.
[
https://issues.apache.org/jira/browse/OPENJPA-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467214
]
Marc Prud'hommeaux commented on OPENJPA-108:
This sounds like a bug with the IBM JVM, as reported at
[
https://issues.apache.org/jira/browse/OPENJPA-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467215
]
Marc Prud'hommeaux commented on OPENJPA-107:
This is the same comment as I made in OPENJPA-108. This
[
https://issues.apache.org/jira/browse/OPENJPA-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467216
]
Marc Prud'hommeaux commented on OPENJPA-110:
It looks like you are getting back a list of Integers.
native queries fail when use named parameters
-
Key: OPENJPA-111
URL: https://issues.apache.org/jira/browse/OPENJPA-111
Project: OpenJPA
Issue Type: Bug
Environment: windows xp,
[
https://issues.apache.org/jira/browse/OPENJPA-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Prud'hommeaux resolved OPENJPA-111.
Resolution: Invalid
Section 3.6.3 of the JPA spec: Only positional parameter
[
https://issues.apache.org/jira/browse/OPENJPA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467219
]
Patrick Linskey commented on OPENJPA-112:
-
While the failure is legit (see OPENJPA-111), the error message
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:
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.
16 matches
Mail list logo