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

[Steve Ebersole]

The API does need to change.  So we can leave the classes, but every usage
of them would need to be adjusted.  Well every usage other than CLI, which
you mention, which is a decent point.   So I'll leave the classes in place,
but change the contracts.

On Wed, Feb 3, 2016 at 12:58 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> When you say dropping, what would be the alternative for CLI users? It
> seems like a strong change to do in a minor revision.
>
> What are the required changes you need to do here? My hope would have
> been that the API of these tools would not have to change.
>
> 2016-02-02 22:10 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > Part of the work here is going to require significant changes to
> > org.hibernate.tool.hbm2ddl.SchemaExport,
> > org.hibernate.tool.hbm2ddl.SchemaUpdate 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.
>