[hibernate-dev] 5.1 tentative release date

Tue Jan 19 10:25:09 EST 2016

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
>