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

andrea boriero dreborier at gmail.com
Tue Feb 2 16:21:34 EST 2016


i think it's better to drop

On 2 February 2016 at 21:10, Steve Ebersole <steve at 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 <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.
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list