Marina-
Let me give it a try. How would the persistence.xml property look
like to generate .sql file?
Actually, I just took a look at this, and it look like it isn't
possible to use the "SynchronizeMappings" property to automatically
output a sql file. The reason is that the property takes a standard
OpenJPA plugin string that configures an instances of MappingTool,
but the MappingTool class doesn't have a setter for the SQL file to
write out to.
So I think your only recourse would be to write your own adapter to
to this that manually creates a MappingTool instance and runs it with
the correct flags for outputting a sql file. Take a look at the
javadocs for the MappingTool to get started, and let us know if you
have any questions about proceeding.
On Mar 20, 2007, at 4:59 PM, Marina Vatkina wrote:
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 should test with both listing them and not listing them. I'd
be interested to know if it works without.
Let me give it a try. How would the persistence.xml property look
like to generate .sql file? Where will it be placed in EE
environment? Does it use use the name as-is or prepend it with
some path?
thanks.
On Mar 20, 2007, at 4:19 PM, Marina Vatkina wrote:
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 persistent
classes". Is this true for EE case also?
Yes. People usually list them all in the <class> tags in the
persistence.xml file.
They do in SE, but as there is no requirement to do it in EE,
people try to reduce the amount of typing ;).
If OpenJPA can identify all entities in EE world, why can't it
do the same for the schema generation?
I'll check the rest.
thanks,
-marina
2. Section "1.2.Generating DDL SQL" talks about .sql files,
but what I am looking for are "jdbc" files, i.e. files with
the lines that can be used directly as java.sql statements to
be executed against database.
The output should be sufficient. Try it out and see if the
format is something you can use.
3. Is there a document that describes all possible values for
the "openjpa.jdbc.SynchronizeMappings" property?
Unfortunately, no. Basically, the setting of the
"SynchronizeMappings" property will be of the form "action
(Bean1=value1,Bean2=value2)", where the "bean" values are
those listed in org.apache.openjpa.jdbc.meta.MappingTool
(whose javadoc you can see http://incubator.apache.org/openjpa/
docs/latest/ javadoc/org/ apache/openjpa/jdbc/meta/
MappingTool.html ).
thank you,
-marina
Marc Prud'hommeaux wrote:
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
sets of files for each PU: a ...dropDDL.jdbc and
a ...createDDL.jdbc file on deploy (i.e. before the
application is actually loaded into the container) and
then executing 'create' file as the last step in
deployment, and 'drop' file on undeploy or the 1st step in
redeploy. This allows us to drop tables created by the
previous deploy operation.
This approach is done for both, the CMP and the default
JPA provider. It would be nice to add java2db support for
OpenJPA as well, and I'm wondering if we need to do
anything special, or it'll all work just by itself?
We do have support for runtime creation of the schema via
the "openjpa.jdbc.SynchronizeMappings" property. It is
described at:
http://incubator.apache.org/openjpa/docs/latest/manual/
manual.html#ref_guide_mapping_synch
The property can be configured to run the mappingtool (also
described in the documentation) at runtime against all the
registered persistent classes.
Here are my 1st set of questions:
1. Which API would trigger the process, assuming the
correct values are specified in the persistence.xml file?
Is it:
a) <provider>.createContainerEntityManagerFactory(...)? or
b) the 1st call to emf.createEntityManager() in this VM?
c) something else?
b
2. How would a user drop the tables in such environment?
I don't think it can be used to automatically drop then
create tables. The "mappingtool" can be executed manually
twice, the first time to drop all the tables, and the
second time to re- create them, but I don't think it can be
automatically done at runtime with the
"SynchronizeMappings" property.
3. If the answer to either 1a or 1b is yes, how does the
code distinguish between the server startup time and the
application being loaded for the 1st time?
That is one of the reasons why we think it would be
inadvisable to automatically drop tables at runtime :)
4. Is there a mode that allows creating a file with the
jdbc statements to create or drop the tables and constraints?
Yes. See:
http://incubator.apache.org/openjpa/docs/latest/manual/
manual.html#ref_guide_ddl_examples
thank you,
-marina