From yoann at hibernate.org Wed Nov 2 07:38:18 2016 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 2 Nov 2016 12:38:18 +0100 Subject: [hibernate-dev] Hibernate Search and Elasticsearch 5 support Message-ID: Hello, I just finished assessing the required changes for supporting Elasticsearch 5.0. I put the details in this ticket: https://hibernate.atlassian.net/browse/HSEARCH-2434 Here is a quick summary: - Some (non-breaking) changes are required in Jest [1] - We'll have to update the way we do integration testing: elasticsearch-maven-plugin doesn't work well with ES 5.0 and will require a major overhaul to work. [2] - There are some breaking changes that require us either drop support for ES 2.x or introduce dialects (for instance the string datatype has been split into two datatypes: text and keyword, which behave quite differently). - And, perhaps most importantly, support for defining analyzers in elasticsearch.yml has been dropped. This means users have to resort to the index settings API to define their analyzers. So this breaks our automatic index creation / mapping generation feature: we put mappings just after creating the index, but since the index was just created analyzer definitions will be missing and the mapping will be rejected. See HSEARCH-2434 (in the comments) for details. Ultimately, what we have to decide is how and when we're going to support ES 5. Several options have already been mentioned on HipChat: 1. Support ES 5.x right now and drop support for ES 2.x 2. Support both ES 5.x and 2.x right now by introducing dialects (that could be chosen automatically by asking the running version to the server) 3. Only support ES 2.x for now and keep ES 5.x for later (probably HS 6.0) We have to consider several things in order to make the decision: - Deadlines and available resources. Supporting 5.x only should be easy enough, I think (if we ignore the analyzer definition issue) ; actually I already did some work [3]. The dialect solution would obviously require some more work, but if only target a quick, dirty fix (to be refactored in 6.0) it shouldn't be hell. - Users. Dropping support for 2.x probably will make someone angry. But then, we only published alpha/betas and advertised experimental support for now, so there's shouldn't be many people using it in a production environment. Thoughts, opinions? [1] https://github.com/searchbox-io/Jest/pull/408 [2] https://github.com/alexcojocaru/elasticsearch-maven-plugin/pull/19 [3] https://github.com/yrodiere/hibernate-search/tree/HSEARCH-2434 Yoann Rodi?re Hibernate NoORM Team From guillaume.smet at gmail.com Wed Nov 2 07:59:46 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 2 Nov 2016 12:59:46 +0100 Subject: [hibernate-dev] Hibernate Search and Elasticsearch 5 support In-Reply-To: References: Message-ID: Hi! On Wed, Nov 2, 2016 at 12:38 PM, Yoann Rodiere wrote: > - And, perhaps most importantly, support for defining analyzers in > elasticsearch.yml has been dropped. This means users have to resort to > the > index settings API to define their analyzers. So this breaks our > automatic > index creation / mapping generation feature: we put mappings just after > creating the index, but since the index was just created analyzer > definitions will be missing and the mapping will be rejected. See > HSEARCH-2434 (in the comments) for details. > The other important point (mentioned in the issue but I think it's important to outline it here) concerning the analyzers is that they are now defined per index: there are no global analyzers, you have to define them for every index using the analyzer. It is totally different from our current approach and make defining them manually (and maintaining them) even more cumbersome. Thus I don't think we can consider defining them manually as an option. If we want to support Es 5, we need to provide a way to define these analyzers in HS and make HS post them to Es. -- Guillaume From steve at hibernate.org Wed Nov 2 09:49:13 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 02 Nov 2016 13:49:13 +0000 Subject: [hibernate-dev] HHH-11155 : problems updating lazy properties in lazy groups In-Reply-To: References: Message-ID: It looks like I only adjusted the reading of values (SELECT) for fetch-groups. Updates should only consider initialized attributes. I had assumed that was already the case. The same is probably true for property-based optimistic locking as well. We should verify that feature as well On Wed, Oct 26, 2016 at 2:15 AM Gail Badner wrote: > Static update strings appear to cover only the following situations: > 1) there are no uninitialized properties (so all updateable attributes > should be updated); > 2) all lazy properties are uninitialized (so only > non-lazy, updateable attributes should be updated). > > As of 5.1, we have "lazy groups". It is possible some lazy groups are > initialized, and some are uninitialized. We have a couple of alternatives > for dealing with the various combinations: > > For example, if there are are 3 lazy groups: lazyGroup1, lazyGroup2, > lazyGroup3. > > 1) Generate SQL update strings for all possible combinations of initialized > lazy groups: > > SQL update strings are already generated for the following combinations: > > * lazyGroup1: uninitialized; lazyGroup2: uninitialized; lazyGroup3: > uninitialized > * lazyGroup1: initialized; lazyGroup2: initialized; lazyGroup3: > initialized > > SQL update strings for the following combinations need to be generated to > fix the bug: > > * lazyGroup1: initialized; lazyGroup2: uninitialized; lazyGroup3: > uninitialized > * lazyGroup1: uninitialized; lazyGroup2: initialized; lazyGroup3: > uninitialized > * lazyGroup1: uninitialized; lazyGroup2: uninitialized; lazyGroup3: > initialized > * lazyGroup1: initialized; lazyGroup2: initialized; lazyGroup3: > uninitialized > * lazyGroup1: initialized; lazyGroup2: uninitialized; lazyGroup3: > initialized > * lazyGroup1: uninitialized; lazyGroup2: initialized; lazyGroup3: > initialized > > The update strings could be stored in a Map with key containing the names > (or indexes?) of the corresponding initialized lazy groups. > > 2) Generate dynamic update strings when there is at least 1 uninitialized > group, or when there are more than N lazy groups. What should N be? > > Comments or suggestions? > > A related bug is that calling a setter on a lazy property only initializes > that one lazy property. It should also initialize other properties in the > same lazy group. This one is pretty easy to fix. > Thanks, > Gail > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Wed Nov 2 09:59:22 2016 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 2 Nov 2016 14:59:22 +0100 Subject: [hibernate-dev] Hibernate Search and Elasticsearch 5 support In-Reply-To: References: Message-ID: On 2 November 2016 at 12:59, Guillaume Smet wrote: > The other important point (mentioned in the issue but I think it's > important to outline it here) concerning the analyzers is that they are now > defined per index: there are no global analyzers, you have to define them > for every index using the analyzer. It is totally different from our > current approach and make defining them manually (and maintaining them) > even more cumbersome. Thus I don't think we can consider defining them > manually as an option. > Yes, and that's the reason our automatic mapping generation is broken. Since the scope of analyzers is now the index, posting analyzer definitions should take place after index creation. But it should also happen before mappings are put in the index (since they reference analyzers). In practice, that means we must have users create indexes themselves (which can't be done in bulk, which is cumbersome) and post analyzer definitions themselves (which can be done in bulk and is relatively easy). On 2 November 2016 at 12:59, Guillaume Smet wrote: > If we want to support Es 5, we need to provide a way to define these > analyzers in HS and make HS post them to Es. > Agreed: once we automate posting analyzer definitions to Elasticsearch from HS, the actual API used to create indexes or post analyzers and its "cumbersomeness" become irrelevant. Our options are: - Using the existing annotations and try as best we can to translate Lucene analyzers to their name and parameters in ES: it won't help when using non-Lucene analyzers, and it feels like something we can't maintain forever. - Introducing a new analyzer definition API: is it the right time, with HS 6.0 looming over the horizon? - Using the simple JSON file solution I proposed. Ok, maybe *simplistic* rather than *simple*, but it'd be easy to implement and probably wouldn't require much maintenance work if we decide to keep it in 6.0. Yoann Rodi?re Hibernate NoORM Team From steve at hibernate.org Thu Nov 3 09:55:57 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 03 Nov 2016 13:55:57 +0000 Subject: [hibernate-dev] HHH-11155 : problems updating lazy properties in lazy groups In-Reply-To: References: Message-ID: Just be sure to consider custom SQL for loading and updates as it will affect many of the things discussed here. On Wed, Nov 2, 2016 at 8:49 AM Steve Ebersole wrote: > It looks like I only adjusted the reading of values (SELECT) for > fetch-groups. > > Updates should only consider initialized attributes. I had assumed that > was already the case. > > The same is probably true for property-based optimistic locking as well. > We should verify that feature as well > > > On Wed, Oct 26, 2016 at 2:15 AM Gail Badner wrote: > > Static update strings appear to cover only the following situations: > 1) there are no uninitialized properties (so all updateable attributes > should be updated); > 2) all lazy properties are uninitialized (so only > non-lazy, updateable attributes should be updated). > > As of 5.1, we have "lazy groups". It is possible some lazy groups are > initialized, and some are uninitialized. We have a couple of alternatives > for dealing with the various combinations: > > For example, if there are are 3 lazy groups: lazyGroup1, lazyGroup2, > lazyGroup3. > > 1) Generate SQL update strings for all possible combinations of initialized > lazy groups: > > SQL update strings are already generated for the following combinations: > > * lazyGroup1: uninitialized; lazyGroup2: uninitialized; lazyGroup3: > uninitialized > * lazyGroup1: initialized; lazyGroup2: initialized; lazyGroup3: > initialized > > SQL update strings for the following combinations need to be generated to > fix the bug: > > * lazyGroup1: initialized; lazyGroup2: uninitialized; lazyGroup3: > uninitialized > * lazyGroup1: uninitialized; lazyGroup2: initialized; lazyGroup3: > uninitialized > * lazyGroup1: uninitialized; lazyGroup2: uninitialized; lazyGroup3: > initialized > * lazyGroup1: initialized; lazyGroup2: initialized; lazyGroup3: > uninitialized > * lazyGroup1: initialized; lazyGroup2: uninitialized; lazyGroup3: > initialized > * lazyGroup1: uninitialized; lazyGroup2: initialized; lazyGroup3: > initialized > > The update strings could be stored in a Map with key containing the names > (or indexes?) of the corresponding initialized lazy groups. > > 2) Generate dynamic update strings when there is at least 1 uninitialized > group, or when there are more than N lazy groups. What should N be? > > Comments or suggestions? > > A related bug is that calling a setter on a lazy property only initializes > that one lazy property. It should also initialize other properties in the > same lazy group. This one is pretty easy to fix. > Thanks, > Gail > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From yoann at hibernate.org Fri Nov 4 09:41:45 2016 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 4 Nov 2016 14:41:45 +0100 Subject: [hibernate-dev] [Hibernate Search] Added a test utility to assert produced log Message-ID: Hi team, Just so you know, if you ever need to assert that a certain log is produced in your JUnit tests, there's now a tool to do just that in Hibernate Search: org.hibernate.search.test.util.impl.ExpectedLog4jLog [1] You may use it much like you would use the ExpectedException rule: public class MyTest { @org.junit.Rule public ExpectedLog4jLog logged = ExpectedLog4jLog.create(); @Test public void test() { logged.expectMessage( "HSEARCH400032", "some substring I want in the same log" ); // ... Do test ... } } You can also assert more complex conditions on the logs, using a org.hamcrest.Matcher, but then it's starting to get a bit exotic. You may find an example of real-life use at [2]. [1] https://github.com/hibernate/hibernate-search/blob/master/engine/src/test/java/org/hibernate/search/test/util/impl/ExpectedLog4jLog.java [2] https://github.com/hibernate/hibernate-search/blob/master/elasticsearch/src/test/java/org/hibernate/search/elasticsearch/test/ElasticsearchUnsupportedFeaturesIT.java Cheers, Yoann Rodi?re Hibernate NoORM Team From sanne at hibernate.org Fri Nov 4 10:13:06 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 4 Nov 2016 14:13:06 +0000 Subject: [hibernate-dev] [Hibernate Search] Added a test utility to assert produced log In-Reply-To: References: Message-ID: Nice trick! I didn't know about the Log4j feature, but had created something similar for JBoss Logging; it's in the ORM project though so not easily reusable in all of Search components: - org.hibernate.testing.logger.LoggerInspectionRule On 4 November 2016 at 13:41, Yoann Rodiere wrote: > Hi team, > > Just so you know, if you ever need to assert that a certain log is produced > in your JUnit tests, there's now a tool to do just that in Hibernate > Search: org.hibernate.search.test.util.impl.ExpectedLog4jLog [1] > > You may use it much like you would use the ExpectedException rule: > > public class MyTest { > @org.junit.Rule > public ExpectedLog4jLog logged = ExpectedLog4jLog.create(); > > @Test > public void test() { > logged.expectMessage( "HSEARCH400032", "some substring I want in the same > log" ); > > // ... Do test ... > } > } > > You can also assert more complex conditions on the logs, using > a org.hamcrest.Matcher, but then it's starting to > get a bit exotic. > > You may find an example of real-life use at [2]. > > [1] > https://github.com/hibernate/hibernate-search/blob/master/engine/src/test/java/org/hibernate/search/test/util/impl/ExpectedLog4jLog.java > [2] > https://github.com/hibernate/hibernate-search/blob/master/elasticsearch/src/test/java/org/hibernate/search/elasticsearch/test/ElasticsearchUnsupportedFeaturesIT.java > > Cheers, > > Yoann Rodi?re > Hibernate NoORM Team > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Nov 4 10:27:43 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 04 Nov 2016 14:27:43 +0000 Subject: [hibernate-dev] [Hibernate Search] Added a test utility to assert produced log In-Reply-To: References: Message-ID: I think we should consider creating a set of generic testing utils as a separate project. Things like LoggerInspectionRule, @ExpectedFailure, @BeforeClassOnce, @AfterClassOnce, @Skip, etc are generally useful I find On Fri, Nov 4, 2016 at 9:16 AM Sanne Grinovero wrote: > Nice trick! > > I didn't know about the Log4j feature, but had created something > similar for JBoss Logging; it's in the ORM project though so not > easily reusable in all of Search components: > - org.hibernate.testing.logger.LoggerInspectionRule > > On 4 November 2016 at 13:41, Yoann Rodiere wrote: > > Hi team, > > > > Just so you know, if you ever need to assert that a certain log is > produced > > in your JUnit tests, there's now a tool to do just that in Hibernate > > Search: org.hibernate.search.test.util.impl.ExpectedLog4jLog [1] > > > > You may use it much like you would use the ExpectedException rule: > > > > public class MyTest { > > @org.junit.Rule > > public ExpectedLog4jLog logged = ExpectedLog4jLog.create(); > > > > @Test > > public void test() { > > logged.expectMessage( "HSEARCH400032", "some substring I want in the same > > log" ); > > > > // ... Do test ... > > } > > } > > > > You can also assert more complex conditions on the logs, using > > a org.hamcrest.Matcher, but then it's starting to > > get a bit exotic. > > > > You may find an example of real-life use at [2]. > > > > [1] > > > https://github.com/hibernate/hibernate-search/blob/master/engine/src/test/java/org/hibernate/search/test/util/impl/ExpectedLog4jLog.java > > [2] > > > https://github.com/hibernate/hibernate-search/blob/master/elasticsearch/src/test/java/org/hibernate/search/elasticsearch/test/ElasticsearchUnsupportedFeaturesIT.java > > > > Cheers, > > > > Yoann Rodi?re > > Hibernate NoORM Team > > _______________________________________________ > > 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 From sanne at hibernate.org Fri Nov 4 10:29:44 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 4 Nov 2016 14:29:44 +0000 Subject: [hibernate-dev] [Hibernate Search] Added a test utility to assert produced log In-Reply-To: References: Message-ID: On 4 November 2016 at 14:27, Steve Ebersole wrote: > I think we should consider creating a set of generic testing utils as a > separate project. Things like LoggerInspectionRule, @ExpectedFailure, > @BeforeClassOnce, @AfterClassOnce, @Skip, etc are generally useful I find +1 for the general testing utilities, however the LoggerInspectionRule will move into a JBoss Logger utility as it's useful for anyone using JBoss Logger. > On Fri, Nov 4, 2016 at 9:16 AM Sanne Grinovero wrote: >> >> Nice trick! >> >> I didn't know about the Log4j feature, but had created something >> similar for JBoss Logging; it's in the ORM project though so not >> easily reusable in all of Search components: >> - org.hibernate.testing.logger.LoggerInspectionRule >> >> On 4 November 2016 at 13:41, Yoann Rodiere wrote: >> > Hi team, >> > >> > Just so you know, if you ever need to assert that a certain log is >> > produced >> > in your JUnit tests, there's now a tool to do just that in Hibernate >> > Search: org.hibernate.search.test.util.impl.ExpectedLog4jLog [1] >> > >> > You may use it much like you would use the ExpectedException rule: >> > >> > public class MyTest { >> > @org.junit.Rule >> > public ExpectedLog4jLog logged = ExpectedLog4jLog.create(); >> > >> > @Test >> > public void test() { >> > logged.expectMessage( "HSEARCH400032", "some substring I want in the >> > same >> > log" ); >> > >> > // ... Do test ... >> > } >> > } >> > >> > You can also assert more complex conditions on the logs, using >> > a org.hamcrest.Matcher, but then it's starting >> > to >> > get a bit exotic. >> > >> > You may find an example of real-life use at [2]. >> > >> > [1] >> > >> > https://github.com/hibernate/hibernate-search/blob/master/engine/src/test/java/org/hibernate/search/test/util/impl/ExpectedLog4jLog.java >> > [2] >> > >> > https://github.com/hibernate/hibernate-search/blob/master/elasticsearch/src/test/java/org/hibernate/search/elasticsearch/test/ElasticsearchUnsupportedFeaturesIT.java >> > >> > Cheers, >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > _______________________________________________ >> > 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 From steve at hibernate.org Fri Nov 4 10:32:09 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 04 Nov 2016 14:32:09 +0000 Subject: [hibernate-dev] [Hibernate Search] Added a test utility to assert produced log In-Reply-To: References: Message-ID: Sweet. Good to know On Fri, Nov 4, 2016 at 9:30 AM Sanne Grinovero wrote: > On 4 November 2016 at 14:27, Steve Ebersole wrote: > > I think we should consider creating a set of generic testing utils as a > > separate project. Things like LoggerInspectionRule, @ExpectedFailure, > > @BeforeClassOnce, @AfterClassOnce, @Skip, etc are generally useful I find > > +1 for the general testing utilities, however the LoggerInspectionRule > will move into a JBoss Logger utility as it's useful for anyone using > JBoss Logger. > > > > On Fri, Nov 4, 2016 at 9:16 AM Sanne Grinovero > wrote: > >> > >> Nice trick! > >> > >> I didn't know about the Log4j feature, but had created something > >> similar for JBoss Logging; it's in the ORM project though so not > >> easily reusable in all of Search components: > >> - org.hibernate.testing.logger.LoggerInspectionRule > >> > >> On 4 November 2016 at 13:41, Yoann Rodiere wrote: > >> > Hi team, > >> > > >> > Just so you know, if you ever need to assert that a certain log is > >> > produced > >> > in your JUnit tests, there's now a tool to do just that in Hibernate > >> > Search: org.hibernate.search.test.util.impl.ExpectedLog4jLog [1] > >> > > >> > You may use it much like you would use the ExpectedException rule: > >> > > >> > public class MyTest { > >> > @org.junit.Rule > >> > public ExpectedLog4jLog logged = ExpectedLog4jLog.create(); > >> > > >> > @Test > >> > public void test() { > >> > logged.expectMessage( "HSEARCH400032", "some substring I want in the > >> > same > >> > log" ); > >> > > >> > // ... Do test ... > >> > } > >> > } > >> > > >> > You can also assert more complex conditions on the logs, using > >> > a org.hamcrest.Matcher, but then it's starting > >> > to > >> > get a bit exotic. > >> > > >> > You may find an example of real-life use at [2]. > >> > > >> > [1] > >> > > >> > > https://github.com/hibernate/hibernate-search/blob/master/engine/src/test/java/org/hibernate/search/test/util/impl/ExpectedLog4jLog.java > >> > [2] > >> > > >> > > https://github.com/hibernate/hibernate-search/blob/master/elasticsearch/src/test/java/org/hibernate/search/elasticsearch/test/ElasticsearchUnsupportedFeaturesIT.java > >> > > >> > Cheers, > >> > > >> > Yoann Rodi?re > >> > Hibernate NoORM Team > >> > _______________________________________________ > >> > 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 > From guillaume.smet at gmail.com Tue Nov 8 10:20:48 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 8 Nov 2016 16:20:48 +0100 Subject: [hibernate-dev] Hibernate NoORM IRC meeting minutes Message-ID: Hi! As usual, the minutes of our regular IRC meeting: 16:17 < jbott> Ending meeting. Generating minutes. Be patient :) 16:17 < jbott> Meeting ended Tue Nov 8 15:17:12 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:17 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-08-14.03.html 16:17 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-08-14.03.txt 16:17 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-08-14.03.log.html Most notably a discussion on HS and ES 5 support. Cheers, -- Guillaume From sanne at hibernate.org Tue Nov 8 12:16:07 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 8 Nov 2016 17:16:07 +0000 Subject: [hibernate-dev] Releasing Hibernate OGM 5.1.0.Beta1: now with Hot Rod support! Message-ID: Hello everyone, we can finally announce that Hibernate OGM 5.1.0.Beta1 is released, and now includes support for Infinispan Server, alias Hot Rod, also known as Infinispan Remote .. - http://in.relation.to/2016/11/08/hibernate-ogm-with-hotrod-support We also released Hibernate OGM 5.0.3.Final Kind Regards, Sanne From rvansa at redhat.com Tue Nov 8 12:50:06 2016 From: rvansa at redhat.com (Radim Vansa) Date: Tue, 8 Nov 2016 12:50:06 -0500 Subject: [hibernate-dev] [hibernate-announce] Releasing Hibernate OGM 5.1.0.Beta1: now with Hot Rod support! In-Reply-To: References: Message-ID: <950d8070-74e1-8b3b-80ba-084021a73034@redhat.com> Wouldn't it be worth mentioning the lack of referential integrity among the limitations? Anyway, thumbs up! Radim On 11/08/2016 12:16 PM, Sanne Grinovero wrote: > Hello everyone, > > we can finally announce that Hibernate OGM 5.1.0.Beta1 is released, > and now includes support for Infinispan Server, alias Hot Rod, also > known as Infinispan Remote .. > > - http://in.relation.to/2016/11/08/hibernate-ogm-with-hotrod-support > > We also released Hibernate OGM 5.0.3.Final > > Kind Regards, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Radim Vansa JBoss Performance Team From sanne at hibernate.org Tue Nov 8 13:53:25 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 8 Nov 2016 18:53:25 +0000 Subject: [hibernate-dev] [hibernate-announce] Releasing Hibernate OGM 5.1.0.Beta1: now with Hot Rod support! In-Reply-To: <950d8070-74e1-8b3b-80ba-084021a73034@redhat.com> References: <950d8070-74e1-8b3b-80ba-084021a73034@redhat.com> Message-ID: Thanks Radim! the blog attempts to be short, I mention the Referential Integrity problem in the reference documentation: " Referential integrity While we can use relations based on foreign keys, Infinispan has no notion of referential integrity. Hibernate is able to maintain the integrity as it won?t "forget" stale references, > but since the storage doesn?t support transactions either it is possible to interrupt Hibernate OGM during such maintenance and introduce breaks of integrity. " - https://docs.jboss.org/hibernate/ogm/5.1/reference/en-US/html_single/#storage_principles_of_the_infinispan_remote_dataprovider It's not explicitly listed in the known limitations, as I consider it part of the "there's no transactions" point here: - https://docs.jboss.org/hibernate/ogm/5.1/reference/en-US/html_single/#known_limitations_future_improvements You think that's enough? It's a though one, as I want to be clear about the limitations but w/o scaring people off by repeating limitations too many times. There are also various big highlighted baloons mentioning: " Caution The Hibernate OGM support for Infinispan Remote is considered experimental. " Happy to clarify the docs as needed. Thanks! Sanne On 8 November 2016 at 17:50, Radim Vansa wrote: > Wouldn't it be worth mentioning the lack of referential integrity among > the limitations? > > Anyway, thumbs up! > > Radim > > On 11/08/2016 12:16 PM, Sanne Grinovero wrote: >> Hello everyone, >> >> we can finally announce that Hibernate OGM 5.1.0.Beta1 is released, >> and now includes support for Infinispan Server, alias Hot Rod, also >> known as Infinispan Remote .. >> >> - http://in.relation.to/2016/11/08/hibernate-ogm-with-hotrod-support >> >> We also released Hibernate OGM 5.0.3.Final >> >> Kind Regards, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From rvansa at redhat.com Tue Nov 8 14:13:46 2016 From: rvansa at redhat.com (Radim Vansa) Date: Tue, 8 Nov 2016 14:13:46 -0500 Subject: [hibernate-dev] [hibernate-announce] Releasing Hibernate OGM 5.1.0.Beta1: now with Hot Rod support! In-Reply-To: References: <950d8070-74e1-8b3b-80ba-084021a73034@redhat.com> Message-ID: <93d51c26-9ef1-d785-31c5-0dee1219d1cc@redhat.com> I understand that you don't want to scare users off, but I would mention that at least in the section about deciding between embedded and Hot Rod: "When connecting to an /Infinispan Server/ over the /Hot Rod client/, the architecture is similar to having Hibernate connect to traditional database: the data is stored on the /Infinispan Server/ nodes, and Hibernate OGM uses a client with a pool of TCP connections to talk to the server." Traditional databases are transactional, so I would put a notice about no-transactions here, with a link to "9.3.4. Storage Principles of the Infinispan Remote dataprovider" Most people probably understand what *is* the loss of referential integrity, but 9.3.4 is not really specific *when* does this happen. As you speak about "interrupting Hibernate OGM", I would assume that this is limited to a case when some operation fails (due to network breakage), but it's not clear that this can happen even with successful concurrent operations. Therefore, an example that can lead to broken integrity could be useful, along with information about concurrent operations that are safe (basically saying that if each session uses distinct set of entities, you are safe). Is there any option to detect (and fix) the problems? (by a batch job...?) Radim On 11/08/2016 01:53 PM, Sanne Grinovero wrote: > Thanks Radim! > > the blog attempts to be short, I mention the Referential Integrity > problem in the reference documentation: > > " > Referential integrity > While we can use relations based on foreign keys, Infinispan has no > notion of referential integrity. Hibernate is able to maintain the > integrity as it won?t "forget" stale references, > but since the > storage doesn?t support transactions either it is possible to > interrupt Hibernate OGM during such maintenance and introduce breaks > of integrity. > " > - https://docs.jboss.org/hibernate/ogm/5.1/reference/en-US/html_single/#storage_principles_of_the_infinispan_remote_dataprovider > > It's not explicitly listed in the known limitations, as I consider it > part of the "there's no transactions" point here: > - https://docs.jboss.org/hibernate/ogm/5.1/reference/en-US/html_single/#known_limitations_future_improvements > > You think that's enough? It's a though one, as I want to be clear > about the limitations but w/o scaring people off by repeating > limitations too many times. > There are also various big highlighted baloons mentioning: > > " > Caution > The Hibernate OGM support for Infinispan Remote is considered experimental. " > > Happy to clarify the docs as needed. > > Thanks! > Sanne > > > On 8 November 2016 at 17:50, Radim Vansa wrote: >> Wouldn't it be worth mentioning the lack of referential integrity among >> the limitations? >> >> Anyway, thumbs up! >> >> Radim >> >> On 11/08/2016 12:16 PM, Sanne Grinovero wrote: >>> Hello everyone, >>> >>> we can finally announce that Hibernate OGM 5.1.0.Beta1 is released, >>> and now includes support for Infinispan Server, alias Hot Rod, also >>> known as Infinispan Remote .. >>> >>> - http://in.relation.to/2016/11/08/hibernate-ogm-with-hotrod-support >>> >>> We also released Hibernate OGM 5.0.3.Final >>> >>> Kind Regards, >>> Sanne >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> -- >> Radim Vansa >> JBoss Performance Team >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Radim Vansa JBoss Performance Team From sanne at hibernate.org Tue Nov 8 14:59:02 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 8 Nov 2016 19:59:02 +0000 Subject: [hibernate-dev] [hibernate-announce] Releasing Hibernate OGM 5.1.0.Beta1: now with Hot Rod support! In-Reply-To: <93d51c26-9ef1-d785-31c5-0dee1219d1cc@redhat.com> References: <950d8070-74e1-8b3b-80ba-084021a73034@redhat.com> <93d51c26-9ef1-d785-31c5-0dee1219d1cc@redhat.com> Message-ID: On 8 November 2016 at 19:13, Radim Vansa wrote: > I understand that you don't want to scare users off, but I would mention > that at least in the section about deciding between embedded and Hot Rod: > > "When connecting to an /Infinispan Server/ over the /Hot Rod client/, the > architecture is similar to having Hibernate connect to traditional database: > the data is stored on the /Infinispan Server/ nodes, and Hibernate OGM uses > a client with a pool of TCP connections to talk to the server." > > Traditional databases are transactional, so I would put a notice about > no-transactions here, with a link to "9.3.4. Storage Principles of the > Infinispan Remote dataprovider" > > Most people probably understand what *is* the loss of referential integrity, > but 9.3.4 is not really specific *when* does this happen. As you speak about > "interrupting Hibernate OGM", I would assume that this is limited to a case > when some operation fails (due to network breakage), but it's not clear that > this can happen even with successful concurrent operations. Therefore, an > example that can lead to broken integrity could be useful, along with > information about concurrent operations that are safe (basically saying that > if each session uses distinct set of entities, you are safe). Ok, thanks I'll add the notice. I wouldn't go too much into an explanation though, as it's supposed to be a reference documentation and I feel like I'm writing a book about Infinispan :) - https://hibernate.atlassian.net/browse/OGM-1206 > Is there any option to detect (and fix) the problems? (by a batch job...?) We'd be able to identify references leading nowhere, but it's also possible that a once broken reference later leads to a valid entity... we'd not be able to spot those, so I'm afraid that such a tool would give a false sense of confidence. I guess we could strictly ban ID reuse, then we could avoid this and identify them safely; but what then? Deleting the owning entity is not always the right thing to do. A user's callback? I'm afraid it gets messy quickly. But also.. remember: people seem to be happy with stuff like MongoDB. Ignorance is a bliss? Let's admit that we want to do better and do "the right thing": clearly we need to work towards having proper transactions, or at least fully atomic operations. At least this OGM support is a great improvement in usability compared to "roll your own" backend using native Hot Rod APIs; remember Hibernate minimises the problem with referential integrity by updating relations in "the right order", I suspect it even takes some skill to craft an effective reproducer.. Thanks, Sanne > > Radim > > > On 11/08/2016 01:53 PM, Sanne Grinovero wrote: >> >> Thanks Radim! >> >> the blog attempts to be short, I mention the Referential Integrity >> problem in the reference documentation: >> >> " >> Referential integrity >> While we can use relations based on foreign keys, Infinispan has no >> notion of referential integrity. Hibernate is able to maintain the >> integrity as it won?t "forget" stale references, > but since the >> storage doesn?t support transactions either it is possible to >> interrupt Hibernate OGM during such maintenance and introduce breaks >> of integrity. >> " >> - >> https://docs.jboss.org/hibernate/ogm/5.1/reference/en-US/html_single/#storage_principles_of_the_infinispan_remote_dataprovider >> >> It's not explicitly listed in the known limitations, as I consider it >> part of the "there's no transactions" point here: >> - >> https://docs.jboss.org/hibernate/ogm/5.1/reference/en-US/html_single/#known_limitations_future_improvements >> >> You think that's enough? It's a though one, as I want to be clear >> about the limitations but w/o scaring people off by repeating >> limitations too many times. >> There are also various big highlighted baloons mentioning: >> >> " >> Caution >> The Hibernate OGM support for Infinispan Remote is considered >> experimental. " >> >> Happy to clarify the docs as needed. >> >> Thanks! >> Sanne >> >> >> On 8 November 2016 at 17:50, Radim Vansa wrote: >>> >>> Wouldn't it be worth mentioning the lack of referential integrity among >>> the limitations? >>> >>> Anyway, thumbs up! >>> >>> Radim >>> >>> On 11/08/2016 12:16 PM, Sanne Grinovero wrote: >>>> >>>> Hello everyone, >>>> >>>> we can finally announce that Hibernate OGM 5.1.0.Beta1 is released, >>>> and now includes support for Infinispan Server, alias Hot Rod, also >>>> known as Infinispan Remote .. >>>> >>>> - http://in.relation.to/2016/11/08/hibernate-ogm-with-hotrod-support >>>> >>>> We also released Hibernate OGM 5.0.3.Final >>>> >>>> Kind Regards, >>>> Sanne >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> >>> -- >>> Radim Vansa >>> JBoss Performance Team >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > -- > Radim Vansa > JBoss Performance Team > From steve at hibernate.org Wed Nov 9 09:15:30 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 09 Nov 2016 14:15:30 +0000 Subject: [hibernate-dev] Checkstyle checks in ORM Message-ID: While developing the Byte Buddy Enhancer, Rafael ran into what I thnk is a valid problem in the ORM build. Namely the fact that we incorporate non-fatal Checktyle checks. In local builds this leads to a situation where it is extremely difficult for new contributors to find out what exactly they violated. Jenkins presents these better and makes it easier to see just "fatal" (high priority) violations, but the Checktype report itself does not. Even worse the Checkstyle report does not even show the priority of individual violations at all. I suggest we remove all non-fatal Checkstyle rules to make it easier on contributors. From davide at hibernate.org Wed Nov 9 10:14:07 2016 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 9 Nov 2016 15:14:07 +0000 Subject: [hibernate-dev] Checkstyle checks in ORM In-Reply-To: References: Message-ID: What do you think about having different profiles? One for new contributors (more relaxed) and one for active developers. Given that I'm not sure what kind of checkstyle rules we are talking about. On Wed, Nov 9, 2016 at 2:15 PM, Steve Ebersole wrote: > While developing the Byte Buddy Enhancer, Rafael ran into what I thnk is a > valid problem in the ORM build. Namely the fact that we incorporate > non-fatal Checktyle checks. In local builds this leads to a situation > where it is extremely difficult for new contributors to find out what > exactly they violated. Jenkins presents these better and makes it easier > to see just "fatal" (high priority) violations, but the Checktype report > itself does not. Even worse the Checkstyle report does not even show the > priority of individual violations at all. > > I suggest we remove all non-fatal Checkstyle rules to make it easier on > contributors. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From mihalcea.vlad at gmail.com Wed Nov 9 10:20:35 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 9 Nov 2016 17:20:35 +0200 Subject: [hibernate-dev] Checkstyle checks in ORM In-Reply-To: References: Message-ID: I like Davide's proposal. +1 On Wed, Nov 9, 2016 at 5:14 PM, Davide D'Alto wrote: > What do you think about having different profiles? > One for new contributors (more relaxed) > and one for active developers. > > Given that I'm not sure what kind of checkstyle rules we are talking about. > > On Wed, Nov 9, 2016 at 2:15 PM, Steve Ebersole > wrote: > > While developing the Byte Buddy Enhancer, Rafael ran into what I thnk is > a > > valid problem in the ORM build. Namely the fact that we incorporate > > non-fatal Checktyle checks. In local builds this leads to a situation > > where it is extremely difficult for new contributors to find out what > > exactly they violated. Jenkins presents these better and makes it easier > > to see just "fatal" (high priority) violations, but the Checktype report > > itself does not. Even worse the Checkstyle report does not even show the > > priority of individual violations at all. > > > > I suggest we remove all non-fatal Checkstyle rules to make it easier on > > contributors. > > _______________________________________________ > > 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 > From steve at hibernate.org Wed Nov 9 10:20:36 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 09 Nov 2016 15:20:36 +0000 Subject: [hibernate-dev] Checkstyle checks in ORM In-Reply-To: References: Message-ID: http://ci.hibernate.org/job/hibernate-orm-master-h2-check/106/checkstyleResult/ Any of the 0 versus 2846 + 609 On Wed, Nov 9, 2016 at 9:14 AM Davide D'Alto wrote: > What do you think about having different profiles? > One for new contributors (more relaxed) > and one for active developers. > > Given that I'm not sure what kind of checkstyle rules we are talking about. > > On Wed, Nov 9, 2016 at 2:15 PM, Steve Ebersole > wrote: > > While developing the Byte Buddy Enhancer, Rafael ran into what I thnk is > a > > valid problem in the ORM build. Namely the fact that we incorporate > > non-fatal Checktyle checks. In local builds this leads to a situation > > where it is extremely difficult for new contributors to find out what > > exactly they violated. Jenkins presents these better and makes it easier > > to see just "fatal" (high priority) violations, but the Checktype report > > itself does not. Even worse the Checkstyle report does not even show the > > priority of individual violations at all. > > > > I suggest we remove all non-fatal Checkstyle rules to make it easier on > > contributors. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Nov 9 10:22:35 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 09 Nov 2016 15:22:35 +0000 Subject: [hibernate-dev] Checkstyle checks in ORM In-Reply-To: References: Message-ID: Gradle does not have profiles. So you mean different tasks? On Wed, Nov 9, 2016 at 9:20 AM Vlad Mihalcea wrote: > I like Davide's proposal. +1 > > On Wed, Nov 9, 2016 at 5:14 PM, Davide D'Alto > wrote: > > What do you think about having different profiles? > One for new contributors (more relaxed) > and one for active developers. > > Given that I'm not sure what kind of checkstyle rules we are talking about. > > On Wed, Nov 9, 2016 at 2:15 PM, Steve Ebersole > wrote: > > While developing the Byte Buddy Enhancer, Rafael ran into what I thnk is > a > > valid problem in the ORM build. Namely the fact that we incorporate > > non-fatal Checktyle checks. In local builds this leads to a situation > > where it is extremely difficult for new contributors to find out what > > exactly they violated. Jenkins presents these better and makes it easier > > to see just "fatal" (high priority) violations, but the Checktype report > > itself does not. Even worse the Checkstyle report does not even show the > > priority of individual violations at all. > > > > I suggest we remove all non-fatal Checkstyle rules to make it easier on > > contributors. > > _______________________________________________ > > 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 > > > From steve at hibernate.org Wed Nov 9 10:42:00 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 09 Nov 2016 15:42:00 +0000 Subject: [hibernate-dev] Checkstyle checks in ORM In-Reply-To: References: Message-ID: https://hibernate.atlassian.net/browse/HHH-11235 On Wed, Nov 9, 2016 at 9:22 AM Steve Ebersole wrote: > Gradle does not have profiles. So you mean different tasks? > > > On Wed, Nov 9, 2016 at 9:20 AM Vlad Mihalcea > wrote: > > I like Davide's proposal. +1 > > On Wed, Nov 9, 2016 at 5:14 PM, Davide D'Alto > wrote: > > What do you think about having different profiles? > One for new contributors (more relaxed) > and one for active developers. > > Given that I'm not sure what kind of checkstyle rules we are talking about. > > On Wed, Nov 9, 2016 at 2:15 PM, Steve Ebersole > wrote: > > While developing the Byte Buddy Enhancer, Rafael ran into what I thnk is > a > > valid problem in the ORM build. Namely the fact that we incorporate > > non-fatal Checktyle checks. In local builds this leads to a situation > > where it is extremely difficult for new contributors to find out what > > exactly they violated. Jenkins presents these better and makes it easier > > to see just "fatal" (high priority) violations, but the Checktype report > > itself does not. Even worse the Checkstyle report does not even show the > > priority of individual violations at all. > > > > I suggest we remove all non-fatal Checkstyle rules to make it easier on > > contributors. > > _______________________________________________ > > 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 > > > From guillaume.smet at hibernate.org Thu Nov 10 12:37:37 2016 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Thu, 10 Nov 2016 18:37:37 +0100 Subject: [hibernate-dev] Hibernate Validator 5.3.2.Final is out Message-ID: Hi, I'm pleased to announce the second maintenance release of Hibernate Validator 5.3. For more information, please see the full announcement here: http://in.relation.to/2016/11/10/hibernate-validator-532-final-out/ . Have a nice day! -- Guillaume From sanne at hibernate.org Thu Nov 10 19:18:41 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 11 Nov 2016 00:18:41 +0000 Subject: [hibernate-dev] Vibur DBCP connection pool Message-ID: Hi all, Steve in particular, there's a nice and friendly offer to integrate this connection pool in the "Hibernate distribution". - https://hibernate.atlassian.net/browse/HHH-10541 I asked to Simeon - the project lead for Vibur and issue reporter - if he would help to maintain it and there seem to be good intentions.. but then we didn't get him an answer. What do you all think about this? I understand we can't integrate everything but the approach seemed promising to me; he has a point that it would just be simpler to maintain if the integration point it incorporated, like we do with HikariCP and the most popular 2nd level cache implementations. Thanks, Sanne From steve at hibernate.org Thu Nov 10 19:56:03 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 11 Nov 2016 00:56:03 +0000 Subject: [hibernate-dev] Vibur DBCP connection pool In-Reply-To: References: Message-ID: I replied on the Jira. I apologize - for some reason I did not receive notifications from that issue On Thu, Nov 10, 2016 at 6:21 PM Sanne Grinovero wrote: > Hi all, Steve in particular, > > there's a nice and friendly offer to integrate this connection pool in the > "Hibernate distribution". > - https://hibernate.atlassian.net/browse/HHH-10541 > > I asked to Simeon - the project lead for Vibur and issue reporter - if he > would help to maintain it and there seem to be good intentions.. but then > we didn't get him an answer. > > What do you all think about this? > > I understand we can't integrate everything but the approach seemed > promising to me; he has a point that it would just be simpler to maintain > if the integration point it incorporated, like we do with HikariCP and the > most popular 2nd level cache implementations. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From davide at hibernate.org Wed Nov 16 07:42:52 2016 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 16 Nov 2016 12:42:52 +0000 Subject: [hibernate-dev] [OGM] Inheritance mapping in Neo4j Message-ID: A user created the issue https://hibernate.atlassian.net/browse/OGM-1210 The problem is that when we use the SingleTable strategy in Neo4j we add a property DTYPE to the node to discriminate the entities instead of using labels. As an example, given an entity Player that extends Person we create: (n:Person {DTYPE: Player}) instead of having a node with two labels: (n:Person:Player) I think the mapping with multiple labels is more natural than the one we currently have. I was wondering if we should fix this for the next release, the problem is that I would need additional information in one of our .spi.*Context and it will change the mapping. The next release should be 5.1.Beta2 What do you think? Thanks, Davide From sanne at hibernate.org Thu Nov 17 08:13:08 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 17 Nov 2016 13:13:08 +0000 Subject: [hibernate-dev] Shaping the requirements for the new DocumentBuilder to come in Hibernate Search 6 Message-ID: Hi all, among the various plans for Hibernate Search 6, one of the reasons we had to do the Elasticsearch integration sooner as experimental was to get ourselves a clearer picture of what's going to be needed in terms of internal cleanup. Our DocumentBuilder is ancient, and several new features have been added since it was a well designed, simple piece of code.. So, while we have discussed several wishes already, I started now a document to try get all our thoughts to converge. For convenience, pasting the current content below. - https://docs.google.com/document/d/1JwKanIRHVTw1LvCdLGyY6EKuyvvQn6gvlkmPGqDjFxw/edit?usp=sharing I'm not giving comment permissions to the world; anyone who's interested please answer here or drop me a note, happy to give permissions to comment to well-intentioned people. N.B. The document will very likely evolve beyond this email; as it is now it's an initial brain dump. For example, I haven't thought about the ES capability of nesting structures yet. Thanks, Sanne ==== Pasting from document ===== DocumentBuilder and FieldBridge requirements for Hibernate Search 6.0 * Never import Lucene types; ideally make Lucene an dependency of the Lucene backend only. * In a modular world, don?t expect end user code to be able to load Lucene class definitions. * Efficient lookup ?field name? -> field mappings and its indexing options; not least: * Cardinality {always one, optional one, one-many, zero-many} * Needed for validation of queries, e.g. query for null can use an ?exists? query only in some of these cases, vs needing a null token. * projectable alone vs part of multiple fields relating to a single property (allow projection of Two-Way bridges using multiple fields) * Might need ?group name?.?sub field name? for groups and index time joins * IndexedEmbedded * ?depth? and navigational graph to be pre-computed: tree of valid fields and options to be known in advance. * Navigating into a relation must deal with possibly navigating into subclasses of the relation type: http://stackoverflow.com/questions/39516355/indexing-a-interface-in-hibernate-search * Immutable, threadsafe, easy to inspect/walk mapping tree * Built and validated at boostrap of the IndexManager * can?t be updated after that * Field names and custom FieldType not to be allocated at runtime * Efficient to validate Queries * Allow efficient production of an Entity instance into: * Elasticsearch ?document? * Lucene ?document? * An efficient to serialize ?document? * If it gets easy enough, make our own simple serialization? * Extensible to other backends e.g. Apache Solr in the future (a Walkable SPI) * Pretty printed text to dump the ?schema? we?re using from a given domain model * Validations and comparisons * Allow to validate compatibility with an Elasticsearch schema * Allow to validate compatibility with a Lucene schema * Walking tree to map to ORM loading strategies * allow to predict which paths we?ll need to initialize (database load) for efficient batch loading (graph initialization) * Allow for accurate Dirty-checking to skip indexing operations * Allow generation of better MassIndexer queries (fetch join some of the relations?) * ID handling: specific care * ad-hoc encoders for ID * stricter validation (e.g. cardinatlity, DocValues, Two-Way fieldbridges) * Support multi-term IDs (composite keys, @IdClass) * Have different ?index id strategies? to have them apply different logic, i.e. ?delete by term? and ?update by term? only apply on single-term IDs. * ID handling strategy might need to take into account if the index is shared among types. * Decoupling from Java ?Class? as entity-type identifiers * Sharding: * Allow reuse of the same schema for indexes using the same * Allow reuse of some elements for indexes sharing such elements * Properties / Field relations * Handle one property -> multiple Fields as a bidirectional relation. * Disallow one index field being target of different properties and/or bridges? * Representation of ?Join points? and Groups: * allow future production of Lucene documents with index-time join (write in groups) * allow efficient Query validation for both index-time and query-time join options * Composable * @ClassBridge, @Field annotations to both contribute to field definitions * a @ClassBridge of an @IndexedEmbedded to both contribute to the embedded field definitions * Include type-bound user custom Bridges (see BridgeProvider) in the compositions * Both @ClassBridge and custom Bridges need to trigger on polymorphic relations as well From sanne at hibernate.org Thu Nov 17 08:30:23 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 17 Nov 2016 13:30:23 +0000 Subject: [hibernate-dev] [OGM] Inheritance mapping in Neo4j In-Reply-To: References: Message-ID: Hi, it makes sense but I don't think we can change the mapping now. Could you do it as a new option? Would you be able to adjust the queries as needed? If you can make it a configuration property, default to the old style mapping, and log a warning of using a deprecated mapping when the old one is being used. This implies that people not choosing any mapping style explicitly will see a warning (as the old one would still be the default). Thanks, Sanne On 16 November 2016 at 12:42, Davide D'Alto wrote: > A user created the issue https://hibernate.atlassian.net/browse/OGM-1210 > > The problem is that when we use the SingleTable strategy in Neo4j we > add a property DTYPE to the node to discriminate the entities instead > of using labels. > > As an example, given an entity Player that extends Person we create: > > (n:Person {DTYPE: Player}) > > instead of having a node with two labels: > > (n:Person:Player) > > I think the mapping with multiple labels is more natural than the one > we currently have. > > I was wondering if we should fix this for the next release, the > problem is that I would need additional information in one of our > .spi.*Context and it will change the mapping. > > The next release should be 5.1.Beta2 > > What do you think? > > Thanks, > Davide > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Thu Nov 17 09:15:47 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 17 Nov 2016 15:15:47 +0100 Subject: [hibernate-dev] [OGM] Inheritance mapping in Neo4j In-Reply-To: References: Message-ID: Hi, As I understand it, having 2 labels means that you could search either with n:Person or n:Player? Thus if we keep the DTYPE: Player in place in addition to both labels, we won't break anything, will we? -- Guillaume On Thu, Nov 17, 2016 at 2:30 PM, Sanne Grinovero wrote: > Hi, it makes sense but I don't think we can change the mapping now. > > Could you do it as a new option? Would you be able to adjust the > queries as needed? > > If you can make it a configuration property, default to the old style > mapping, and log a warning of using a deprecated mapping when the old > one is being used. This implies that people not choosing any mapping > style explicitly will see a warning (as the old one would still be the > default). > > Thanks, > Sanne > > On 16 November 2016 at 12:42, Davide D'Alto wrote: > > A user created the issue https://hibernate.atlassian.net/browse/OGM-1210 > > > > The problem is that when we use the SingleTable strategy in Neo4j we > > add a property DTYPE to the node to discriminate the entities instead > > of using labels. > > > > As an example, given an entity Player that extends Person we create: > > > > (n:Person {DTYPE: Player}) > > > > instead of having a node with two labels: > > > > (n:Person:Player) > > > > I think the mapping with multiple labels is more natural than the one > > we currently have. > > > > I was wondering if we should fix this for the next release, the > > problem is that I would need additional information in one of our > > .spi.*Context and it will change the mapping. > > > > The next release should be 5.1.Beta2 > > > > What do you think? > > > > Thanks, > > Davide > > _______________________________________________ > > 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 > From davide at hibernate.org Thu Nov 17 09:26:53 2016 From: davide at hibernate.org (Davide D'Alto) Date: Thu, 17 Nov 2016 14:26:53 +0000 Subject: [hibernate-dev] [OGM] Inheritance mapping in Neo4j In-Reply-To: References: Message-ID: Yes, I think that if we keep the property and only add the label we won't break anything in the mapping. On Thu, Nov 17, 2016 at 2:15 PM, Guillaume Smet wrote: > Hi, > > As I understand it, having 2 labels means that you could search either with > n:Person or n:Player? > > Thus if we keep the DTYPE: Player in place in addition to both labels, we > won't break anything, will we? > > -- > Guillaume > > On Thu, Nov 17, 2016 at 2:30 PM, Sanne Grinovero > wrote: >> >> Hi, it makes sense but I don't think we can change the mapping now. >> >> Could you do it as a new option? Would you be able to adjust the >> queries as needed? >> >> If you can make it a configuration property, default to the old style >> mapping, and log a warning of using a deprecated mapping when the old >> one is being used. This implies that people not choosing any mapping >> style explicitly will see a warning (as the old one would still be the >> default). >> >> Thanks, >> Sanne >> >> On 16 November 2016 at 12:42, Davide D'Alto wrote: >> > A user created the issue https://hibernate.atlassian.net/browse/OGM-1210 >> > >> > The problem is that when we use the SingleTable strategy in Neo4j we >> > add a property DTYPE to the node to discriminate the entities instead >> > of using labels. >> > >> > As an example, given an entity Player that extends Person we create: >> > >> > (n:Person {DTYPE: Player}) >> > >> > instead of having a node with two labels: >> > >> > (n:Person:Player) >> > >> > I think the mapping with multiple labels is more natural than the one >> > we currently have. >> > >> > I was wondering if we should fix this for the next release, the >> > problem is that I would need additional information in one of our >> > .spi.*Context and it will change the mapping. >> > >> > The next release should be 5.1.Beta2 >> > >> > What do you think? >> > >> > Thanks, >> > Davide >> > _______________________________________________ >> > 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 > > From mihalcea.vlad at gmail.com Sat Nov 19 05:04:45 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Sat, 19 Nov 2016 12:04:45 +0200 Subject: [hibernate-dev] Correlating Java 1.8 Streams and ScrollableResults with database cursors Message-ID: Hi, I've noticed this new Jira ticket: https://hibernate.atlassian.net/browse/HHH-11260 and I think we should correlate the Session#stream and Session#scroll with database cursors. While Oracle uses a fetch size of 10, and SQL Server uses an adaptive cursor, PostgreSQL and MySQL just fetch the whole result set into the client. So, for MySQL we could do as suggested in the Jira ticket, by setting the fetch size to Integer.MIN_VALUE. My question is about PotgreSQL. Postgres requires setting the fetch size to some positive value in order to turn the current statement into a database cursor. Now, should we set a default value for streaming (e.g. 10), which can be controlled via a new config property: hibernate.jdbc.stream.fetch_size Let me know what you think. Vlad From vikas_bali at calypso.com Sun Nov 20 13:51:11 2016 From: vikas_bali at calypso.com (Vikas Bali) Date: Sun, 20 Nov 2016 18:51:11 +0000 Subject: [hibernate-dev] FW: DirectPropertyAccessor replacement in hibernate 5.2.4 In-Reply-To: References: Message-ID: Hi I used to extend DirectPropertyAccessor and had custom implementation of getter and setter implementation of the hibernate property. Could you please let me know what should I replace it with. I tried replacing it with PropertyAccessStrategyBasicImpl and PropertyAccessStrategyFieldImpl but I keep getting error of missing field on the properties defined in my hbm file and it used to work fine with hibernate 4.1.6.Final. Please suggest. Thanks Vikas From rvansa at redhat.com Mon Nov 21 05:04:12 2016 From: rvansa at redhat.com (Radim Vansa) Date: Mon, 21 Nov 2016 11:04:12 +0100 Subject: [hibernate-dev] Change in DB lock acquisition in ORM? Message-ID: <6c0fa4b5-aa6d-3871-5b8c-d38faed32581@redhat.com> Hi, I am investigating the failures in hibernate-infinispan testsuite and I've found that [1] is failing as this uses two threads that both do 1. load entity 2. delete entity 3. flush session 4. commit tx on the same entity. There is a synchronization blocking the commit until both threads flush, and since the first thread holds a H2 DB lock on the entity, the other thread is blocked doing the flush on this lock. It makes sense to me, but I wonder why did the test work in the past. Was there a change in some locking defaults (optimistic/pessimistic) or was there anything delegating the lock acquisition to the commit instead of flush? The test works on 5.0.10. Radim [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/TombstoneTest.java#L37 -- Radim Vansa JBoss Performance Team From sanne at hibernate.org Mon Nov 21 06:15:40 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 21 Nov 2016 11:15:40 +0000 Subject: [hibernate-dev] Change in DB lock acquisition in ORM? In-Reply-To: <6c0fa4b5-aa6d-3871-5b8c-d38faed32581@redhat.com> References: <6c0fa4b5-aa6d-3871-5b8c-d38faed32581@redhat.com> Message-ID: Hi Radim, I was wondering the same; I am not sure yet if it's related, but noticed that the JDBC connection URL changed from jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1 to jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=10000 I'm running the testsuite now reverting that change locally, but I can't say yet as the tests take ages to run... If anyone knows of other locking related changes please let us know :) Thanks, Sanne On 21 November 2016 at 10:04, Radim Vansa wrote: > Hi, > > I am investigating the failures in hibernate-infinispan testsuite and > I've found that [1] is failing as this uses two threads that both do > > 1. load entity > 2. delete entity > 3. flush session > 4. commit tx > > on the same entity. There is a synchronization blocking the commit until > both threads flush, and since the first thread holds a H2 DB lock on the > entity, the other thread is blocked doing the flush on this lock. > > It makes sense to me, but I wonder why did the test work in the past. > Was there a change in some locking defaults (optimistic/pessimistic) or > was there anything delegating the lock acquisition to the commit instead > of flush? The test works on 5.0.10. > > Radim > > [1] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/TombstoneTest.java#L37 > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Mon Nov 21 06:16:37 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 21 Nov 2016 11:16:37 +0000 Subject: [hibernate-dev] Change in DB lock acquisition in ORM? In-Reply-To: References: <6c0fa4b5-aa6d-3871-5b8c-d38faed32581@redhat.com> Message-ID: Actually those tests just failed, so that's not it. On 21 November 2016 at 11:15, Sanne Grinovero wrote: > Hi Radim, > I was wondering the same; I am not sure yet if it's related, but > noticed that the JDBC connection URL changed from > > jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1 > > to > > jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=10000 > > I'm running the testsuite now reverting that change locally, but I > can't say yet as the tests take ages to run... > > If anyone knows of other locking related changes please let us know :) > > Thanks, > Sanne > > > On 21 November 2016 at 10:04, Radim Vansa wrote: >> Hi, >> >> I am investigating the failures in hibernate-infinispan testsuite and >> I've found that [1] is failing as this uses two threads that both do >> >> 1. load entity >> 2. delete entity >> 3. flush session >> 4. commit tx >> >> on the same entity. There is a synchronization blocking the commit until >> both threads flush, and since the first thread holds a H2 DB lock on the >> entity, the other thread is blocked doing the flush on this lock. >> >> It makes sense to me, but I wonder why did the test work in the past. >> Was there a change in some locking defaults (optimistic/pessimistic) or >> was there anything delegating the lock acquisition to the commit instead >> of flush? The test works on 5.0.10. >> >> Radim >> >> [1] >> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/TombstoneTest.java#L37 >> >> >> -- >> Radim Vansa >> JBoss Performance Team >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From rvansa at redhat.com Mon Nov 21 06:43:31 2016 From: rvansa at redhat.com (Radim Vansa) Date: Mon, 21 Nov 2016 12:43:31 +0100 Subject: [hibernate-dev] Change in DB lock acquisition in ORM? In-Reply-To: References: <6c0fa4b5-aa6d-3871-5b8c-d38faed32581@redhat.com> Message-ID: <123610f4-8f21-97cf-bf16-770014f02000@redhat.com> Aha, that explains why the test take much longer. I was just about to look this up. I'll see if I can shorten this for tests where we expect such situations. Nevertheless, the test seems to be failing because it used to throw org.hibernate. PessimisticLockException and now it is throwing javax.persistence.PessimisticLockException (the hibernate exception is provided as cause). Radim On 11/21/2016 12:15 PM, Sanne Grinovero wrote: > Hi Radim, > I was wondering the same; I am not sure yet if it's related, but > noticed that the JDBC connection URL changed from > > jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1 > > to > > jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=10000 > > I'm running the testsuite now reverting that change locally, but I > can't say yet as the tests take ages to run... > > If anyone knows of other locking related changes please let us know :) > > Thanks, > Sanne > > > On 21 November 2016 at 10:04, Radim Vansa wrote: >> Hi, >> >> I am investigating the failures in hibernate-infinispan testsuite and >> I've found that [1] is failing as this uses two threads that both do >> >> 1. load entity >> 2. delete entity >> 3. flush session >> 4. commit tx >> >> on the same entity. There is a synchronization blocking the commit until >> both threads flush, and since the first thread holds a H2 DB lock on the >> entity, the other thread is blocked doing the flush on this lock. >> >> It makes sense to me, but I wonder why did the test work in the past. >> Was there a change in some locking defaults (optimistic/pessimistic) or >> was there anything delegating the lock acquisition to the commit instead >> of flush? The test works on 5.0.10. >> >> Radim >> >> [1] >> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/TombstoneTest.java#L37 >> >> >> -- >> Radim Vansa >> JBoss Performance Team >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Radim Vansa JBoss Performance Team From steve at hibernate.org Mon Nov 21 09:44:54 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 21 Nov 2016 14:44:54 +0000 Subject: [hibernate-dev] Change in DB lock acquisition in ORM? In-Reply-To: <123610f4-8f21-97cf-bf16-770014f02000@redhat.com> References: <6c0fa4b5-aa6d-3871-5b8c-d38faed32581@redhat.com> <123610f4-8f21-97cf-bf16-770014f02000@redhat.com> Message-ID: The change in exception type is new to 5.2 (merging HEM into core). IIRC you did not "see failures in hibernate-infinispan tests" because we had those disabled due to their ongoing intermittent failures. On Mon, Nov 21, 2016 at 5:46 AM Radim Vansa wrote: > Aha, that explains why the test take much longer. I was just about to > look this up. I'll see if I can shorten this for tests where we expect > such situations. > > Nevertheless, the test seems to be failing because it used to throw > org.hibernate. PessimisticLockException and now it is throwing > javax.persistence.PessimisticLockException (the hibernate exception is > provided as cause). > > Radim > > On 11/21/2016 12:15 PM, Sanne Grinovero wrote: > > Hi Radim, > > I was wondering the same; I am not sure yet if it's related, but > > noticed that the JDBC connection URL changed from > > > > jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1 > > > > to > > > > jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=10000 > > > > I'm running the testsuite now reverting that change locally, but I > > can't say yet as the tests take ages to run... > > > > If anyone knows of other locking related changes please let us know :) > > > > Thanks, > > Sanne > > > > > > On 21 November 2016 at 10:04, Radim Vansa wrote: > >> Hi, > >> > >> I am investigating the failures in hibernate-infinispan testsuite and > >> I've found that [1] is failing as this uses two threads that both do > >> > >> 1. load entity > >> 2. delete entity > >> 3. flush session > >> 4. commit tx > >> > >> on the same entity. There is a synchronization blocking the commit until > >> both threads flush, and since the first thread holds a H2 DB lock on the > >> entity, the other thread is blocked doing the flush on this lock. > >> > >> It makes sense to me, but I wonder why did the test work in the past. > >> Was there a change in some locking defaults (optimistic/pessimistic) or > >> was there anything delegating the lock acquisition to the commit instead > >> of flush? The test works on 5.0.10. > >> > >> Radim > >> > >> [1] > >> > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/TombstoneTest.java#L37 > >> > >> > >> -- > >> Radim Vansa > >> JBoss Performance Team > >> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Mon Nov 21 10:30:10 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 21 Nov 2016 17:30:10 +0200 Subject: [hibernate-dev] Change in DB lock acquisition in ORM? In-Reply-To: References: <6c0fa4b5-aa6d-3871-5b8c-d38faed32581@redhat.com> <123610f4-8f21-97cf-bf16-770014f02000@redhat.com> Message-ID: The only thing related to transaction handling was the way connection are released. Now, we are using AFTER_TRANSACTION instead of ON_CLOSE for resource local ones. But that should not impact your test, I guess. Vlad On Mon, Nov 21, 2016 at 4:44 PM, Steve Ebersole wrote: > The change in exception type is new to 5.2 (merging HEM into core). IIRC > you did not "see failures in hibernate-infinispan tests" because we had > those disabled due to their ongoing intermittent failures. > > > On Mon, Nov 21, 2016 at 5:46 AM Radim Vansa wrote: > > > Aha, that explains why the test take much longer. I was just about to > > look this up. I'll see if I can shorten this for tests where we expect > > such situations. > > > > Nevertheless, the test seems to be failing because it used to throw > > org.hibernate. PessimisticLockException and now it is throwing > > javax.persistence.PessimisticLockException (the hibernate exception is > > provided as cause). > > > > Radim > > > > On 11/21/2016 12:15 PM, Sanne Grinovero wrote: > > > Hi Radim, > > > I was wondering the same; I am not sure yet if it's related, but > > > noticed that the JDBC connection URL changed from > > > > > > jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1 > > > > > > to > > > > > > jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=10000 > > > > > > I'm running the testsuite now reverting that change locally, but I > > > can't say yet as the tests take ages to run... > > > > > > If anyone knows of other locking related changes please let us know :) > > > > > > Thanks, > > > Sanne > > > > > > > > > On 21 November 2016 at 10:04, Radim Vansa wrote: > > >> Hi, > > >> > > >> I am investigating the failures in hibernate-infinispan testsuite and > > >> I've found that [1] is failing as this uses two threads that both do > > >> > > >> 1. load entity > > >> 2. delete entity > > >> 3. flush session > > >> 4. commit tx > > >> > > >> on the same entity. There is a synchronization blocking the commit > until > > >> both threads flush, and since the first thread holds a H2 DB lock on > the > > >> entity, the other thread is blocked doing the flush on this lock. > > >> > > >> It makes sense to me, but I wonder why did the test work in the past. > > >> Was there a change in some locking defaults (optimistic/pessimistic) > or > > >> was there anything delegating the lock acquisition to the commit > instead > > >> of flush? The test works on 5.0.10. > > >> > > >> Radim > > >> > > >> [1] > > >> > > https://github.com/hibernate/hibernate-orm/blob/master/ > hibernate-infinispan/src/test/java/org/hibernate/test/cache/ > infinispan/functional/TombstoneTest.java#L37 > > >> > > >> > > >> -- > > >> Radim Vansa > > >> JBoss Performance Team > > >> > > >> _______________________________________________ > > >> hibernate-dev mailing list > > >> hibernate-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > -- > > Radim Vansa > > JBoss Performance Team > > > > _______________________________________________ > > 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 > From steve at hibernate.org Mon Nov 21 12:16:31 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 21 Nov 2016 17:16:31 +0000 Subject: [hibernate-dev] SQM - subqueries and order-by Message-ID: SQL 92, 93 and 99 (i have not checked 2003) all limit order-by to only be allowable in the root query. Unfortunately the current HQL grammar allows subqueries to be ordered. So I wanted to start a discussion of whether we want to support this as we transition to SQM and 6.0. The real problem with supporting ordering of a subquery is that neither HQL nor JPQL support pagination of a subquery which is honestly the only time that ordering the subquery makes any sense. So IMO we have 2 choices: 1. Add a new pagination syntax to the HQL language and continue to allow ordering of subqueries 2. drop support for ordering subqueries. Thoughts? From sanne at hibernate.org Mon Nov 21 13:09:43 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 21 Nov 2016 18:09:43 +0000 Subject: [hibernate-dev] Correlating Java 1.8 Streams and ScrollableResults with database cursors In-Reply-To: References: Message-ID: Hi Vlad, I'm not sure if we should set the fetch size automatically, especially not globally. Could we not use the API wisely to encourage people to provide an estimate of a reasonable size, which will be different on each query? I'm aware that MySQL requires this strange value to avoid pre-loading it all in memory; in fact for example in Hibernate Search the "mass index rebuild" has to scroll on the whole dataset, so the documentation recommends to set the fetch size.. However in some cases the optimisation might make sense; for example if the resultset is small, why would you use pagination when you can load it all in one single roundtrip? On the other hand, if you all think Hibernate should be able to figure this out automatically, then maybe I should also change Search to automatically set MIN_VALUE when running on MySQL, etc.. Thanks, Sanne On 19 November 2016 at 10:04, Vlad Mihalcea wrote: > Hi, > > I've noticed this new Jira ticket: > > https://hibernate.atlassian.net/browse/HHH-11260 > > and I think we should correlate the Session#stream and Session#scroll with > database cursors. > > While Oracle uses a fetch size of 10, and SQL Server uses an adaptive > cursor, PostgreSQL and MySQL just fetch the whole result set into the > client. > > So, for MySQL we could do as suggested in the Jira ticket, by setting the > fetch size to Integer.MIN_VALUE. > > My question is about PotgreSQL. Postgres requires setting the fetch size to > some positive value in order to turn the current statement into a database > cursor. > Now, should we set a default value for streaming (e.g. 10), which can be > controlled via a new config property: > > hibernate.jdbc.stream.fetch_size > > Let me know what you think. > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Nov 21 13:17:30 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 21 Nov 2016 18:17:30 +0000 Subject: [hibernate-dev] Correlating Java 1.8 Streams and ScrollableResults with database cursors In-Reply-To: References: Message-ID: I had a discussion about this with Vlad on the PR and privately on HipChat. I personally am -1 on this as well. As you say Sanne the problem is "if you all think Hibernate should be able to figure this out automatically"... You would never be able to figure this out across all situations. On Mon, Nov 21, 2016 at 12:12 PM Sanne Grinovero wrote: > Hi Vlad, > I'm not sure if we should set the fetch size automatically, especially > not globally. Could we not use the API wisely to encourage people to > provide an estimate of a reasonable size, which will be different on > each query? > > I'm aware that MySQL requires this strange value to avoid pre-loading > it all in memory; in fact for example in Hibernate Search the "mass > index rebuild" has to scroll on the whole dataset, so the > documentation recommends to set the fetch size.. > > However in some cases the optimisation might make sense; for example > if the resultset is small, why would you use pagination when you can > load it all in one single roundtrip? > > On the other hand, if you all think Hibernate should be able to figure > this out automatically, then maybe I should also change Search to > automatically set MIN_VALUE when running on MySQL, etc.. > > Thanks, > Sanne > > > > > On 19 November 2016 at 10:04, Vlad Mihalcea > wrote: > > Hi, > > > > I've noticed this new Jira ticket: > > > > https://hibernate.atlassian.net/browse/HHH-11260 > > > > and I think we should correlate the Session#stream and Session#scroll > with > > database cursors. > > > > While Oracle uses a fetch size of 10, and SQL Server uses an adaptive > > cursor, PostgreSQL and MySQL just fetch the whole result set into the > > client. > > > > So, for MySQL we could do as suggested in the Jira ticket, by setting the > > fetch size to Integer.MIN_VALUE. > > > > My question is about PotgreSQL. Postgres requires setting the fetch size > to > > some positive value in order to turn the current statement into a > database > > cursor. > > Now, should we set a default value for streaming (e.g. 10), which can be > > controlled via a new config property: > > > > hibernate.jdbc.stream.fetch_size > > > > Let me know what you think. > > > > Vlad > > _______________________________________________ > > 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 > From sanne at hibernate.org Mon Nov 21 13:25:34 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 21 Nov 2016 18:25:34 +0000 Subject: [hibernate-dev] Correlating Java 1.8 Streams and ScrollableResults with database cursors In-Reply-To: References: Message-ID: On 21 November 2016 at 18:17, Steve Ebersole wrote: > I had a discussion about this with Vlad on the PR and privately on HipChat. > > I personally am -1 on this as well. As you say Sanne the problem is "if you > all think Hibernate should be able to figure this out automatically"... You > would never be able to figure this out across all situations. I agree with that, but I guess we all equally agree that the MySQL "optimisation" is a dangerous default (various Search users got burned, I regularly have to remind about that little note in the docs...) We could maybe stride on the safe side, and default to small, lazy loading, unless the user knows better and overrides the fetch-size explicitly on a query? Only for databases which have an "unsafe default" of course. Thanks, Sanne > > > On Mon, Nov 21, 2016 at 12:12 PM Sanne Grinovero > wrote: >> >> Hi Vlad, >> I'm not sure if we should set the fetch size automatically, especially >> not globally. Could we not use the API wisely to encourage people to >> provide an estimate of a reasonable size, which will be different on >> each query? >> >> I'm aware that MySQL requires this strange value to avoid pre-loading >> it all in memory; in fact for example in Hibernate Search the "mass >> index rebuild" has to scroll on the whole dataset, so the >> documentation recommends to set the fetch size.. >> >> However in some cases the optimisation might make sense; for example >> if the resultset is small, why would you use pagination when you can >> load it all in one single roundtrip? >> >> On the other hand, if you all think Hibernate should be able to figure >> this out automatically, then maybe I should also change Search to >> automatically set MIN_VALUE when running on MySQL, etc.. >> >> Thanks, >> Sanne >> >> >> >> >> On 19 November 2016 at 10:04, Vlad Mihalcea >> wrote: >> > Hi, >> > >> > I've noticed this new Jira ticket: >> > >> > https://hibernate.atlassian.net/browse/HHH-11260 >> > >> > and I think we should correlate the Session#stream and Session#scroll >> > with >> > database cursors. >> > >> > While Oracle uses a fetch size of 10, and SQL Server uses an adaptive >> > cursor, PostgreSQL and MySQL just fetch the whole result set into the >> > client. >> > >> > So, for MySQL we could do as suggested in the Jira ticket, by setting >> > the >> > fetch size to Integer.MIN_VALUE. >> > >> > My question is about PotgreSQL. Postgres requires setting the fetch size >> > to >> > some positive value in order to turn the current statement into a >> > database >> > cursor. >> > Now, should we set a default value for streaming (e.g. 10), which can be >> > controlled via a new config property: >> > >> > hibernate.jdbc.stream.fetch_size >> > >> > Let me know what you think. >> > >> > Vlad >> > _______________________________________________ >> > 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 From steve at hibernate.org Mon Nov 21 13:40:29 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 21 Nov 2016 18:40:29 +0000 Subject: [hibernate-dev] Correlating Java 1.8 Streams and ScrollableResults with database cursors In-Reply-To: References: Message-ID: As I understand it, the MySQL driver/db does not support a fetch size. It supports a binary choice between (1) pull all results into client memory or (2) stream and buffer, but without any control over the sizing of that buffering. If I am incorrect in that understanding then the rest here maybe does not follow. But if I am correct, then my concern has to do with the overhead of streaming and buffering over small amounts of data. Obviously there is a tipping point where one or the other approach makes sense. I think we just do not have the necessary visibility into where that tipping point is. And in my experience picking one or the other in such binary cases where we are just making a "shot in the dark" is usually not a good plan. Anyway, Vladimir was going to do some testing to see how relevant the concerns regarding overhead of stream/buffer is for smallish results. That too might mitigate some of my concern On Mon, Nov 21, 2016, 12:25 PM Sanne Grinovero wrote: > On 21 November 2016 at 18:17, Steve Ebersole wrote: > > I had a discussion about this with Vlad on the PR and privately on > HipChat. > > > > I personally am -1 on this as well. As you say Sanne the problem is "if > you > > all think Hibernate should be able to figure this out automatically"... > You > > would never be able to figure this out across all situations. > > I agree with that, but I guess we all equally agree that the MySQL > "optimisation" is a dangerous default (various Search users got > burned, I regularly have to remind about that little note in the > docs...) > > We could maybe stride on the safe side, and default to small, lazy > loading, unless the user knows better and overrides the fetch-size > explicitly on a query? > Only for databases which have an "unsafe default" of course. > > Thanks, > Sanne > > > > > > > On Mon, Nov 21, 2016 at 12:12 PM Sanne Grinovero > > wrote: > >> > >> Hi Vlad, > >> I'm not sure if we should set the fetch size automatically, especially > >> not globally. Could we not use the API wisely to encourage people to > >> provide an estimate of a reasonable size, which will be different on > >> each query? > >> > >> I'm aware that MySQL requires this strange value to avoid pre-loading > >> it all in memory; in fact for example in Hibernate Search the "mass > >> index rebuild" has to scroll on the whole dataset, so the > >> documentation recommends to set the fetch size.. > >> > >> However in some cases the optimisation might make sense; for example > >> if the resultset is small, why would you use pagination when you can > >> load it all in one single roundtrip? > >> > >> On the other hand, if you all think Hibernate should be able to figure > >> this out automatically, then maybe I should also change Search to > >> automatically set MIN_VALUE when running on MySQL, etc.. > >> > >> Thanks, > >> Sanne > >> > >> > >> > >> > >> On 19 November 2016 at 10:04, Vlad Mihalcea > >> wrote: > >> > Hi, > >> > > >> > I've noticed this new Jira ticket: > >> > > >> > https://hibernate.atlassian.net/browse/HHH-11260 > >> > > >> > and I think we should correlate the Session#stream and Session#scroll > >> > with > >> > database cursors. > >> > > >> > While Oracle uses a fetch size of 10, and SQL Server uses an adaptive > >> > cursor, PostgreSQL and MySQL just fetch the whole result set into the > >> > client. > >> > > >> > So, for MySQL we could do as suggested in the Jira ticket, by setting > >> > the > >> > fetch size to Integer.MIN_VALUE. > >> > > >> > My question is about PotgreSQL. Postgres requires setting the fetch > size > >> > to > >> > some positive value in order to turn the current statement into a > >> > database > >> > cursor. > >> > Now, should we set a default value for streaming (e.g. 10), which can > be > >> > controlled via a new config property: > >> > > >> > hibernate.jdbc.stream.fetch_size > >> > > >> > Let me know what you think. > >> > > >> > Vlad > >> > _______________________________________________ > >> > 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 > From steve at hibernate.org Mon Nov 21 13:54:01 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 21 Nov 2016 18:54:01 +0000 Subject: [hibernate-dev] Spring Cache integration Message-ID: Someone just opened a PR to add support for Spring Cache as a second-level cache provider[1]. They implemented this by adding a new Hibernate module `hibernate-spring-cache` that essentially wraps Spring Cache as a JCache (apparently Spring Cache does not implement the JCache contracts). Part of the hope with hibernate-jcache was to get out of the business of us maintaining these individual cache integrations. Anyone have strong opinions here? [1] https://github.com/hibernate/hibernate-orm/pull/1639 From sanne at hibernate.org Mon Nov 21 17:55:08 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 21 Nov 2016 22:55:08 +0000 Subject: [hibernate-dev] Spring Cache integration In-Reply-To: References: Message-ID: My initial reaction to this was of highly skeptical, as I don't see how adding layers and layers of adapters helps performance, which is crucial to the very purpose of Caching being effective. But the PR mentions interesting things; if indeed people want to use cloud service abstractions for "general purpose" caching within their application, and use the same for Hibernate than it makes sense of course to reuse the initialized components. But I've never heard of this "Spring Cloud AWS's Elasticache" .. is that really a popular solution? And is it sensible to use in this case? From its docs it seems to support only memcached and Redis. Caching on a remote shared service will never be as effective as having a local cache, so I'd suspect the memcached solution would not be very useful; this leaves Redis which might be interesting but has poor support for clustering (multi-node, aka scalable deployments). In several ways, I wonder if Infinispan itself wouldn't be a better abstraction to such alternative caching solutions: it can be configured to use an hybrid of local caching, distributed invalidation, and offload to an alternative shared storage engine (a "CacheStore"); such an "hybrid" solution would be a better choice, as then people can tune local/remote tradeoffs. Infinispan has a wide collection of such CacheStore implementations; not least it *did* have support for JClouds storage: it was implemented, however that component hasn't been updated for a while. It could be revived if there's such interest. I totally agree with the spirit of the PR though: if a system is configuring caching systems, it should be easy (and more efficient) to reuse the same configurations and the same "connections" whatever these are in a specific caching technology, rather than having Hibernate to start a new instance of these services. On an entirely different aspect, I wonder if it's really possible to have a system built on Redis / memcached to provide the consistency requirements we typically expect; both Ehcache and Infinispan had to solve massive challenges to become the fairly good solutions they are today. My fear is that even just to document eventual limitations, we'd need to study them quite a bit, probably challenge them empirically, which would require adding many more tests. Thanks, Sanne On 21 November 2016 at 18:54, Steve Ebersole wrote: > Someone just opened a PR to add support for Spring Cache as a second-level > cache provider[1]. They implemented this by adding a new Hibernate module > `hibernate-spring-cache` that essentially wraps Spring Cache as a JCache > (apparently Spring Cache does not implement the JCache contracts). > > Part of the hope with hibernate-jcache was to get out of the business of us > maintaining these individual cache integrations. > > Anyone have strong opinions here? > > [1] https://github.com/hibernate/hibernate-orm/pull/1639 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Tue Nov 22 10:44:11 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 22 Nov 2016 16:44:11 +0100 Subject: [hibernate-dev] Hibernate NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of this week's NoORM meeting: 16:28 < jbott> Meeting ended Tue Nov 22 15:27:44 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:28 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-22-14.00.html 16:28 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-22-14.00.txt 16:28 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-22-14.00.log.html Cheers, -- Guillaume From steve at hibernate.org Tue Nov 22 11:40:17 2016 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 22 Nov 2016 16:40:17 +0000 Subject: [hibernate-dev] Spring Cache integration In-Reply-To: References: Message-ID: I think this gets back to the idea we discussed when first integrating the JCache solution.. namely the idea of provisioning for these regions. At the time we concluded that it would be better to simply have the JCache integration not deal with the configuration/building of a javax.cache.CacheManager. Instead it was decided to simply let it consume a javax.cache.CacheManager it acquires from other means. I personally don't see how this "Spring Cache" integration could not simply fit into that paradigm. I personally want to avoid supporting any more specific caching backends, especially when it fits into this hibernate-jcache paradigm. That was the point of supporting JCache. What I do not get here is why Spring's `org.springframework.cache.CacheManager` does not simply implement `javax.cache.CacheManager`. That is by far the easiest solution. On Mon, Nov 21, 2016 at 4:55 PM Sanne Grinovero wrote: > My initial reaction to this was of highly skeptical, as I don't see > how adding layers and layers of adapters helps performance, which is > crucial to the very purpose of Caching being effective. > > But the PR mentions interesting things; if indeed people want to use > cloud service abstractions for "general purpose" caching within their > application, and use the same for Hibernate than it makes sense of > course to reuse the initialized components. > > But I've never heard of this "Spring Cloud AWS's Elasticache" .. is > that really a popular solution? And is it sensible to use in this > case? From its docs it seems to support only memcached and Redis. > Caching on a remote shared service will never be as effective as > having a local cache, so I'd suspect the memcached solution would not > be very useful; this leaves Redis which might be interesting but has > poor support for clustering (multi-node, aka scalable deployments). > > In several ways, I wonder if Infinispan itself wouldn't be a better > abstraction to such alternative caching solutions: it can be > configured to use an hybrid of local caching, distributed > invalidation, and offload to an alternative shared storage engine (a > "CacheStore"); such an "hybrid" solution would be a better choice, as > then people can tune local/remote tradeoffs. > Infinispan has a wide collection of such CacheStore implementations; > not least it *did* have support for JClouds storage: it was > implemented, however that component hasn't been updated for a while. > It could be revived if there's such interest. > > I totally agree with the spirit of the PR though: if a system is > configuring caching systems, it should be easy (and more efficient) to > reuse the same configurations and the same "connections" whatever > these are in a specific caching technology, rather than having > Hibernate to start a new instance of these services. > > On an entirely different aspect, I wonder if it's really possible to > have a system built on Redis / memcached to provide the consistency > requirements we typically expect; both Ehcache and Infinispan had to > solve massive challenges to become the fairly good solutions they are > today. My fear is that even just to document eventual limitations, > we'd need to study them quite a bit, probably challenge them > empirically, which would require adding many more tests. > > Thanks, > Sanne > > > > On 21 November 2016 at 18:54, Steve Ebersole wrote: > > Someone just opened a PR to add support for Spring Cache as a > second-level > > cache provider[1]. They implemented this by adding a new Hibernate > module > > `hibernate-spring-cache` that essentially wraps Spring Cache as a JCache > > (apparently Spring Cache does not implement the JCache contracts). > > > > Part of the hope with hibernate-jcache was to get out of the business of > us > > maintaining these individual cache integrations. > > > > Anyone have strong opinions here? > > > > [1] https://github.com/hibernate/hibernate-orm/pull/1639 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From ljacomet at gmail.com Tue Nov 22 11:50:58 2016 From: ljacomet at gmail.com (Louis Jacomet) Date: Tue, 22 Nov 2016 16:50:58 +0000 Subject: [hibernate-dev] Spring Cache integration In-Reply-To: References: Message-ID: Hi all, Can't really say anything about the Hibernate integration, but the reason Spring caching does not implement JCache is because the abstraction is tailored at Spring integration and allows to wrap JCache into Spring Cache, because the later existed before the former. SO it would be weird to now have a way to get Spring Cache act as a JCache provider. Also there is a spec vs. framework abstraction thing at play here. Supporting Spring Cache is a much looser contract than supporting JCache for any cache implementor. I guess in an ideal world (or a new framework) you would no longer create a cache abstraction instead relying on JCache. Regards, Louis On Tue, Nov 22, 2016 at 5:41 PM Steve Ebersole wrote: > I think this gets back to the idea we discussed when first integrating the > JCache solution.. namely the idea of provisioning for these regions. At > the time we concluded that it would be better to simply have the JCache > integration not deal with the configuration/building of > a javax.cache.CacheManager. Instead it was decided to simply let it > consume a javax.cache.CacheManager it acquires from other means. > > I personally don't see how this "Spring Cache" integration could not simply > fit into that paradigm. > > I personally want to avoid supporting any more specific caching backends, > especially when it fits into this hibernate-jcache paradigm. That was the > point of supporting JCache. > > What I do not get here is why Spring's > `org.springframework.cache.CacheManager` does not simply implement > `javax.cache.CacheManager`. That is by far the easiest solution. > > > > On Mon, Nov 21, 2016 at 4:55 PM Sanne Grinovero > wrote: > > > My initial reaction to this was of highly skeptical, as I don't see > > how adding layers and layers of adapters helps performance, which is > > crucial to the very purpose of Caching being effective. > > > > But the PR mentions interesting things; if indeed people want to use > > cloud service abstractions for "general purpose" caching within their > > application, and use the same for Hibernate than it makes sense of > > course to reuse the initialized components. > > > > But I've never heard of this "Spring Cloud AWS's Elasticache" .. is > > that really a popular solution? And is it sensible to use in this > > case? From its docs it seems to support only memcached and Redis. > > Caching on a remote shared service will never be as effective as > > having a local cache, so I'd suspect the memcached solution would not > > be very useful; this leaves Redis which might be interesting but has > > poor support for clustering (multi-node, aka scalable deployments). > > > > In several ways, I wonder if Infinispan itself wouldn't be a better > > abstraction to such alternative caching solutions: it can be > > configured to use an hybrid of local caching, distributed > > invalidation, and offload to an alternative shared storage engine (a > > "CacheStore"); such an "hybrid" solution would be a better choice, as > > then people can tune local/remote tradeoffs. > > Infinispan has a wide collection of such CacheStore implementations; > > not least it *did* have support for JClouds storage: it was > > implemented, however that component hasn't been updated for a while. > > It could be revived if there's such interest. > > > > I totally agree with the spirit of the PR though: if a system is > > configuring caching systems, it should be easy (and more efficient) to > > reuse the same configurations and the same "connections" whatever > > these are in a specific caching technology, rather than having > > Hibernate to start a new instance of these services. > > > > On an entirely different aspect, I wonder if it's really possible to > > have a system built on Redis / memcached to provide the consistency > > requirements we typically expect; both Ehcache and Infinispan had to > > solve massive challenges to become the fairly good solutions they are > > today. My fear is that even just to document eventual limitations, > > we'd need to study them quite a bit, probably challenge them > > empirically, which would require adding many more tests. > > > > Thanks, > > Sanne > > > > > > > > On 21 November 2016 at 18:54, Steve Ebersole > wrote: > > > Someone just opened a PR to add support for Spring Cache as a > > second-level > > > cache provider[1]. They implemented this by adding a new Hibernate > > module > > > `hibernate-spring-cache` that essentially wraps Spring Cache as a > JCache > > > (apparently Spring Cache does not implement the JCache contracts). > > > > > > Part of the hope with hibernate-jcache was to get out of the business > of > > us > > > maintaining these individual cache integrations. > > > > > > Anyone have strong opinions here? > > > > > > [1] https://github.com/hibernate/hibernate-orm/pull/1639 > > > _______________________________________________ > > > 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 > From guillaume.smet at hibernate.org Tue Nov 22 13:09:23 2016 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Tue, 22 Nov 2016 19:09:23 +0100 Subject: [hibernate-dev] Hibernate Validator 5.3.3.Final is out Message-ID: Hi, I'm pleased to announce the third maintenance release of Hibernate Validator 5.3. For more information, please see the full announcement here: http://in.relation.to/2016/11/22/hibernate-validator-533-final-out/ . Have a nice day! -- Guillaume From gunnar at hibernate.org Wed Nov 23 02:39:11 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 23 Nov 2016 08:39:11 +0100 Subject: [hibernate-dev] Spring Cache integration In-Reply-To: References: Message-ID: This is a very interesting contribution, only I am wondering why it should be located within the Hibernate ORM project. It seems interesting to Spring users only, so wouldn't it be better located under the Spring umbrella? --Gunnar 2016-11-22 17:50 GMT+01:00 Louis Jacomet : > Hi all, > > Can't really say anything about the Hibernate integration, but the reason > Spring caching does not implement JCache is because the abstraction is > tailored at Spring integration and allows to wrap JCache into Spring Cache, > because the later existed before the former. SO it would be weird to now > have a way to get Spring Cache act as a JCache provider. > Also there is a spec vs. framework abstraction thing at play here. > Supporting Spring Cache is a much looser contract than supporting JCache > for any cache implementor. > > I guess in an ideal world (or a new framework) you would no longer create a > cache abstraction instead relying on JCache. > > Regards, > Louis > > On Tue, Nov 22, 2016 at 5:41 PM Steve Ebersole > wrote: > > > I think this gets back to the idea we discussed when first integrating > the > > JCache solution.. namely the idea of provisioning for these regions. At > > the time we concluded that it would be better to simply have the JCache > > integration not deal with the configuration/building of > > a javax.cache.CacheManager. Instead it was decided to simply let it > > consume a javax.cache.CacheManager it acquires from other means. > > > > I personally don't see how this "Spring Cache" integration could not > simply > > fit into that paradigm. > > > > I personally want to avoid supporting any more specific caching backends, > > especially when it fits into this hibernate-jcache paradigm. That was > the > > point of supporting JCache. > > > > What I do not get here is why Spring's > > `org.springframework.cache.CacheManager` does not simply implement > > `javax.cache.CacheManager`. That is by far the easiest solution. > > > > > > > > On Mon, Nov 21, 2016 at 4:55 PM Sanne Grinovero > > wrote: > > > > > My initial reaction to this was of highly skeptical, as I don't see > > > how adding layers and layers of adapters helps performance, which is > > > crucial to the very purpose of Caching being effective. > > > > > > But the PR mentions interesting things; if indeed people want to use > > > cloud service abstractions for "general purpose" caching within their > > > application, and use the same for Hibernate than it makes sense of > > > course to reuse the initialized components. > > > > > > But I've never heard of this "Spring Cloud AWS's Elasticache" .. is > > > that really a popular solution? And is it sensible to use in this > > > case? From its docs it seems to support only memcached and Redis. > > > Caching on a remote shared service will never be as effective as > > > having a local cache, so I'd suspect the memcached solution would not > > > be very useful; this leaves Redis which might be interesting but has > > > poor support for clustering (multi-node, aka scalable deployments). > > > > > > In several ways, I wonder if Infinispan itself wouldn't be a better > > > abstraction to such alternative caching solutions: it can be > > > configured to use an hybrid of local caching, distributed > > > invalidation, and offload to an alternative shared storage engine (a > > > "CacheStore"); such an "hybrid" solution would be a better choice, as > > > then people can tune local/remote tradeoffs. > > > Infinispan has a wide collection of such CacheStore implementations; > > > not least it *did* have support for JClouds storage: it was > > > implemented, however that component hasn't been updated for a while. > > > It could be revived if there's such interest. > > > > > > I totally agree with the spirit of the PR though: if a system is > > > configuring caching systems, it should be easy (and more efficient) to > > > reuse the same configurations and the same "connections" whatever > > > these are in a specific caching technology, rather than having > > > Hibernate to start a new instance of these services. > > > > > > On an entirely different aspect, I wonder if it's really possible to > > > have a system built on Redis / memcached to provide the consistency > > > requirements we typically expect; both Ehcache and Infinispan had to > > > solve massive challenges to become the fairly good solutions they are > > > today. My fear is that even just to document eventual limitations, > > > we'd need to study them quite a bit, probably challenge them > > > empirically, which would require adding many more tests. > > > > > > Thanks, > > > Sanne > > > > > > > > > > > > On 21 November 2016 at 18:54, Steve Ebersole > > wrote: > > > > Someone just opened a PR to add support for Spring Cache as a > > > second-level > > > > cache provider[1]. They implemented this by adding a new Hibernate > > > module > > > > `hibernate-spring-cache` that essentially wraps Spring Cache as a > > JCache > > > > (apparently Spring Cache does not implement the JCache contracts). > > > > > > > > Part of the hope with hibernate-jcache was to get out of the business > > of > > > us > > > > maintaining these individual cache integrations. > > > > > > > > Anyone have strong opinions here? > > > > > > > > [1] https://github.com/hibernate/hibernate-orm/pull/1639 > > > > _______________________________________________ > > > > 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 > From rvansa at redhat.com Wed Nov 23 05:08:27 2016 From: rvansa at redhat.com (Radim Vansa) Date: Wed, 23 Nov 2016 11:08:27 +0100 Subject: [hibernate-dev] Broken nightly builds Message-ID: <3d504f1a-31c4-541b-bff3-5471d9e9264b@redhat.com> Hi, seems something went wrong with HHH-11083 integration and I've broken the nightly builds. Fix is in [1], please integrate asap. Radim [1] https://github.com/hibernate/hibernate-orm/pull/1647 -- Radim Vansa JBoss Performance Team From steve at hibernate.org Wed Nov 23 07:39:29 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 23 Nov 2016 12:39:29 +0000 Subject: [hibernate-dev] Spring Cache integration In-Reply-To: References: Message-ID: I think they believe the reverse. Personally I am leery of accepting this because ultimately it is yet another piece of code we are not the experts on but will be responsible for maintaining. On Wed, Nov 23, 2016 at 1:39 AM Gunnar Morling wrote: > This is a very interesting contribution, only I am wondering why it should > be located within the Hibernate ORM project. > > It seems interesting to Spring users only, so wouldn't it be better > located under the Spring umbrella? > > --Gunnar > > > 2016-11-22 17:50 GMT+01:00 Louis Jacomet : > > Hi all, > > Can't really say anything about the Hibernate integration, but the reason > Spring caching does not implement JCache is because the abstraction is > tailored at Spring integration and allows to wrap JCache into Spring Cache, > because the later existed before the former. SO it would be weird to now > have a way to get Spring Cache act as a JCache provider. > Also there is a spec vs. framework abstraction thing at play here. > Supporting Spring Cache is a much looser contract than supporting JCache > for any cache implementor. > > I guess in an ideal world (or a new framework) you would no longer create a > cache abstraction instead relying on JCache. > > Regards, > Louis > > On Tue, Nov 22, 2016 at 5:41 PM Steve Ebersole > wrote: > > > I think this gets back to the idea we discussed when first integrating > the > > JCache solution.. namely the idea of provisioning for these regions. At > > the time we concluded that it would be better to simply have the JCache > > integration not deal with the configuration/building of > > a javax.cache.CacheManager. Instead it was decided to simply let it > > consume a javax.cache.CacheManager it acquires from other means. > > > > I personally don't see how this "Spring Cache" integration could not > simply > > fit into that paradigm. > > > > I personally want to avoid supporting any more specific caching backends, > > especially when it fits into this hibernate-jcache paradigm. That was > the > > point of supporting JCache. > > > > What I do not get here is why Spring's > > `org.springframework.cache.CacheManager` does not simply implement > > `javax.cache.CacheManager`. That is by far the easiest solution. > > > > > > > > On Mon, Nov 21, 2016 at 4:55 PM Sanne Grinovero > > wrote: > > > > > My initial reaction to this was of highly skeptical, as I don't see > > > how adding layers and layers of adapters helps performance, which is > > > crucial to the very purpose of Caching being effective. > > > > > > But the PR mentions interesting things; if indeed people want to use > > > cloud service abstractions for "general purpose" caching within their > > > application, and use the same for Hibernate than it makes sense of > > > course to reuse the initialized components. > > > > > > But I've never heard of this "Spring Cloud AWS's Elasticache" .. is > > > that really a popular solution? And is it sensible to use in this > > > case? From its docs it seems to support only memcached and Redis. > > > Caching on a remote shared service will never be as effective as > > > having a local cache, so I'd suspect the memcached solution would not > > > be very useful; this leaves Redis which might be interesting but has > > > poor support for clustering (multi-node, aka scalable deployments). > > > > > > In several ways, I wonder if Infinispan itself wouldn't be a better > > > abstraction to such alternative caching solutions: it can be > > > configured to use an hybrid of local caching, distributed > > > invalidation, and offload to an alternative shared storage engine (a > > > "CacheStore"); such an "hybrid" solution would be a better choice, as > > > then people can tune local/remote tradeoffs. > > > Infinispan has a wide collection of such CacheStore implementations; > > > not least it *did* have support for JClouds storage: it was > > > implemented, however that component hasn't been updated for a while. > > > It could be revived if there's such interest. > > > > > > I totally agree with the spirit of the PR though: if a system is > > > configuring caching systems, it should be easy (and more efficient) to > > > reuse the same configurations and the same "connections" whatever > > > these are in a specific caching technology, rather than having > > > Hibernate to start a new instance of these services. > > > > > > On an entirely different aspect, I wonder if it's really possible to > > > have a system built on Redis / memcached to provide the consistency > > > requirements we typically expect; both Ehcache and Infinispan had to > > > solve massive challenges to become the fairly good solutions they are > > > today. My fear is that even just to document eventual limitations, > > > we'd need to study them quite a bit, probably challenge them > > > empirically, which would require adding many more tests. > > > > > > Thanks, > > > Sanne > > > > > > > > > > > > On 21 November 2016 at 18:54, Steve Ebersole > > wrote: > > > > Someone just opened a PR to add support for Spring Cache as a > > > second-level > > > > cache provider[1]. They implemented this by adding a new Hibernate > > > module > > > > `hibernate-spring-cache` that essentially wraps Spring Cache as a > > JCache > > > > (apparently Spring Cache does not implement the JCache contracts). > > > > > > > > Part of the hope with hibernate-jcache was to get out of the business > > of > > > us > > > > maintaining these individual cache integrations. > > > > > > > > Anyone have strong opinions here? > > > > > > > > [1] https://github.com/hibernate/hibernate-orm/pull/1639 > > > > _______________________________________________ > > > > 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 > > > From florian.lacreuse at smile.fr Wed Nov 23 09:10:53 2016 From: florian.lacreuse at smile.fr (Florian Lacreuse) Date: Wed, 23 Nov 2016 15:10:53 +0100 Subject: [hibernate-dev] Use @AssociationOverride with @MapKeyJoinColumn Message-ID: <69d2f63c-d6a4-cc2e-bbd9-d15edcfa1497@smile.fr> Hi, We have a problem using @AssociationOverride and @MapKeyJoinColumn and we would like to have your opinion about this to know if this is an issue. Here is the test case : https://github.com/florianlacreuse/hibernate-test-case Short explanation about the model : an entity with an embeddable field wrapping a map with an entity as key and a basic type as value. We use @AssociationOverride to rename the join table (annotation on embeddable field) and @MapKeyJoinColumn to rename the column related to the key map (annotation on map field). Unfortunately, it would seem that the @MapKeyJoinColumn annotation is ignored. @AssociationOverride may override any other annotations on the map field ? In this case how to rename the column related to the key map with the @AssociationOverride ? Is this an issue or is there any trick we don't know about? Thanks for your help. Kind regards, Logo 151 boulevard Stalingrad 69100 Villeurbanne www.smile.fr *Florian LACREUSE* Ing?nieur d'?tudes et d?veloppement P?le D?veloppement Sp?cifique Java Open Wide - Syst?mes d'Information Email : florian.lacreuse at smile.fr From mihalcea.vlad at gmail.com Wed Nov 23 10:08:10 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 23 Nov 2016 17:08:10 +0200 Subject: [hibernate-dev] Use @AssociationOverride with @MapKeyJoinColumn In-Reply-To: <69d2f63c-d6a4-cc2e-bbd9-d15edcfa1497@smile.fr> References: <69d2f63c-d6a4-cc2e-bbd9-d15edcfa1497@smile.fr> Message-ID: The JPA spec does not specify a way to override the MapKeyJoinColumn. You can override the association, like the JoinColumn for a ManyToOne or a JoinTable for OneToMany. In your case, maybe it's better to move that association out of the embeddable. It's always a good idea to keep the model as simple as possible. Vlad On Wed, Nov 23, 2016 at 4:10 PM, Florian Lacreuse wrote: > Hi, > > We have a problem using @AssociationOverride and @MapKeyJoinColumn and > we would like to have your opinion about this to know if this is an issue. > > Here is the test case : > https://github.com/florianlacreuse/hibernate-test-case > > Short explanation about the model : an entity with an embeddable field > wrapping a map with an entity as key and a basic type as value. > > We use @AssociationOverride to rename the join table (annotation on > embeddable field) and @MapKeyJoinColumn to rename the column related to > the key map (annotation on map field). > > Unfortunately, it would seem that the @MapKeyJoinColumn annotation is > ignored. @AssociationOverride may override any other annotations on the > map field ? In this case how to rename the column related to the key map > with the @AssociationOverride ? > > Is this an issue or is there any trick we don't know about? > > Thanks for your help. > > Kind regards, > > > Logo > > 151 boulevard Stalingrad > 69100 Villeurbanne > www.smile.fr > *Florian LACREUSE* > Ing?nieur d'?tudes et d?veloppement > P?le D?veloppement Sp?cifique Java > Open Wide - Syst?mes d'Information > Email : florian.lacreuse at smile.fr > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From florian.lacreuse at smile.fr Wed Nov 23 11:09:37 2016 From: florian.lacreuse at smile.fr (Florian Lacreuse) Date: Wed, 23 Nov 2016 17:09:37 +0100 Subject: [hibernate-dev] Use @AssociationOverride with @MapKeyJoinColumn In-Reply-To: References: <69d2f63c-d6a4-cc2e-bbd9-d15edcfa1497@smile.fr> Message-ID: <9656f2b2-22ff-9554-dd8e-3292a4ea6851@smile.fr> We didn't know about the JPA spec on this particular detail, thanks for the precision. Nonetheless, we don't want to override the @MapKeyJoinColumn, we just want the annotation to be taken into consideration while we use @AssociationOverride to override something else. We have updated the test case (https://github.com/florianlacreuse/hibernate-test-case ). In Employee entity we use the same embeddable twice, so we have to use @AssociationOverride to name the two join tables. In both tables, the column related to the key has the default name ("experiences_KEY") instead of the one provided by the @MapKeyJoinColumn ("jobtitle_id"). To resume, we understrand that it's not possible to override @MapKeyJoinColumn but @MapKeyJoinColumn should not be ignored. In Employee entity you can also find a third attribute with the same embeddable but without any @AssociationOverride. In this case, @MapKeyJoinColumn works as expected. Kind regards, Logo 151 boulevard Stalingrad 69100 Villeurbanne www.smile.fr *Florian LACREUSE* Ing?nieur d'?tudes et d?veloppement P?le D?veloppement Sp?cifique Java Open Wide - Syst?mes d'Information Email : florian.lacreuse at smile.fr Le 23/11/2016 ? 16:08, Vlad Mihalcea a ?crit : > The JPA spec does not specify a way to override the MapKeyJoinColumn. > You can override the association, like the JoinColumn for a ManyToOne > or a JoinTable for OneToMany. > > In your case, maybe it's better to move that association out of the > embeddable. > It's always a good idea to keep the model as simple as possible. > > Vlad > > On Wed, Nov 23, 2016 at 4:10 PM, Florian Lacreuse > > wrote: > > Hi, > > We have a problem using @AssociationOverride and @MapKeyJoinColumn and > we would like to have your opinion about this to know if this is > an issue. > > Here is the test case : > https://github.com/florianlacreuse/hibernate-test-case > > > Short explanation about the model : an entity with an embeddable field > wrapping a map with an entity as key and a basic type as value. > > We use @AssociationOverride to rename the join table (annotation on > embeddable field) and @MapKeyJoinColumn to rename the column > related to > the key map (annotation on map field). > > Unfortunately, it would seem that the @MapKeyJoinColumn annotation is > ignored. @AssociationOverride may override any other annotations > on the > map field ? In this case how to rename the column related to the > key map > with the @AssociationOverride ? > > Is this an issue or is there any trick we don't know about? > > Thanks for your help. > > Kind regards, > > > Logo > > 151 boulevard Stalingrad > 69100 Villeurbanne > www.smile.fr > *Florian LACREUSE* > Ing?nieur d'?tudes et d?veloppement > P?le D?veloppement Sp?cifique Java > Open Wide - Syst?mes d'Information > Email : florian.lacreuse at smile.fr > > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From gbadner at redhat.com Wed Nov 23 19:10:01 2016 From: gbadner at redhat.com (Gail Badner) Date: Wed, 23 Nov 2016 16:10:01 -0800 Subject: [hibernate-dev] Preparing to release 5.1.3 Message-ID: Please do not push anything to 5.1 branch while I'm preparing the release. Thanks, Gail From gbadner at redhat.com Wed Nov 23 22:31:51 2016 From: gbadner at redhat.com (Gail Badner) Date: Wed, 23 Nov 2016 19:31:51 -0800 Subject: [hibernate-dev] Hibernate ORM 5.1.3.Final Released Message-ID: http://in.relation.to/2016/11/23/hibernate-orm-513-final-release/ From yoann at hibernate.org Thu Nov 24 04:17:34 2016 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 24 Nov 2016 10:17:34 +0100 Subject: [hibernate-dev] Use @AssociationOverride with @MapKeyJoinColumn In-Reply-To: <9656f2b2-22ff-9554-dd8e-3292a4ea6851@smile.fr> References: <69d2f63c-d6a4-cc2e-bbd9-d15edcfa1497@smile.fr> <9656f2b2-22ff-9554-dd8e-3292a4ea6851@smile.fr> Message-ID: Hi, I just ran the test case, and there's something odd indeed: as Florian said, @MapKeyJoinColumn in embeddables seem to be completely ignored when the (embedded) association is overridden using @AssociationOverride. When not using @AssociationOverride, everything works fine. Vlad, do you think this could be a bug? It seems odd, but maybe I'm missing something. I forked the test to make it run on an embedded H2 instance, which should be easier to run quickly: https://github.com/yrodiere/hibernate-test-case Yoann Rodi?re Hibernate NoORM Team On 23 November 2016 at 17:09, Florian Lacreuse wrote: > We didn't know about the JPA spec on this particular detail, thanks for > the precision. > > Nonetheless, we don't want to override the @MapKeyJoinColumn, we just > want the annotation to be taken into consideration while we use > @AssociationOverride to override something else. > > We have updated the test case > (https://github.com/florianlacreuse/hibernate-test-case > ). In Employee > entity we use the same embeddable twice, so we have to use > @AssociationOverride to name the two join tables. In both tables, the > column related to the key has the default name ("experiences_KEY") > instead of the one provided by the @MapKeyJoinColumn ("jobtitle_id"). > > To resume, we understrand that it's not possible to override > @MapKeyJoinColumn but @MapKeyJoinColumn should not be ignored. > > In Employee entity you can also find a third attribute with the same > embeddable but without any @AssociationOverride. In this case, > @MapKeyJoinColumn works as expected. > > Kind regards, > > Logo > > 151 boulevard Stalingrad > 69100 Villeurbanne > www.smile.fr > *Florian LACREUSE* > Ing?nieur d'?tudes et d?veloppement > P?le D?veloppement Sp?cifique Java > Open Wide - Syst?mes d'Information > Email : florian.lacreuse at smile.fr > > > Le 23/11/2016 ? 16:08, Vlad Mihalcea a ?crit : > > The JPA spec does not specify a way to override the MapKeyJoinColumn. > > You can override the association, like the JoinColumn for a ManyToOne > > or a JoinTable for OneToMany. > > > > In your case, maybe it's better to move that association out of the > > embeddable. > > It's always a good idea to keep the model as simple as possible. > > > > Vlad > > > > On Wed, Nov 23, 2016 at 4:10 PM, Florian Lacreuse > > > wrote: > > > > Hi, > > > > We have a problem using @AssociationOverride and @MapKeyJoinColumn > and > > we would like to have your opinion about this to know if this is > > an issue. > > > > Here is the test case : > > https://github.com/florianlacreuse/hibernate-test-case > > > > > > Short explanation about the model : an entity with an embeddable > field > > wrapping a map with an entity as key and a basic type as value. > > > > We use @AssociationOverride to rename the join table (annotation on > > embeddable field) and @MapKeyJoinColumn to rename the column > > related to > > the key map (annotation on map field). > > > > Unfortunately, it would seem that the @MapKeyJoinColumn annotation is > > ignored. @AssociationOverride may override any other annotations > > on the > > map field ? In this case how to rename the column related to the > > key map > > with the @AssociationOverride ? > > > > Is this an issue or is there any trick we don't know about? > > > > Thanks for your help. > > > > Kind regards, > > > > > > Logo > > > > 151 boulevard Stalingrad > > 69100 Villeurbanne > > www.smile.fr > > *Florian LACREUSE* > > Ing?nieur d'?tudes et d?veloppement > > P?le D?veloppement Sp?cifique Java > > Open Wide - Syst?mes d'Information > > Email : florian.lacreuse at smile.fr > > > > >> > > > > > > _______________________________________________ > > 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 > From mihalcea.vlad at gmail.com Thu Nov 24 04:48:35 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 24 Nov 2016 11:48:35 +0200 Subject: [hibernate-dev] Use @AssociationOverride with @MapKeyJoinColumn In-Reply-To: References: <69d2f63c-d6a4-cc2e-bbd9-d15edcfa1497@smile.fr> <9656f2b2-22ff-9554-dd8e-3292a4ea6851@smile.fr> Message-ID: Hi, I checked the JPA spec and there is no indication whether we should override the @MapKeyJoinColumn. Steve, what he thinks about this issue? Should we support @MapKeyJoinColumn with @AssociationOverride? Vlad On Thu, Nov 24, 2016 at 11:17 AM, Yoann Rodiere wrote: > Hi, > > I just ran the test case, and there's something odd indeed: as Florian > said, @MapKeyJoinColumn in embeddables seem to be completely ignored when > the (embedded) association is overridden using @AssociationOverride. When > not using @AssociationOverride, everything works fine. > > Vlad, do you think this could be a bug? It seems odd, but maybe I'm > missing something. > > I forked the test to make it run on an embedded H2 instance, which should > be easier to run quickly: https://github.com/yrodiere/hibernate-test-case > > Yoann Rodi?re > Hibernate NoORM Team > > On 23 November 2016 at 17:09, Florian Lacreuse > wrote: > >> We didn't know about the JPA spec on this particular detail, thanks for >> the precision. >> >> Nonetheless, we don't want to override the @MapKeyJoinColumn, we just >> want the annotation to be taken into consideration while we use >> @AssociationOverride to override something else. >> >> We have updated the test case >> (https://github.com/florianlacreuse/hibernate-test-case >> ). In Employee >> entity we use the same embeddable twice, so we have to use >> @AssociationOverride to name the two join tables. In both tables, the >> column related to the key has the default name ("experiences_KEY") >> instead of the one provided by the @MapKeyJoinColumn ("jobtitle_id"). >> >> To resume, we understrand that it's not possible to override >> @MapKeyJoinColumn but @MapKeyJoinColumn should not be ignored. >> >> In Employee entity you can also find a third attribute with the same >> embeddable but without any @AssociationOverride. In this case, >> @MapKeyJoinColumn works as expected. >> >> Kind regards, >> >> Logo >> >> 151 boulevard Stalingrad >> 69100 Villeurbanne >> www.smile.fr >> *Florian LACREUSE* >> Ing?nieur d'?tudes et d?veloppement >> P?le D?veloppement Sp?cifique Java >> Open Wide - Syst?mes d'Information >> Email : florian.lacreuse at smile.fr >> >> >> Le 23/11/2016 ? 16:08, Vlad Mihalcea a ?crit : >> > The JPA spec does not specify a way to override the MapKeyJoinColumn. >> > You can override the association, like the JoinColumn for a ManyToOne >> > or a JoinTable for OneToMany. >> > >> > In your case, maybe it's better to move that association out of the >> > embeddable. >> > It's always a good idea to keep the model as simple as possible. >> > >> > Vlad >> > >> > On Wed, Nov 23, 2016 at 4:10 PM, Florian Lacreuse >> > > wrote: >> > >> > Hi, >> > >> > We have a problem using @AssociationOverride and @MapKeyJoinColumn >> and >> > we would like to have your opinion about this to know if this is >> > an issue. >> > >> > Here is the test case : >> > https://github.com/florianlacreuse/hibernate-test-case >> > >> > >> > Short explanation about the model : an entity with an embeddable >> field >> > wrapping a map with an entity as key and a basic type as value. >> > >> > We use @AssociationOverride to rename the join table (annotation on >> > embeddable field) and @MapKeyJoinColumn to rename the column >> > related to >> > the key map (annotation on map field). >> > >> > Unfortunately, it would seem that the @MapKeyJoinColumn annotation >> is >> > ignored. @AssociationOverride may override any other annotations >> > on the >> > map field ? In this case how to rename the column related to the >> > key map >> > with the @AssociationOverride ? >> > >> > Is this an issue or is there any trick we don't know about? >> > >> > Thanks for your help. >> > >> > Kind regards, >> > >> > >> > Logo >> > >> > 151 boulevard Stalingrad >> > 69100 Villeurbanne >> > www.smile.fr >> > *Florian LACREUSE* >> > Ing?nieur d'?tudes et d?veloppement >> > P?le D?veloppement Sp?cifique Java >> > Open Wide - Syst?mes d'Information >> > Email : florian.lacreuse at smile.fr >> > >> > > >> >> > >> > >> > _______________________________________________ >> > 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 >> > > From andrea at hibernate.org Thu Nov 24 06:51:08 2016 From: andrea at hibernate.org (andrea boriero) Date: Thu, 24 Nov 2016 11:51:08 +0000 Subject: [hibernate-dev] Starting 5.2.5 release Message-ID: Please do not push anything to master branch. Thanks, Andrea From andrea at hibernate.org Thu Nov 24 10:45:51 2016 From: andrea at hibernate.org (andrea boriero) Date: Thu, 24 Nov 2016 15:45:51 +0000 Subject: [hibernate-dev] Hibernate ORM 5.2.5.Final has been released Message-ID: For details: http://in.relation.to/2016/11/24/hibernate-orm-525-final-release From chris at hibernate.org Mon Nov 28 09:40:17 2016 From: chris at hibernate.org (Chris Cranford) Date: Mon, 28 Nov 2016 09:40:17 -0500 Subject: [hibernate-dev] RH Summit 2017 CFP Message-ID: <43d9408d-fc47-2967-89e5-4692696bdbcf@hibernate.org> The Red Hat Summit 2017 CFP is closing on December 16th and I would recommend we try and submit our abstracts this week if we could. From the ORM side, is there any particular topics we'd care to present or anyone who would like to present? Chris From mihalcea.vlad at gmail.com Mon Nov 28 09:43:16 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 28 Nov 2016 16:43:16 +0200 Subject: [hibernate-dev] RH Summit 2017 CFP In-Reply-To: <43d9408d-fc47-2967-89e5-4692696bdbcf@hibernate.org> References: <43d9408d-fc47-2967-89e5-4692696bdbcf@hibernate.org> Message-ID: Hi, I've talked to Steve about this topic, and I remember that we concluded that we should send a presentation proposal on the following two topics: - What's new in Hibernate 6.0 - Hibernate Performance Tuning Tips Vlad On Mon, Nov 28, 2016 at 4:40 PM, Chris Cranford wrote: > The Red Hat Summit 2017 CFP is closing on December 16th and I would > recommend we try and submit our abstracts this week if we could. From > the ORM side, is there any particular topics we'd care to present or > anyone who would like to present? > > Chris > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Tue Nov 29 08:34:44 2016 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 29 Nov 2016 14:34:44 +0100 Subject: [hibernate-dev] Hibernate Search 5.6.0.Beta4 and 5.7.0.Beta1 released Message-ID: Hello everyone, We just released Hibernate Search 5.6.0.Beta4 and 5.7.0.Beta1, with the latest bugfixes and previously missing features for our experimental Elasticsearch integration. For more information, please see our blog: http://in.relation.to/2016/11/29/hibernate-search-5-6-0-Beta4-and-5-7-0-Beta1/ Have a nice day, Yoann Rodi?re Hibernate NoORM Team