Ehcache is all of those things iiuc. You are more than welcome to help Louis, Alex, Sanne and the rest of us work on that JSR-107 based integration to get it integrated sooner since its so important for you and since its such a travesty ;)
On Thu, Jan 14, 2016 at 8:51 AM Steve Ebersole <st...@hibernate.org> wrote: > 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
