[hibernate-dev] 5.1 tentative release date

Wed Jan 20 07:13:51 EST 2016

I went for the proposed intermediary step to avoid breaking the API of
SchemaManagementTool and its delegates. If you have a way for not
breaking the API or think breaking it is alright, then +1 for doing
the ProperSolution™ in 5.1.

What would it comprise, changing the delegate methods such as
doCreate() to expect a single parameter object providing all the
required info? Target could be a part of this, just an enum probably,
based on wich delegates would do their thing. If it's that, I can try
and help out with it.

Regarding the release schedule, I'd personally be fine with pushing it
a bit back, but then I don't know whether there are any other hard
timelines to be met.

2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> 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 <gunnar at 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 <steve at 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 <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
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev