[hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date)

Steve Ebersole steve at hibernate.org
Tue Feb 2 16:10:40 EST 2016

Part of the work here is going to require significant changes
to org.hibernate.tool.hbm2ddl.SchemaExport,
and org.hibernate.tool.hbm2ddl.SchemaValidator.  Significant as in current
usages would not work at all.  So does it make sense to do those changes,
or to simply drop those classes?

On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole <steve at hibernate.org> wrote:

> I am debating with myself about
> reusing `javax.persistence.schema-generation.database.action` and `javax.persistence.schema-generation.scripts.action`
> in terms of this new unified support.  The debate point being the fact that
> we'd have to have those accept an extended range of values which
> potentially hurts users in terms of JPA provider portability.  For example,
> if they have:
> javax.persistence.schema-generation.database.action=validate
> Hibernate would understand that, but other providers likely would not.
> This is beyond the concept of "strict compliance" I started in SQM in my
> opinion.  Here we are moving toward a unification, meaning we expect people
> to use this.
> So do we reuse the JPA names?
> On a related note.. in regards to the fact that JPA splits action between
> script and database target whereas hbm2ddl defines just a singular action
> value... does anyone know of a real case where someone defines different
> actions between script and database?  I mean aside from one being NONE.  I
> mean cases where they say we should do "create" for scripts but send
> "drop-and-create" to the database?  That just seems odd to me.  I think we
> have to account for the split since we have to account for JPA, and that
> model fits both.  I was just curious
> On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>> > I also plan on adding an @Incubating annotation for just such things :)
>>> Yes, please. We have an annotation @Experimental in OGM which we use
>>> for tagging APIs under development.
>> See https://hibernate.atlassian.net/browse/HHH-10487.  I also started a
>> separate discussion about this on the dev list.
>> BTW, as an extension to changing  SchemaManagementTool another thing I'd
>> like to add is some hook account for Envers use cases.  Specifically the
>> idea there is to be able to do a few things:
>> 1) perform a selective create/drop.  selective in terms of just certain
>> objects.  This may be achievable through the new filter concept, although
>> we'd at least need a way to identify Envers tables from non-Envers tables.
>> Think of starting to use Hibernate+Envers on a schema that already exists.
>> 2) perform "actions".  This is maybe beyond "schema tooling"; perhaps it
>> is more of a SessionFactory boot concept.  But one thing Envers misses
>> today that would be good to add is the ability to "prime" the audit
>> tables.  Meaning, for audited entities that do not have entries in their
>> audit table, create one.  This for sure goes beyond simple SQL statements
>> though.

More information about the hibernate-dev mailing list