Re: [hibernate-dev] Configuration to support batching (or sorting) of DELETE statements efficiently
Thanks! that looks like a very good idea. On 28 January 2016 at 05:48, Vlad Mihalcea wrote: > I created this JIRA issue for this: > > https://hibernate.atlassian.net/browse/HHH-10483 > > Vlad > > On Wed, Jan 27, 2016 at 7:02 PM, Vlad Mihalcea > wrote: > >> Then we can add this task as a feature request and see when we have some >> time to add support for it. >> >> Vlad >> >> On Wed, Jan 27, 2016 at 6:54 PM, Steve Ebersole >> wrote: >> >>> Just pesky things like resources ;) >>> >>> On Wed, Jan 27, 2016 at 12:43 AM Vlad Mihalcea >>> wrote: >>> This must be done like insert but in reverse order. With inserts, we need to add parents first and children after, because of the foreign key constraints. For delete, we need to group children first and delete them prior to deleting parents. Is there something that prevents us from implementing this feature? Vlad On Wed, Jan 27, 2016 at 7:01 AM, Madhusudana Reddy Sunnapu < smreddy2...@gmail.com> wrote: > Hi, > > Hibernate provides simple configuration properties to enable batch inserts > and updates using "hibernate.order_inserts" and "hibernate.order_updates" > respectively. These setting allow hibernate to sort the insert and update > statements and process them in batches efficiently. > > But we don't have such a configuration to sort or batch delete statements > efficiently. Especially with CascadeType.DELETE we can see that delete > statements are not batched effectively and could result in extra network > calls to the database for deletion.(Refer: > > http://vladmihalcea.com/2015/03/26/how-to-batch-delete-statements-with-hibernate/ > ) > > So I am thinking wouldn't it be a good feature to have hibernate support > similar configuration, say "hibernate.order_deletes", to enable batch > deletes similar to updates and inserts. > > Cheers, > Madhu. > ___ > 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
Re: [hibernate-dev] JDBC warnings performance matter
I agree with providing a specific property to enable this behaviour. I noticed also that handleAndClearWarnings(Connection connection,WarningHandler handler) does the walking without checking for the log level. On 28 January 2016 at 07:59, Gunnar Morling wrote: > Is the call also expensive if there are no SQL warnings (i.e. null is > returned, so no further walking is required)? > > It'd be my hope that drivers should be able to fetch the first warning > - if any - upon statement execution without further round-trips. So > getWarnings() would be cheap if no warnings exist. In that case people > should IMHO actually fix the warnings instead of complaining that > reporting them takes time. > > If it is a general perf issue also if no SQL warnings exist, +1 for > having a property for opting into logging them. > > 2016-01-28 8:46 GMT+01:00 Emmanuel Bernard : > > If that’s effectively widespread, I think indeed we should guard this > feature with an explicit property. > > It’s not necessarily easy to anticipate such consequences when designing > things. > > In insight, something more explicit looks better. > > > >> On 28 Jan 2016, at 06:25, Vlad Mihalcea > wrote: > >> > >> Hi, > >> > >> The guys at Plumbr wrote an article about how MySQL JDBC warnings are > >> handled by Hibernate: > >> > >> > https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate > >> > >> I remember seeing this issue on StackOverflow too and I was curious if > you > >> want to tweak it a little bit. > >> I also agree that relying on the log levels to prevent fetching warnings > >> might come as a surprise to many users and we should document this > behavior. > >> > >> We could also have a hibernate.jdbc.log.warnings boolean property to > >> control whether we want to log those warnings or not. > >> This way, if users set the logger level to WARN, they will see the logs > >> generated by the framework stack and the JDBC warnings will be logged > only > >> if this configuration property is true. > >> > >> What do you think? > >> > >> Vlad > >> ___ > >> 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
Re: [hibernate-dev] JDBC warnings performance matter
+1 to allow a setting to control *logging* of SQLWarnings. I find it silly that MySQL handle it this way (I can only find reference to MySQL when I google search for `JDBC getSQLWarnings performance`) in terms of it being such a performance hit. However I really do not like the idea of fencing the *clearing* of SQLWarnings based on this setting. On Thu, Jan 28, 2016 at 6:14 AM andrea boriero wrote: > I agree with providing a specific property to enable this behaviour. > > I noticed also that handleAndClearWarnings(Connection > connection,WarningHandler handler) does the walking without checking for > the log level. > > > > > On 28 January 2016 at 07:59, Gunnar Morling wrote: > > > Is the call also expensive if there are no SQL warnings (i.e. null is > > returned, so no further walking is required)? > > > > It'd be my hope that drivers should be able to fetch the first warning > > - if any - upon statement execution without further round-trips. So > > getWarnings() would be cheap if no warnings exist. In that case people > > should IMHO actually fix the warnings instead of complaining that > > reporting them takes time. > > > > If it is a general perf issue also if no SQL warnings exist, +1 for > > having a property for opting into logging them. > > > > 2016-01-28 8:46 GMT+01:00 Emmanuel Bernard : > > > If that’s effectively widespread, I think indeed we should guard this > > feature with an explicit property. > > > It’s not necessarily easy to anticipate such consequences when > designing > > things. > > > In insight, something more explicit looks better. > > > > > >> On 28 Jan 2016, at 06:25, Vlad Mihalcea > > wrote: > > >> > > >> Hi, > > >> > > >> The guys at Plumbr wrote an article about how MySQL JDBC warnings are > > >> handled by Hibernate: > > >> > > >> > > > https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate > > >> > > >> I remember seeing this issue on StackOverflow too and I was curious if > > you > > >> want to tweak it a little bit. > > >> I also agree that relying on the log levels to prevent fetching > warnings > > >> might come as a surprise to many users and we should document this > > behavior. > > >> > > >> We could also have a hibernate.jdbc.log.warnings boolean property to > > >> control whether we want to log those warnings or not. > > >> This way, if users set the logger level to WARN, they will see the > logs > > >> generated by the framework stack and the JDBC warnings will be logged > > only > > >> if this configuration property is true. > > >> > > >> What do you think? > > >> > > >> Vlad > > >> ___ > > >> 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 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in Oracle
-1 for me. -- View this message in context: http://hibernate-development.74578.x6.nabble.com/Re-hibernate-dev-HHH-6726-LONG-and-LONG-RAW-column-types-in-Oracle-tp1224p1243.html Sent from the Hibernate Development mailing list archive at Nabble.com. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Travis support
Hi Guillaume, I am a bit skeptical as we have CI working already on ci.hibernate.org and having limited people we can't really afford to fix things which already work. That said, this does look good, and it's certainly positive that we can get some free computation resources from travis.org as our AWS bills are getting high. Definitely positive that the build configurations are versioned; we have auditing of configuration changes on Jenkins [ci.hibernate.org] but having it in git looks very nice. I'm not entirely convinced about having the job configurations within the repository itself though - there should be some freedom in running different combinations, and try new job configurations without having to send pull requests; not least branches will go out of synch. There is a jenkins plugin which will take the job configuration from the repository if we think that is important: I played with it but it didn't seem very mature when I tried the first Alpha release. The Infinispan and WildFly teams have switched from Jenkins to TeamCity and are very happy with it; one of the reasons for them to prefer it over Jenkins is that it does a great job at tracking evolution over time of failures of a specific test: you can examine the build stability from various perspectives. But it's not OSS so it loses some points there. Another strong candidate which we discusses some times is to use Atlassian's Bamboo. That seems another very strong product, and would have the additional benefit of great integration with JIRA which I think we all love, and we get excellent help from Atlassian as they sponsor our JIRA installation. Using Bamboo could help us streamline some aspects of the release process and I hear it's very easy to setup and maintain. Finally, from some reviews and documentation I honestly think that GO is actually the best platform (although not having much experience with all these I'm not counting my own opinion very strongly). And it was recently open sourced. To summarize what I like of Travis: - simple configuration - not much maintenance from our side - your recommendation counts - they pay the bills? - you say that it's very popular among Java developers. About the popularity point, you surprised me. I honestly thought that we should stay on Jenkins because that was the most popular one. Do you have some data to back that nowadays people are more familiar with Travis? Finally I have been burned several times by not having "root access" on the whole thing. I guess Docker might make this reasoning moot now, but it's something to consider. It's also quite important that we make sure our releases are created in a reliable environment, so there's the trust issue of delegating the keys to the kingdom to a third party. I'd even like it we could start "signing" the artifacts we release as some users mentioned that this would be important for them. So I think that we might move some (several?) jobs to Travis but we'd still want some job to run on our own platform - like the releases and that implies jobs which test releases regularly - and then I'm not sure if we want to have people necessarily familiarize with multiple different UIs ? Sorry to be skeptical, I didn't mean to stress the negative aspects but to clarify that there are many aspects to consider for such a move. I'm definitely open to consider using it for a subset of jobs, like you mentioned the PR review system might be a good fit. It's also a good thing for sure to test in additional environments: can it also run jobs on Windows and OSX ? We're missing that.. we could fix the lack of Windows via AWS but that has a steep price tag.. I'll rather volunteer an old laptop from home. Thanks, Sanne On 27 January 2016 at 23:40, Guillaume Smet wrote: > Hi, > > As mentioned in our last discussion, I explored adding Travis support to > Search. > > The diff is here: > https://github.com/gsmet/hibernate-search/commit/cbd2c1fff05532974823da572795d53cb8b9d26a > (yes it's short but it was a long road :)) > > I had to raise a bit the JGroups timeout for one test and had to fix > TestRunnerStandalone > so that it effectively uses the configuration from the profile (this change > is not specific to Travis and should be committed anyway). > > The result is here: > https://travis-ci.org/gsmet/hibernate-search > > What I like in Travis: > - The CI configuration is code and is versioned > - Parallelization with a *lot* of resources > - The ability to build a test matrix very easily > - Complete isolation as each build is run in its own Docker container > > What is less cool: > - The only way to get the logs is to ship them to AWS S3 - that said, I did > it and it's pretty straightforward as it's well integrated (I commented out > the code in the .travis.yml for now) > - It might seem less flexible as we are depending on the Travis > infrastructure (for instance, I created a ticket to ask for the support of > JDK 9: https://github.com/travis-ci/travis-ci/i
Re: [hibernate-dev] [Search] Travis support
I do not know how to quantify "popularity", but I do know I have seen lots of projects using travis for commit validation. TBH my only concern would be access to the results. And that is more an unknown. As I have never used Travis CI I do not know how its UI works. Guillaume do you have project in Travis you can point us to so that we can see? On Thu, Jan 28, 2016 at 8:24 AM Sanne Grinovero wrote: > Hi Guillaume, > I am a bit skeptical as we have CI working already on ci.hibernate.org > and having limited people we can't really afford to fix things which > already work. > That said, this does look good, and it's certainly positive that we > can get some free computation resources from travis.org as our AWS > bills are getting high. > > Definitely positive that the build configurations are versioned; we > have auditing of configuration changes on Jenkins [ci.hibernate.org] > but having it in git looks very nice. I'm not entirely convinced about > having the job configurations within the repository itself though - > there should be some freedom in running different combinations, and > try new job configurations without having to send pull requests; not > least branches will go out of synch. > There is a jenkins plugin which will take the job configuration from > the repository if we think that is important: I played with it but it > didn't seem very mature when I tried the first Alpha release. > > The Infinispan and WildFly teams have switched from Jenkins to > TeamCity and are very happy with it; one of the reasons for them to > prefer it over Jenkins is that it does a great job at tracking > evolution over time of failures of a specific test: you can examine > the build stability from various perspectives. But it's not OSS so it > loses some points there. > > Another strong candidate which we discusses some times is to use > Atlassian's Bamboo. That seems another very strong product, and would > have the additional benefit of great integration with JIRA which I > think we all love, and we get excellent help from Atlassian as they > sponsor our JIRA installation. Using Bamboo could help us streamline > some aspects of the release process and I hear it's very easy to setup > and maintain. > > Finally, from some reviews and documentation I honestly think that GO > is actually the best platform (although not having much experience > with all these I'm not counting my own opinion very strongly). And it > was recently open sourced. > > To summarize what I like of Travis: > - simple configuration > - not much maintenance from our side > - your recommendation counts > - they pay the bills? > - you say that it's very popular among Java developers. > > About the popularity point, you surprised me. I honestly thought that > we should stay on Jenkins because that was the most popular one. Do > you have some data to back that nowadays people are more familiar with > Travis? > > Finally I have been burned several times by not having "root access" > on the whole thing. I guess Docker might make this reasoning moot now, > but it's something to consider. > It's also quite important that we make sure our releases are created > in a reliable environment, so there's the trust issue of delegating > the keys to the kingdom to a third party. I'd even like it we could > start "signing" the artifacts we release as some users mentioned that > this would be important for them. > > So I think that we might move some (several?) jobs to Travis but we'd > still want some job to run on our own platform - like the releases and > that implies jobs which test releases regularly - and then I'm not > sure if we want to have people necessarily familiarize with multiple > different UIs ? > > Sorry to be skeptical, I didn't mean to stress the negative aspects > but to clarify that there are many aspects to consider for such a > move. > I'm definitely open to consider using it for a subset of jobs, like > you mentioned the PR review system might be a good fit. > It's also a good thing for sure to test in additional environments: > can it also run jobs on Windows and OSX ? We're missing that.. we > could fix the lack of Windows via AWS but that has a steep price tag.. > I'll rather volunteer an old laptop from home. > > Thanks, > Sanne > > On 27 January 2016 at 23:40, Guillaume Smet > wrote: > > Hi, > > > > As mentioned in our last discussion, I explored adding Travis support to > > Search. > > > > The diff is here: > > > https://github.com/gsmet/hibernate-search/commit/cbd2c1fff05532974823da572795d53cb8b9d26a > > (yes it's short but it was a long road :)) > > > > I had to raise a bit the JGroups timeout for one test and had to fix > > TestRunnerStandalone > > so that it effectively uses the configuration from the profile (this > change > > is not specific to Travis and should be committed anyway). > > > > The result is here: > > https://travis-ci.org/gsmet/hibernate-search > > > > What I like in Travis: > > - The CI configuration is
Re: [hibernate-dev] [Search] Travis support
Yep: https://travis-ci.org/gsmet/hibernate-search As already mentioned, if you want to get the results of the test, you can push them to an AWS S3 bucket. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [Search] ElasticSearch - DSL
Hi all (and especially Gunnar), I dug a bit in your ElasticSearch work today as I wanted to give a try to the facet implementation and I was wondering if maybe we should use the ElasticSearch DSL to build the queries instead of building raw JSON strings. I experimented here: https://github.com/gsmet/hibernate-search/commit/18737f720a1200b125adf2bb0465b52d5d2b3ca3 I think the code is a bit clearer now. I haven't changed all the queries in the tests so I kept the fromJson method in ElasticSearchQueries but I think we should remove it and rely on the DSL: I'll wait for your opinion as you might have had a very good reason to not use the DSL. One of the challenges waiting for us will be to transform the Lucene Filters into proper Elastic Search queries. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Travis support
Hi Sanne, On Thu, Jan 28, 2016 at 3:23 PM, Sanne Grinovero wrote: > I am a bit skeptical as we have CI working already on ci.hibernate.org > and having limited people we can't really afford to fix things which > already work. > I perfectly understand that. I wanted to experiment it without bothering you about it. > To summarize what I like of Travis: > - simple configuration > - not much maintenance from our side > - your recommendation counts > - they pay the bills? > - you say that it's very popular among Java developers. > > About the popularity point, you surprised me. I honestly thought that > we should stay on Jenkins because that was the most popular one. Do > you have some data to back that nowadays people are more familiar with > Travis? > It's very widespread in the Open Source projects running on GitHub, either in Java, Ruby, PHP, Python and so on. HikariCP for instance uses Travis and there are a lot of others projects using it: https://github.com/brettwooldridge/HikariCP . We use Jenkins at my company too for our private projects but we use Travis for our Open Source ones. > Finally I have been burned several times by not having "root access" > on the whole thing. I guess Docker might make this reasoning moot now, > but it's something to consider. > It's also quite important that we make sure our releases are created > in a reliable environment, so there's the trust issue of delegating > the keys to the kingdom to a third party. I'd even like it we could > start "signing" the artifacts we release as some users mentioned that > this would be important for them. > Yes, Travis won't replace the release tasks. I think it's good for the day to day builds and PR builds and we should only use it for that - if we decide to use it. > Sorry to be skeptical, I didn't mean to stress the negative aspects > but to clarify that there are many aspects to consider for such a > move. > I'm definitely open to consider using it for a subset of jobs, like > you mentioned the PR review system might be a good fit. > It's also a good thing for sure to test in additional environments: > can it also run jobs on Windows and OSX ? We're missing that.. we > could fix the lack of Windows via AWS but that has a steep price tag.. > I'll rather volunteer an old laptop from home. > They have OSX support but it's sparse. It's mostly here to test MacOS and iOS apps. They don't have Windows support. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] ElasticSearch - DSL
Hi Guillaume, Indeed there is a reason for not using the DSL: I wanted to avoid the dependency to the ES libraries. They in turn pull in Lucene in a version which potentially differs from the Lucene version used by Hibernate Search itself. Also I wanted to leave the door open for supporting multiple (potentially incompatibly altered) versions of ES backends, say ES 2 and a future ES 3. All in all, these advantages outweigh the slightly simpler usage of the DSL to me. > One of the challenges waiting for us will be to transform the Lucene > Filters into proper Elastic Search queries I haven't looked into filters yet, but it's high on my agenda. Do you think it's more difficult than transforming actual queries? Btw. the ES PoC allows to pass in plain ES queries, at some point these should be allowed to contain filter clauses, too (this might even work already, haven't tried it). Cheers, --Gunnar 2016-01-28 18:16 GMT+01:00 Guillaume Smet : > Hi all (and especially Gunnar), > > I dug a bit in your ElasticSearch work today as I wanted to give a try to > the facet implementation and I was wondering if maybe we should use the > ElasticSearch DSL to build the queries instead of building raw JSON strings. > > I experimented here: > https://github.com/gsmet/hibernate-search/commit/18737f720a1200b125adf2bb0465b52d5d2b3ca3 > > I think the code is a bit clearer now. I haven't changed all the queries in > the tests so I kept the fromJson method in ElasticSearchQueries but I think > we should remove it and rely on the DSL: I'll wait for your opinion as you > might have had a very good reason to not use the DSL. > > One of the challenges waiting for us will be to transform the Lucene > Filters into proper Elastic Search queries. > > -- > 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] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date)
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 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 : > > 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 > 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 : > >> > 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/interpret
Re: [hibernate-dev] [Search] ElasticSearch - DSL
Hey Gunnar, On Thu, Jan 28, 2016 at 6:52 PM, Gunnar Morling wrote: > > They in turn pull in Lucene in a version which potentially differs > from the Lucene version used by Hibernate Search itself. Also I wanted > to leave the door open for supporting multiple (potentially > incompatibly altered) versions of ES backends, say ES 2 and a future > ES 3. > > All in all, these advantages outweigh the slightly simpler usage of > the DSL to me. Yeah, I understand your concerns. Apart from the more complicated usage, I'm afraid building raw JSON is going to be harder to maintain. We only do simple things atm and I don't find the JSON manipulation very readable nor very solid. It's going to be worse when we will add aggregations for faceting and so on. As for the dependencies, I could take a look at shading the necessary classes for the builders and see if we can come up with something clean? I don't know if it's something acceptable for an Hibernate project. It doesn't solve the multi versions thingy but if they change the API, it's going to be quite ugly to generate different JSON queries anyway, don't you think? > > One of the challenges waiting for us will be to transform the Lucene > > Filters into proper Elastic Search queries > > I haven't looked into filters yet, but it's high on my agenda. > > Do you think it's more difficult than transforming actual queries? > Btw. the ES PoC allows to pass in plain ES queries, at some point > these should be allowed to contain filter clauses, too (this might > even work already, haven't tried it). > Yeah I saw you could inject native ES queries and that's also something that worries me with the raw JSON approach. I find it much more user-friendly to provide an API to build the queries. (Using these various discussions to adjust how I work and be more compliant with the Hibernate way of life :)) -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] ElasticSearch - DSL
2016-01-28 20:17 GMT+01:00 Guillaume Smet : > Hey Gunnar, > > On Thu, Jan 28, 2016 at 6:52 PM, Gunnar Morling > wrote: >> >> They in turn pull in Lucene in a version which potentially differs >> from the Lucene version used by Hibernate Search itself. Also I wanted >> to leave the door open for supporting multiple (potentially >> incompatibly altered) versions of ES backends, say ES 2 and a future >> ES 3. >> >> All in all, these advantages outweigh the slightly simpler usage of >> the DSL to me. > > > Yeah, I understand your concerns. Apart from the more complicated usage, I'm > afraid building raw JSON is going to be harder to maintain. We only do > simple things atm and I don't find the JSON manipulation very readable nor > very solid. It's going to be worse when we will add aggregations for > faceting and so on. I don't find too bad what we have atm. :) If becomes too much of a burden at some point in the future, we still may reconsider. A general credo we have is to make things as good for the user as possible also if it means some more trouble for us internally. I think sparing the user from dependency issues is worth the JSON crafting on our side. > > As for the dependencies, I could take a look at shading the necessary > classes for the builders and see if we can come up with something clean? I > don't know if it's something acceptable for an Hibernate project. Our experiences with shading are mixed; I think most don't like it. It might work, but the issue remains that the ES JAR depends on a specific Lucene version. We may be lucky and the query builder stuff is nicely isolated from that so that there would be no problem by HS itself using a different version. Still it'd appear as a potential source of trouble to me. The loose coupling via JSON is more practical IMHO. I'd not exclude the builder stuff for all times, but right now it seems not worth it. Btw. - I should have mentioned that in my first reply - our vision regarding queries is to modify and generalize the HSEARCH query builder DSL so it can emit queries for the backend du jour, be it plain Lucene, ES or Solr. We just didn't get there yet :) > > It doesn't solve the multi versions thingy but if they change the API, it's > going to be quite ugly to generate different JSON queries anyway, don't you > think? See above, I think some internal ugliness is ok if it helps the user in a reasonable way. > >> >> > One of the challenges waiting for us will be to transform the Lucene >> > Filters into proper Elastic Search queries >> >> I haven't looked into filters yet, but it's high on my agenda. >> >> Do you think it's more difficult than transforming actual queries? >> Btw. the ES PoC allows to pass in plain ES queries, at some point >> these should be allowed to contain filter clauses, too (this might >> even work already, haven't tried it). > > > Yeah I saw you could inject native ES queries and that's also something that > worries me with the raw JSON approach. I find it much more user-friendly to > provide an API to build the queries. Yes, fully agreed, hence the idea to enable the HSEARCH query DSL for that. The native ES query injection is something I built to have something functional quickly and it also might be helpful for people giving HSEARCH a quick try. > > (Using these various discussions to adjust how I work and be more compliant > with the Hibernate way of life :)) +1 Keep them coming :) > > -- > Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
