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

[Gunnar Morling]

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.