openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar" <>
Subject RE: Using DDL generation in a Java EE environment?
Date Tue, 20 Mar 2007 23:26:16 GMT
 > They do in SE, but as there is no requirement to do it in EE, people 
> try to reduce the amount of typing ;).

In EE, persistent classes can be specified via
a) explictly via <class>
b) via one or more <jar-file>
c) via one or more <mapping-file>
d) leave everything unspecified and OpenJPA will scan for @Entity
annotated classes in the deployed unit 

Pinaki Poddar
BEA Systems

-----Original Message-----
From: Marc Prud'hommeaux [] On Behalf Of
Marc Prud'hommeaux
Sent: Tuesday, March 20, 2007 6:22 PM
Subject: Re: Using DDL generation in a Java EE environment?


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

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

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

View raw message