[hibernate-dev] 5.1 tentative release date

Steve Ebersole steve at hibernate.org
Thu Jan 14 09:51:14 EST 2016


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 at 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 at gmail.com>:
> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> If you clean up the conflicts I can look for 5.1
> >>
> >
> > Done!
> >
> > --
> > Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list