i think it's better to drop On 2 February 2016 at 21:10, Steve Ebersole <st...@hibernate.org> wrote:
> 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
