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