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 <st...@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 <st...@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 <st...@hibernate.org> >> wrote: >>> >>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling <gun...@hibernate.org> >>> wrote: >>>> >>>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole <st...@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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
