11:21 a.m.
For anyone familiar using SchemaExport from the command line... Am I
interpreting this correctly when I see that `--create` means "just create"
and `--drop` means "just drop"? From what I can tell, passing both seems to
(looking at the code) cause just drop to happen.
Anyone else find that extremely counter-intuitive? Any objection to
instead exposing an `--action` option that can be one of "create",
"drop",
"create-and-drop", and "none"? And where "create-and-drop"
is the default?
On Wed, Feb 3, 2016 at 6:50 AM Steve Ebersole <steve(a)hibernate.org> wrote:
The API does need to change. So we can leave the classes, but every
usage
of them would need to be adjusted. Well every usage other than CLI, which
you mention, which is a decent point. So I'll leave the classes in place,
but change the contracts.
On Wed, Feb 3, 2016 at 12:58 AM Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> 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 <steve(a)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 <steve(a)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(a)hibernate.org>
> >> wrote:
> >>>
> >>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling
<gunnar(a)hibernate.org
> >
> >>> wrote:
> >>>>
> >>>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole
<steve(a)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.
>