Add failonerror=true to the java task example at enhancingwithmaven.html
--
Key: OPENJPA-195
URL: https://issues.apache.org/jira/browse/OPENJPA-195
Project: OpenJPA
[
https://issues.apache.org/jira/browse/OPENJPA-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on OPENJPA-196 started by Marc Prud'hommeaux.
Ease the restrictions on forcing a matche between the number of declared and
assigned positional parameters
Seem fair enough to get rid of the description. I've opened https://
issues.apache.org/jira/browse/OPENJPA-196 describing the issue.
+1 from me to remove the restriction that there be exactly as many
positional parameters declared as were assigned.
On Mar 31, 2007, at 7:32 PM, Dain
[
https://issues.apache.org/jira/browse/OPENJPA-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Prud'hommeaux updated OPENJPA-196:
---
Attachment: OPENJPA-196.patch
This siple patch removed the restirction.
Ease the
Marina-
The sql flag merely says that OpenJPA should write the SQL to an
external file. It still needs to connect to the database in order to
see which tables currently exist, so it can determine if it needs to
create new tables or columns.
If you just want a fresh database view for the
On Mar 30, 2007, at 4:17 PM, Marina Vatkina wrote:
Marc,
I'd rather have provider-neutral code in GlassFish ;(.
Well, until the JPA spec (or some other spec) provides details on how
schema creation and/or migration should work, I don't think it is
realistic to expect every vendor to
Hi Jeff,
The reason that this is done is so you can create an instance of the
PageId class without having a persistent (or detached) instance of
Book. The way it works now, if you have the id of the Book you can
construct an instance of the PageId by also supplying the page number.
If
+1.
On a side note, I really don't understand why named and positional
parameters are in separate namespaces.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may
+1 to remove the restriction. As long as no parameters are missing,
the query should be considered sufficient.
Craig
On Apr 1, 2007, at 9:30 AM, Marc Prud'hommeaux wrote:
Seem fair enough to get rid of the description. I've opened https://
issues.apache.org/jira/browse/OPENJPA-196