2016-01-29 17:18 GMT+01:00 Steve Ebersole <st...@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 <gun...@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 <st...@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 <gun...@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 <st...@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 <gun...@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 <st...@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 >> >> >> > <gun...@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.s...@gmail.com >> >> >: >> >> >> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole < >> >> st...@hibernate.org> >> >> >> >> wrote: >> >> >> >> > >> >> >> >> >> If you clean up the conflicts I can look for 5.1 >> >> >> >> >> >> >> >> >> > >> >> >> >> > Done! >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Guillaume >> >> >> >> > _______________________________________________ >> >> >> >> > hibernate-dev mailing list >> >> >> >> > hibernate-dev@lists.jboss.org >> >> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> >> >> > _______________________________________________ >> >> >> > hibernate-dev mailing list >> >> >> > hibernate-dev@lists.jboss.org >> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
