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 Mon, 19 Mar 2007 02:36:58 GMT
Hi Patrick,

I'll check the docs for more details, but what would happen if the user changes 
the entities between deployments in such a way that the new schema is not 
compatible with the previous one (e.g. there is no more entity B that the entity 
A has been referencing before, or that entity B has been renamed to X)?

People do find our java2db feature very useful and like an option to have the 
settings stored in the persistence.xml (though there are deployment command 
option to cause drop and create the tables). With the settings in the 
persistence.xml, we need to suppress them on load of PU for TopLink Essentials 
so that the schema is not recreated between the server restarts.

I'll probably have more questions after I poke around the docs ;).


Patrick Linskey wrote:
> Hi,
> I'm typing this while offline, so don't have access to the OpenJPA docs
> URL, so can't include any links. Much of this is discussed in the
> documentation, however.
>>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?
> OpenJPA does already have features that generally do what you're
> mentioning.
>>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?
> When using the openjpa.jdbc.SynchronizeMappings property in the
> persistence.xml file, I believe that it's the first call to
> emf.createEntityManager().  You can also directly interact with the
> MappingTool and SchemaTool programmatically.
>>2. How would a user drop the tables in such environment?
> The MappingTool and SchemaTool provide table drop capabilities. However,
> why do you want to drop the tables in such an environment? Typically,
> I've found that what people want is to clean out their tables so that at
> the beginning of a test run, they're working with empty tables. OpenJPA
> supports an option to automatically synchronize the database tables with
> what's in the current mappings, and then issue a DELETE statement
> against each table. In a test environment, this is often much faster
> than doing schema mutation. Additionally, it is more common to have
> permission to delete all rows in the database than to do schema
> manipulation. See for
> details about how to do this.
>>3. If the answer to either 1a or 1b is yes, how does the code 
>>between the server startup time and the application being 
>>loaded for the 1st time?
> It doesn't.
>>4. Is there a mode that allows creating a file with the jdbc 
>>statements to 
>>create or drop the tables and constraints?
> Yes.
> -Patrick

View raw message