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

[Steve Ebersole]

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