[hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date)

Gunnar Morling gunnar at hibernate.org
Fri Jan 29 11:40:41 EST 2016 

2016-01-29 17:18 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> I also plan on adding an @Incubating annotation for just such things :)

Yes, please. We have an annotation @Experimental in OGM which we use
for tagging APIs under development.

>
> Anyway, I will start on this today.  It will take a few days though I think.
> I'll let you know when I have something ready to look at.
>
> P.S.  Do you agree with what I said on your PR wrt TargetBase?

Yes, I do.

Not sure why I pulled the SQL logger into the base class tbh., as you
say it really makes only sense in the DB impl. I did not mean
TargetBase to be extended/customized by OGM, just to centralize some
stuff between the different impls in ORM. But that's mood with your
proposed redesign anyways I think.

>
>
> On Fri, Jan 29, 2016 at 10:15 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> Hi Steve,
>>
>> What you suggest sounds good. I've added a comment to
>> https://hibernate.atlassian.net/browse/HHH-10458 itself.
>>
>> The reason why I didn't go for this from the beginning just was that I
>> didn't want to break the contract of SchemaCreator and the other
>> delegates.
>>
>> --Gunnar
>>
>>
>>
>>
>> 2016-01-28 19:27 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > For this to work will require some significant changes.  The main one
>> > being
>> > to combine JPA's support for schema generation along
>> > with SchemaManagementTool.  The reason being simply that I will need to
>> > encapsulate the interpretation of all these settings behind
>> > the SchemaManagementTool facade in order for things to properly
>> > replace SchemaManagementTool as Gunnar suggests.
>> >
>> > I am starting this work now on top of the work Gunnar has already done
>> > on
>> > the PR he sent[1].  But that work is just the tip of the iceberg.  So if
>> > you have input to this, speak soon.
>> >
>> >
>> > [1] https://github.com/hibernate/hibernate-orm/pull/1231
>> >
>> > 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
>> >>
>> > _______________________________________________
>> > 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