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.
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
