[hibernate-dev] 5.1 tentative release date

[Steve Ebersole]

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 <steve at 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 <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
>>
>