+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
