Re: [hibernate-dev] 5.1 tentative release date

Hi Steve, As discussed on IRC, I tried plugging in my own SchemaManagementTool and delegates and letting them do the initialization work required for OGM. I am hitting a wall though when it comes to the usage in the SchemaExport controller: As it's invoking doCreate() and doDrop() right in the constructor with a "fake" target for delegating the SQL statements, I am bitten by the fact that SchemaExport is instantiated twice in SessionFactoryImpl (once for create, once for drop at shutdown), so I see to invocations to doCreate() and doDrop(). Also I am lacking the knowledge of what's passed as Target for the controller invocation. So I went ahead and changed SchemaExport to invoke SchemaCreator and -Dropper only in execute(), passing them actual Target implementations as it's done in SchemaUpdate, too. It's not yet what you described as the ultimate goal (not looping back to Target), but IMO it's a step into the right direction, not the least making things consistent between SchemaExport and SchemaUpdate and also leaving APIs largely unchanged for the time being. With that I should be able to do it on the OGM side as you suggested, essentially ignoring the Target/Exporter stuff. I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231 for the change. Let me know what you think. Cheers, --Gunnar 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > I am not sure I am a big fan of The String->Object change specifically. In > theory it sounds great. But there is a major premise in schema tooling > around the idea of the actions being reduce-able to Strings. That's > important not just for SQL, but for the idea of writing to a file as well. > It also affects the whole concept of Exporter/Exportable. > > The ultimate design goal here is to unify schema creation and dropping > across native and JPA requirements. I just simply have not had the time to > work on that. This would all happen "behind" SchemaManagementTool and > friends. SchemaExport, etc are actually just controllers responsible for > coordinating the calls into the SchemaManagementTool delegates. The main > problem at the moment IMO is that Target gets passed into these > SchemaManagementTool delegates. Ideally, and certainly this would fit with > your case, I think we want SchemaManagementTool or its delegates to handle > interpreting the "arguments". This was part of the intent of developing > the "CommandLineArgs" stuff that is used inside SchemaExport, etc now; the > idea was to encapsulate the settings each tool needs to operate and isolate > the process of building/interpreting those args. > > The next step I wanted to look at there was to morph CommandLineArgs into a > more generic "parameter object" for initializing the actual > SchemaManagementTool delegates. > > The idea is that the more we can push into SchemaManagementTool and its > delegates the more pluggable this entire process becomes. Ultimately, as I > mentioned above, I just do not think it is feasible for ORM and OGM to > share all of these implementation contracts. Forcing a switch from String > (the DDL) arguments to some amorphic Object reinforces that in my mind. > But that would not stop OGM from completely swapping SchemaManagementTool > and its delegates and simply not using Target, Exporters, etc. > > > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > >> Hi Steve, >> >> One thing useful to have for OGM would be a generalization of the >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not >> all of them are "schemaless", e.g. Cassandra works with a fixed >> schema, and while MongoDB largely is schemaless, we still want to >> create stuff like indexes in the database. >> >> I took a look and found that SchemaManagementTool as a pluggable >> service already goes halfway into that direction. The issue with it is >> that I cannot replace the list of exporters used by SchemaExport nor >> the list of tool targets used by SchemaUpdate. Having a pluggable >> service allowing me to customize that with an OGM-specific >> implementation should do the trick. >> >> As per some comments in the code, SchemaExport seems to be in some >> intermediary state, where the ops are not executed directly through >> the targets passed to SchemaCreator/Dropper but are read into String >> arrays which are then passed on to separate exporters. I suppose part >> of that work should be to consolidate this and basically follow the >> same approach as used in SchemaUpdate? >> >> Another facet is that for some OGM grid dialects we'd need another >> representation of commands than Strings, as not all the backends have >> a DDL but expect API invocations for that purpose. For that it'd be >> required to change Target#accept(String) into accept(Object) so we can >> pass some kind of command object. File exports would only work in a >> limited fashion, but we could live with that. Schema creation/dropping >> bound to the SF lifecycle is what I am after here. >> >> I'd be willing to work on this once we agree on the general approach. >> >> Any thoughts? >> >> Thanks, >> >> --Gunnar >> >> >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet(a)gmail.com&gt;: >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> > >> >> If you clean up the conflicts I can look for 5.1 >> >> >> > >> > Done! >> > >> > -- >> > Guillaume >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev