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

[Steve Ebersole]

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 at 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 at 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 at 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 at 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 at 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 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
>>
>