Re: [hibernate-dev] 5.1 tentative release date
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> 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>:
> On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve(a)hibernate.org>
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