openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <>
Subject Re: Using DDL generation in a Java EE environment?
Date Tue, 20 Mar 2007 23:09:10 GMT

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 
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:
>> 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:
>> manual.html#ref_guide_ddl_examples
>>> thank you,
>>> -marina

View raw message