12:03 p.m.
Sorry I mean to say "drop-and-create", not "create-and-drop", to
follow the
JPA.
I guess if we are adding this it is a good time to address a confusion
between JPA and our action names. So JPA defines an action "create" which
we previously did not have in terms of hbm2ddl.auto' JPA's "create" is
a
"create only". hbm2ddl.auto did also defione a "create" action, but
it is
equivalent to what JPA calls "drop-and-create", meaning "drop the schema
and then (re)create it".
I think it is also a good idea to make this consistent with the
hbm2ddl.auto options. To account for JPA's "create" I added a new
enumeration called "create-only". So in terms of hbm2ddl.auto options we
have:
* none
* create-only
* drop
* create (which is drop-and-create)
* create-drop (drop-and-create + drop on SF-close)
* update
* validate
Ideally we'd consolidate on JPA's terms in regards to
create-only/create/drop-and-create, but that would mean a very surprising
outcome for people using `hbm2ddl.auto=create` and expecting the legacy
behavior.
On Wed, Feb 3, 2016 at 11:28 AM andrea boriero <dreborier(a)gmail.com> wrote:
+1 for `--action` option with "create", "drop",
"create-and-drop", and
"none"
not sure if as default value is better "create" or "create-and-drop"
On 3 February 2016 at 17:21, Steve Ebersole <steve(a)hibernate.org> wrote:
> 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.
> >>
> >
>
_______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>