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

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(a)hibernate.org&gt; wrote: > On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: > >> 2016-01-29 17:18 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> > 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. >