users@jpa-spec.java.net

[jpa-spec users] Extensibility of schema generation

From: Christian Kaltepoth <christian_at_kaltepoth.de>
Date: Thu, 7 Feb 2013 17:26:08 +0100

Hello all,

first let me emphasize that I'm really happy to see that JPA 2.1 will
support database schema generation. In my opinion this is a very important
and useful feature for everyone working with JPA.

According to the current draft of the spec, JPA will support automatic
creation of the database schema from mapping metadata and custom DDL
scripts. The problem I'm seeing here is that these methods typically only
work well if there is no initial database at all. But this is rarely the
case. A very frequent case is that the database schema is not *created* but
*migrated*. New versions of existing applications often require the
database schema to be modified. In these cases the schema creation methods
described in the current draft are not really useful. Of cause the JPA
provider is able to automatically create missing tables and columns, but
typically developers need more control over the migration process.
Especially when doing real schema refactorings like column data type
changes, modified constraints, etc.

There are very good tools out there that focus on database schema migration
like Liquibase [1] or Flyway [2]. But unfortunately there is no really easy
portable way to integrate these tools into a JEE application.

So I was thinking that it may be a good addition to the spec to provide an
extension point for the schema creation process. This would be a great
feature because it would allow users to customize the schema creation in
any way they want. They could integrate 3rd party tools specialized in
database schema migration or they could build their own way of working with
schema versions and their migration.

I could think of an API like this:

public interface SchemaGenerationProvider {
  void generateSchema(java.sql.Connection connection, java.util.Properties
map)
}

One option to specify an implementation for custom schema generation would
be to set a property for the persistent unit like this:

javax.persistence.schema-generation.provider-class=com.example.myapp.MySchemaGenerationProvider

Another option would be to use the standard JDK ServiceLoader mechanism.

What do you think? Does it make sense to provided portable extensibility
for the schema generation process? Is it worth adding it to the spec?

I would love to get feedback on this.

Best regards

Christian Kaltepoth

[1] http://www.liquibase.org/
[2] http://flywaydb.org/


-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal