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 ;).
thanks,
-marina
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 https://issues.apache.org/jira/browse/OPENJPA-94 for
details about how to do this.
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?
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
