[hibernate-dev] 5.1 tentative release date

Steve Ebersole steve at hibernate.org
Fri Jan 22 10:16:32 EST 2016 

And please let's not take that to mean "let's add more tasks to 5.1 now..."
;)

On Fri, Jan 22, 2016 at 9:16 AM Steve Ebersole <steve at hibernate.org> wrote:

> I just pushed 5.1 back to Feb 10th in order to get all this work in.
>
> On Wed, Jan 20, 2016 at 6:13 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> 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
>>
>

More information about the hibernate-dev mailing list