I'd like to get this work into 5.1. But, as much as possible, I'd like to get the ProperSolution in place rather than just a StepInTheRightDirection. If we need to push this date 2-4 weeks I am ok with that. That would help us coordinate with Infinispan 8.2 schedule (iiuc) for hibernate-infinispan, not to mention I still have to review the work Vlad has done on the docs again as well as polish the load-by-multi-id API[1].
[1] Sanne still waiting on your feedback to the open question of internal routing of those calls. On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gun...@hibernate.org> wrote: > 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 <st...@hibernate.org>: > > 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 <gun...@hibernate.org> > 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.s...@gmail.com>: > >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <st...@hibernate.org> > >> wrote: > >> > > >> >> If you clean up the conflicts I can look for 5.1 > >> >> > >> > > >> > Done! > >> > > >> > -- > >> > Guillaume > >> > _______________________________________________ > >> > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
