Marc,
All my experiments are just that - experiments. My goal is to enable DDL
generation in GlassFish when the persistence provider is set to that of the
OpenJPA and the user-visible behavior is similar to the one we have for CMP
(i.e. our internal code) and for TopLink Essentials as 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
Marc,
I'd rather have provider-neutral code in GlassFish ;(.
The problem with adding new columns to the existing table in my example below is
a) in having a PK in the table that is not mapped to any field the entity, and
b) not making the entity's id a pk (I didn't get any warning from not
Marc,
I'm trying to run MappingTool to look at -sql option, but I can't make it to
work with a PU without connecting to the database (my persistence.xml has
jta-data-source), and I can't find in the docs how to specify the DBDictionary
without persistence.xml.
thanks,
-marina
Marc
Marina-
On Mar 20, 2007, at 4:02 PM, Marina Vatkina wrote:
Marc,
Thanks for the pointers. Can you please answer the following set of
questions?
1. The doc requires that In order to enable automatic runtime
mapping, you must first list all your persistent classes. Is this
true for EE
Marc,
Marc Prud'hommeaux wrote:
Marina-
On Mar 20, 2007, at 4:02 PM, Marina Vatkina wrote:
Marc,
Thanks for the pointers. Can you please answer the following set of
questions?
1. The doc requires that In order to enable automatic runtime
mapping, you must first list all your
Marina-
They do in SE, but as there is no requirement to do it in EE,
people try to reduce the amount of typing ;).
Hmm ... we might not actually require it in EE, since we do examine
the ejb jar to look for persistent classes. I'm not sure though.
You should test with both listing them
DDL generation in a Java EE environment?
Marina-
They do in SE, but as there is no requirement to do it in EE, people
try to reduce the amount of typing ;).
Hmm ... we might not actually require it in EE, since we do examine the
ejb jar to look for persistent classes. I'm not sure though
Marc,
Marc Prud'hommeaux wrote:
Marina-
They do in SE, but as there is no requirement to do it in EE, people
try to reduce the amount of typing ;).
Hmm ... we might not actually require it in EE, since we do examine the
ejb jar to look for persistent classes. I'm not sure though.
You
Then I'll first start with an easier task - check what happens in EE if entities
are not explicitly listed in the persistence.xml file :).
thanks,
-marina
Marc Prud'hommeaux wrote:
Marina-
Let me give it a try. How would the persistence.xml property look
like to generate .sql file?
To: open-jpa-dev@incubator.apache.org
Subject: Using DDL generation in a Java EE environment?
Hi,
I am part of the GlassFish persistence team and was wondering
how does OpenJPA
support JPA auto DDL generation (we call it java2db) in a
Java EE application
server.
Our application server
Marina-
On Mar 15, 2007, at 5:01 PM, Marina Vatkina wrote:
Hi,
I am part of the GlassFish persistence team and was wondering how
does OpenJPA support JPA auto DDL generation (we call it java2db)
in a Java EE application server.
Our application server supports java2db via creating two
Hi,
I am part of the GlassFish persistence team and was wondering how does OpenJPA
support JPA auto DDL generation (we call it java2db) in a Java EE application
server.
Our application server supports java2db via creating two sets of files for each
PU: a ...dropDDL.jdbc and a
14 matches
Mail list logo
