openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marina Vatkina <Marina.Vatk...@Sun.COM>
Subject Re: Using DDL generation in a Java EE environment?
Date Tue, 20 Mar 2007 23:59:19 GMT
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
>>>>>>
>>>>
>>
> 


Mime
View raw message