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 <drebor...@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 <st...@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 <st...@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 <gun...@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 <st...@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 <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
