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

[Steve Ebersole]

For anyone familiar using SchemaExport from the command line...  Am I
interpreting this correctly when I see that `--create` means "just create"
and `--drop` means "just drop"? From what I can tell, passing both seems to
(looking at the code) cause just drop to happen.

Anyone else find that extremely counter-intuitive?  Any objection to
instead exposing an `--action` option that can be one of "create", "drop",
"create-and-drop", and "none"?  And where "create-and-drop" is the default?

On Wed, Feb 3, 2016 at 6:50 AM Steve Ebersole <steve at hibernate.org> wrote:

> 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.
>>
>