From gunnar at hibernate.org Wed Feb 1 05:33:02 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 1 Feb 2017 11:33:02 +0100 Subject: [hibernate-dev] Behaviour of validation mode "auto" in case of error during validator factory bootstrap Message-ID: Hi, JPA defines for validation mode "auto" that bean validation must occur if a BV provider is present and that no validation shall occur otherwise. What should happen though if a BV provider such as HV is present but it fails to bootstrap? In case of HV this happens if no expression language implementation can be found. Currently, the user has a very hard time to find out about this, as this exception essentially is suppressed (for mode "callback" the exception is raised). Should we raise a specific exception in HV if it cannot be bootstrapped? In ORM, we could handle that one specifically and raise it also if for validation mode "auto" (would have to happen reflectively, though, as to avoid a hard dependency). I can do this change but first wanted to make sure that this is inline with what you all think should be done. Thanks, --Gunnar From sanne at hibernate.org Wed Feb 1 06:09:57 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 1 Feb 2017 11:09:57 +0000 Subject: [hibernate-dev] Behaviour of validation mode "auto" in case of error during validator factory bootstrap In-Reply-To: References: Message-ID: +1 for fail fast I think we generally aim for that as a good practice - when doable - and I suspect people expect it. On 1 February 2017 at 10:33, Gunnar Morling wrote: > Hi, > > JPA defines for validation mode "auto" that bean validation must occur > if a BV provider is present and that no validation shall occur > otherwise. > > What should happen though if a BV provider such as HV is present but > it fails to bootstrap? In case of HV this happens if no expression > language implementation can be found. > > Currently, the user has a very hard time to find out about this, as > this exception essentially is suppressed (for mode "callback" the > exception is raised). > > Should we raise a specific exception in HV if it cannot be > bootstrapped? In ORM, we could handle that one specifically and raise > it also if for validation mode "auto" (would have to happen > reflectively, though, as to avoid a hard dependency). > > I can do this change but first wanted to make sure that this is inline > with what you all think should be done. > > Thanks, > > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Wed Feb 1 10:38:10 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 1 Feb 2017 16:38:10 +0100 Subject: [hibernate-dev] Blog posts not featured on the hibernate.org website Message-ID: Hi, FYI, I just fixed the issue and the blogs posts are now featured on the website again. The good news: - we don't rely on an external service anymore - there is no cache so new blog posts are displayed on the website as soon as the blog post is published The in.relation.to blog now generates static jsonp feeds that are consumed by the website. For those interested: - https://github.com/hibernate/in.relation.to/commit/c50acd51dd84ef0dad1cd9798108f0ec85a525ab - https://github.com/hibernate/hibernate.org/commit/2a6b41e83c0308440837633d25b14a5ea87a289b -- Guillaume From gunnar at hibernate.org Wed Feb 1 10:42:21 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 1 Feb 2017 16:42:21 +0100 Subject: [hibernate-dev] Blog posts not featured on the hibernate.org website In-Reply-To: References: Message-ID: Great news! One minor nitpick: letters reaching out to the bottom of the line (e.g. "p", "y", "g") are cut off by one pixel or so. Can we increase the box, line height or whatever is needed for it? 2017-02-01 16:38 GMT+01:00 Guillaume Smet : > Hi, > > FYI, I just fixed the issue and the blogs posts are now featured on the > website again. > > The good news: > - we don't rely on an external service anymore > - there is no cache so new blog posts are displayed on the website as soon > as the blog post is published > > The in.relation.to blog now generates static jsonp feeds that are consumed > by the website. > > For those interested: > - > https://github.com/hibernate/in.relation.to/commit/c50acd51dd84ef0dad1cd9798108f0ec85a525ab > - > https://github.com/hibernate/hibernate.org/commit/2a6b41e83c0308440837633d25b14a5ea87a289b > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From davide at hibernate.org Wed Feb 1 10:42:12 2017 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 1 Feb 2017 15:42:12 +0000 Subject: [hibernate-dev] Blog posts not featured on the hibernate.org website In-Reply-To: References: Message-ID: Great, thanks On Wed, Feb 1, 2017 at 3:38 PM, Guillaume Smet wrote: > Hi, > > FYI, I just fixed the issue and the blogs posts are now featured on the > website again. > > The good news: > - we don't rely on an external service anymore > - there is no cache so new blog posts are displayed on the website as soon > as the blog post is published > > The in.relation.to blog now generates static jsonp feeds that are consumed > by the website. > > For those interested: > - > https://github.com/hibernate/in.relation.to/commit/c50acd51dd84ef0dad1cd9798108f0ec85a525ab > - > https://github.com/hibernate/hibernate.org/commit/2a6b41e83c0308440837633d25b14a5ea87a289b > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Wed Feb 1 10:47:55 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 1 Feb 2017 16:47:55 +0100 Subject: [hibernate-dev] Blog posts not featured on the hibernate.org website In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 4:42 PM, Gunnar Morling wrote: > Great news! > > One minor nitpick: letters reaching out to the bottom of the line > (e.g. "p", "y", "g") are cut off by one pixel or so. Can we increase > the box, line height or whatever is needed for it? > I think it's a preexisting issue as I didn't change that. Will fix. -- Guillaume From guillaume.smet at gmail.com Wed Feb 1 11:05:34 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 1 Feb 2017 17:05:34 +0100 Subject: [hibernate-dev] Blog posts not featured on the hibernate.org website In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 4:47 PM, Guillaume Smet wrote: > > On Wed, Feb 1, 2017 at 4:42 PM, Gunnar Morling > wrote: > >> Great news! >> >> One minor nitpick: letters reaching out to the bottom of the line >> (e.g. "p", "y", "g") are cut off by one pixel or so. Can we increase >> the box, line height or whatever is needed for it? >> > > I think it's a preexisting issue as I didn't change that. Will fix. > Fixed. You might have to insist a bit to get the new CSS. -- Guillaume From steve at hibernate.org Wed Feb 1 12:43:17 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 01 Feb 2017 17:43:17 +0000 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts) In-Reply-To: References: Message-ID: Most likely it is the cycle between hibernate-core and hibernate-orm-modules. Let me research a bit... On Tue, Jan 31, 2017 at 2:34 PM andrea boriero wrote: > rebased my old PR and it stops working, the "publishing is not yet able to > resolve a dependency on a project with multiple different publications" > exception is back :( > I'm investigating to understand what change reintroduced this issue. > > On 31 January 2017 at 09:57, andrea boriero wrote: > > after thinking a bit on +1 for Steve proposal > > On 31 January 2017 at 08:09, Gunnar Morling wrote: > > Agreed, it'd be the right time if we wanted to change this. > > I vote for 1 in case we do it. > > In ORM it's enough for many use cases to just add that core module, > hence I like the more concise "hibernate-orm" id (similar to > "hibernate-validator"). It's a bit different for OGM and HSEARCH where > one needs core and typically another module with the NoSQL/indexing > backend (hence I like "hibernate-ogm-core" there). > > > > 2017-01-30 17:31 GMT+01:00 Steve Ebersole : > > Relatedly, I have been thinking whether we want to rename the ORM > artifacts > > as well since this is the best time if we wanted to do that. > > > > So we know we will change the groupId to `org.hibernate.orm`. > > > > I was thinking we might want to also either: > > > > 1. rename `hibernate-core` as `hibernate-orm` > > 2. rename all the artifacts following the pattern > `hibernate-orm-${1}`, > > e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. > > > > > > On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole > wrote: > > > >> Well let's investigate what this consistency means across projects > first. > >> As Sanne mentions, if it makes it building ORM more difficult then I'd > be > >> -1 it too. But I promise to take a peek when I get back from PTO in a > few > >> days. Or maybe Andrea can in the next few days as he already has > worked on > >> the changes to release relocation artifacts for ORM; I just do not know > >> when he is coming back from PTO. Either way we will have looked at it > for > >> ORM by the end of week. > >> > >> On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet < > guillaume.smet at gmail.com> > >> wrote: > >> > >> On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero > >> wrote: > >> > >> > Different projects have different needs. Consistency is nice, and > >> > certainly makes it easier to find oneself comfortably "at home" when > >> > jumping from one project to another, but it also is inconvenient to do > >> > things "for consistency" when one has different requirements. > >> > > >> > >> I don't think we would have different requirements regarding the > relocation > >> artifacts. > >> > >> But if you see any issue with the approach we chose for HV, interesting > in > >> hearing them so that we can have the same approach for the different > NoORM > >> project. > >> > >> -- > >> Guillaume > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > From steve at hibernate.org Wed Feb 1 12:45:27 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 01 Feb 2017 17:45:27 +0000 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts) In-Reply-To: References: Message-ID: The underlying problem is still unfixed[1]. There is a work around we could try. [1] https://issues.gradle.org/browse/GRADLE-2966 -> https://github.com/gradle/gradle/issues/1061 On Wed, Feb 1, 2017 at 11:43 AM Steve Ebersole wrote: > Most likely it is the cycle between hibernate-core and > hibernate-orm-modules. Let me research a bit... > > > On Tue, Jan 31, 2017 at 2:34 PM andrea boriero > wrote: > > rebased my old PR and it stops working, the "publishing is not yet able to > resolve a dependency on a project with multiple different publications" > exception is back :( > I'm investigating to understand what change reintroduced this issue. > > On 31 January 2017 at 09:57, andrea boriero wrote: > > after thinking a bit on +1 for Steve proposal > > On 31 January 2017 at 08:09, Gunnar Morling wrote: > > Agreed, it'd be the right time if we wanted to change this. > > I vote for 1 in case we do it. > > In ORM it's enough for many use cases to just add that core module, > hence I like the more concise "hibernate-orm" id (similar to > "hibernate-validator"). It's a bit different for OGM and HSEARCH where > one needs core and typically another module with the NoSQL/indexing > backend (hence I like "hibernate-ogm-core" there). > > > > 2017-01-30 17:31 GMT+01:00 Steve Ebersole : > > Relatedly, I have been thinking whether we want to rename the ORM > artifacts > > as well since this is the best time if we wanted to do that. > > > > So we know we will change the groupId to `org.hibernate.orm`. > > > > I was thinking we might want to also either: > > > > 1. rename `hibernate-core` as `hibernate-orm` > > 2. rename all the artifacts following the pattern > `hibernate-orm-${1}`, > > e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. > > > > > > On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole > wrote: > > > >> Well let's investigate what this consistency means across projects > first. > >> As Sanne mentions, if it makes it building ORM more difficult then I'd > be > >> -1 it too. But I promise to take a peek when I get back from PTO in a > few > >> days. Or maybe Andrea can in the next few days as he already has > worked on > >> the changes to release relocation artifacts for ORM; I just do not know > >> when he is coming back from PTO. Either way we will have looked at it > for > >> ORM by the end of week. > >> > >> On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet < > guillaume.smet at gmail.com> > >> wrote: > >> > >> On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero > >> wrote: > >> > >> > Different projects have different needs. Consistency is nice, and > >> > certainly makes it easier to find oneself comfortably "at home" when > >> > jumping from one project to another, but it also is inconvenient to do > >> > things "for consistency" when one has different requirements. > >> > > >> > >> I don't think we would have different requirements regarding the > relocation > >> artifacts. > >> > >> But if you see any issue with the approach we chose for HV, interesting > in > >> hearing them so that we can have the same approach for the different > NoORM > >> project. > >> > >> -- > >> Guillaume > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > From sanne at hibernate.org Wed Feb 1 12:46:49 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 1 Feb 2017 17:46:49 +0000 Subject: [hibernate-dev] Blog posts not featured on the hibernate.org website In-Reply-To: References: Message-ID: Great, thanks for that! One minor issue: currently the homepage mentions literally "Bulk-id strategies when you can’t use temporary tables" Looks like something wrong with escaping? On 1 February 2017 at 16:05, Guillaume Smet wrote: > On Wed, Feb 1, 2017 at 4:47 PM, Guillaume Smet > wrote: > >> >> On Wed, Feb 1, 2017 at 4:42 PM, Gunnar Morling >> wrote: >> >>> Great news! >>> >>> One minor nitpick: letters reaching out to the bottom of the line >>> (e.g. "p", "y", "g") are cut off by one pixel or so. Can we increase >>> the box, line height or whatever is needed for it? >>> >> >> I think it's a preexisting issue as I didn't change that. Will fix. >> > > Fixed. You might have to insist a bit to get the new CSS. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Feb 1 13:40:31 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 01 Feb 2017 18:40:31 +0000 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts) In-Reply-To: References: Message-ID: Good points Gunnar. So then we'll plan to rename hibernate-core to hibernate-orm and the others from hibernate-{module} to hibernate-orm-{module}. On Tue, Jan 31, 2017 at 2:09 AM Gunnar Morling wrote: > Agreed, it'd be the right time if we wanted to change this. > > I vote for 1 in case we do it. > > In ORM it's enough for many use cases to just add that core module, > hence I like the more concise "hibernate-orm" id (similar to > "hibernate-validator"). It's a bit different for OGM and HSEARCH where > one needs core and typically another module with the NoSQL/indexing > backend (hence I like "hibernate-ogm-core" there). > > > > 2017-01-30 17:31 GMT+01:00 Steve Ebersole : > > Relatedly, I have been thinking whether we want to rename the ORM > artifacts > > as well since this is the best time if we wanted to do that. > > > > So we know we will change the groupId to `org.hibernate.orm`. > > > > I was thinking we might want to also either: > > > > 1. rename `hibernate-core` as `hibernate-orm` > > 2. rename all the artifacts following the pattern > `hibernate-orm-${1}`, > > e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. > > > > > > On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole > wrote: > > > >> Well let's investigate what this consistency means across projects > first. > >> As Sanne mentions, if it makes it building ORM more difficult then I'd > be > >> -1 it too. But I promise to take a peek when I get back from PTO in a > few > >> days. Or maybe Andrea can in the next few days as he already has > worked on > >> the changes to release relocation artifacts for ORM; I just do not know > >> when he is coming back from PTO. Either way we will have looked at it > for > >> ORM by the end of week. > >> > >> On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet < > guillaume.smet at gmail.com> > >> wrote: > >> > >> On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero > >> wrote: > >> > >> > Different projects have different needs. Consistency is nice, and > >> > certainly makes it easier to find oneself comfortably "at home" when > >> > jumping from one project to another, but it also is inconvenient to do > >> > things "for consistency" when one has different requirements. > >> > > >> > >> I don't think we would have different requirements regarding the > relocation > >> artifacts. > >> > >> But if you see any issue with the approach we chose for HV, interesting > in > >> hearing them so that we can have the same approach for the different > NoORM > >> project. > >> > >> -- > >> Guillaume > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Wed Feb 1 17:23:46 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 1 Feb 2017 23:23:46 +0100 Subject: [hibernate-dev] Blog posts not featured on the hibernate.org website In-Reply-To: References: Message-ID: Yeah I saw that this evening when the new post of Vlad arrived. There shouldn't be any escaping but apparently at some point, entities are escaped. There is an :html_entities = false option used by the atomizer plugin that I also used but apparently it's not used at all in the awestruct code base. I'll take a look tomorrow morning. From guillaume.smet at gmail.com Wed Feb 1 18:25:39 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 2 Feb 2017 00:25:39 +0100 Subject: [hibernate-dev] Blog posts not featured on the hibernate.org website In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 6:46 PM, Sanne Grinovero wrote: > Great, thanks for that! > > One minor issue: > currently the homepage mentions literally "Bulk-id strategies when you > can’t use temporary tables" > Looks like something wrong with escaping > Fixed. -- Guillaume From guillaume.smet at hibernate.org Thu Feb 2 04:07:09 2017 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Thu, 2 Feb 2017 10:07:09 +0100 Subject: [hibernate-dev] Hibernate Validator 5.4.0.Final is out Message-ID: Hi! It's with great pleasure that I announce the release of Hibernate Validator 5.4.0.Final. This final version brings a few improvements and bugfixes on top of our CR1 as well as a new reference documentation layout. For more information, see the announcement post here: http://in.relation.to/2017/02/02/hibernate-validator-540-final-out/ Have a nice day! -- Guillaume From sanne at hibernate.org Thu Feb 2 07:03:50 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 2 Feb 2017 12:03:50 +0000 Subject: [hibernate-dev] Blog posts not featured on the hibernate.org website In-Reply-To: References: Message-ID: On 1 February 2017 at 23:25, Guillaume Smet wrote: > On Wed, Feb 1, 2017 at 6:46 PM, Sanne Grinovero wrote: >> >> Great, thanks for that! >> >> One minor issue: >> currently the homepage mentions literally "Bulk-id strategies when you >> can’t use temporary tables" >> Looks like something wrong with escaping > > > Fixed. By publishing the Validator release blog? :D Thanks! > > -- > Guillaume From steve at hibernate.org Thu Feb 2 07:24:03 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 02 Feb 2017 12:24:03 +0000 Subject: [hibernate-dev] Behaviour of validation mode "auto" in case of error during validator factory bootstrap In-Reply-To: References: Message-ID: +1 fof fail-fast in regards to bootstrap problems whenever possible On Wed, Feb 1, 2017 at 5:12 AM Sanne Grinovero wrote: > +1 for fail fast > > I think we generally aim for that as a good practice - when doable - > and I suspect people expect it. > > On 1 February 2017 at 10:33, Gunnar Morling wrote: > > Hi, > > > > JPA defines for validation mode "auto" that bean validation must occur > > if a BV provider is present and that no validation shall occur > > otherwise. > > > > What should happen though if a BV provider such as HV is present but > > it fails to bootstrap? In case of HV this happens if no expression > > language implementation can be found. > > > > Currently, the user has a very hard time to find out about this, as > > this exception essentially is suppressed (for mode "callback" the > > exception is raised). > > > > Should we raise a specific exception in HV if it cannot be > > bootstrapped? In ORM, we could handle that one specifically and raise > > it also if for validation mode "auto" (would have to happen > > reflectively, though, as to avoid a hard dependency). > > > > I can do this change but first wanted to make sure that this is inline > > with what you all think should be done. > > > > Thanks, > > > > --Gunnar > > _______________________________________________ > > 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 Thu Feb 2 07:24:43 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 02 Feb 2017 12:24:43 +0000 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId In-Reply-To: <8ac62a27-3990-198a-241a-e5404ad3e853@gmail.com> References: <8ac62a27-3990-198a-241a-e5404ad3e853@gmail.com> Message-ID: https://hibernate.atlassian.net/browse/HHH-11444 On Tue, Jan 31, 2017 at 12:52 AM Christian Beikov < christian.beikov at gmail.com> wrote: > Sounds good to me. +1 > > Am 30.01.2017 um 17:31 schrieb Steve Ebersole: > > Relatedly, I have been thinking whether we want to rename the ORM > artifacts > > as well since this is the best time if we wanted to do that. > > > > So we know we will change the groupId to `org.hibernate.orm`. > > > > I was thinking we might want to also either: > > > > 1. rename `hibernate-core` as `hibernate-orm` > > 2. rename all the artifacts following the pattern > `hibernate-orm-${1}`, > > e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. > > > > > > On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole > wrote: > > > >> Well let's investigate what this consistency means across projects > first. > >> As Sanne mentions, if it makes it building ORM more difficult then I'd > be > >> -1 it too. But I promise to take a peek when I get back from PTO in a > few > >> days. Or maybe Andrea can in the next few days as he already has > worked on > >> the changes to release relocation artifacts for ORM; I just do not know > >> when he is coming back from PTO. Either way we will have looked at it > for > >> ORM by the end of week. > >> > >> On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet < > guillaume.smet at gmail.com> > >> wrote: > >> > >> On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero > >> wrote: > >> > >>> Different projects have different needs. Consistency is nice, and > >>> certainly makes it easier to find oneself comfortably "at home" when > >>> jumping from one project to another, but it also is inconvenient to do > >>> things "for consistency" when one has different requirements. > >>> > >> I don't think we would have different requirements regarding the > relocation > >> artifacts. > >> > >> But if you see any issue with the approach we chose for HV, interesting > in > >> hearing them so that we can have the same approach for the different > NoORM > >> project. > >> > >> -- > >> Guillaume > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Feb 2 07:24:59 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 02 Feb 2017 12:24:59 +0000 Subject: [hibernate-dev] Query#iterate In-Reply-To: References: <836985ff-3d69-e726-4f93-555b4de216b5@gmail.com> <17f7d7ab-fae1-0ef1-28df-bc8f3ca359e6@hibernate.org> Message-ID: https://hibernate.atlassian.net/browse/HHH-11443 On Sat, Jan 28, 2017 at 6:38 PM andrea boriero wrote: > +1 to remove > > On 28 Jan 2017 20:44, "Chris Cranford" wrote: > > > +1 to remove as well > > > > > > On 01/27/2017 01:50 PM, Sanne Grinovero wrote: > > > +1 to remove > > > > > > On 27 January 2017 at 18:34, Vlad Mihalcea > > wrote: > > >> I'm for removing it even if it didn't complicate the query parser. > > >> > > >> Vlad > > >> > > >> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole > > wrote: > > >> > > >>> Because the behavior is also fundamentally questionable. > > >>> > > >>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov < > > >>> christian.beikov at gmail.com> wrote: > > >>> > > >>>> I'm sorry, I apparently confused iterate() with scroll() then, so > > forget > > >>>> what I wrote before ^^ > > >>>> > > >>>> In face of that new info, I actually don't know of any actual users. > > >>> After > > >>>> thinking a bit about it, why not make that behavior configurable via > > >>>> setProperty and drop that method? > > >>>> > > >>>> > > >>>> Am 27.01.2017 um 19:01 schrieb Steve Ebersole: > > >>>> > > >>>> On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov < > > >>>> christian.beikov at gmail.com> wrote: > > >>>> > > >>>> I just know of people that are using iterate() now for efficient > > >>>> incremental processing, but I guess any other approach(streams > maybe?) > > >>>> to do incremental processing would be good enough for these users. > > >>>> > > >>>> > > >>>> ScrollableResults do not meet that need? > > >>>> > > >>>> > > >>>> > > >>>> Unfortunately I don't know what a shallow query is or what the > > >>>> implication on the query or the processing of being shallow are. > > >>>> > > >>>> > > >>>> Just what I said before. "shallow" is simply a boolean flag that is > > part > > >>>> of the translator. It is set to true when the translation is > > triggered > > >>>> from Query#iterate. When the translation is triggered from > > Query#list or > > >>>> Query#scroll it is set to false. > > >>>> > > >>>> > > >>>> > > >>>> I guess this has to do with how row processing is done? > > >>>> > > >>>> > > >>>> The main thing is effects is the SQL we render. For "entity > returns" > > it > > >>>> simply selects the ids and we expect to then load them > (immediately!) > > by > > >>>> that id (N+1). Its usefulness is actually VERY limited in scope as > it > > >>>> actually performs horrendously in, what, 95-99% of use cases? > > >>>> > > >>>> Interestingly it really does not have much effect on "row > processing". > > >>>> > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> 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 > > > > _______________________________________________ > > 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 rory.odonnell at oracle.com Fri Feb 3 16:16:47 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 3 Feb 2017 21:16:47 +0000 Subject: [hibernate-dev] JDK 9 EA Build 155 is available on java.net Message-ID: <67e544ca-0401-af9d-f8fa-646650c5c04f@oracle.com> Hi Sanne, *JDK 9 Early Access* b155 is available on java.net There have been a number of fixes to bugs reported by Open Source projects since the last availability email : * b155 - JDK-8167273 : Calendar.getDisplayNames inconsistent with DateFormatSymbols * b154 - JDK-8157611 : field visiblePackages is null for the unnamed module producing NPE when accessed * b153 - JDK-8163449 : Allow per protocol setting for URLConnection defaultUseCaches * b152 - JDK-8172158 : Annotation processor not run with -source <= 8 Dalibor and I are presenting at FOSDEM this weekend, we would love to meet you there! * JDK 9 Outreach - The Awesome Parts Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From mark at lawinegevaar.nl Sat Feb 4 09:05:46 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sat, 4 Feb 2017 15:05:46 +0100 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL Message-ID: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> Firebird has a problem with some of the SQL generated by Hibernate, in some queries Hibernate appends StringHelper.WHITESPACE between conditions (specifically in CollectionBinder.bindFilters(boolean)). The problem is that StringHelper.WHITESPACE contains a formfeed (\f, 0x0C), and Firebird does not accept a formfeed as whitespace. It looks like the usage of StringHelper.WHITESPACE is wrong; the other places this constant is used is for splitting/tokenizing strings, and not for adding whitespace. Is there any objection if I replace the usage in CollectionBinder.bindFilters(boolean) with a single space (or maybe with " \n\t" to produce more similar SQL as previous)? Mark -- Mark Rotteveel From mihalcea.vlad at gmail.com Mon Feb 6 07:37:02 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 6 Feb 2017 14:37:02 +0200 Subject: [hibernate-dev] MariaDB-specific Dialects Message-ID: Hi, I've had a very interesting discussion on Twitter regarding MarisDB: https://twitter.com/bobbytank42/status/828529312731013121 And, since MySQL and MariaDB have gone in different directions, we might want to provide MariaDB Dialects as well. For instance, it's not very intuitive for a Hibernate user to figure out that they need to use the MySQLInnoDb57Dialect to handle Timestamps with microsecond precision which have been available since MariaDB 5.3: https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/ Let me know what you think. Vlad From sanne at hibernate.org Mon Feb 6 07:43:48 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 6 Feb 2017 12:43:48 +0000 Subject: [hibernate-dev] MariaDB-specific Dialects In-Reply-To: References: Message-ID: +1 to split them. I don't expect people to consider them "the same" anymore.. We probably should have split them even if there had been no technical differences, just to make it clear which one needs to be configured. On 6 February 2017 at 12:37, Vlad Mihalcea wrote: > Hi, > > I've had a very interesting discussion on Twitter regarding MarisDB: > > https://twitter.com/bobbytank42/status/828529312731013121 > > And, since MySQL and MariaDB have gone in different directions, we might > want to provide MariaDB Dialects as well. > > For instance, it's not very intuitive for a Hibernate user to figure out > that they need to use the MySQLInnoDb57Dialect to handle Timestamps with > microsecond precision which have been available since MariaDB 5.3: > > https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/ > > 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 Feb 6 08:19:20 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 06 Feb 2017 13:19:20 +0000 Subject: [hibernate-dev] MariaDB-specific Dialects In-Reply-To: References: Message-ID: Fwiw Dialect discovery is far and away the preferred solution for "specifying" Dialect. That said, I am ok with splitting off Dialect(s) specific to MariaDB. Relatedly, I wonder if we should begin to remove the Dialects we have marked as deprecated and whether we should consider a "legacy" repo where we can dump these (as well as other removed features - Javassist support e.g.). The expectation would be no continued development, but would make them more readily available to users who still needed them as opposed to simply dropping them completely. We could even alter the license of those classes to be less restrictive than LGPL in terms of contributing back changes. On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero wrote: > +1 to split them. I don't expect people to consider them "the same" > anymore.. > > We probably should have split them even if there had been no technical > differences, just to make it clear which one needs to be configured. > > On 6 February 2017 at 12:37, Vlad Mihalcea > wrote: > > Hi, > > > > I've had a very interesting discussion on Twitter regarding MarisDB: > > > > https://twitter.com/bobbytank42/status/828529312731013121 > > > > And, since MySQL and MariaDB have gone in different directions, we might > > want to provide MariaDB Dialects as well. > > > > For instance, it's not very intuitive for a Hibernate user to figure out > > that they need to use the MySQLInnoDb57Dialect to handle Timestamps with > > microsecond precision which have been available since MariaDB 5.3: > > > > https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/ > > > > 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 emmanuel at hibernate.org Mon Feb 6 09:53:47 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 6 Feb 2017 15:53:47 +0100 Subject: [hibernate-dev] Behaviour of validation mode "auto" in case of error during validator factory bootstrap In-Reply-To: References: Message-ID: <1D3918AA-6174-4A06-AF02-7FD6B3C7A865@hibernate.org> +1 to fail fast with the explicit error in that case. > On 1 Feb 2017, at 11:33, Gunnar Morling wrote: > > Hi, > > JPA defines for validation mode "auto" that bean validation must occur > if a BV provider is present and that no validation shall occur > otherwise. > > What should happen though if a BV provider such as HV is present but > it fails to bootstrap? In case of HV this happens if no expression > language implementation can be found. > > Currently, the user has a very hard time to find out about this, as > this exception essentially is suppressed (for mode "callback" the > exception is raised). > > Should we raise a specific exception in HV if it cannot be > bootstrapped? In ORM, we could handle that one specifically and raise > it also if for validation mode "auto" (would have to happen > reflectively, though, as to avoid a hard dependency). > > I can do this change but first wanted to make sure that this is inline > with what you all think should be done. > > Thanks, > > --Gunnar > _______________________________________________ > 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 Feb 6 10:05:10 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 6 Feb 2017 17:05:10 +0200 Subject: [hibernate-dev] MariaDB-specific Dialects In-Reply-To: References: Message-ID: I'll create a new Jira issue for the MariaDB Dialects. For the deprecated Dialects, I'd just remove them. But the Javassist support can be moved to a to a hibernate-legacy GitHub repository. Vlad On Mon, Feb 6, 2017 at 3:19 PM, Steve Ebersole wrote: > Fwiw Dialect discovery is far and away the preferred solution for > "specifying" Dialect. That said, I am ok with splitting off Dialect(s) > specific to MariaDB. > > Relatedly, I wonder if we should begin to remove the Dialects we have > marked as deprecated and whether we should consider a "legacy" repo where > we can dump these (as well as other removed features - Javassist support > e.g.). The expectation would be no continued development, but would make > them more readily available to users who still needed them as opposed to > simply dropping them completely. We could even alter the license of those > classes to be less restrictive than LGPL in terms of contributing back > changes. > > On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero wrote: > >> +1 to split them. I don't expect people to consider them "the same" >> anymore.. >> >> We probably should have split them even if there had been no technical >> differences, just to make it clear which one needs to be configured. >> >> On 6 February 2017 at 12:37, Vlad Mihalcea >> wrote: >> > Hi, >> > >> > I've had a very interesting discussion on Twitter regarding MarisDB: >> > >> > https://twitter.com/bobbytank42/status/828529312731013121 >> > >> > And, since MySQL and MariaDB have gone in different directions, we might >> > want to provide MariaDB Dialects as well. >> > >> > For instance, it's not very intuitive for a Hibernate user to figure out >> > that they need to use the MySQLInnoDb57Dialect to handle Timestamps with >> > microsecond precision which have been available since MariaDB 5.3: >> > >> > https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/ >> > >> > 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 crancran at gmail.com Mon Feb 6 10:17:52 2017 From: crancran at gmail.com (Chris Cranford) Date: Mon, 6 Feb 2017 10:17:52 -0500 Subject: [hibernate-dev] MariaDB-specific Dialects In-Reply-To: References: Message-ID: +1 for both On 02/06/2017 08:19 AM, Steve Ebersole wrote: > Fwiw Dialect discovery is far and away the preferred solution for > "specifying" Dialect. That said, I am ok with splitting off Dialect(s) > specific to MariaDB. > > Relatedly, I wonder if we should begin to remove the Dialects we have > marked as deprecated and whether we should consider a "legacy" repo where > we can dump these (as well as other removed features - Javassist support > e.g.). The expectation would be no continued development, but would make > them more readily available to users who still needed them as opposed to > simply dropping them completely. We could even alter the license of those > classes to be less restrictive than LGPL in terms of contributing back > changes. > > On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero wrote: > >> +1 to split them. I don't expect people to consider them "the same" >> anymore.. >> >> We probably should have split them even if there had been no technical >> differences, just to make it clear which one needs to be configured. >> >> On 6 February 2017 at 12:37, Vlad Mihalcea >> wrote: >>> Hi, >>> >>> I've had a very interesting discussion on Twitter regarding MarisDB: >>> >>> https://twitter.com/bobbytank42/status/828529312731013121 >>> >>> And, since MySQL and MariaDB have gone in different directions, we might >>> want to provide MariaDB Dialects as well. >>> >>> For instance, it's not very intuitive for a Hibernate user to figure out >>> that they need to use the MySQLInnoDb57Dialect to handle Timestamps with >>> microsecond precision which have been available since MariaDB 5.3: >>> >>> https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/ >>> >>> 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 >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From andrea at hibernate.org Mon Feb 6 10:20:33 2017 From: andrea at hibernate.org (andrea boriero) Date: Mon, 6 Feb 2017 15:20:33 +0000 Subject: [hibernate-dev] MariaDB-specific Dialects In-Reply-To: References: Message-ID: +1 for MariaDB dialect. +1 also for the deprecated repos On 6 February 2017 at 15:05, Vlad Mihalcea wrote: > I'll create a new Jira issue for the MariaDB Dialects. > > For the deprecated Dialects, I'd just remove them. But the Javassist > support can be moved to a to a hibernate-legacy GitHub repository. > > Vlad > > On Mon, Feb 6, 2017 at 3:19 PM, Steve Ebersole > wrote: > > > Fwiw Dialect discovery is far and away the preferred solution for > > "specifying" Dialect. That said, I am ok with splitting off Dialect(s) > > specific to MariaDB. > > > > Relatedly, I wonder if we should begin to remove the Dialects we have > > marked as deprecated and whether we should consider a "legacy" repo > where > > we can dump these (as well as other removed features - Javassist support > > e.g.). The expectation would be no continued development, but would make > > them more readily available to users who still needed them as opposed to > > simply dropping them completely. We could even alter the license of > those > > classes to be less restrictive than LGPL in terms of contributing back > > changes. > > > > On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero > wrote: > > > >> +1 to split them. I don't expect people to consider them "the same" > >> anymore.. > >> > >> We probably should have split them even if there had been no technical > >> differences, just to make it clear which one needs to be configured. > >> > >> On 6 February 2017 at 12:37, Vlad Mihalcea > >> wrote: > >> > Hi, > >> > > >> > I've had a very interesting discussion on Twitter regarding MarisDB: > >> > > >> > https://twitter.com/bobbytank42/status/828529312731013121 > >> > > >> > And, since MySQL and MariaDB have gone in different directions, we > might > >> > want to provide MariaDB Dialects as well. > >> > > >> > For instance, it's not very intuitive for a Hibernate user to figure > out > >> > that they need to use the MySQLInnoDb57Dialect to handle Timestamps > with > >> > microsecond precision which have been available since MariaDB 5.3: > >> > > >> > https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/ > >> > > >> > 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 > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Mon Feb 6 10:21:06 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 6 Feb 2017 16:21:06 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: Message-ID: <77ABC669-F7D9-4247-BAF0-BB6ED29155F0@hibernate.org> Hey all, On the license, I think ASL 2.0 is the best for such project. On the group id, am I right that this project is some utilities used by us internally? And would not be imported by a user? If true then I?d avoid common as it feels like something that a user would import. internal could work. Some other proposal (to be combined or not): - utilities - infra - toolbox On the theme, I don't have a definitive opinion but I think like Guillaume I?d prefer a lighter customized version of the default Asciidoc theme rather than the heavyweight one. Emmanuel > On 31 Jan 2017, at 12:27, Guillaume Smet wrote: > > On Tue, Jan 31, 2017 at 11:34 AM, Gunnar Morling > wrote: > >> == Repo organization == >> >> I would prefer to have the AsciiDoc style, shared testing utilities >> and other utilities in separate repos, not a shared one. To me, a repo >> represents a coherent unit of "things" with its own lifecycle. Updates >> to the style should not mandate an update of the version of the >> testing and other utilities, so they should be in their own repo. This >> should also make it easier in terms of licenses (no need for >> relicensing). >> > > Yeah, that was my first intention but I got outnumbered and to be honest I > don't really care as long as they are purely internal projects. I'll let > Yoann and Sanne explain their point of view as they will do that better > than me (IIRC, it was mostly about the maintenance cost but I'm not sure it > makes a difference if the lifecycles are completely different). > > Anyway, it does not solve the license issue. As per our discussion last > week, if we have some general utilities to share between the NoORM projects > for instance, we would probably like to copy the sources of the utilities > to avoid conflicting dependencies when depending on 2 of the projects > (probably using > https://maven.apache.org/plugins/maven-dependency-plugin/examples/using-dependencies-sources.html). > In this case, I think we would need to dual license (ASL 2 + LGPL) the > utilities as the sources will be distributed with the rest of the projects. > > So, if I try to sum it up: > > == GroupId == > > 2 proposals: > - org.hibernate.common (the same as hibernate-commons-annotations) > - org.hibernate.internal > > (let's drop my initial org.hibernate.commons proposal, it's too confusing > with org.hibernate.common) > > == The license == > > The license: probably better to dual license everything under the ASL2 and > the LGPL - especially if we start to share utilities. > > Will check with Emmanuel when he's back. > > == The AsciiDoctor theme == > > We mostly agree that it's probably better to converge on a similar layout. > > Steve seems to be strongly attached to the Hibernate theme. > > I personally don't like it and think it would be more painful to maintain > in the long term as it overrides more things. Sanne was also more convinced > by the white banner. > > If I sum up the differences between the 2 themes ( > http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html > vs http://docs.jboss.org/hibernate/beta/html_single/): > - black banner vs white banner > - original Docbook icons vs font based icons (Font Awesome) > - dark blue titles vs standard red ones > - admonitions are totally different (compare > http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#naming > and the end of this paragraph > http://docs.jboss.org/hibernate/beta/html_single/#search-batchindexing-threadsandconnections > ) > - a lots of fonts loaded in the ORM doc but I must admit that I think most > are useless: > http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibernate-fonts.css > so we could probably clean this up > - more overrides (compare > http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibernate-layout.css > vs http://docs.jboss.org/hibernate/beta/html_single/css/hibernate.css) so > more maintenance if the HTML output of AsciiDoctor is changed - note that > I'm new to AsciiDoctor so I don't know how stable the HTML output is > > The ORM output might have been better than the default AsciiDoctor output > at the time it was made, but as of now I really think the current > AsciiDoctor output is more pleasant to read and more modern. And we would > benefit from future improvements for free. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From brett at hibernate.org Mon Feb 6 10:30:16 2017 From: brett at hibernate.org (Brett Meyer) Date: Mon, 6 Feb 2017 10:30:16 -0500 Subject: [hibernate-dev] MariaDB-specific Dialects In-Reply-To: References: Message-ID: <976c7cf7-eb67-a4c7-1ab6-b7269ab4de9e@hibernate.org> Ditto -- a cleanup would be fantastic. On 02/06/2017 10:20 AM, andrea boriero wrote: > +1 for MariaDB dialect. > > +1 also for the deprecated repos > > > On 6 February 2017 at 15:05, Vlad Mihalcea wrote: > >> I'll create a new Jira issue for the MariaDB Dialects. >> >> For the deprecated Dialects, I'd just remove them. But the Javassist >> support can be moved to a to a hibernate-legacy GitHub repository. >> >> Vlad >> >> On Mon, Feb 6, 2017 at 3:19 PM, Steve Ebersole >> wrote: >> >>> Fwiw Dialect discovery is far and away the preferred solution for >>> "specifying" Dialect. That said, I am ok with splitting off Dialect(s) >>> specific to MariaDB. >>> >>> Relatedly, I wonder if we should begin to remove the Dialects we have >>> marked as deprecated and whether we should consider a "legacy" repo >> where >>> we can dump these (as well as other removed features - Javassist support >>> e.g.). The expectation would be no continued development, but would make >>> them more readily available to users who still needed them as opposed to >>> simply dropping them completely. We could even alter the license of >> those >>> classes to be less restrictive than LGPL in terms of contributing back >>> changes. >>> >>> On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero >> wrote: >>>> +1 to split them. I don't expect people to consider them "the same" >>>> anymore.. >>>> >>>> We probably should have split them even if there had been no technical >>>> differences, just to make it clear which one needs to be configured. >>>> >>>> On 6 February 2017 at 12:37, Vlad Mihalcea >>>> wrote: >>>>> Hi, >>>>> >>>>> I've had a very interesting discussion on Twitter regarding MarisDB: >>>>> >>>>> https://twitter.com/bobbytank42/status/828529312731013121 >>>>> >>>>> And, since MySQL and MariaDB have gone in different directions, we >> might >>>>> want to provide MariaDB Dialects as well. >>>>> >>>>> For instance, it's not very intuitive for a Hibernate user to figure >> out >>>>> that they need to use the MySQLInnoDb57Dialect to handle Timestamps >> with >>>>> microsecond precision which have been available since MariaDB 5.3: >>>>> >>>>> https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/ >>>>> >>>>> 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 >>>> >> _______________________________________________ >> 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 Feb 6 10:34:24 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 6 Feb 2017 15:34:24 +0000 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: <77ABC669-F7D9-4247-BAF0-BB6ED29155F0@hibernate.org> References: <77ABC669-F7D9-4247-BAF0-BB6ED29155F0@hibernate.org> Message-ID: On 6 February 2017 at 15:21, Emmanuel Bernard wrote: > Hey all, > > On the license, I think ASL 2.0 is the best for such project. > On the group id, am I right that this project is some utilities used by us internally? And would not be imported by a user? That's what I hope should be the intent as well. This repo would be useful to e.g. not rebuild the same checkstyle extensions over and over, but I'd not like to share actual runtime code from this project. Project inter-dependency matrix is complex enough for end-users. Thanks, Sanne > > If true then I?d avoid common as it feels like something that a user would import. internal could work. Some other proposal (to be combined or not): > - utilities > - infra > - toolbox > > On the theme, I don't have a definitive opinion but I think like Guillaume I?d prefer a lighter customized version of the default Asciidoc theme rather than the heavyweight one. > > Emmanuel > >> On 31 Jan 2017, at 12:27, Guillaume Smet wrote: >> >> On Tue, Jan 31, 2017 at 11:34 AM, Gunnar Morling >> wrote: >> >>> == Repo organization == >>> >>> I would prefer to have the AsciiDoc style, shared testing utilities >>> and other utilities in separate repos, not a shared one. To me, a repo >>> represents a coherent unit of "things" with its own lifecycle. Updates >>> to the style should not mandate an update of the version of the >>> testing and other utilities, so they should be in their own repo. This >>> should also make it easier in terms of licenses (no need for >>> relicensing). >>> >> >> Yeah, that was my first intention but I got outnumbered and to be honest I >> don't really care as long as they are purely internal projects. I'll let >> Yoann and Sanne explain their point of view as they will do that better >> than me (IIRC, it was mostly about the maintenance cost but I'm not sure it >> makes a difference if the lifecycles are completely different). >> >> Anyway, it does not solve the license issue. As per our discussion last >> week, if we have some general utilities to share between the NoORM projects >> for instance, we would probably like to copy the sources of the utilities >> to avoid conflicting dependencies when depending on 2 of the projects >> (probably using >> https://maven.apache.org/plugins/maven-dependency-plugin/examples/using-dependencies-sources.html). >> In this case, I think we would need to dual license (ASL 2 + LGPL) the >> utilities as the sources will be distributed with the rest of the projects. >> >> So, if I try to sum it up: >> >> == GroupId == >> >> 2 proposals: >> - org.hibernate.common (the same as hibernate-commons-annotations) >> - org.hibernate.internal >> >> (let's drop my initial org.hibernate.commons proposal, it's too confusing >> with org.hibernate.common) >> >> == The license == >> >> The license: probably better to dual license everything under the ASL2 and >> the LGPL - especially if we start to share utilities. >> >> Will check with Emmanuel when he's back. >> >> == The AsciiDoctor theme == >> >> We mostly agree that it's probably better to converge on a similar layout. >> >> Steve seems to be strongly attached to the Hibernate theme. >> >> I personally don't like it and think it would be more painful to maintain >> in the long term as it overrides more things. Sanne was also more convinced >> by the white banner. >> >> If I sum up the differences between the 2 themes ( >> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html >> vs http://docs.jboss.org/hibernate/beta/html_single/): >> - black banner vs white banner >> - original Docbook icons vs font based icons (Font Awesome) >> - dark blue titles vs standard red ones >> - admonitions are totally different (compare >> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#naming >> and the end of this paragraph >> http://docs.jboss.org/hibernate/beta/html_single/#search-batchindexing-threadsandconnections >> ) >> - a lots of fonts loaded in the ORM doc but I must admit that I think most >> are useless: >> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibernate-fonts.css >> so we could probably clean this up >> - more overrides (compare >> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibernate-layout.css >> vs http://docs.jboss.org/hibernate/beta/html_single/css/hibernate.css) so >> more maintenance if the HTML output of AsciiDoctor is changed - note that >> I'm new to AsciiDoctor so I don't know how stable the HTML output is >> >> The ORM output might have been better than the default AsciiDoctor output >> at the time it was made, but as of now I really think the current >> AsciiDoctor output is more pleasant to read and more modern. And we would >> benefit from future improvements for free. >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Mon Feb 6 10:49:00 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 6 Feb 2017 16:49:00 +0100 Subject: [hibernate-dev] [HV/HSEARCH] Free form In-Reply-To: References: <452FAF91-6C62-44E9-86E5-4CB1B7726460@hibernate.org> Message-ID: <1C4DDF41-A476-4018-BBDF-38C249EBA2B1@hibernate.org> Your prototype is very Hibernate Search tainted. I wonder how or whether we want it reusable across Hibernate Validator, Search and possibly more. Have you captured somewhere the discussion about the new document builder so I could get a better grip of what?s at bay? Would this reverse of logic also be embraced by Hibernate Validator? There are runtime decisions done in HV during traversal that made me doubt that it would be as pertinent. > On 30 Jan 2017, at 11:21, Yoann Rodiere wrote: > > Hi, > > Did the same this week-end, and adapted your work to match the bigger picture of what we discussed on Friday. > Basically the "StructureTraverser" is now called "ValueProcessor", because it's not responsible for exposing the internals of a structure anymore, but only to process a structure according to previously defined metadata, passing the output to the "DocumentContext". I think it's the second option you suggested. It makes sense in my opinion, since metadata will be defined differently for different source types (POJO, JSON, ...). > This design allows in particular what Sanne suggested: when bootstrapping, we can build some kind of "walker" (a composition of "ValueProcessors") from the metadata, and avoid metadata lookup at runtime. > > The snippet is there: https://gist.github.com/yrodiere/9ff8fe8a8c7f59c1a051b36db20fbd4d > > I'm sure it'll have to be refined to address additional constraints, but in its current state it seems to address all of our requirements. > > Yoann Rodi?re > > Software Engineer > Red Hat / Hibernate NoORM Team > > On 27 January 2017 at 18:23, Emmanuel Bernard > wrote: > I took the flight home to play with free form and specifically how we would retrieve data from the free form structure. > By free-form I mean non POJO but they will have schema (not expressed here). > > https://github.com/emmanuelbernard/hibernate-search/commit/0bd3fbab137bdad81bfa5b9934063792a050f537 > > And in particular > https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freeform/src/main/java/org/hibernate/freeform/StructureTraverser.java > https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freeform/src/main/java/org/hibernate/freeform/pojo/impl/PojoStructureTraverser.java > > It probably does not compile, I could not make the build work. > > I figured it was important to dump this raw thinking because it will influence and will be influenced by the redesign of the DocumentBuilder of Hibernate Search. > > There are several options for traversing a free form structure > - expose the traversing API as a holder to navigate all properties per structure and sub structure. This is what the prototype shows. Caching needs to be accessed via a hashmap get or other lookup. Metadata and the traversing structure will be navigated in parallel > - expose a structure that is specialized to a single property or container unwrapping aspect. The structures will be spread across and embedded in the Metadata > > > Another angle: > - create a traversable object per payload to carry it (sharing metadata info per type) > - have a stateless traversable object that is provided the payload for each access > > The former seems better as it does not create a traversable object per object navigated. > The latter is better for payloads that need parsing or are better at sequential access since state could be cached. > > We need to discuss that and know where DocumentBuilder is going to properly design this API. > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Feb 6 10:50:10 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 6 Feb 2017 15:50:10 +0000 Subject: [hibernate-dev] MariaDB-specific Dialects In-Reply-To: References: Message-ID: On 6 February 2017 at 13:19, Steve Ebersole wrote: > Fwiw Dialect discovery is far and away the preferred solution for > "specifying" Dialect. That said, I am ok with splitting off Dialect(s) > specific to MariaDB. Right I agree auto-detection is preferred. Are you suggesting that we actually can't automatically figure out if the connected database is a MariaDB or a MySQL instance? That would be sad. I hope you can find a solution :) > > Relatedly, I wonder if we should begin to remove the Dialects we have marked > as deprecated and whether we should consider a "legacy" repo where we can > dump these (as well as other removed features - Javassist support e.g.). > The expectation would be no continued development, but would make them more > readily available to users who still needed them as opposed to simply > dropping them completely. We could even alter the license of those classes > to be less restrictive than LGPL in terms of contributing back changes. > > > On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero wrote: >> >> +1 to split them. I don't expect people to consider them "the same" >> anymore.. >> >> We probably should have split them even if there had been no technical >> differences, just to make it clear which one needs to be configured. >> >> On 6 February 2017 at 12:37, Vlad Mihalcea >> wrote: >> > Hi, >> > >> > I've had a very interesting discussion on Twitter regarding MarisDB: >> > >> > https://twitter.com/bobbytank42/status/828529312731013121 >> > >> > And, since MySQL and MariaDB have gone in different directions, we might >> > want to provide MariaDB Dialects as well. >> > >> > For instance, it's not very intuitive for a Hibernate user to figure out >> > that they need to use the MySQLInnoDb57Dialect to handle Timestamps with >> > microsecond precision which have been available since MariaDB 5.3: >> > >> > https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/ >> > >> > 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 davide at hibernate.org Tue Feb 7 05:04:25 2017 From: davide at hibernate.org (Davide D'Alto) Date: Tue, 7 Feb 2017 10:04:25 +0000 Subject: [hibernate-dev] Update JDK 9 to build 154 on CI Message-ID: Are there any problems if I update the JDK 9 on Jenkins? Let me know, Davide From sanne at hibernate.org Tue Feb 7 05:07:49 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 7 Feb 2017 10:07:49 +0000 Subject: [hibernate-dev] Update JDK 9 to build 154 on CI In-Reply-To: References: Message-ID: No problem, but we're at build 155 since last week ;) Thanks! On 7 February 2017 at 10:04, Davide D'Alto wrote: > Are there any problems if I update the JDK 9 on Jenkins? > > Let me know, > Davide > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Tue Feb 7 05:17:53 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 7 Feb 2017 11:17:53 +0100 Subject: [hibernate-dev] [HV/HSEARCH] Free form In-Reply-To: <1C4DDF41-A476-4018-BBDF-38C249EBA2B1@hibernate.org> References: <452FAF91-6C62-44E9-86E5-4CB1B7726460@hibernate.org> <1C4DDF41-A476-4018-BBDF-38C249EBA2B1@hibernate.org> Message-ID: Emmanuel, In your PoC, how would a complete tree-like structure be traversed? It's not clear to me, who is driving StructureTraverser, i.e. which component will call processSubstructureInContainer() et al. when traversing an entire tree. @Yoann, maybe you can add a usage example similar to Emmanuel's? You have a lot of framework code, but I'm not sure about how it'd be used. For Hibernate Search, the traversal pattern I implemented for the ScenicView PoC may be of interest. Its general idea is to represent a tree traversal as a sequence of events which a traverser implementation receives and can act on, e.g. to create a corresponding de-normalized structure, Lucene document etc. The retrieval of values and associated objects happens lazily as the traverser ("TreeTraversalEventConsumer" in my lingo) pulls events from the sequence, similar to what some XML parsers do. The main contract can be found at [1]. There are two event sequence implements, one based on Hibernate's meta-model [2] and one for java.util.Map [3]. An example event consumer implementation which creates MongoDB documents can be found at [4]. As said I think it'd nicely fit for Hibernate Search, for HV I'm not so sure. The reason being that the order of traversal may very, depending on the defined validation groups and sequences. Sometimes we need to go "depth first". I've been contemplating to employ an event-like approach as described above for HV, but it may look different than the one used for HSEARCH. --Gunnar [1] https://github.com/gunnarmorling/scenicview-mvp/blob/master/core/src/main/java/org/hibernate/scenicview/spi/backend/model/TreeTraversalSequence.java. [2] https://github.com/gunnarmorling/scenicview-mvp/blob/master/core/src/main/java/org/hibernate/scenicview/internal/model/EntityStateBasedTreeTraversalSequence.java [3] https://github.com/gunnarmorling/scenicview-mvp/blob/master/core/src/test/java/org/hibernate/scenicview/test/traversal/MapTreeTraversalSequence.java [4] https://github.com/gunnarmorling/scenicview-mvp/blob/master/mongodb/src/main/java/org/hibernate/scenicview/mongodb/internal/MongoDbDenormalizationBackend.java#L91..L128 2017-02-06 16:49 GMT+01:00 Emmanuel Bernard : > Your prototype is very Hibernate Search tainted. I wonder how or whether we want it reusable across Hibernate Validator, Search and possibly more. > > Have you captured somewhere the discussion about the new document builder so I could get a better grip of what?s at bay? > Would this reverse of logic also be embraced by Hibernate Validator? There are runtime decisions done in HV during traversal that made me doubt that it would be as pertinent. > > > >> On 30 Jan 2017, at 11:21, Yoann Rodiere wrote: >> >> Hi, >> >> Did the same this week-end, and adapted your work to match the bigger picture of what we discussed on Friday. >> Basically the "StructureTraverser" is now called "ValueProcessor", because it's not responsible for exposing the internals of a structure anymore, but only to process a structure according to previously defined metadata, passing the output to the "DocumentContext". I think it's the second option you suggested. It makes sense in my opinion, since metadata will be defined differently for different source types (POJO, JSON, ...). >> This design allows in particular what Sanne suggested: when bootstrapping, we can build some kind of "walker" (a composition of "ValueProcessors") from the metadata, and avoid metadata lookup at runtime. >> >> The snippet is there: https://gist.github.com/yrodiere/9ff8fe8a8c7f59c1a051b36db20fbd4d >> >> I'm sure it'll have to be refined to address additional constraints, but in its current state it seems to address all of our requirements. >> >> Yoann Rodi?re > >> Software Engineer >> Red Hat / Hibernate NoORM Team >> >> On 27 January 2017 at 18:23, Emmanuel Bernard > wrote: >> I took the flight home to play with free form and specifically how we would retrieve data from the free form structure. >> By free-form I mean non POJO but they will have schema (not expressed here). >> >> https://github.com/emmanuelbernard/hibernate-search/commit/0bd3fbab137bdad81bfa5b9934063792a050f537 >> >> And in particular >> https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freeform/src/main/java/org/hibernate/freeform/StructureTraverser.java >> https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freeform/src/main/java/org/hibernate/freeform/pojo/impl/PojoStructureTraverser.java >> >> It probably does not compile, I could not make the build work. >> >> I figured it was important to dump this raw thinking because it will influence and will be influenced by the redesign of the DocumentBuilder of Hibernate Search. >> >> There are several options for traversing a free form structure >> - expose the traversing API as a holder to navigate all properties per structure and sub structure. This is what the prototype shows. Caching needs to be accessed via a hashmap get or other lookup. Metadata and the traversing structure will be navigated in parallel >> - expose a structure that is specialized to a single property or container unwrapping aspect. The structures will be spread across and embedded in the Metadata >> >> >> Another angle: >> - create a traversable object per payload to carry it (sharing metadata info per type) >> - have a stateless traversable object that is provided the payload for each access >> >> The former seems better as it does not create a traversable object per object navigated. >> The latter is better for payloads that need parsing or are better at sequential access since state could be cached. >> >> We need to discuss that and know where DocumentBuilder is going to properly design this API. >> >> Emmanuel >> _______________________________________________ >> 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 gunnar at hibernate.org Tue Feb 7 05:53:55 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 7 Feb 2017 11:53:55 +0100 Subject: [hibernate-dev] Behaviour of validation mode "auto" in case of error during validator factory bootstrap In-Reply-To: <1D3918AA-6174-4A06-AF02-7FD6B3C7A865@hibernate.org> References: <1D3918AA-6174-4A06-AF02-7FD6B3C7A865@hibernate.org> Message-ID: So the issue is a more general one than I thought. We'll run into the same situation, too, when there is an error in BV's validation.xml or any constraint mapping file (e.g. a reference to a non-existent MessageInterpolator). That error will currently be suppressed with validation-mode auto. I'm wondering whether in BV 2.0 we should define a new sub-type of ValidationException: NoProviderFoundException which is raised by javax.validation.Validation in case no BV provider is found. Then JPA/ORM could specifically ignore this exception in validation-mode auto but let all other exceptions bubble up, letting the user know early on about any issues they have with their validation provider or its config. Thoughts? 2017-02-06 15:53 GMT+01:00 Emmanuel Bernard : > +1 to fail fast with the explicit error in that case. > >> On 1 Feb 2017, at 11:33, Gunnar Morling wrote: >> >> Hi, >> >> JPA defines for validation mode "auto" that bean validation must occur >> if a BV provider is present and that no validation shall occur >> otherwise. >> >> What should happen though if a BV provider such as HV is present but >> it fails to bootstrap? In case of HV this happens if no expression >> language implementation can be found. >> >> Currently, the user has a very hard time to find out about this, as >> this exception essentially is suppressed (for mode "callback" the >> exception is raised). >> >> Should we raise a specific exception in HV if it cannot be >> bootstrapped? In ORM, we could handle that one specifically and raise >> it also if for validation mode "auto" (would have to happen >> reflectively, though, as to avoid a hard dependency). >> >> I can do this change but first wanted to make sure that this is inline >> with what you all think should be done. >> >> Thanks, >> >> --Gunnar >> _______________________________________________ >> 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 Feb 7 06:03:05 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 7 Feb 2017 12:03:05 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: <77ABC669-F7D9-4247-BAF0-BB6ED29155F0@hibernate.org> References: <77ABC669-F7D9-4247-BAF0-BB6ED29155F0@hibernate.org> Message-ID: Hi, On Mon, Feb 6, 2017 at 4:21 PM, Emmanuel Bernard wrote: > On the license, I think ASL 2.0 is the best for such project. > As we discussed it in Lisbon, we might "copy" (using Maven) sources from an internal utility project to the NoORM projects, as we want to avoid dependency hell with different versions of the utilities. In this case, they might be included in the source jar. Thus, I think the best is to dual license everything from the start. I'll go do that. > On the group id, am I right that this project is some utilities used by us > internally? And would not be imported by a user? > > If true then I?d avoid common as it feels like something that a user would > import. internal could work. Some other proposal (to be combined or not): > - utilities > - infra > - toolbox > OK, if internal works for you, let's settle on it. It's widely used in the Java world to name internal packages. It makes perfect sense here. > On the theme, I don't have a definitive opinion but I think like Guillaume > I?d prefer a lighter customized version of the default Asciidoc theme > rather than the heavyweight one. > OK, let's start with this to unblock the situation with OGM and Search. ORM can still use part of the theme (the PDF goodies) and keep their CSS if they prefer. And once they moved to use part of it, we can revisit and adjust so that everyone is happy. It's not as if the changes were breaking changes for the users, it won't be an issue to adjust one way or the other. -- Guillaume From mark at lawinegevaar.nl Tue Feb 7 07:26:33 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Tue, 7 Feb 2017 13:26:33 +0100 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> References: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> Message-ID: <057e58e4-fb6a-78f8-dbbf-d3d8a523710f@lawinegevaar.nl> Any comments, or should I take the lack of answers as approval ;) Mark On 4-2-2017 15:05, Mark Rotteveel wrote: > Firebird has a problem with some of the SQL generated by Hibernate, in > some queries Hibernate appends StringHelper.WHITESPACE between > conditions (specifically in CollectionBinder.bindFilters(boolean)). > > The problem is that StringHelper.WHITESPACE contains a formfeed (\f, > 0x0C), and Firebird does not accept a formfeed as whitespace. > > It looks like the usage of StringHelper.WHITESPACE is wrong; the other > places this constant is used is for splitting/tokenizing strings, and > not for adding whitespace. > > Is there any objection if I replace the usage in > CollectionBinder.bindFilters(boolean) with a single space (or maybe with > " \n\t" to produce more similar SQL as previous)? > > Mark > -- Mark Rotteveel From mihalcea.vlad at gmail.com Tue Feb 7 07:51:15 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 7 Feb 2017 14:51:15 +0200 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: <057e58e4-fb6a-78f8-dbbf-d3d8a523710f@lawinegevaar.nl> References: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> <057e58e4-fb6a-78f8-dbbf-d3d8a523710f@lawinegevaar.nl> Message-ID: You're right. For CollectionBinder, we shouldn't use the StringHelper.WHITESPACE. We should probably use a simple whitespace character. I guess that was the original intention. Vlad On Tue, Feb 7, 2017 at 2:26 PM, Mark Rotteveel wrote: > Any comments, or should I take the lack of answers as approval ;) > > Mark > > On 4-2-2017 15:05, Mark Rotteveel wrote: > > Firebird has a problem with some of the SQL generated by Hibernate, in > > some queries Hibernate appends StringHelper.WHITESPACE between > > conditions (specifically in CollectionBinder.bindFilters(boolean)). > > > > The problem is that StringHelper.WHITESPACE contains a formfeed (\f, > > 0x0C), and Firebird does not accept a formfeed as whitespace. > > > > It looks like the usage of StringHelper.WHITESPACE is wrong; the other > > places this constant is used is for splitting/tokenizing strings, and > > not for adding whitespace. > > > > Is there any objection if I replace the usage in > > CollectionBinder.bindFilters(boolean) with a single space (or maybe with > > " \n\t" to produce more similar SQL as previous)? > > > > Mark > > > > > -- > Mark Rotteveel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Tue Feb 7 07:55:24 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 7 Feb 2017 12:55:24 +0000 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: <057e58e4-fb6a-78f8-dbbf-d3d8a523710f@lawinegevaar.nl> References: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> <057e58e4-fb6a-78f8-dbbf-d3d8a523710f@lawinegevaar.nl> Message-ID: Hi Mark, that's not my area of expertise but it seems like a very reasonable proposal. Please open a JIRA, I'm sure someone from the right team will review and merge any such patch. Thanks, Sanne On 7 February 2017 at 12:26, Mark Rotteveel wrote: > Any comments, or should I take the lack of answers as approval ;) > > Mark > > On 4-2-2017 15:05, Mark Rotteveel wrote: >> Firebird has a problem with some of the SQL generated by Hibernate, in >> some queries Hibernate appends StringHelper.WHITESPACE between >> conditions (specifically in CollectionBinder.bindFilters(boolean)). >> >> The problem is that StringHelper.WHITESPACE contains a formfeed (\f, >> 0x0C), and Firebird does not accept a formfeed as whitespace. >> >> It looks like the usage of StringHelper.WHITESPACE is wrong; the other >> places this constant is used is for splitting/tokenizing strings, and >> not for adding whitespace. >> >> Is there any objection if I replace the usage in >> CollectionBinder.bindFilters(boolean) with a single space (or maybe with >> " \n\t" to produce more similar SQL as previous)? >> >> Mark >> > > > -- > Mark Rotteveel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From mihalcea.vlad at gmail.com Tue Feb 7 08:12:35 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 7 Feb 2017 15:12:35 +0200 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: References: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> <057e58e4-fb6a-78f8-dbbf-d3d8a523710f@lawinegevaar.nl> Message-ID: +1. I forgot to mention to add a Jira issue. If you don't have time, let me know, and I'll take care of this issue for you. Vlad On Tue, Feb 7, 2017 at 2:55 PM, Sanne Grinovero wrote: > Hi Mark, > that's not my area of expertise but it seems like a very reasonable > proposal. Please open a JIRA, I'm sure someone from the right team > will review and merge any such patch. > > Thanks, > Sanne > > > On 7 February 2017 at 12:26, Mark Rotteveel wrote: > > Any comments, or should I take the lack of answers as approval ;) > > > > Mark > > > > On 4-2-2017 15:05, Mark Rotteveel wrote: > >> Firebird has a problem with some of the SQL generated by Hibernate, in > >> some queries Hibernate appends StringHelper.WHITESPACE between > >> conditions (specifically in CollectionBinder.bindFilters(boolean)). > >> > >> The problem is that StringHelper.WHITESPACE contains a formfeed (\f, > >> 0x0C), and Firebird does not accept a formfeed as whitespace. > >> > >> It looks like the usage of StringHelper.WHITESPACE is wrong; the other > >> places this constant is used is for splitting/tokenizing strings, and > >> not for adding whitespace. > >> > >> Is there any objection if I replace the usage in > >> CollectionBinder.bindFilters(boolean) with a single space (or maybe > with > >> " \n\t" to produce more similar SQL as previous)? > >> > >> Mark > >> > > > > > > -- > > Mark Rotteveel > > _______________________________________________ > > 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 mark at lawinegevaar.nl Tue Feb 7 08:14:54 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Tue, 7 Feb 2017 14:14:54 +0100 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: References: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> <057e58e4-fb6a-78f8-dbbf-d3d8a523710f@lawinegevaar.nl> Message-ID: <7f3b3c52-6eb4-1274-43fe-eb524ccc2639@lawinegevaar.nl> On 7-2-2017 14:12, Vlad Mihalcea wrote: > +1. > > I forgot to mention to add a Jira issue. If you don't have time, let me > know, and I'll take care of this issue for you. I was considering doing it as part of my Firebird dialect PR, but if you prefer a separate ticket + PR, I can do that as well. Mark -- Mark Rotteveel From andrea at hibernate.org Tue Feb 7 08:32:10 2017 From: andrea at hibernate.org (andrea boriero) Date: Tue, 7 Feb 2017 13:32:10 +0000 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: References: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> <057e58e4-fb6a-78f8-dbbf-d3d8a523710f@lawinegevaar.nl> <7f3b3c52-6eb4-1274-43fe-eb524ccc2639@lawinegevaar.nl> Message-ID: And naturally a separate jira :) On 7 Feb 2017 13:30, andrea boriero wrote: > It's better to have a separate. > > On 7 Feb 2017 13:17, "Mark Rotteveel" wrote: > > On 7-2-2017 14:12, Vlad Mihalcea wrote: > > +1. > > > > I forgot to mention to add a Jira issue. If you don't have time, let me > > know, and I'll take care of this issue for you. > > I was considering doing it as part of my Firebird dialect PR, but if you > prefer a separate ticket + PR, I can do that as well. > > Mark > -- > Mark Rotteveel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From andrea at hibernate.org Tue Feb 7 08:32:10 2017 From: andrea at hibernate.org (andrea boriero) Date: Tue, 7 Feb 2017 13:32:10 +0000 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: <7f3b3c52-6eb4-1274-43fe-eb524ccc2639@lawinegevaar.nl> References: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> <057e58e4-fb6a-78f8-dbbf-d3d8a523710f@lawinegevaar.nl> <7f3b3c52-6eb4-1274-43fe-eb524ccc2639@lawinegevaar.nl> Message-ID: Hi Mark, I think it's better to have a separate PR. Thanks On 7 Feb 2017 13:17, "Mark Rotteveel" wrote: On 7-2-2017 14:12, Vlad Mihalcea wrote: > +1. > > I forgot to mention to add a Jira issue. If you don't have time, let me > know, and I'll take care of this issue for you. I was considering doing it as part of my Firebird dialect PR, but if you prefer a separate ticket + PR, I can do that as well. Mark -- Mark Rotteveel _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From mihalcea.vlad at gmail.com Tue Feb 7 08:43:00 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 7 Feb 2017 15:43:00 +0200 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: References: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> <057e58e4-fb6a-78f8-dbbf-d3d8a523710f@lawinegevaar.nl> <7f3b3c52-6eb4-1274-43fe-eb524ccc2639@lawinegevaar.nl> Message-ID: +1 A separate Jira/PR is better since we can backport to other versions. Vlad On Tue, Feb 7, 2017 at 3:32 PM, andrea boriero wrote: > And naturally a separate jira :) > > On 7 Feb 2017 13:30, andrea boriero wrote: > >> It's better to have a separate. >> >> On 7 Feb 2017 13:17, "Mark Rotteveel" wrote: >> >> On 7-2-2017 14:12, Vlad Mihalcea wrote: >> > +1. >> > >> > I forgot to mention to add a Jira issue. If you don't have time, let me >> > know, and I'll take care of this issue for you. >> >> I was considering doing it as part of my Firebird dialect PR, but if you >> prefer a separate ticket + PR, I can do that as well. >> >> Mark >> -- >> Mark Rotteveel >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> From yoann at hibernate.org Tue Feb 7 10:36:38 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 7 Feb 2017 16:36:38 +0100 Subject: [hibernate-dev] [HV/HSEARCH] Free form In-Reply-To: References: <452FAF91-6C62-44E9-86E5-4CB1B7726460@hibernate.org> <1C4DDF41-A476-4018-BBDF-38C249EBA2B1@hibernate.org> Message-ID: This conversation is starting to get a bit complex, so I'll try to organize my answers: # Applying the same solution to HV and HSearch @Emmanuel: right, I didn't see you were also talking about HV. I was only considering the HSearch case. I think I agree with you both, HV and HSearch are a bit different and we certainly cannot share the whole code. Some principles could probably be shared, such as the abstraction over accessing the input type with Emmanuel's "StructureTraverser". But the traversal algorithms are probably very different. And in fact, these traversals are at the core of each project's purpose, so it may not be a good idea to try to make them "more similar". # The requirements for HSearch @Emmanuel: we didn't take much notes, but we did draw a diagram of the target architecture: https://drive.google.com/a/redhat.com/file/d/0B_z-zSf_hJiZam JkZFBlNG5CeDQ/view?usp=sharing When you shared your recordings/pictures, I asked for the write permission on the shared folder to put the diagram, but you probably haven't had time yet. If I remember correctly, here were the main requirements: - Separate the source data traversal from the actual output format. - This will help when implementing different indexing services (Elasticsearch, Solr): we don't want to assume anything about the target format. - Make the implementation of JGroups/JMS as simple as possible. - In these case, we don't really want to build documents, we just want to transform the entity to a serializable object, and reduce the information to transmit over the network to a minimum. - Ideally, we'd just want to "record" the output of the traversal, transmit this recording to the master node, and leave the master node replay it to build a document. This would have the added benefit of not requiring any knowledge of the underlying technology (Lucene/ES/Solr) on the client side. - Requirements on the "mapping tree" (I'm not absolutely sure about those, Sanne may want to clarify): - ?depth? and navigational graph to be pre-computed: tree of valid fields and options to be known in advance. - Immutable, threadsafe, easy to inspect/walk mapping tree - And on my end (I think Sanne shared this concern, but I may be wrong): query metadata as little as possible at runtime. # More info on my snippet @Gunnar: you asked for some client code, but I'm not sure it'll be very explicit. The only client-facing interface (as far as document building goes) is EntityDocumentConverter. So, the parts of the application that need to convert an entity to a document will do something like that: EntityDocumentConverter converter = indexManager.getEntityDocument Converter(); D document = converter.convert( entity ); indexManager.performOperation( newAddOperation( document ) ); The idea behind this was to make runtime code as simple as possible, and move the complexity to the bootstrapping. Basically, when you call converter.convert, it will delegate to ValueProcessors, which will extract information from the entity and inject it into the DocumentBuilder. What is extracted, and how to extract it, is completely up to the ValueProcessor. This means that, when bootstrapping, a tree of ValueProcessors will be built according to the metadata. For instance when a @Field is encountered, we build an appropriate ValueProcessor (potentially nesting multiple ones if we want to keep matters separate: one for extracting the property's value, one for transforming this value using a bridge). When an @IndexedEmbedded is encountered, we build a different ValueProcessor. And so on. Here is an (admittedly very simple) example of what it'd look like in the metadata processor; List collectedProcessors = new ArrayList<>(); for ( XProperty property : properties ) { Field fieldAnnotation = property.getAnnotation( Field.class ); if ( fieldAnnotation != null ) { ValueProcessor fieldBridgeProcessor = createFieldBridgeProcessor( property.getType(), fieldAnnotation ); ValueProcessor propertyProcessor = new JavaPropertyProcessor( property, fieldBridgeProcessor ); // The value of the property will be passed to the fieldBridgeProcessor at runtime collectedProcessor.add( propertyProcessor ); } } ValueProcessor rootProcessor = new CompositeProcessor( collectedProcessors ); return new EntityDocumentConverter( rootProcessor, indexManagerType.getDocumentBuilder() ) The actual code will obviously be more complex, first because we need to support much more features than just @Field, but also because the createFieldBridgeProcessor() method needs to somehow build backend-specific metadata based on the nature of the field. But I think the snippet captures the spirit. # Summary Thinking about it a little, there's a different focus in our solutions. 1. Emmanuel's solutions focuses on abstracting over the input data format (thanks to StructureTraverser), assuming the traversal algorithm will be re-implemented for each output type. 2. My solution focuses on abstracting over the output data format (thanks to DocumentBuilder), assuming the traversal algorithm will be re-implemented for each input type using different ValueProcessors. 3. Gunnar's solution seem to focus on abstracting over the output data format, reimplementing the traversal algorithm for each input type using a different TreeTraversalSequence. Solution 1 and 2 are, in my opinion, compatible. We could have very generic ValueProcessors that would make use of a StructureTraverser to extract data and of a DocumentBuilder to inject it into a document. I'm not sure it is necessary, because I expect metadata to be defined differently based on the input type, and hence the traversal algorithms to be slightly different, but I think we could do it. About solution 3: TreeTraversalSequence seems to implement the traversal algorithm, while TreeTraversalEventConsumer abstracts over the output format and TreeTraversalEvent abstracts over the information being transferred. I think the general principles are more or less equivalent to solution 2. The main difference are: - How the context around the data to transfer is propagated. In solution 2, we pass the context progressively by making call to the DocumentBuilder (documentBuilder.nest(...), documentBuilder.addField(...)). In solution 3, the context is explicitly modeled as a TreeTraversalEvent. - How metadata is looked up. In solution 2, the metadata is built in the objects implementing the traversal algorithm, so there is no look up to speak of. In solution 3, there is a metadata lookup for each node in the tree. Maybe there's a matter of performance, but I don't know enough about this to give a definitive answer. In the end it's probably more a matter of taste. Yoann Rodi?re Hibernate NoORM Team On 7 February 2017 at 11:17, Gunnar Morling wrote: > Emmanuel, > > In your PoC, how would a complete tree-like structure be traversed? > It's not clear to me, who is driving StructureTraverser, i.e. which > component will call processSubstructureInContainer() et al. when > traversing an entire tree. > > @Yoann, maybe you can add a usage example similar to Emmanuel's? You > have a lot of framework code, but I'm not sure about how it'd be used. > > For Hibernate Search, the traversal pattern I implemented for the > ScenicView PoC may be of interest. Its general idea is to represent a > tree traversal as a sequence of events which a traverser > implementation receives and can act on, e.g. to create a corresponding > de-normalized structure, Lucene document etc. The retrieval of values > and associated objects happens lazily as the traverser > ("TreeTraversalEventConsumer" in my lingo) pulls events from the > sequence, similar to what some XML parsers do. > > The main contract can be found at [1]. There are two event sequence > implements, one based on Hibernate's meta-model [2] and one for > java.util.Map [3]. An example event consumer implementation which > creates MongoDB documents can be found at [4]. > > As said I think it'd nicely fit for Hibernate Search, for HV I'm not > so sure. The reason being that the order of traversal may very, > depending on the defined validation groups and sequences. Sometimes we > need to go "depth first". I've been contemplating to employ an > event-like approach as described above for HV, but it may look > different than the one used for HSEARCH. > > --Gunnar > > [1] https://github.com/gunnarmorling/scenicview-mvp/ > blob/master/core/src/main/java/org/hibernate/scenicview/spi/backend/model/ > TreeTraversalSequence.java. > [2] https://github.com/gunnarmorling/scenicview-mvp/ > blob/master/core/src/main/java/org/hibernate/scenicview/internal/model/ > EntityStateBasedTreeTraversalSequence.java > [3] https://github.com/gunnarmorling/scenicview-mvp/ > blob/master/core/src/test/java/org/hibernate/scenicview/test/traversal/ > MapTreeTraversalSequence.java > [4] https://github.com/gunnarmorling/scenicview-mvp/ > blob/master/mongodb/src/main/java/org/hibernate/scenicview/ > mongodb/internal/MongoDbDenormalizationBackend.java#L91..L128 > > > > 2017-02-06 16:49 GMT+01:00 Emmanuel Bernard : > > Your prototype is very Hibernate Search tainted. I wonder how or whether > we want it reusable across Hibernate Validator, Search and possibly more. > > > > Have you captured somewhere the discussion about the new document > builder so I could get a better grip of what?s at bay? > > Would this reverse of logic also be embraced by Hibernate Validator? > There are runtime decisions done in HV during traversal that made me doubt > that it would be as pertinent. > > > > > > > >> On 30 Jan 2017, at 11:21, Yoann Rodiere wrote: > >> > >> Hi, > >> > >> Did the same this week-end, and adapted your work to match the bigger > picture of what we discussed on Friday. > >> Basically the "StructureTraverser" is now called "ValueProcessor", > because it's not responsible for exposing the internals of a structure > anymore, but only to process a structure according to previously defined > metadata, passing the output to the "DocumentContext". I think it's the > second option you suggested. It makes sense in my opinion, since metadata > will be defined differently for different source types (POJO, JSON, ...). > >> This design allows in particular what Sanne suggested: when > bootstrapping, we can build some kind of "walker" (a composition of > "ValueProcessors") from the metadata, and avoid metadata lookup at runtime. > >> > >> The snippet is there: https://gist.github.com/yrodiere/ > 9ff8fe8a8c7f59c1a051b36db20fbd4d 9ff8fe8a8c7f59c1a051b36db20fbd4d> > >> > >> I'm sure it'll have to be refined to address additional constraints, > but in its current state it seems to address all of our requirements. > >> > >> Yoann Rodi?re > > >> Software Engineer > >> Red Hat / Hibernate NoORM Team > >> > >> On 27 January 2017 at 18:23, Emmanuel Bernard > wrote: > >> I took the flight home to play with free form and specifically how we > would retrieve data from the free form structure. > >> By free-form I mean non POJO but they will have schema (not expressed > here). > >> > >> https://github.com/emmanuelbernard/hibernate-search/commit/ > 0bd3fbab137bdad81bfa5b9934063792a050f537 emmanuelbernard/hibernate-search/commit/0bd3fbab137bdad81bfa5b99340637 > 92a050f537> > >> > >> And in particular > >> https://github.com/emmanuelbernard/hibernate- > search/blob/freeform/freeform/src/main/java/org/hibernate/ > freeform/StructureTraverser.java emmanuelbernard/hibernate-search/blob/freeform/freeform/ > src/main/java/org/hibernate/freeform/StructureTraverser.java> > >> https://github.com/emmanuelbernard/hibernate- > search/blob/freeform/freeform/src/main/java/org/hibernate/ > freeform/pojo/impl/PojoStructureTraverser.java emmanuelbernard/hibernate-search/blob/freeform/freeform/ > src/main/java/org/hibernate/freeform/pojo/impl/PojoStructureTraverser.java > > > >> > >> It probably does not compile, I could not make the build work. > >> > >> I figured it was important to dump this raw thinking because it will > influence and will be influenced by the redesign of the DocumentBuilder of > Hibernate Search. > >> > >> There are several options for traversing a free form structure > >> - expose the traversing API as a holder to navigate all properties > per structure and sub structure. This is what the prototype shows. Caching > needs to be accessed via a hashmap get or other lookup. Metadata and the > traversing structure will be navigated in parallel > >> - expose a structure that is specialized to a single property or > container unwrapping aspect. The structures will be spread across and > embedded in the Metadata > >> > >> > >> Another angle: > >> - create a traversable object per payload to carry it (sharing metadata > info per type) > >> - have a stateless traversable object that is provided the payload for > each access > >> > >> The former seems better as it does not create a traversable object per > object navigated. > >> The latter is better for payloads that need parsing or are better at > sequential access since state could be cached. > >> > >> We need to discuss that and know where DocumentBuilder is going to > properly design this API. > >> > >> Emmanuel > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev < > 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 mark at lawinegevaar.nl Tue Feb 7 10:58:20 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Tue, 7 Feb 2017 16:58:20 +0100 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> References: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> Message-ID: Issue: https://hibernate.atlassian.net/browse/HHH-11467 PR: https://github.com/hibernate/hibernate-orm/pull/1781 On 4-2-2017 15:05, Mark Rotteveel wrote: > Firebird has a problem with some of the SQL generated by Hibernate, in > some queries Hibernate appends StringHelper.WHITESPACE between > conditions (specifically in CollectionBinder.bindFilters(boolean)). > > The problem is that StringHelper.WHITESPACE contains a formfeed (\f, > 0x0C), and Firebird does not accept a formfeed as whitespace. > > It looks like the usage of StringHelper.WHITESPACE is wrong; the other > places this constant is used is for splitting/tokenizing strings, and > not for adding whitespace. > > Is there any objection if I replace the usage in > CollectionBinder.bindFilters(boolean) with a single space (or maybe with > " \n\t" to produce more similar SQL as previous)? > > Mark > -- Mark Rotteveel From sanne at hibernate.org Tue Feb 7 12:08:23 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 7 Feb 2017 17:08:23 +0000 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: References: <77aac074-ba30-efdc-c690-759295bec905@lawinegevaar.nl> Message-ID: merged it, and promoted your JIRA account so you can assign issues to yourself. Thanks! Sanne On 7 February 2017 at 15:58, Mark Rotteveel wrote: > Issue: https://hibernate.atlassian.net/browse/HHH-11467 > PR: https://github.com/hibernate/hibernate-orm/pull/1781 > > On 4-2-2017 15:05, Mark Rotteveel wrote: >> Firebird has a problem with some of the SQL generated by Hibernate, in >> some queries Hibernate appends StringHelper.WHITESPACE between >> conditions (specifically in CollectionBinder.bindFilters(boolean)). >> >> The problem is that StringHelper.WHITESPACE contains a formfeed (\f, >> 0x0C), and Firebird does not accept a formfeed as whitespace. >> >> It looks like the usage of StringHelper.WHITESPACE is wrong; the other >> places this constant is used is for splitting/tokenizing strings, and >> not for adding whitespace. >> >> Is there any objection if I replace the usage in >> CollectionBinder.bindFilters(boolean) with a single space (or maybe with >> " \n\t" to produce more similar SQL as previous)? >> >> Mark >> > > > -- > Mark Rotteveel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From mark at lawinegevaar.nl Tue Feb 7 12:51:23 2017 From: mark at lawinegevaar.nl (=?utf-8?B?TWFyayBSb3R0ZXZlZWw=?=) Date: Tue, 07 Feb 2017 18:51:23 +0100 Subject: [hibernate-dev] =?utf-8?q?Form-feed_=28=5Cf_0x0C=29_in_generated_?= =?utf-8?q?SQL?= Message-ID: <201702071751.v17HphOS031252@lists01.dmz-a.mwc.hst.phx2.redhat.com> Thanks! I just received a build failure notification with an ExceptionInInitialiserError, but I can't see how my PR would introduce that error. Any idea, or should I just ignore it? Mark ----- Bericht beantwoorden ----- Van: "Sanne Grinovero" Aan: "Mark Rotteveel" CC: "Hibernate.org" Onderwerp: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL Datum: di, feb. 7, 2017 18:08 merged it, and promoted your JIRA account so you can assign issues to yourself. Thanks! Sanne On 7 February 2017 at 15:58, Mark Rotteveel wrote: > Issue: https://hibernate.atlassian.net/browse/HHH-11467 > PR: https://github.com/hibernate/hibernate-orm/pull/1781 > > On 4-2-2017 15:05, Mark Rotteveel wrote: >> Firebird has a problem with some of the SQL generated by Hibernate, in >> some queries Hibernate appends StringHelper.WHITESPACE between >> conditions (specifically in CollectionBinder.bindFilters(boolean)). >> >> The problem is that StringHelper.WHITESPACE contains a formfeed (\f, >> 0x0C), and Firebird does not accept a formfeed as whitespace. >> >> It looks like the usage of StringHelper.WHITESPACE is wrong; the other >> places this constant is used is for splitting/tokenizing strings, and >> not for adding whitespace. >> >> Is there any objection if I replace the usage in >> CollectionBinder.bindFilters(boolean) with a single space (or maybe with >> " \n\t" to produce more similar SQL as previous)? >> >> Mark >> > > > -- > Mark Rotteveel > _______________________________________________ > 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 Feb 7 14:07:46 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 7 Feb 2017 20:07:46 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: <77ABC669-F7D9-4247-BAF0-BB6ED29155F0@hibernate.org> Message-ID: Hi, So, apparently, people didn't like internal in the groupId so we ended up with org.hibernate.infra which was one of the groupIds suggested by Emmanuel. The Asciidoctor theme is here: https://github.com/hibernate/hibernate-asciidoctor-theme . I just pushed the first version to our Nexus so I will start pushing the PR to all the NoORM projects. -- Guillaume On Tue, Feb 7, 2017 at 12:03 PM, Guillaume Smet wrote: > Hi, > > On Mon, Feb 6, 2017 at 4:21 PM, Emmanuel Bernard > wrote: > >> On the license, I think ASL 2.0 is the best for such project. >> > > As we discussed it in Lisbon, we might "copy" (using Maven) sources from > an internal utility project to the NoORM projects, as we want to avoid > dependency hell with different versions of the utilities. In this case, > they might be included in the source jar. Thus, I think the best is to dual > license everything from the start. > > I'll go do that. > > >> On the group id, am I right that this project is some utilities used by >> us internally? And would not be imported by a user? >> >> If true then I?d avoid common as it feels like something that a user >> would import. internal could work. Some other proposal (to be combined or >> not): >> - utilities >> - infra >> - toolbox >> > > OK, if internal works for you, let's settle on it. It's widely used in the > Java world to name internal packages. It makes perfect sense here. > > >> On the theme, I don't have a definitive opinion but I think like >> Guillaume I?d prefer a lighter customized version of the default Asciidoc >> theme rather than the heavyweight one. >> > > OK, let's start with this to unblock the situation with OGM and Search. > ORM can still use part of the theme (the PDF goodies) and keep their CSS if > they prefer. And once they moved to use part of it, we can revisit and > adjust so that everyone is happy. It's not as if the changes were breaking > changes for the users, it won't be an issue to adjust one way or the other. > > -- > Guillaume > > From steve at hibernate.org Tue Feb 7 14:11:14 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 07 Feb 2017 19:11:14 +0000 Subject: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL In-Reply-To: <201702071751.v17HphOS031252@lists01.dmz-a.mwc.hst.phx2.redhat.com> References: <201702071751.v17HphOS031252@lists01.dmz-a.mwc.hst.phx2.redhat.com> Message-ID: >From which job? The JDK 9 one? Those failures you can ignore On Tue, Feb 7, 2017, 11:52 AM Mark Rotteveel wrote: > Thanks! > I just received a build failure notification with an > ExceptionInInitialiserError, but I can't see how my PR would introduce that > error. > > Any idea, or should I just ignore it? > > Mark > > ----- Bericht beantwoorden ----- > Van: "Sanne Grinovero" > Aan: "Mark Rotteveel" > CC: "Hibernate.org" > Onderwerp: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL > Datum: di, feb. 7, 2017 18:08 > > merged it, and promoted your JIRA account so you can assign issues to > yourself. > > Thanks! > Sanne > > On 7 February 2017 at 15:58, Mark Rotteveel wrote: > > Issue: https://hibernate.atlassian.net/browse/HHH-11467 > > PR: https://github.com/hibernate/hibernate-orm/pull/1781 > > > > On 4-2-2017 15:05, Mark Rotteveel wrote: > >> Firebird has a problem with some of the SQL generated by Hibernate, in > >> some queries Hibernate appends StringHelper.WHITESPACE between > >> conditions (specifically in CollectionBinder.bindFilters(boolean)). > >> > >> The problem is that StringHelper.WHITESPACE contains a formfeed (\f, > >> 0x0C), and Firebird does not accept a formfeed as whitespace. > >> > >> It looks like the usage of StringHelper.WHITESPACE is wrong; the other > >> places this constant is used is for splitting/tokenizing strings, and > >> not for adding whitespace. > >> > >> Is there any objection if I replace the usage in > >> CollectionBinder.bindFilters(boolean) with a single space (or maybe with > >> " \n\t" to produce more similar SQL as previous)? > >> > >> Mark > >> > > > > > > -- > > Mark Rotteveel > > _______________________________________________ > > 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 mark at lawinegevaar.nl Tue Feb 7 15:32:05 2017 From: mark at lawinegevaar.nl (=?utf-8?B?TWFyayBSb3R0ZXZlZWw=?=) Date: Tue, 07 Feb 2017 21:32:05 +0100 Subject: [hibernate-dev] =?utf-8?q?Form-feed_=28=5Cf_0x0C=29_in_generated_?= =?utf-8?q?SQL?= Message-ID: <201702072032.v17KW7Lw014745@lists01.dmz-a.mwc.hst.phx2.redhat.com> Yes, it is the jdk9 job. Sorry, that I forgot to include that info. Mark ----- Bericht beantwoorden ----- Van: "Steve Ebersole" Aan: "Mark Rotteveel" , "Sanne Grinovero" CC: "Hibernate.org" Onderwerp: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL Datum: di, feb. 7, 2017 20:11 From which job? The JDK 9 one?? Those failures you can ignore On Tue, Feb 7, 2017, 11:52 AM Mark Rotteveel wrote: Thanks! I just received a build failure notification with an ExceptionInInitialiserError, but I can't see how my PR would introduce that error. Any idea, or should I just ignore it? Mark ----- Bericht beantwoorden ----- Van: "Sanne Grinovero" Aan: "Mark Rotteveel" CC: "Hibernate.org" Onderwerp: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL Datum: di, feb. 7, 2017 18:08 merged it, and promoted your JIRA account so you can assign issues to yourself. Thanks! Sanne On 7 February 2017 at 15:58, Mark Rotteveel wrote: > Issue: https://hibernate.atlassian.net/browse/HHH-11467 > PR: https://github.com/hibernate/hibernate-orm/pull/1781 > > On 4-2-2017 15:05, Mark Rotteveel wrote: >> Firebird has a problem with some of the SQL generated by Hibernate, in >> some queries Hibernate appends StringHelper.WHITESPACE between >> conditions (specifically in CollectionBinder.bindFilters(boolean)). >> >> The problem is that StringHelper.WHITESPACE contains a formfeed (\f, >> 0x0C), and Firebird does not accept a formfeed as whitespace. >> >> It looks like the usage of StringHelper.WHITESPACE is wrong; the other >> places this constant is used is for splitting/tokenizing strings, and >> not for adding whitespace. >> >> Is there any objection if I replace the usage in >> CollectionBinder.bindFilters(boolean) with a single space (or maybe with >> " \n\t" to produce more similar SQL as previous)? >> >> Mark >> > > > -- > Mark Rotteveel > _______________________________________________ > 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 Wed Feb 8 02:00:20 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 8 Feb 2017 09:00:20 +0200 Subject: [hibernate-dev] Refactor MySQL Dialects Message-ID: Hi, While working on MariaDB Dialects, I realize that we should also refactor the MySQL ones. The problem is that we introduced the InnoDB hierarchy. Since the only difference between those two is related to 3 methods, I think we should hide them behind a MySQLStorageEngine hierarchy with InnoDB being the default one. This way, we'll have a single MySQL Dialect hierarchy, and users can switch to MyISAM via a configuration property which define what MySQLStorageEngine implementation we are using. Let me know what you think. Vlad From emmanuel at hibernate.org Wed Feb 8 05:01:09 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 8 Feb 2017 11:01:09 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: <77ABC669-F7D9-4247-BAF0-BB6ED29155F0@hibernate.org> Message-ID: > On 7 Feb 2017, at 12:03, Guillaume Smet wrote: > > Hi, > > On Mon, Feb 6, 2017 at 4:21 PM, Emmanuel Bernard > wrote: > On the license, I think ASL 2.0 is the best for such project. > > As we discussed it in Lisbon, we might "copy" (using Maven) sources from an internal utility project to the NoORM projects, as we want to avoid dependency hell with different versions of the utilities. In this case, they might be included in the source jar. Thus, I think the best is to dual license everything from the start. > > I'll go do that. For your info, having ASL licensed files side by side LGPL code is fine. Just make sure that each ASL file retains their copyright and license headers. The Apache Software Foundation has stricter rules for its projects consuming other licenses than what the license text says. But dual licensing works. From emmanuel at hibernate.org Wed Feb 8 05:04:17 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 8 Feb 2017 11:04:17 +0100 Subject: [hibernate-dev] [HV/HSEARCH] Free form In-Reply-To: References: <452FAF91-6C62-44E9-86E5-4CB1B7726460@hibernate.org> <1C4DDF41-A476-4018-BBDF-38C249EBA2B1@hibernate.org> Message-ID: <3A6DCDAE-8A78-4F60-899E-8B45D1C857CF@hibernate.org> > On 7 Feb 2017, at 11:17, Gunnar Morling wrote: > > Emmanuel, > > In your PoC, how would a complete tree-like structure be traversed? > It's not clear to me, who is driving StructureTraverser, i.e. which > component will call processSubstructureInContainer() et al. when > traversing an entire tree. The metadata you have about which entity and property is indexed will drive the traversal. In case of HV, the metadata about which entity / property is constrained will. The metadata is a separate model because: 1. some structures like JSON have no real model 2. we still need additional information like @Field, @Valid etc as part of our metadata to drive navigation From emmanuel at hibernate.org Wed Feb 8 05:11:58 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 8 Feb 2017 11:11:58 +0100 Subject: [hibernate-dev] Behaviour of validation mode "auto" in case of error during validator factory bootstrap In-Reply-To: References: <1D3918AA-6174-4A06-AF02-7FD6B3C7A865@hibernate.org> Message-ID: <6A37A2A0-D9E9-40B9-8EED-BB0FC1BDA0C0@hibernate.org> Sounds good to me. > On 7 Feb 2017, at 11:53, Gunnar Morling wrote: > > So the issue is a more general one than I thought. > > We'll run into the same situation, too, when there is an error in BV's > validation.xml or any constraint mapping file (e.g. a reference to a > non-existent MessageInterpolator). That error will currently be > suppressed with validation-mode auto. > > I'm wondering whether in BV 2.0 we should define a new sub-type of > ValidationException: NoProviderFoundException which is raised by > javax.validation.Validation in case no BV provider is found. > > Then JPA/ORM could specifically ignore this exception in > validation-mode auto but let all other exceptions bubble up, letting > the user know early on about any issues they have with their > validation provider or its config. > > Thoughts? > > > > > 2017-02-06 15:53 GMT+01:00 Emmanuel Bernard : >> +1 to fail fast with the explicit error in that case. >> >>> On 1 Feb 2017, at 11:33, Gunnar Morling wrote: >>> >>> Hi, >>> >>> JPA defines for validation mode "auto" that bean validation must occur >>> if a BV provider is present and that no validation shall occur >>> otherwise. >>> >>> What should happen though if a BV provider such as HV is present but >>> it fails to bootstrap? In case of HV this happens if no expression >>> language implementation can be found. >>> >>> Currently, the user has a very hard time to find out about this, as >>> this exception essentially is suppressed (for mode "callback" the >>> exception is raised). >>> >>> Should we raise a specific exception in HV if it cannot be >>> bootstrapped? In ORM, we could handle that one specifically and raise >>> it also if for validation mode "auto" (would have to happen >>> reflectively, though, as to avoid a hard dependency). >>> >>> I can do this change but first wanted to make sure that this is inline >>> with what you all think should be done. >>> >>> Thanks, >>> >>> --Gunnar >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> From marcello74 at gmail.com Wed Feb 8 15:11:49 2017 From: marcello74 at gmail.com (Marcello Romano) Date: Wed, 8 Feb 2017 15:11:49 -0500 Subject: [hibernate-dev] Issue with unidirectional one-to-many association with a join column that references a column that is not the primary key Message-ID: Hi, A one-to-many association is causing Hibernate to throw the following exception when loading an entity via Session.get(domainClass, identifier), under the following conditions: 1. the association collection is annotated with @Fetch(FetchMode.JOIN) 2. the association's join column is referencing a non-primary key of the owning entity 3. the association's join column value is referencing a non-existing record of the associated table (the "many" side). Caused by: org.hibernate.property.access.spi.PropertyAccessException: Error accessing field [protected java.lang.Long ...] by reflection for persistent property [...] : 1GBE4E1E04 at org.hibernate.property.access.spi.GetterFieldImpl.get(GetterFieldImpl.java:43) at org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValue(AbstractComponentTuplizer.java:58) at org.hibernate.type.ComponentType.getPropertyValue(ComponentType.java:419) at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:242) at org.hibernate.engine.spi.CollectionKey.generateHashCode(CollectionKey.java:64) at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:58) at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:43) at org.hibernate.engine.loading.internal.CollectionLoadContext.getLoadingCollection(CollectionLoadContext.java:95) at org.hibernate.loader.plan.exec.process.internal.CollectionReferenceInitializerImpl.finishUpRow(CollectionReferenceInitializerImpl.java:105) at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow(AbstractRowReader.java:121) at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails$EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:239) at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:122) at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:122) at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:86) at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:167) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3967) at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:508) at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:478) at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) at org.hibernate.internal.SessionImpl.access$2600(SessionImpl.java:164) at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2696) at org.hibernate.internal.SessionImpl.get(SessionImpl.java:975) ... Caused by: java.lang.IllegalArgumentException: Can not set ... to java.lang.String at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:55) at sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:36) at java.lang.reflect.Field.get(Field.java:379) at org.hibernate.property.access.spi.GetterFieldImpl.get(GetterFieldImpl.java:39) ... 44 more The problem is that when initializing the collection, Hibernate is not able to retrieve the association key value in CollectionReferenceInitializerImpl.finishUpRow and will fall back to use the entity owner's primary key instead, causing the IllegalArgumentException. We have noticed that there is a related open issue: https://hibernate.atlassian.net/browse/HHH-9370 We have worked around this issue by changing the way optionalKey is retrieved in CollectionReferenceInitializerImpl.finishUpRow, foreignKeyPropertyName ); ResultSetProcessingContext.EntityReferenceProcessingState ownerState = context.getOwnerProcessingState( (Fetch) collectionReference ); Serializable optionalKey = collectionReference.getCollectionPersister().getCollectionType().getKeyOfOwner(ownerState.getEntityInstance(), context.getSession()); Although this seems to work for us, we would like to collaborate to have this fixed upstream, if you believe this is actually caused by a bug and not by using Hibernate associations in the wrong way. Thanks, Marcello From mihalcea.vlad at gmail.com Wed Feb 8 15:35:48 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 8 Feb 2017 22:35:48 +0200 Subject: [hibernate-dev] Issue with unidirectional one-to-many association with a join column that references a column that is not the primary key In-Reply-To: References: Message-ID: Hi, You can send us a Pull Request on GitHub with a test case that replicates it, so we can discuss and integrate it. Vlad On Wed, Feb 8, 2017 at 10:11 PM, Marcello Romano wrote: > Hi, > > A one-to-many association is causing Hibernate to > throw the following exception when loading an entity via > Session.get(domainClass, identifier), under the following conditions: > > 1. the association collection is annotated with @Fetch(FetchMode.JOIN) > 2. the association's join column is referencing a non-primary key of the > owning entity > 3. the association's join column value is referencing a non-existing record > of the associated table (the "many" side). > > Caused by: org.hibernate.property.access.spi.PropertyAccessException: > Error > accessing field [protected java.lang.Long ...] by reflection for persistent > property [...] : 1GBE4E1E04 > at > org.hibernate.property.access.spi.GetterFieldImpl.get( > GetterFieldImpl.java:43) > at > org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValue( > AbstractComponentTuplizer.java:58) > at org.hibernate.type.ComponentType.getPropertyValue( > ComponentType.java:419) > at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:242) > at > org.hibernate.engine.spi.CollectionKey.generateHashCode( > CollectionKey.java:64) > at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:58) > at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:43) > at > org.hibernate.engine.loading.internal.CollectionLoadContext. > getLoadingCollection(CollectionLoadContext.java:95) > at > org.hibernate.loader.plan.exec.process.internal. > CollectionReferenceInitializerImpl.finishUpRow( > CollectionReferenceInitializerImpl.java:105) > at > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow( > AbstractRowReader.java:121) > at > org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails$ > EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:239) > at > org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl. > extractResults(ResultSetProcessorImpl.java:122) > at > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader. > executeLoad(AbstractLoadPlanBasedLoader.java:122) > at > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader. > executeLoad(AbstractLoadPlanBasedLoader.java:86) > at > org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load( > AbstractLoadPlanBasedEntityLoader.java:167) > at > org.hibernate.persister.entity.AbstractEntityPersister.load( > AbstractEntityPersister.java:3967) > at > org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource( > DefaultLoadEventListener.java:508) > at > org.hibernate.event.internal.DefaultLoadEventListener.doLoad( > DefaultLoadEventListener.java:478) > at > org.hibernate.event.internal.DefaultLoadEventListener.load( > DefaultLoadEventListener.java:219) > at > org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad( > DefaultLoadEventListener.java:278) > at > org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad( > DefaultLoadEventListener.java:121) > at > org.hibernate.event.internal.DefaultLoadEventListener.onLoad( > DefaultLoadEventListener.java:89) > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) > at org.hibernate.internal.SessionImpl.access$2600(SessionImpl.java:164) > at > org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load( > SessionImpl.java:2696) > at org.hibernate.internal.SessionImpl.get(SessionImpl.java:975) > ... > Caused by: java.lang.IllegalArgumentException: Can not set ... to > java.lang.String > at > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentExcepti > on(UnsafeFieldAccessorImpl.java:164) > at > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentExcepti > on(UnsafeFieldAccessorImpl.java:168) > at > sun.reflect.UnsafeFieldAccessorImpl.ensureObj( > UnsafeFieldAccessorImpl.java:55) > at > sun.reflect.UnsafeObjectFieldAccessorImpl.get( > UnsafeObjectFieldAccessorImpl.java:36) > at java.lang.reflect.Field.get(Field.java:379) > at > org.hibernate.property.access.spi.GetterFieldImpl.get( > GetterFieldImpl.java:39) > ... 44 more > > > The problem is that when initializing the collection, Hibernate is not able > to retrieve the association key value in > CollectionReferenceInitializerImpl.finishUpRow and will fall back to use > the entity owner's primary key instead, causing the > IllegalArgumentException. > > We have noticed that there is a related open issue: > https://hibernate.atlassian.net/browse/HHH-9370 > > We have worked around this issue by changing the way optionalKey is > retrieved in CollectionReferenceInitializerImpl.finishUpRow, > foreignKeyPropertyName ); > > ResultSetProcessingContext.EntityReferenceProcessingState ownerState = > context.getOwnerProcessingState( (Fetch) collectionReference ); > Serializable optionalKey = > collectionReference.getCollectionPersister().getCollectionType(). > getKeyOfOwner(ownerState.getEntityInstance(), > context.getSession()); > > > Although this seems to work for us, we would like to collaborate to have > this fixed upstream, if you believe this is actually caused by a bug and > not by using Hibernate associations in the wrong way. > > Thanks, > Marcello > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From marcello74 at gmail.com Wed Feb 8 19:25:15 2017 From: marcello74 at gmail.com (Marcello Romano) Date: Wed, 8 Feb 2017 19:25:15 -0500 Subject: [hibernate-dev] Issue with unidirectional one-to-many association with a join column that references a column that is not the primary key In-Reply-To: References: Message-ID: Hi Vlad, I have created the following pull request with the test case: https://github.com/hibernate/hibernate-orm/pull/1786 Thanks, Marcello On 8 February 2017 at 15:35, Vlad Mihalcea wrote: > Hi, > > You can send us a Pull Request on GitHub with a test case that replicates > it, so we can discuss and integrate it. > > Vlad > > On Wed, Feb 8, 2017 at 10:11 PM, Marcello Romano > wrote: > >> Hi, >> >> A one-to-many association is causing Hibernate to >> throw the following exception when loading an entity via >> Session.get(domainClass, identifier), under the following conditions: >> >> 1. the association collection is annotated with @Fetch(FetchMode.JOIN) >> 2. the association's join column is referencing a non-primary key of the >> owning entity >> 3. the association's join column value is referencing a non-existing >> record >> of the associated table (the "many" side). >> >> Caused by: org.hibernate.property.access.spi.PropertyAccessException: >> Error >> accessing field [protected java.lang.Long ...] by reflection for >> persistent >> property [...] : 1GBE4E1E04 >> at >> org.hibernate.property.access.spi.GetterFieldImpl.get(Getter >> FieldImpl.java:43) >> at >> org.hibernate.tuple.component.AbstractComponentTuplizer.getP >> ropertyValue(AbstractComponentTuplizer.java:58) >> at org.hibernate.type.ComponentType.getPropertyValue(ComponentT >> ype.java:419) >> at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:242) >> at >> org.hibernate.engine.spi.CollectionKey.generateHashCode(Coll >> ectionKey.java:64) >> at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:58) >> at org.hibernate.engine.spi.CollectionKey.(CollectionKey.java:43) >> at >> org.hibernate.engine.loading.internal.CollectionLoadContext. >> getLoadingCollection(CollectionLoadContext.java:95) >> at >> org.hibernate.loader.plan.exec.process.internal.CollectionRe >> ferenceInitializerImpl.finishUpRow(CollectionReferenc >> eInitializerImpl.java:105) >> at >> org.hibernate.loader.plan.exec.process.internal.AbstractRowR >> eader.readRow(AbstractRowReader.java:121) >> at >> org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetai >> ls$EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:239) >> at >> org.hibernate.loader.plan.exec.process.internal.ResultSetPro >> cessorImpl.extractResults(ResultSetProcessorImpl.java:122) >> at >> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBase >> dLoader.executeLoad(AbstractLoadPlanBasedLoader.java:122) >> at >> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBase >> dLoader.executeLoad(AbstractLoadPlanBasedLoader.java:86) >> at >> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntity >> Loader.load(AbstractLoadPlanBasedEntityLoader.java:167) >> at >> org.hibernate.persister.entity.AbstractEntityPersister.load( >> AbstractEntityPersister.java:3967) >> at >> org.hibernate.event.internal.DefaultLoadEventListener.loadFr >> omDatasource(DefaultLoadEventListener.java:508) >> at >> org.hibernate.event.internal.DefaultLoadEventListener.doLoad >> (DefaultLoadEventListener.java:478) >> at >> org.hibernate.event.internal.DefaultLoadEventListener.load(D >> efaultLoadEventListener.java:219) >> at >> org.hibernate.event.internal.DefaultLoadEventListener.proxyO >> rLoad(DefaultLoadEventListener.java:278) >> at >> org.hibernate.event.internal.DefaultLoadEventListener.doOnLo >> ad(DefaultLoadEventListener.java:121) >> at >> org.hibernate.event.internal.DefaultLoadEventListener.onLoad >> (DefaultLoadEventListener.java:89) >> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) >> at org.hibernate.internal.SessionImpl.access$2600(SessionImpl.java:164) >> at >> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl. >> load(SessionImpl.java:2696) >> at org.hibernate.internal.SessionImpl.get(SessionImpl.java:975) >> ... >> Caused by: java.lang.IllegalArgumentException: Can not set ... to >> java.lang.String >> at >> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException( >> UnsafeFieldAccessorImpl.java:164) >> at >> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException( >> UnsafeFieldAccessorImpl.java:168) >> at >> sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAcc >> essorImpl.java:55) >> at >> sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFi >> eldAccessorImpl.java:36) >> at java.lang.reflect.Field.get(Field.java:379) >> at >> org.hibernate.property.access.spi.GetterFieldImpl.get(Getter >> FieldImpl.java:39) >> ... 44 more >> >> >> The problem is that when initializing the collection, Hibernate is not >> able >> to retrieve the association key value in >> CollectionReferenceInitializerImpl.finishUpRow and will fall back to use >> the entity owner's primary key instead, causing the >> IllegalArgumentException. >> >> We have noticed that there is a related open issue: >> https://hibernate.atlassian.net/browse/HHH-9370 >> >> We have worked around this issue by changing the way optionalKey is >> retrieved in CollectionReferenceInitializerImpl.finishUpRow, >> foreignKeyPropertyName ); >> >> ResultSetProcessingContext.EntityReferenceProcessingState ownerState = >> context.getOwnerProcessingState( (Fetch) collectionReference ); >> Serializable optionalKey = >> collectionReference.getCollectionPersister().getCollectionTy >> pe().getKeyOfOwner(ownerState.getEntityInstance(), >> context.getSession()); >> >> >> Although this seems to work for us, we would like to collaborate to have >> this fixed upstream, if you believe this is actually caused by a bug and >> not by using Hibernate associations in the wrong way. >> >> Thanks, >> Marcello >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From steve at hibernate.org Thu Feb 9 08:28:48 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 09 Feb 2017 13:28:48 +0000 Subject: [hibernate-dev] Refactor MySQL Dialects In-Reply-To: References: Message-ID: That is a good solution for now. Ultimately I think we still want to add some capability for Dialects to configure either themselves or the things they return based on Connection, env, etc. It's something we have discussed for some time. On Wed, Feb 8, 2017 at 1:01 AM Vlad Mihalcea wrote: > Hi, > > While working on MariaDB Dialects, I realize that we should also refactor > the MySQL ones. > The problem is that we introduced the InnoDB hierarchy. > > Since the only difference between those two is related to 3 methods, I > think we should hide them behind a MySQLStorageEngine hierarchy with InnoDB > being the default one. > This way, we'll have a single MySQL Dialect hierarchy, and users can switch > to MyISAM via a configuration property which define what MySQLStorageEngine > implementation we are using. > > 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 mihalcea.vlad at gmail.com Thu Feb 9 08:42:55 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 9 Feb 2017 15:42:55 +0200 Subject: [hibernate-dev] Refactor MySQL Dialects In-Reply-To: References: Message-ID: I created a Pull Request for this: https://github.com/hibernate/hibernate-orm/pull/1787 If you think we should not make this change, then I can close it. However, I think it's much easier if we have a single hierarchy in the MySQL Dialects. Vlad On Thu, Feb 9, 2017 at 3:28 PM, Steve Ebersole wrote: > That is a good solution for now. > > Ultimately I think we still want to add some capability for Dialects to > configure either themselves or the things they return based on Connection, > env, etc. It's something we have discussed for some time. > > On Wed, Feb 8, 2017 at 1:01 AM Vlad Mihalcea > wrote: > >> Hi, >> >> While working on MariaDB Dialects, I realize that we should also refactor >> the MySQL ones. >> The problem is that we introduced the InnoDB hierarchy. >> >> Since the only difference between those two is related to 3 methods, I >> think we should hide them behind a MySQLStorageEngine hierarchy with >> InnoDB >> being the default one. >> This way, we'll have a single MySQL Dialect hierarchy, and users can >> switch >> to MyISAM via a configuration property which define what >> MySQLStorageEngine >> implementation we are using. >> >> 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 mark at lawinegevaar.nl Sat Feb 11 09:28:22 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sat, 11 Feb 2017 15:28:22 +0100 Subject: [hibernate-dev] SUBSTRING example in documentation uses start position 0 instead of 1. Message-ID: I'm still working on getting tests working for Firebird. One of the tests that fails is the documentation test org.hibernate.userguide.hql.HQLTest.test_hql_substring_function_example The reason this test fails is that Firebird hasn't implemented the SQL:2011 requirement that start positions lower than 1 should be handled as 1. See: http://tracker.firebirdsql.org/browse/CORE-5480 The example code is: List prefixes = entityManager.createQuery( "select substring( p.number, 0, 2 ) " + "from Call c " + "join c.phone p", String.class ) .getResultList(); However this example is slightly confusing in that it implies that start position is 0-based, while both SQL and JPA 2.1 (section 4.6.17.2.1) make clear it should be 1-based. Any objections if I prepare a pull request to change this example to use 1 and the related documentation to specify that start position is 1-based? Or is there a specific reason this example uses 0? Mark -- Mark Rotteveel From mihalcea.vlad at gmail.com Sat Feb 11 09:56:57 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Sat, 11 Feb 2017 16:56:57 +0200 Subject: [hibernate-dev] SUBSTRING example in documentation uses start position 0 instead of 1. In-Reply-To: References: Message-ID: Hi Mark, Good catch. We should change it to 1, instead of 0. Vlad On Sat, Feb 11, 2017 at 4:28 PM, Mark Rotteveel wrote: > I'm still working on getting tests working for Firebird. > > One of the tests that fails is the documentation test > org.hibernate.userguide.hql.HQLTest.test_hql_substring_function_example > > The reason this test fails is that Firebird hasn't implemented the > SQL:2011 requirement that start positions lower than 1 should be handled > as 1. See: http://tracker.firebirdsql.org/browse/CORE-5480 > > The example code is: > > List prefixes = entityManager.createQuery( > "select substring( p.number, 0, 2 ) " + > "from Call c " + > "join c.phone p", String.class ) > .getResultList(); > > However this example is slightly confusing in that it implies that start > position is 0-based, while both SQL and JPA 2.1 (section 4.6.17.2.1) > make clear it should be 1-based. > > Any objections if I prepare a pull request to change this example to use > 1 and the related documentation to specify that start position is 1-based? > > Or is there a specific reason this example uses 0? > > Mark > -- > Mark Rotteveel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mark at lawinegevaar.nl Sat Feb 11 10:10:36 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sat, 11 Feb 2017 16:10:36 +0100 Subject: [hibernate-dev] SUBSTRING example in documentation uses start position 0 instead of 1. In-Reply-To: References: Message-ID: <52422f79-8606-d26b-b69e-3366e56e3501@lawinegevaar.nl> On 11-2-2017 15:56, Vlad Mihalcea wrote: > Hi Mark, > > Good catch. We should change it to 1, instead of 0. I created https://hibernate.atlassian.net/browse/HHH-11482, will post a PR later (hopefully this weekend). Mark -- Mark Rotteveel From mihalcea.vlad at gmail.com Sat Feb 11 10:14:58 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Sat, 11 Feb 2017 17:14:58 +0200 Subject: [hibernate-dev] SUBSTRING example in documentation uses start position 0 instead of 1. In-Reply-To: <52422f79-8606-d26b-b69e-3366e56e3501@lawinegevaar.nl> References: <52422f79-8606-d26b-b69e-3366e56e3501@lawinegevaar.nl> Message-ID: Thanks a lot. Vlad On Sat, Feb 11, 2017 at 5:10 PM, Mark Rotteveel wrote: > On 11-2-2017 15:56, Vlad Mihalcea wrote: > >> Hi Mark, >> >> Good catch. We should change it to 1, instead of 0. >> > > I created https://hibernate.atlassian.net/browse/HHH-11482, will post a > PR later (hopefully this weekend). > > Mark > -- > Mark Rotteveel > From mark at lawinegevaar.nl Sat Feb 11 12:17:28 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sat, 11 Feb 2017 18:17:28 +0100 Subject: [hibernate-dev] SUBSTRING example in documentation uses start position 0 instead of 1. In-Reply-To: <52422f79-8606-d26b-b69e-3366e56e3501@lawinegevaar.nl> References: <52422f79-8606-d26b-b69e-3366e56e3501@lawinegevaar.nl> Message-ID: <13c8d43d-0658-bcbe-166b-429c464dd85a@lawinegevaar.nl> On 11-2-2017 16:10, Mark Rotteveel wrote: > On 11-2-2017 15:56, Vlad Mihalcea wrote: >> Hi Mark, >> >> Good catch. We should change it to 1, instead of 0. > > I created https://hibernate.atlassian.net/browse/HHH-11482, will post a > PR later (hopefully this weekend). Pull request: https://github.com/hibernate/hibernate-orm/pull/1792 Mark -- Mark Rotteveel From mihalcea.vlad at gmail.com Mon Feb 13 02:40:11 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 13 Feb 2017 09:40:11 +0200 Subject: [hibernate-dev] @Filter does not apply to direct entity fetching Message-ID: Hi, I got the following question on StackOverflow: http://stackoverflow.com/questions/42173894/hibernate-enablefilter-not-working-when-loading-entity-by-id/42197922#42197922 and it looks like a @Filter that's enabled for the current Session only applies to entity queries, but not to direct fetching (loading the entity by its identifier). Is this a bug, or was it intended to work like that? Vlad From guillaume.smet at gmail.com Mon Feb 13 06:05:21 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 13 Feb 2017 12:05:21 +0100 Subject: [hibernate-dev] JDK 9 EA Build 155 is available on java.net In-Reply-To: <67e544ca-0401-af9d-f8fa-646650c5c04f@oracle.com> References: <67e544ca-0401-af9d-f8fa-646650c5c04f@oracle.com> Message-ID: Hello Rory, I just tried updating our build of Hibernate Validator to b156 and I discovered this one: https://bugs.openjdk.java.net/browse/JDK-8173604 . I was surprised to see the module renaming from java.annotations.common to java.xml.ws.annotation considering this module contains the @Generated annotation, which is pretty... mmmh... common and not really related to XML or webservices. I also fail to see how @PostConstruct, @PreDestroy or @Resource are related to XML or webservices in any way. By the way, I think it's going to be a breaking change for a lot of projects. See https://github.com/ops4j/org.ops4j.pax.exam2/blob/master/containers/pax-exam-container-karaf/src/main/java/org/ops4j/pax/exam/karaf/container/internal/runner/KarafJavaRunner.java#L63 for instance. Could you explain us the rationale of this renaming? It's looks pretty far fetched from here. Thanks! -- Guillaume On Fri, Feb 3, 2017 at 10:16 PM, Rory O'Donnell wrote: > > Hi Sanne, > > *JDK 9 Early Access* b155 is > available on java.net > > > There have been a number of fixes to bugs reported by Open Source > projects since the last availability email : > > * b155 - JDK-8167273 : Calendar.getDisplayNames inconsistent with > DateFormatSymbols > * b154 - JDK-8157611 : field visiblePackages is null for the unnamed > module producing NPE when accessed > * b153 - JDK-8163449 : Allow per protocol setting for URLConnection > defaultUseCaches > * b152 - JDK-8172158 : Annotation processor not run with -source <= 8 > > > Dalibor and I are presenting at FOSDEM this weekend, we would love to > meet you there! > > * JDK 9 Outreach - The Awesome Parts > > > > Rgds,Rory > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From rory.odonnell at oracle.com Mon Feb 13 06:47:24 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 13 Feb 2017 11:47:24 +0000 Subject: [hibernate-dev] JDK 9 EA Build 155 is available on java.net In-Reply-To: References: <67e544ca-0401-af9d-f8fa-646650c5c04f@oracle.com> Message-ID: Hi Guillaume, It would be great if you could open a thread on jigsaw-dev mailing list on this topic ? Rgds,Rory On 13/02/2017 11:05, Guillaume Smet wrote: > Hello Rory, > > I just tried updating our build of Hibernate Validator to b156 and I > discovered this one: https://bugs.openjdk.java.net/browse/JDK-8173604 . > > I was surprised to see the module renaming from > java.annotations.common to java.xml.ws.annotation considering this > module contains the @Generated annotation, which is pretty... mmmh... > common and not really related to XML or webservices. I also fail to > see how @PostConstruct, @PreDestroy or @Resource are related to XML or > webservices in any way. > > By the way, I think it's going to be a breaking change for a lot of > projects. See > https://github.com/ops4j/org.ops4j.pax.exam2/blob/master/containers/pax-exam-container-karaf/src/main/java/org/ops4j/pax/exam/karaf/container/internal/runner/KarafJavaRunner.java#L63 > for instance. > > Could you explain us the rationale of this renaming? It's looks pretty > far fetched from here. > > Thanks! > > -- > Guillaume > > On Fri, Feb 3, 2017 at 10:16 PM, Rory O'Donnell > > wrote: > > > Hi Sanne, > > *JDK 9 Early Access* b155 > is > available on java.net > > > There have been a number of fixes to bugs reported by Open Source > projects since the last availability email : > > * b155 - JDK-8167273 : Calendar.getDisplayNames inconsistent with > DateFormatSymbols > * b154 - JDK-8157611 : field visiblePackages is null for the unnamed > module producing NPE when accessed > * b153 - JDK-8163449 : Allow per protocol setting for URLConnection > defaultUseCaches > * b152 - JDK-8172158 : Annotation processor not run with -source > <= 8 > > > Dalibor and I are presenting at FOSDEM this weekend, we would love to > meet you there! > > * JDK 9 Outreach - The Awesome Parts > > > > > Rgds,Rory > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From guillaume.smet at gmail.com Mon Feb 13 07:51:42 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 13 Feb 2017 13:51:42 +0100 Subject: [hibernate-dev] JDK 9 EA Build 155 is available on java.net In-Reply-To: References: <67e544ca-0401-af9d-f8fa-646650c5c04f@oracle.com> Message-ID: Hi Rory, Will do, thanks! On Mon, Feb 13, 2017 at 12:47 PM, Rory O'Donnell wrote: > Hi Guillaume, > > It would be great if you could open a thread on jigsaw-dev mailing list on > this topic ? > > Rgds,Rory > From steve at hibernate.org Mon Feb 13 07:59:20 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 13 Feb 2017 12:59:20 +0000 Subject: [hibernate-dev] @Filter does not apply to direct entity fetching In-Reply-To: References: Message-ID: It is designed to work that way. On Mon, Feb 13, 2017 at 1:43 AM Vlad Mihalcea wrote: > Hi, > > I got the following question on StackOverflow: > > > http://stackoverflow.com/questions/42173894/hibernate-enablefilter-not-working-when-loading-entity-by-id/42197922#42197922 > > and it looks like a @Filter that's enabled for the current Session only > applies to entity queries, but not to direct fetching (loading the entity > by its identifier). > > Is this a bug, or was it intended to work like that? > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From andrea at hibernate.org Mon Feb 13 08:40:26 2017 From: andrea at hibernate.org (andrea boriero) Date: Mon, 13 Feb 2017 13:40:26 +0000 Subject: [hibernate-dev] @Filter does not apply to direct entity fetching In-Reply-To: References: Message-ID: Vlad, it would be great to add this info to the documentation. On 13 February 2017 at 12:59, Steve Ebersole wrote: > It is designed to work that way. > > On Mon, Feb 13, 2017 at 1:43 AM Vlad Mihalcea > wrote: > > > Hi, > > > > I got the following question on StackOverflow: > > > > > > http://stackoverflow.com/questions/42173894/hibernate- > enablefilter-not-working-when-loading-entity-by-id/42197922#42197922 > > > > and it looks like a @Filter that's enabled for the current Session only > > applies to entity queries, but not to direct fetching (loading the entity > > by its identifier). > > > > Is this a bug, or was it intended to work like that? > > > > 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 mihalcea.vlad at gmail.com Mon Feb 13 08:49:49 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 13 Feb 2017 15:49:49 +0200 Subject: [hibernate-dev] @Filter does not apply to direct entity fetching In-Reply-To: References: Message-ID: All right. I'm going to add a task for it. On Mon, Feb 13, 2017 at 3:40 PM, andrea boriero wrote: > Vlad, it would be great to add this info to the documentation. > > On 13 February 2017 at 12:59, Steve Ebersole wrote: > >> It is designed to work that way. >> >> On Mon, Feb 13, 2017 at 1:43 AM Vlad Mihalcea >> wrote: >> >> > Hi, >> > >> > I got the following question on StackOverflow: >> > >> > >> > http://stackoverflow.com/questions/42173894/hibernate-enable >> filter-not-working-when-loading-entity-by-id/42197922#42197922 >> > >> > and it looks like a @Filter that's enabled for the current Session only >> > applies to entity queries, but not to direct fetching (loading the >> entity >> > by its identifier). >> > >> > Is this a bug, or was it intended to work like that? >> > >> > 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 guillaume.smet at gmail.com Tue Feb 14 10:01:52 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 14 Feb 2017 16:01:52 +0100 Subject: [hibernate-dev] Minutes of the NoORM IRC meeting Message-ID: Hi all, Here they are: 16:00 < jbott> Meeting ended Tue Feb 14 15:00:27 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:00 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-02-14-14.01.html 16:00 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-02-14-14.01.txt 16:00 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-02-14-14.01.log.html Have a nice day. -- Guillaume From davide at hibernate.org Wed Feb 15 11:11:49 2017 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 15 Feb 2017 16:11:49 +0000 Subject: [hibernate-dev] Hibernate OGM 5.1 CR1 is out! Message-ID: Good news! The first candidate release for Hibernate OGM 5.1 is out. Compared to 5.1 Beta3, this release upgrades Hibernate Search to version 5.5.6.Final and supports MongoDB aggregate operation in native queries. This means that now you can use Hibernate OGM to do CRUD operations on your favourite NoSQL database while having it also transparently synchronize to an Elasticsearch cluster. You can find all the details in the blog post: http://in.relation.to/2017/02/15/hibernate-ogm-5-1-cr1-released Thanks, Davide From gbadner at redhat.com Thu Feb 16 02:16:23 2017 From: gbadner at redhat.com (Gail Badner) Date: Wed, 15 Feb 2017 23:16:23 -0800 Subject: [hibernate-dev] DB2 cross joins Message-ID: HHH-11487 can be fixed by using changing DB2Dialect#getCrossJoinSeparator to return " cross join ". DB2 9.1 did not support CROSS JOIN, but DB2 9.5 and later do support CROSS JOIN. I see that DB2 9.1 is no longer supported as of April 30, 2015. It's tempting to just update DB2Dialect, but I suspect that would break existing applications still using DB2 9.1. I'm considering adding a new dialect DB295Dialect that extends DB2Dialect and overrides DB2Dialect#getCrossJoinSeparator to return "cross join". WDYT? Regards, Gail From christian.beikov at gmail.com Thu Feb 16 04:57:38 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Thu, 16 Feb 2017 10:57:38 +0100 Subject: [hibernate-dev] DB2 cross joins In-Reply-To: References: Message-ID: <9c941bac-01c7-2149-7018-c1c7b9b43e37@gmail.com> How about a different approach? Like passing the DB version somehow to the dialect so that it can decide for itself instead of having different subclasses. Am 16.02.2017 um 08:16 schrieb Gail Badner: > HHH-11487 can be fixed by using changing DB2Dialect#getCrossJoinSeparator > to return " cross join ". > > DB2 9.1 did not support CROSS JOIN, but DB2 9.5 and later do support CROSS > JOIN. I see that DB2 9.1 is no longer supported as of April 30, 2015. > > It's tempting to just update DB2Dialect, but I suspect that would break > existing applications still using DB2 9.1. > > I'm considering adding a new dialect DB295Dialect that extends DB2Dialect > and overrides DB2Dialect#getCrossJoinSeparator to return "cross join". > > WDYT? > > Regards, > Gail > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From crancran at gmail.com Thu Feb 16 09:23:33 2017 From: crancran at gmail.com (Chris Cranford) Date: Thu, 16 Feb 2017 09:23:33 -0500 Subject: [hibernate-dev] DB2 cross joins In-Reply-To: <9c941bac-01c7-2149-7018-c1c7b9b43e37@gmail.com> References: <9c941bac-01c7-2149-7018-c1c7b9b43e37@gmail.com> Message-ID: <6287e97e-52a7-25df-1c0d-ec4df3d70dca@gmail.com> We have actually discussed doing something where Dialect's auto-configure themselves, but such a change would likely be appropriate for a major release only. On 02/16/2017 04:57 AM, Christian Beikov wrote: > How about a different approach? Like passing the DB version somehow to > the dialect so that it can decide for itself instead of having different > subclasses. > > Am 16.02.2017 um 08:16 schrieb Gail Badner: >> HHH-11487 can be fixed by using changing DB2Dialect#getCrossJoinSeparator >> to return " cross join ". >> >> DB2 9.1 did not support CROSS JOIN, but DB2 9.5 and later do support CROSS >> JOIN. I see that DB2 9.1 is no longer supported as of April 30, 2015. >> >> It's tempting to just update DB2Dialect, but I suspect that would break >> existing applications still using DB2 9.1. >> >> I'm considering adding a new dialect DB295Dialect that extends DB2Dialect >> and overrides DB2Dialect#getCrossJoinSeparator to return "cross join". >> >> WDYT? >> >> Regards, >> Gail >> _______________________________________________ >> 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 Thu Feb 16 09:48:32 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 16 Feb 2017 14:48:32 +0000 Subject: [hibernate-dev] DB2 cross joins In-Reply-To: <6287e97e-52a7-25df-1c0d-ec4df3d70dca@gmail.com> References: <9c941bac-01c7-2149-7018-c1c7b9b43e37@gmail.com> <6287e97e-52a7-25df-1c0d-ec4df3d70dca@gmail.com> Message-ID: On 16 February 2017 at 14:23, Chris Cranford wrote: > We have actually discussed doing something where Dialect's auto-configure > themselves, but such a change would likely be appropriate for a major > release only. > > On 02/16/2017 04:57 AM, Christian Beikov wrote: >> How about a different approach? Like passing the DB version somehow to >> the dialect so that it can decide for itself instead of having different >> subclasses. People currently expect to be able to configure a Dialect by choosing a specific classname. I don't disagree on exploring evolutions, but indeed I'd not change such matters in a minor release; Gail needs a fix focusing on the cross join issue so a new class will suffice for the immediate need. >> >> Am 16.02.2017 um 08:16 schrieb Gail Badner: >>> HHH-11487 can be fixed by using changing DB2Dialect#getCrossJoinSeparator >>> to return " cross join ". >>> >>> DB2 9.1 did not support CROSS JOIN, but DB2 9.5 and later do support CROSS >>> JOIN. I see that DB2 9.1 is no longer supported as of April 30, 2015. >>> >>> It's tempting to just update DB2Dialect, but I suspect that would break >>> existing applications still using DB2 9.1. >>> >>> I'm considering adding a new dialect DB295Dialect that extends DB2Dialect >>> and overrides DB2Dialect#getCrossJoinSeparator to return "cross join". >>> >>> WDYT? +1 Thanks, Sanne >>> >>> Regards, >>> Gail >>> _______________________________________________ >>> 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 guillaume.smet at hibernate.org Thu Feb 16 09:51:38 2017 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Thu, 16 Feb 2017 15:51:38 +0100 Subject: [hibernate-dev] Hibernate Validator 6.0.0.Alpha1 is out with initial Bean Validation 2.0 support Message-ID: Hi, It's with great pleasure that I announce the release of Hibernate Validator 6.0.0.Alpha1. This release is coordinated with the Bean Validation 2.0 Early Draft 1 release that happened earlier this week [1]. Hibernate Validator 6 will be the reference implementation of Bean Validation 2.0, but it's also a place to experiment with the future additions to the spec. Apart from initial Bean Validation 2.0 support, this version comes with a lot of good things: - some Java 8 goodness, - nested type use constraints and nested cascaded validation - lambda based constraint definition - Duration support (and a much improved java.time support coming as part of Bean Validation 2.0) As explained in the announce on in.relation.to [2], we are looking forward to your feedback on these features. They might be refined and included in the next Bean Validation 2.0 iteration if they get enough traction. Have a nice day! [1] http://beanvalidation.org/news/2017/02/14/bean-validation-2-0-early-draft-released/ [2] http://in.relation.to/2017/02/16/hibernate-validator-600-alpha1-out/ From paranoiabla at gmail.com Thu Feb 16 10:42:39 2017 From: paranoiabla at gmail.com (Petar Tahchiev) Date: Thu, 16 Feb 2017 17:42:39 +0200 Subject: [hibernate-dev] HHH-11089 Message-ID: Hey guys, a while ago I opened this issue: https://hibernate.atlassian.net/browse/HHH-11089 which blocks me from using Hibernate with Oracle database (the well-known issue with 30 chars limit for table/column/foreignkey/indexkey names). While I managed to workaround the tablename/columnname by specifying a custom PhysicalNamingStrategy. I also created a custom ImplicitNamingStrategy, but figured out it is never invoked when I have already specified a name for the foreign-key/indexkey. It is only called when no name has been given for the foreign key or index. I made a pull request, and you guys asked for some improvements. Long-story-short I just committed my improvements: https://github.com/hibernate/hibernate-orm/pull/1564/commits/78edc44143e39b19668099ea57e9ccb1a3a02b13 to make sure that the implicit naming strategy is always invoked no matter if the user has specified a name for the foreign key or have omitted it. Can someone please review it? BTW I'm not able to build the 5.1 branch and my branch too because I get thousands of checkstyle violations in files that I haven't worked on. I also tried to exclude the checkstyle plugin but seems like my gradle knowledge wasn't enough. Thank you and keep up the good work :) -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 From steve at hibernate.org Thu Feb 16 10:45:51 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 16 Feb 2017 15:45:51 +0000 Subject: [hibernate-dev] DB2 cross joins In-Reply-To: References: <9c941bac-01c7-2149-7018-c1c7b9b43e37@gmail.com> <6287e97e-52a7-25df-1c0d-ec4df3d70dca@gmail.com> Message-ID: To Gail's specific question... As Sanne stated, a new Dialect is the only option IMO for the moment. But what Chris brings up is important, and something we really should start deciding. We have been discussing it off and on for 4-5 years. Dialects were originally designed to be inflexible. We can debate the merits of that decision, but it is what leads to the need for all these Dialect impls for seemingly trivial deviations. So there is also a long term discussion to be had here. However, it is not quite as cut-and-dried as you make out Sanne. Quite a few Dialects already "configure themselves" based on various things (e.g. take a look at the H2Dialect's ctor). The problem is that to-date there has not been a standard way to do that, especially in regards to gaining access to JDBC metadata as part of that self-config. The ideal solution would be to keep Dialects static/inflexible but to use that along with JDBC metadata to build a true understanding of how to interact with the database. Personally, I think it is easier to just simply let the Dialect configure itself. But there is a certain danger there, as there always is when completely changing the design of something, especially something that many many users use. We shall see that play out soon with Type :) On Thu, Feb 16, 2017 at 8:54 AM Sanne Grinovero wrote: > On 16 February 2017 at 14:23, Chris Cranford wrote: > > We have actually discussed doing something where Dialect's auto-configure > > themselves, but such a change would likely be appropriate for a major > > release only. > > > > On 02/16/2017 04:57 AM, Christian Beikov wrote: > >> How about a different approach? Like passing the DB version somehow to > >> the dialect so that it can decide for itself instead of having different > >> subclasses. > > People currently expect to be able to configure a Dialect by choosing > a specific classname. > > I don't disagree on exploring evolutions, but indeed I'd not change > such matters in a minor release; > > Gail needs a fix focusing on the cross join issue so a new class will > suffice for the immediate need. > > >> > >> Am 16.02.2017 um 08:16 schrieb Gail Badner: > >>> HHH-11487 can be fixed by using changing > DB2Dialect#getCrossJoinSeparator > >>> to return " cross join ". > >>> > >>> DB2 9.1 did not support CROSS JOIN, but DB2 9.5 and later do support > CROSS > >>> JOIN. I see that DB2 9.1 is no longer supported as of April 30, 2015. > >>> > >>> It's tempting to just update DB2Dialect, but I suspect that would break > >>> existing applications still using DB2 9.1. > >>> > >>> I'm considering adding a new dialect DB295Dialect that extends > DB2Dialect > >>> and overrides DB2Dialect#getCrossJoinSeparator to return "cross join". > >>> > >>> WDYT? > > +1 > > Thanks, > Sanne > > > >>> > >>> Regards, > >>> Gail > >>> _______________________________________________ > >>> 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 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Thu Feb 16 13:37:13 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 16 Feb 2017 10:37:13 -0800 Subject: [hibernate-dev] DB2 cross joins In-Reply-To: References: <9c941bac-01c7-2149-7018-c1c7b9b43e37@gmail.com> <6287e97e-52a7-25df-1c0d-ec4df3d70dca@gmail.com> Message-ID: In the short term (for master), I'll add new DB2 dialect. Thanks, Gail On Thu, Feb 16, 2017 at 7:45 AM, Steve Ebersole wrote: > To Gail's specific question... As Sanne stated, a new Dialect is the only > option IMO for the moment. > > But what Chris brings up is important, and something we really should start > deciding. We have been discussing it off and on for 4-5 years. > > Dialects were originally designed to be inflexible. We can debate the > merits of that decision, but it is what leads to the need for all these > Dialect impls for seemingly trivial deviations. So there is also a long > term discussion to be had here. > > However, it is not quite as cut-and-dried as you make out Sanne. Quite a > few Dialects already "configure themselves" based on various things (e.g. > take a look at the H2Dialect's ctor). The problem is that to-date there > has not been a standard way to do that, especially in regards to gaining > access to JDBC metadata as part of that self-config. The ideal solution > would be to keep Dialects static/inflexible but to use that along with JDBC > metadata to build a true understanding of how to interact with the > database. > > Personally, I think it is easier to just simply let the Dialect configure > itself. But there is a certain danger there, as there always is when > completely changing the design of something, especially something that many > many users use. We shall see that play out soon with Type :) > > On Thu, Feb 16, 2017 at 8:54 AM Sanne Grinovero > wrote: > > > On 16 February 2017 at 14:23, Chris Cranford wrote: > > > We have actually discussed doing something where Dialect's > auto-configure > > > themselves, but such a change would likely be appropriate for a major > > > release only. > > > > > > On 02/16/2017 04:57 AM, Christian Beikov wrote: > > >> How about a different approach? Like passing the DB version somehow to > > >> the dialect so that it can decide for itself instead of having > different > > >> subclasses. > > > > People currently expect to be able to configure a Dialect by choosing > > a specific classname. > > > > I don't disagree on exploring evolutions, but indeed I'd not change > > such matters in a minor release; > > > > Gail needs a fix focusing on the cross join issue so a new class will > > suffice for the immediate need. > > > > >> > > >> Am 16.02.2017 um 08:16 schrieb Gail Badner: > > >>> HHH-11487 can be fixed by using changing > > DB2Dialect#getCrossJoinSeparator > > >>> to return " cross join ". > > >>> > > >>> DB2 9.1 did not support CROSS JOIN, but DB2 9.5 and later do support > > CROSS > > >>> JOIN. I see that DB2 9.1 is no longer supported as of April 30, 2015. > > >>> > > >>> It's tempting to just update DB2Dialect, but I suspect that would > break > > >>> existing applications still using DB2 9.1. > > >>> > > >>> I'm considering adding a new dialect DB295Dialect that extends > > DB2Dialect > > >>> and overrides DB2Dialect#getCrossJoinSeparator to return "cross > join". > > >>> > > >>> WDYT? > > > > +1 > > > > Thanks, > > Sanne > > > > > > >>> > > >>> Regards, > > >>> Gail > > >>> _______________________________________________ > > >>> 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 > > _______________________________________________ > > 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 Thu Feb 16 14:17:39 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 16 Feb 2017 19:17:39 +0000 Subject: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules Message-ID: Hi all, I'm proposing the use of the `org.hibernate.lucene-modules` group id for the stuff which we'll be releasing from this repository: - https://github.com/hibernate/lucene-modules Context: Hibernate Search has been packaging Apache Lucene as a WildFly module, essentially including the Lucene modules as part of the Hibernate Search modules. We want to separate these modules, for various reasons; the main driver being the build of Infinispan is much simpler if they can source the Lucene modules "out of band" from the Search release version. Sometimes we need some more flexibility, and it's getting close to mission impossible to workaround the tight coupling. This might also help other projects use Lucene when not necessarily interested in Hibernate Search, or in using the Lucene versions which Search would allow (a subset of the Lucene releases). Finally, since we release these modules with name "org.apache.lucene", it might just make sense for them to be independent and just contain Apache Lucene. If you're interested more details, have a look at PR number 1: - https://github.com/hibernate/lucene-modules/pull/1/files In Hibernate Search this would imply: - https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 Thanks, Sanne From gbadner at redhat.com Thu Feb 16 18:18:29 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 16 Feb 2017 15:18:29 -0800 Subject: [hibernate-dev] Can someone confirm if DB2 9.5 supports "cross join"? Message-ID: I created HHH-11499 to create a new dialect for DB2 to use "cross join" syntax instead of "," (as is currently done in DB2Dialect). Although DB2 9.1 reached its end of life April 30, 2015, some applications may still be using that version, so I will create a new DB2 dialect that extends DB2Dialect and overrides getCrossJoinSeparator() to return " cross join ". The question is what to call the new dialect. According to DB2 9.5 and 9.7 documentation, "cross join" syntax is supported in those versions. I am able to confirm this on 9.7, but I do not have access to DB2 9.5 to try it out. If someone can confirm this will work on DB2 9.5 by the time Hibernate 5.2.9 is released, then I'll name the new dialect DB295Dialect; otherwise, I'll name it DB297Dialect. Thanks! Gail From gunnar at hibernate.org Fri Feb 17 04:42:16 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 17 Feb 2017 10:42:16 +0100 Subject: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules In-Reply-To: References: Message-ID: Hi, That's a great initiative. Have you considered to make this a more general effort, esp. should this rather be a repo / group id under the WildFly reign instead of Hibernate? As you say, the modules may be interesting to people not using Hibernate Search, so a group id not tied to Hibernate would be less confusing: org. wildfly.modules.lucene. --Gunnar 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : > Hi all, > > I'm proposing the use of the `org.hibernate.lucene-modules` group id > for the stuff which we'll be releasing from this repository: > - https://github.com/hibernate/lucene-modules > > Context: Hibernate Search has been packaging Apache Lucene as a > WildFly module, essentially including the Lucene modules as part of > the Hibernate Search modules. > > We want to separate these modules, for various reasons; the main > driver being the build of Infinispan is much simpler if they can > source the Lucene modules "out of band" from the Search release > version. Sometimes we need some more flexibility, and it's getting > close to mission impossible to workaround the tight coupling. > > This might also help other projects use Lucene when not necessarily > interested in Hibernate Search, or in using the Lucene versions which > Search would allow (a subset of the Lucene releases). > > Finally, since we release these modules with name "org.apache.lucene", > it might just make sense for them to be independent and just contain > Apache Lucene. > > If you're interested more details, have a look at PR number 1: > - https://github.com/hibernate/lucene-modules/pull/1/files > > In Hibernate Search this would imply: > - https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Fri Feb 17 05:04:37 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 17 Feb 2017 10:04:37 +0000 Subject: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules In-Reply-To: References: Message-ID: On 17 February 2017 at 09:42, Gunnar Morling wrote: > Hi, > > That's a great initiative. Thanks! Credit to Gustavo - he created the project idea - I actually failed to follow up for a long time. I wasn't fully convinced, especially as we were waiting for directions on the area, but convinced now that we should at least split it out even if we don't know the recommended modules format and WildFly strategies going forward. > Have you considered to make this a more > general effort, esp. should this rather be a repo / group id under the > WildFly reign instead of Hibernate? Yes, the "org.hibernate" organization prefix is a deliberate choice. The main reason is that we're the ones maintaining and - hopefully - releasing this module set. Proper organization namespacing is important within the Maven modules world. N.B. the modules id still is "org.apache.lucene": only the Maven group id is prefixed by the Hibernate id. My intent is really to "sign" the provenance only, while the package purpose is general. > > As you say, the modules may be interesting to people not using > Hibernate Search, so a group id not tied to Hibernate would be less > confusing: org. wildfly.modules.lucene. In an ideal world, I would contribute this to the Lucene project: what people need is such a moduleset for each single Lucene release, so you might as well have the Lucene release process provide one. But I think it's premature for that; not least because: - I doubt this format is yet popular enough to be a compelling feature for the Lucene team - we need them to be "retro-active", i.e. to re-package existing Lucene versions - should we use the patch format instead? A feature pack? A fraction? etc.. Many such details need to be ironed out, then I'd be happy to propose it to the Lucene project for inclusion, but this might take some year yet and we need this right now. -- Sanne > > --Gunnar > > > > 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : >> Hi all, >> >> I'm proposing the use of the `org.hibernate.lucene-modules` group id >> for the stuff which we'll be releasing from this repository: >> - https://github.com/hibernate/lucene-modules >> >> Context: Hibernate Search has been packaging Apache Lucene as a >> WildFly module, essentially including the Lucene modules as part of >> the Hibernate Search modules. >> >> We want to separate these modules, for various reasons; the main >> driver being the build of Infinispan is much simpler if they can >> source the Lucene modules "out of band" from the Search release >> version. Sometimes we need some more flexibility, and it's getting >> close to mission impossible to workaround the tight coupling. >> >> This might also help other projects use Lucene when not necessarily >> interested in Hibernate Search, or in using the Lucene versions which >> Search would allow (a subset of the Lucene releases). >> >> Finally, since we release these modules with name "org.apache.lucene", >> it might just make sense for them to be independent and just contain >> Apache Lucene. >> >> If you're interested more details, have a look at PR number 1: >> - https://github.com/hibernate/lucene-modules/pull/1/files >> >> In Hibernate Search this would imply: >> - https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From dreborier at gmail.com Fri Feb 17 05:07:27 2017 From: dreborier at gmail.com (andrea boriero) Date: Fri, 17 Feb 2017 10:07:27 +0000 Subject: [hibernate-dev] Starting 5.2.8 release Message-ID: Please do not push anything to master branch. Thanks, Andrea From gunnar at hibernate.org Fri Feb 17 05:16:28 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 17 Feb 2017 11:16:28 +0100 Subject: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules In-Reply-To: References: Message-ID: 2017-02-17 11:04 GMT+01:00 Sanne Grinovero : > On 17 February 2017 at 09:42, Gunnar Morling wrote: >> Hi, >> >> That's a great initiative. > > Thanks! Credit to Gustavo - he created the project idea - I actually > failed to follow > up for a long time. > > I wasn't fully convinced, especially as we were waiting for directions > on the area, > but convinced now that we should at least split it out even if we don't know > the recommended modules format and WildFly strategies going forward. > >> Have you considered to make this a more >> general effort, esp. should this rather be a repo / group id under the >> WildFly reign instead of Hibernate? > > Yes, the "org.hibernate" organization prefix is a deliberate choice. > > The main reason is that we're the ones maintaining and - hopefully - releasing > this module set. > Proper organization namespacing is important within the Maven modules world. I don't see why we couldn't maintain it when using something under "org.wildfly". Yes, it'll require a bit more work upfront to agree on it. But ideally, WF could even pick up the modules from that project for its own distribution, so it seems like a good fit. > > N.B. the modules id still is "org.apache.lucene": only the Maven group id > is prefixed by the Hibernate id. My intent is really to "sign" the provenance > only, while the package purpose is general. > >> >> As you say, the modules may be interesting to people not using >> Hibernate Search, so a group id not tied to Hibernate would be less >> confusing: org. wildfly.modules.lucene. > > In an ideal world, I would contribute this to the Lucene project: > what people need is such a moduleset for each single Lucene release, > so you might as well have the Lucene release process provide one. I don't think it belongs into Lucene. At least I wouldn't like the idea of maintaining support for downstream integrators like this, were I a Lucene developer :) > > But I think it's premature for that; not least because: > - I doubt this format is yet popular enough to be a compelling > feature for the Lucene team > - we need them to be "retro-active", i.e. to re-package existing > Lucene versions > - should we use the patch format instead? A feature pack? A fraction? etc.. > > Many such details need to be ironed out, then I'd be happy to propose > it to the Lucene > project for inclusion, but this might take some year yet and we need > this right now. > > -- Sanne > >> >> --Gunnar >> >> >> >> 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : >>> Hi all, >>> >>> I'm proposing the use of the `org.hibernate.lucene-modules` group id >>> for the stuff which we'll be releasing from this repository: >>> - https://github.com/hibernate/lucene-modules >>> >>> Context: Hibernate Search has been packaging Apache Lucene as a >>> WildFly module, essentially including the Lucene modules as part of >>> the Hibernate Search modules. >>> >>> We want to separate these modules, for various reasons; the main >>> driver being the build of Infinispan is much simpler if they can >>> source the Lucene modules "out of band" from the Search release >>> version. Sometimes we need some more flexibility, and it's getting >>> close to mission impossible to workaround the tight coupling. >>> >>> This might also help other projects use Lucene when not necessarily >>> interested in Hibernate Search, or in using the Lucene versions which >>> Search would allow (a subset of the Lucene releases). >>> >>> Finally, since we release these modules with name "org.apache.lucene", >>> it might just make sense for them to be independent and just contain >>> Apache Lucene. >>> >>> If you're interested more details, have a look at PR number 1: >>> - https://github.com/hibernate/lucene-modules/pull/1/files >>> >>> In Hibernate Search this would imply: >>> - https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 >>> >>> Thanks, >>> Sanne >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Fri Feb 17 05:30:25 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 17 Feb 2017 10:30:25 +0000 Subject: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules In-Reply-To: References: Message-ID: On 17 February 2017 at 10:16, Gunnar Morling wrote: > 2017-02-17 11:04 GMT+01:00 Sanne Grinovero : >> On 17 February 2017 at 09:42, Gunnar Morling wrote: >>> Hi, >>> >>> That's a great initiative. >> >> Thanks! Credit to Gustavo - he created the project idea - I actually >> failed to follow >> up for a long time. >> >> I wasn't fully convinced, especially as we were waiting for directions >> on the area, >> but convinced now that we should at least split it out even if we don't know >> the recommended modules format and WildFly strategies going forward. >> >>> Have you considered to make this a more >>> general effort, esp. should this rather be a repo / group id under the >>> WildFly reign instead of Hibernate? >> >> Yes, the "org.hibernate" organization prefix is a deliberate choice. >> >> The main reason is that we're the ones maintaining and - hopefully - releasing >> this module set. >> Proper organization namespacing is important within the Maven modules world. > > I don't see why we couldn't maintain it when using something under > "org.wildfly". Yes, it'll require a bit more work upfront to agree on > it. But ideally, WF could even pick up the modules from that project > for its own distribution, so it seems like a good fit. Let's assume we do that. You'd also want me to move this repository to github.com/wildfly ? I'm concerned we're making this maintenance much more "out of reach" for us, just to polish an identifier. For example, the pom metadata I created suggests using this mailing list for any comment, and while I read the WildFly ML periodically, I don't read it as often: - https://github.com/Sanne/lucene-modules/blob/4a823d1f2ec1244c6fb2f38a063253df75cb9187/pom.xml#L34-L54 Mind you, it's not the goal of this project to be popular. It just has to work for our purposes: if having the wrong identifier will lose it some % of users I will still sleep at night just fine. Possibly being useful to other people is nice, but is secondary. > >> >> N.B. the modules id still is "org.apache.lucene": only the Maven group id >> is prefixed by the Hibernate id. My intent is really to "sign" the provenance >> only, while the package purpose is general. >> >>> >>> As you say, the modules may be interesting to people not using >>> Hibernate Search, so a group id not tied to Hibernate would be less >>> confusing: org. wildfly.modules.lucene. >> >> In an ideal world, I would contribute this to the Lucene project: >> what people need is such a moduleset for each single Lucene release, >> so you might as well have the Lucene release process provide one. > > I don't think it belongs into Lucene. At least I wouldn't like the > idea of maintaining support for downstream integrators like this, were > I a Lucene developer :) > >> >> But I think it's premature for that; not least because: >> - I doubt this format is yet popular enough to be a compelling >> feature for the Lucene team >> - we need them to be "retro-active", i.e. to re-package existing >> Lucene versions >> - should we use the patch format instead? A feature pack? A fraction? etc.. >> >> Many such details need to be ironed out, then I'd be happy to propose >> it to the Lucene >> project for inclusion, but this might take some year yet and we need >> this right now. >> >> -- Sanne >> >>> >>> --Gunnar >>> >>> >>> >>> 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : >>>> Hi all, >>>> >>>> I'm proposing the use of the `org.hibernate.lucene-modules` group id >>>> for the stuff which we'll be releasing from this repository: >>>> - https://github.com/hibernate/lucene-modules >>>> >>>> Context: Hibernate Search has been packaging Apache Lucene as a >>>> WildFly module, essentially including the Lucene modules as part of >>>> the Hibernate Search modules. >>>> >>>> We want to separate these modules, for various reasons; the main >>>> driver being the build of Infinispan is much simpler if they can >>>> source the Lucene modules "out of band" from the Search release >>>> version. Sometimes we need some more flexibility, and it's getting >>>> close to mission impossible to workaround the tight coupling. >>>> >>>> This might also help other projects use Lucene when not necessarily >>>> interested in Hibernate Search, or in using the Lucene versions which >>>> Search would allow (a subset of the Lucene releases). >>>> >>>> Finally, since we release these modules with name "org.apache.lucene", >>>> it might just make sense for them to be independent and just contain >>>> Apache Lucene. >>>> >>>> If you're interested more details, have a look at PR number 1: >>>> - https://github.com/hibernate/lucene-modules/pull/1/files >>>> >>>> In Hibernate Search this would imply: >>>> - https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 >>>> >>>> Thanks, >>>> Sanne >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Fri Feb 17 06:04:44 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 17 Feb 2017 12:04:44 +0100 Subject: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules In-Reply-To: References: Message-ID: 2017-02-17 11:30 GMT+01:00 Sanne Grinovero : > On 17 February 2017 at 10:16, Gunnar Morling wrote: >> 2017-02-17 11:04 GMT+01:00 Sanne Grinovero : >>> On 17 February 2017 at 09:42, Gunnar Morling wrote: >>>> Hi, >>>> >>>> That's a great initiative. >>> >>> Thanks! Credit to Gustavo - he created the project idea - I actually >>> failed to follow >>> up for a long time. >>> >>> I wasn't fully convinced, especially as we were waiting for directions >>> on the area, >>> but convinced now that we should at least split it out even if we don't know >>> the recommended modules format and WildFly strategies going forward. >>> >>>> Have you considered to make this a more >>>> general effort, esp. should this rather be a repo / group id under the >>>> WildFly reign instead of Hibernate? >>> >>> Yes, the "org.hibernate" organization prefix is a deliberate choice. >>> >>> The main reason is that we're the ones maintaining and - hopefully - releasing >>> this module set. >>> Proper organization namespacing is important within the Maven modules world. >> >> I don't see why we couldn't maintain it when using something under >> "org.wildfly". Yes, it'll require a bit more work upfront to agree on >> it. But ideally, WF could even pick up the modules from that project >> for its own distribution, so it seems like a good fit. > > Let's assume we do that. You'd also want me to move this repository to > github.com/wildfly ? Yes, that'd be idea. > > I'm concerned we're making this maintenance much more "out of reach" for us, > just to polish an identifier. It's more than that, it'd also allow WF to consume these modules instead of maintaining them twice. > > For example, the pom metadata I created suggests using this mailing > list for any comment, > and while I read the WildFly ML periodically, I don't read it as often: > - https://github.com/Sanne/lucene-modules/blob/4a823d1f2ec1244c6fb2f38a063253df75cb9187/pom.xml#L34-L54 Sorry, but I wouldn't base the decision on which mailing list to read. > > Mind you, it's not the goal of this project to be popular. > It just has to work for our purposes: if having the wrong identifier > will lose it some % of users I will still sleep at night just fine. > Possibly being useful to other people is nice, but is secondary. Ok, it sounded general purpose to me in the beginning. The usage by WF remains. Would be interesting to hear what others think. > >> >>> >>> N.B. the modules id still is "org.apache.lucene": only the Maven group id >>> is prefixed by the Hibernate id. My intent is really to "sign" the provenance >>> only, while the package purpose is general. >>> >>>> >>>> As you say, the modules may be interesting to people not using >>>> Hibernate Search, so a group id not tied to Hibernate would be less >>>> confusing: org. wildfly.modules.lucene. >>> >>> In an ideal world, I would contribute this to the Lucene project: >>> what people need is such a moduleset for each single Lucene release, >>> so you might as well have the Lucene release process provide one. >> >> I don't think it belongs into Lucene. At least I wouldn't like the >> idea of maintaining support for downstream integrators like this, were >> I a Lucene developer :) >> >>> >>> But I think it's premature for that; not least because: >>> - I doubt this format is yet popular enough to be a compelling >>> feature for the Lucene team >>> - we need them to be "retro-active", i.e. to re-package existing >>> Lucene versions >>> - should we use the patch format instead? A feature pack? A fraction? etc.. >>> >>> Many such details need to be ironed out, then I'd be happy to propose >>> it to the Lucene >>> project for inclusion, but this might take some year yet and we need >>> this right now. >>> >>> -- Sanne >>> >>>> >>>> --Gunnar >>>> >>>> >>>> >>>> 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : >>>>> Hi all, >>>>> >>>>> I'm proposing the use of the `org.hibernate.lucene-modules` group id >>>>> for the stuff which we'll be releasing from this repository: >>>>> - https://github.com/hibernate/lucene-modules >>>>> >>>>> Context: Hibernate Search has been packaging Apache Lucene as a >>>>> WildFly module, essentially including the Lucene modules as part of >>>>> the Hibernate Search modules. >>>>> >>>>> We want to separate these modules, for various reasons; the main >>>>> driver being the build of Infinispan is much simpler if they can >>>>> source the Lucene modules "out of band" from the Search release >>>>> version. Sometimes we need some more flexibility, and it's getting >>>>> close to mission impossible to workaround the tight coupling. >>>>> >>>>> This might also help other projects use Lucene when not necessarily >>>>> interested in Hibernate Search, or in using the Lucene versions which >>>>> Search would allow (a subset of the Lucene releases). >>>>> >>>>> Finally, since we release these modules with name "org.apache.lucene", >>>>> it might just make sense for them to be independent and just contain >>>>> Apache Lucene. >>>>> >>>>> If you're interested more details, have a look at PR number 1: >>>>> - https://github.com/hibernate/lucene-modules/pull/1/files >>>>> >>>>> In Hibernate Search this would imply: >>>>> - https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 >>>>> >>>>> Thanks, >>>>> Sanne >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Fri Feb 17 06:10:39 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 17 Feb 2017 11:10:39 +0000 Subject: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules In-Reply-To: References: Message-ID: On 17 February 2017 at 11:04, Gunnar Morling wrote: > 2017-02-17 11:30 GMT+01:00 Sanne Grinovero : >> On 17 February 2017 at 10:16, Gunnar Morling wrote: >>> 2017-02-17 11:04 GMT+01:00 Sanne Grinovero : >>>> On 17 February 2017 at 09:42, Gunnar Morling wrote: >>>>> Hi, >>>>> >>>>> That's a great initiative. >>>> >>>> Thanks! Credit to Gustavo - he created the project idea - I actually >>>> failed to follow >>>> up for a long time. >>>> >>>> I wasn't fully convinced, especially as we were waiting for directions >>>> on the area, >>>> but convinced now that we should at least split it out even if we don't know >>>> the recommended modules format and WildFly strategies going forward. >>>> >>>>> Have you considered to make this a more >>>>> general effort, esp. should this rather be a repo / group id under the >>>>> WildFly reign instead of Hibernate? >>>> >>>> Yes, the "org.hibernate" organization prefix is a deliberate choice. >>>> >>>> The main reason is that we're the ones maintaining and - hopefully - releasing >>>> this module set. >>>> Proper organization namespacing is important within the Maven modules world. >>> >>> I don't see why we couldn't maintain it when using something under >>> "org.wildfly". Yes, it'll require a bit more work upfront to agree on >>> it. But ideally, WF could even pick up the modules from that project >>> for its own distribution, so it seems like a good fit. >> >> Let's assume we do that. You'd also want me to move this repository to >> github.com/wildfly ? > > Yes, that'd be idea. > >> >> I'm concerned we're making this maintenance much more "out of reach" for us, >> just to polish an identifier. > > It's more than that, it'd also allow WF to consume these modules > instead of maintaining them twice. They will not consume it. Remember the prime directive? - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html I'm assuming the previous direction stands, and I'd like to move forward until we know better. This initiative has been stuck for more than a year already, waiting for such input or a better home. > >> >> For example, the pom metadata I created suggests using this mailing >> list for any comment, >> and while I read the WildFly ML periodically, I don't read it as often: >> - https://github.com/Sanne/lucene-modules/blob/4a823d1f2ec1244c6fb2f38a063253df75cb9187/pom.xml#L34-L54 > > Sorry, but I wouldn't base the decision on which mailing list to read. > >> >> Mind you, it's not the goal of this project to be popular. >> It just has to work for our purposes: if having the wrong identifier >> will lose it some % of users I will still sleep at night just fine. >> Possibly being useful to other people is nice, but is secondary. > > Ok, it sounded general purpose to me in the beginning. The usage by WF remains. > > Would be interesting to hear what others think. > >> >>> >>>> >>>> N.B. the modules id still is "org.apache.lucene": only the Maven group id >>>> is prefixed by the Hibernate id. My intent is really to "sign" the provenance >>>> only, while the package purpose is general. >>>> >>>>> >>>>> As you say, the modules may be interesting to people not using >>>>> Hibernate Search, so a group id not tied to Hibernate would be less >>>>> confusing: org. wildfly.modules.lucene. >>>> >>>> In an ideal world, I would contribute this to the Lucene project: >>>> what people need is such a moduleset for each single Lucene release, >>>> so you might as well have the Lucene release process provide one. >>> >>> I don't think it belongs into Lucene. At least I wouldn't like the >>> idea of maintaining support for downstream integrators like this, were >>> I a Lucene developer :) >>> >>>> >>>> But I think it's premature for that; not least because: >>>> - I doubt this format is yet popular enough to be a compelling >>>> feature for the Lucene team >>>> - we need them to be "retro-active", i.e. to re-package existing >>>> Lucene versions >>>> - should we use the patch format instead? A feature pack? A fraction? etc.. >>>> >>>> Many such details need to be ironed out, then I'd be happy to propose >>>> it to the Lucene >>>> project for inclusion, but this might take some year yet and we need >>>> this right now. >>>> >>>> -- Sanne >>>> >>>>> >>>>> --Gunnar >>>>> >>>>> >>>>> >>>>> 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : >>>>>> Hi all, >>>>>> >>>>>> I'm proposing the use of the `org.hibernate.lucene-modules` group id >>>>>> for the stuff which we'll be releasing from this repository: >>>>>> - https://github.com/hibernate/lucene-modules >>>>>> >>>>>> Context: Hibernate Search has been packaging Apache Lucene as a >>>>>> WildFly module, essentially including the Lucene modules as part of >>>>>> the Hibernate Search modules. >>>>>> >>>>>> We want to separate these modules, for various reasons; the main >>>>>> driver being the build of Infinispan is much simpler if they can >>>>>> source the Lucene modules "out of band" from the Search release >>>>>> version. Sometimes we need some more flexibility, and it's getting >>>>>> close to mission impossible to workaround the tight coupling. >>>>>> >>>>>> This might also help other projects use Lucene when not necessarily >>>>>> interested in Hibernate Search, or in using the Lucene versions which >>>>>> Search would allow (a subset of the Lucene releases). >>>>>> >>>>>> Finally, since we release these modules with name "org.apache.lucene", >>>>>> it might just make sense for them to be independent and just contain >>>>>> Apache Lucene. >>>>>> >>>>>> If you're interested more details, have a look at PR number 1: >>>>>> - https://github.com/hibernate/lucene-modules/pull/1/files >>>>>> >>>>>> In Hibernate Search this would imply: >>>>>> - https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 >>>>>> >>>>>> Thanks, >>>>>> Sanne >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Fri Feb 17 07:07:01 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 17 Feb 2017 12:07:01 +0000 Subject: [hibernate-dev] New project, new group-id: org.hibernate.lucene-modules In-Reply-To: References: Message-ID: I've sent a related proposal to the WildFly mailing list: - http://lists.jboss.org/pipermail/wildfly-dev/2017-February/005768.html If they welcome it, that's great. Otherwise I'll release this pack as-is, but for sure ownership is not cast in stone. Thanks, Sanne On 17 February 2017 at 11:10, Sanne Grinovero wrote: > On 17 February 2017 at 11:04, Gunnar Morling wrote: >> 2017-02-17 11:30 GMT+01:00 Sanne Grinovero : >>> On 17 February 2017 at 10:16, Gunnar Morling wrote: >>>> 2017-02-17 11:04 GMT+01:00 Sanne Grinovero : >>>>> On 17 February 2017 at 09:42, Gunnar Morling wrote: >>>>>> Hi, >>>>>> >>>>>> That's a great initiative. >>>>> >>>>> Thanks! Credit to Gustavo - he created the project idea - I actually >>>>> failed to follow >>>>> up for a long time. >>>>> >>>>> I wasn't fully convinced, especially as we were waiting for directions >>>>> on the area, >>>>> but convinced now that we should at least split it out even if we don't know >>>>> the recommended modules format and WildFly strategies going forward. >>>>> >>>>>> Have you considered to make this a more >>>>>> general effort, esp. should this rather be a repo / group id under the >>>>>> WildFly reign instead of Hibernate? >>>>> >>>>> Yes, the "org.hibernate" organization prefix is a deliberate choice. >>>>> >>>>> The main reason is that we're the ones maintaining and - hopefully - releasing >>>>> this module set. >>>>> Proper organization namespacing is important within the Maven modules world. >>>> >>>> I don't see why we couldn't maintain it when using something under >>>> "org.wildfly". Yes, it'll require a bit more work upfront to agree on >>>> it. But ideally, WF could even pick up the modules from that project >>>> for its own distribution, so it seems like a good fit. >>> >>> Let's assume we do that. You'd also want me to move this repository to >>> github.com/wildfly ? >> >> Yes, that'd be idea. >> >>> >>> I'm concerned we're making this maintenance much more "out of reach" for us, >>> just to polish an identifier. >> >> It's more than that, it'd also allow WF to consume these modules >> instead of maintaining them twice. > > They will not consume it. Remember the prime directive? > > - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html > > I'm assuming the previous direction stands, and I'd like to move > forward until we know better. > > This initiative has been stuck for more than a year already, waiting > for such input or a better home. > >> >>> >>> For example, the pom metadata I created suggests using this mailing >>> list for any comment, >>> and while I read the WildFly ML periodically, I don't read it as often: >>> - https://github.com/Sanne/lucene-modules/blob/4a823d1f2ec1244c6fb2f38a063253df75cb9187/pom.xml#L34-L54 >> >> Sorry, but I wouldn't base the decision on which mailing list to read. >> >>> >>> Mind you, it's not the goal of this project to be popular. >>> It just has to work for our purposes: if having the wrong identifier >>> will lose it some % of users I will still sleep at night just fine. >>> Possibly being useful to other people is nice, but is secondary. >> >> Ok, it sounded general purpose to me in the beginning. The usage by WF remains. >> >> Would be interesting to hear what others think. >> >>> >>>> >>>>> >>>>> N.B. the modules id still is "org.apache.lucene": only the Maven group id >>>>> is prefixed by the Hibernate id. My intent is really to "sign" the provenance >>>>> only, while the package purpose is general. >>>>> >>>>>> >>>>>> As you say, the modules may be interesting to people not using >>>>>> Hibernate Search, so a group id not tied to Hibernate would be less >>>>>> confusing: org. wildfly.modules.lucene. >>>>> >>>>> In an ideal world, I would contribute this to the Lucene project: >>>>> what people need is such a moduleset for each single Lucene release, >>>>> so you might as well have the Lucene release process provide one. >>>> >>>> I don't think it belongs into Lucene. At least I wouldn't like the >>>> idea of maintaining support for downstream integrators like this, were >>>> I a Lucene developer :) >>>> >>>>> >>>>> But I think it's premature for that; not least because: >>>>> - I doubt this format is yet popular enough to be a compelling >>>>> feature for the Lucene team >>>>> - we need them to be "retro-active", i.e. to re-package existing >>>>> Lucene versions >>>>> - should we use the patch format instead? A feature pack? A fraction? etc.. >>>>> >>>>> Many such details need to be ironed out, then I'd be happy to propose >>>>> it to the Lucene >>>>> project for inclusion, but this might take some year yet and we need >>>>> this right now. >>>>> >>>>> -- Sanne >>>>> >>>>>> >>>>>> --Gunnar >>>>>> >>>>>> >>>>>> >>>>>> 2017-02-16 20:17 GMT+01:00 Sanne Grinovero : >>>>>>> Hi all, >>>>>>> >>>>>>> I'm proposing the use of the `org.hibernate.lucene-modules` group id >>>>>>> for the stuff which we'll be releasing from this repository: >>>>>>> - https://github.com/hibernate/lucene-modules >>>>>>> >>>>>>> Context: Hibernate Search has been packaging Apache Lucene as a >>>>>>> WildFly module, essentially including the Lucene modules as part of >>>>>>> the Hibernate Search modules. >>>>>>> >>>>>>> We want to separate these modules, for various reasons; the main >>>>>>> driver being the build of Infinispan is much simpler if they can >>>>>>> source the Lucene modules "out of band" from the Search release >>>>>>> version. Sometimes we need some more flexibility, and it's getting >>>>>>> close to mission impossible to workaround the tight coupling. >>>>>>> >>>>>>> This might also help other projects use Lucene when not necessarily >>>>>>> interested in Hibernate Search, or in using the Lucene versions which >>>>>>> Search would allow (a subset of the Lucene releases). >>>>>>> >>>>>>> Finally, since we release these modules with name "org.apache.lucene", >>>>>>> it might just make sense for them to be independent and just contain >>>>>>> Apache Lucene. >>>>>>> >>>>>>> If you're interested more details, have a look at PR number 1: >>>>>>> - https://github.com/hibernate/lucene-modules/pull/1/files >>>>>>> >>>>>>> In Hibernate Search this would imply: >>>>>>> - https://github.com/Sanne/hibernate-search/commit/a271d43d15b6af508ea693b3ccbe720604f9e1c8 >>>>>>> >>>>>>> Thanks, >>>>>>> Sanne >>>>>>> _______________________________________________ >>>>>>> hibernate-dev mailing list >>>>>>> hibernate-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From andrea at hibernate.org Fri Feb 17 07:33:27 2017 From: andrea at hibernate.org (andrea boriero) Date: Fri, 17 Feb 2017 12:33:27 +0000 Subject: [hibernate-dev] Hibernate ORM 5.2.8.Final has been released Message-ID: For details: http://in.relation.to/2017/02/17/hibernate-orm-528-final-release From mihalcea.vlad at gmail.com Fri Feb 17 07:50:09 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 17 Feb 2017 14:50:09 +0200 Subject: [hibernate-dev] @Where clause and finding an entity Message-ID: Hi, I'm testing the way @Where annotation works, and I found the following scenario: If we have an entity annotated like this: @Where(clause = "deleted = false") @SQLDelete(sql = "UPDATE tag set deleted = true where id = ?") If the entity was previously deleted and I try to load it in a new Persistence Context: assertNull(entityManager.find(Tag.class, "Misc")); The entity is fetched successfully, and the assert fails. The only way to make it work is if I override the load query using the @Loader annotation: @Loader(namedQuery = "findTagById") @NamedQuery(name = "findTagById", query = "select t from Tag t where t.id = ? and t.deleted = false") Is this the expected behavior or is it a bug? Vlad From steve at hibernate.org Fri Feb 17 08:24:59 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 17 Feb 2017 13:24:59 +0000 Subject: [hibernate-dev] dynamic instantiation queries In-Reply-To: References: <580e61a5.832ec20a.d257f.6652@mx.google.com> Message-ID: For completeness: https://hibernate.atlassian.net/browse/HHH-11501. Let's continue any discussion there... On Mon, Oct 24, 2016 at 6:40 PM Steve Ebersole wrote: > Still not really understanding what you are getting at. Do you have an > example? > > The entity passed into the "DTO" would be managed. If they wanted to > initialize stuff on that entity it would happen just as normal for a > managed entity. Is that what you mean? > > On Mon, Oct 24, 2016, 4:34 PM Sanne Grinovero wrote: > > On 24 October 2016 at 21:49, Steve Ebersole wrote: > > I'm not sure what you are getting at. This is a feature Hibernate has had > > for close to 15 years. It's not a "new feature", I'm just proposing a > new > > behavior to be more consistent with what people generally expect. > > Yes I like the proposal; I'm just wondering if there might be some > hidden complexities in allowing to initialise additional lazy > properties during the query execution, as a side-effect of the > constructor's code as I guess it might want to invoke various getters > on the Person instance. If you say that's not a problem, then that's > good news :) > > > > > > > On Mon, Oct 24, 2016, 3:30 PM Sanne Grinovero > wrote: > >> > >> Option 2# looks very nice indeed, I'd like that as it would be useful > >> to be able to create immutable DTOs directly from a query; but I'm > >> wondering what kind of difficulties this might pose, for example I'd > >> assume the DTO constructor would be able to trigger lazy loading of > >> any property of Person? > >> > >> Also wondering, if we expose query results as streams in the future, > >> would such a feature not become obsolete? > >> > >> > >> On 24 October 2016 at 20:38, Steve Ebersole > wrote: > >> > So Person is your entity, e.g.: > >> > > >> > @Entity > >> > class Person { > >> > @Id > >> > Long id; > >> > ... > >> > } > >> > > >> > For a query like `select new DTO( p ) from Person p` Hibernate > expects a > >> > DTO like: > >> > > >> > class DTO { > >> > public DTO(Long id) { > >> > ... > >> > } > >> > } > >> > > >> > in fact a DTO like: > >> > > >> > class DTO { > >> > public DTO(Person person) { > >> > ... > >> > } > >> > } > >> > > >> > will not work with Hibernate. > >> > > >> > What I was proposing was for adding some support for that in 6.0 based > >> > on > >> > the SQM work. "Support" here could mean either: > >> > 1) add a flag that says whether to support legacy behavior, or this > new > >> > behavior > >> > 2) attempt to dynamically infer what to do (looks at available ctors) > >> > > >> > (2) would be awesome I think. We'd still have to know how to handle > >> > cases > >> > where the "DTO" defined ctors matching both cases and which to prefer. > >> > > >> > > >> > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea < > mihalcea.vlad at gmail.com> > >> > wrote: > >> > > >> >> Do you mean we should allow the dynamic instantiation to resolve > >> >> entities > >> >> when we pass the entity identifier? > >> >> > >> >> I think I saw this request on StackOverflow once. > >> >> > >> >> Did I understand the question properly? > >> >> > >> >> Vlad > >> >> ------------------------------ > >> >> From: Steve Ebersole > >> >> Sent: ?10/?24/?2016 22:21 > >> >> To: hibernate-dev > >> >> Subject: [hibernate-dev] dynamic instantiation queries > >> >> > >> >> Historically (well before JPA) HIbernate would handle dynamic > >> >> instantiation > >> >> queries in cases where one of the arguments being an entity-reference > >> >> by > >> >> passing just the entity's identifier rather than a complete reference > >> >> to > >> >> the entity. To be clear, I am talking about a query like: > >> >> > >> >> select new DTO( p ) from Person p > >> >> > >> >> Hibernate implicitly treats this like: > >> >> > >> >> select new DTO( p.id ) from Person p > >> >> > >> >> and expects DTO to have a ctor taking the appropriate ID type. > >> >> > >> >> JPA came along and also defines support for dynamic instantiation > >> >> queries, > >> >> but does not specify one way or the other how this case should be > >> >> handled. > >> >> I have been told other providers interpret this the opposite way. > >> >> Makes > >> >> sense. I think it is time we at least allow that as an option. Or > >> >> maybe a > >> >> nicer implementation that looks for both and picks the available one > >> >> (if > >> >> that's not too much effort). > >> >> > >> >> What do y'all think? > >> >> _______________________________________________ > >> >> 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 Fri Feb 17 08:45:33 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 17 Feb 2017 15:45:33 +0200 Subject: [hibernate-dev] HHH-11089 In-Reply-To: References: Message-ID: Hi Petar, We only do development against the master branch, hence we need to apply this on Hibernate 5.2. If Gail wants to backport it to 5.1, then it's up to her whether this change need to be applied to older branches. Can you open a PR with your latest changes against the master branch and I'll review it next week. Thanks, Vlad On Thu, Feb 16, 2017 at 5:42 PM, Petar Tahchiev wrote: > Hey guys, > > a while ago I opened this issue: > > https://hibernate.atlassian.net/browse/HHH-11089 > > which blocks me from using Hibernate with Oracle database (the well-known > issue with 30 chars limit for table/column/foreignkey/indexkey names). > While I managed to workaround the tablename/columnname by specifying a > custom PhysicalNamingStrategy. I also created a custom > ImplicitNamingStrategy, but figured out it is never invoked when I have > already specified a name for the foreign-key/indexkey. It is only called > when no name has been given for the foreign key or index. I made a pull > request, and you guys asked for some improvements. > > Long-story-short I just committed my improvements: > > https://github.com/hibernate/hibernate-orm/pull/1564/commits/ > 78edc44143e39b19668099ea57e9ccb1a3a02b13 > > to make sure that the implicit naming strategy is always invoked no matter > if the user has specified a name for the foreign key or have omitted it. > Can someone please review it? > > BTW I'm not able to build the 5.1 branch and my branch too because I get > thousands of checkstyle violations in files that I haven't worked on. I > also tried to exclude the checkstyle plugin but seems like my gradle > knowledge wasn't enough. > > Thank you and keep up the good work :) > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From paranoiabla at gmail.com Sat Feb 18 11:03:44 2017 From: paranoiabla at gmail.com (Petar Tahchiev) Date: Sat, 18 Feb 2017 18:03:44 +0200 Subject: [hibernate-dev] HHH-11089 In-Reply-To: References: Message-ID: Thanks Vlad, here's a new pull-request against the master: https://github.com/hibernate/hibernate-orm/pull/1797 I wasn't able to test it because ./gradlew build fails even without my changes. 2017-02-17 15:45 GMT+02:00 Vlad Mihalcea : > Hi Petar, > > We only do development against the master branch, hence we need to apply > this on Hibernate 5.2. > If Gail wants to backport it to 5.1, then it's up to her whether this > change need to be applied to older branches. > > Can you open a PR with your latest changes against the master branch and > I'll review it next week. > > Thanks, > Vlad > > On Thu, Feb 16, 2017 at 5:42 PM, Petar Tahchiev > wrote: > >> Hey guys, >> >> a while ago I opened this issue: >> >> https://hibernate.atlassian.net/browse/HHH-11089 >> >> which blocks me from using Hibernate with Oracle database (the well-known >> issue with 30 chars limit for table/column/foreignkey/indexkey names). >> While I managed to workaround the tablename/columnname by specifying a >> custom PhysicalNamingStrategy. I also created a custom >> ImplicitNamingStrategy, but figured out it is never invoked when I have >> already specified a name for the foreign-key/indexkey. It is only called >> when no name has been given for the foreign key or index. I made a pull >> request, and you guys asked for some improvements. >> >> Long-story-short I just committed my improvements: >> >> https://github.com/hibernate/hibernate-orm/pull/1564/commits >> /78edc44143e39b19668099ea57e9ccb1a3a02b13 >> >> to make sure that the implicit naming strategy is always invoked no matter >> if the user has specified a name for the foreign key or have omitted it. >> Can someone please review it? >> >> BTW I'm not able to build the 5.1 branch and my branch too because I get >> thousands of checkstyle violations in files that I haven't worked on. I >> also tried to exclude the checkstyle plugin but seems like my gradle >> knowledge wasn't enough. >> >> Thank you and keep up the good work :) >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 From steve at hibernate.org Mon Feb 20 12:02:45 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 20 Feb 2017 17:02:45 +0000 Subject: [hibernate-dev] 6.0 - Proposed org.hibernate.mapping changes Message-ID: For 6.0, what do y'all think of these changes proposed below to the org.hibernate.mapping package? *Koen, this affects tools so really would like your thoughts...* Mostly this comes from the definition of a `#finishInitialization` method on ManagedTypeImplementor (which covers mapped-superclass, entity and embeddable/embedded). Currently this method takes its supertype as PersistentClass; however PersistentClass is generally understood to model an entity and tooling certainly uses it as such. Keeping this in mind to hopefully minimize impact I propose the following: 1. Define a new org.hibernate.mapping.ManagedTypeMapping that represents mappings for any "managed type" in the normal JPA meaning of that term (mapped-superclass, entity, embeddable) 2. Define a new org.hibernate.mapping.EmbeddedTypeMapping extending ManagedTypeMapping (org.hibernate.mapping.Composite). Or should we split EmbeddableTypeMapping and "EmbeddedMapping"? 3. Define a new org.hibernate.mapping.IdentifiableTypeMapping extending ManagedTypeMapping 4. Define a new org.hibernate.mapping.MappedSuperclassTypeMapping extending IdentifiableTypeMapping 5. Define a new org.hibernate.mapping.EntityTypeMapping extending IdentifiableTypeMapping 6. Make PersistentClass extend EntityTypeMapping and deprecate 7. Make Composite extend EmbeddedTypeMapping and deprecate 8. Make MapppedSuperclass extend MappedSuperclassTypeMapping and deprecate 9. Re-work the hierarchies here to better fit this new model /** * ... * * @todo (6.0) Use ManagedTypeMapping here as super-type rather than PersistentClass */ void finishInitialization( ManagedTypeImplementor superType, PersistentClass entityBinding, PersisterCreationContext creationContext); From yoann at hibernate.org Tue Feb 21 05:20:27 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 21 Feb 2017 11:20:27 +0100 Subject: [hibernate-dev] [SEARCH] Integration of Mincong's work on adding JSR-352 support Message-ID: Hello, Following our recent (and successful) efforts to fix blocking issues on https://github.com/mincong-h/gsoc-hsearch/, I recently added a branch on my repo which contains the Hibernate Search codebase, with the addition of a JSR-352 submodule. You can find the branch at [1]. The build is working just fine ([2]). I tried to preserve as much metadata as possible when building this branch, without keeping a long list of commits that would probably do more harm than good. Basically I squashed commits and put the git log of the squashed commits in the commit's comment. I tried to preserve authorship and approximate dates, so git blame will still be useful. If this branch seems acceptable to everyone, we can start working on further polishing the JSR-352 integration, and eventually merge it. Below are the next few steps to discuss. # What's left to do The full list of remaining issues can be found on the original repo [3]. I marked as "Blocker" those issues that seem unacceptable in a release. To sum up: - we have some APIs that will need further refining (just a few); - we basically don't have any documentation (there is a start, but it's already obsolete); - we lack some tests, most notably integration tests with other implementations than JBeret; - composite IDs are not supported correctly; - there are performance issues (or at least there were last time we checked); - failure recovery doesn't seem to be implemented correctly (uses AddLuceneWork instead of UpdateLuceneWork for the failing partition); - there are still questions about how transaction timeouts should be handled. # Organization I'd like to avoid merging the branch to master as long as the module isn't ready. Here's why: 1. The module isn't ready for prime-time yet (see above) 2. The module is only loosely tied to Hibernate Search, in a few very specific portions of the code, so rebasing it shouldn't be hell. And it'll probably be me doing it anyway ;) So think we should leave the code where it is now (a branch on my repo, see [1]) and manage pull requests there. About CI, Travis is working just fine for me, and since we're working on an additional module the changes we make shouldn't have any impact on the core. So I don't think setting up a job on ci.hibernate.org is required yet. Regarding the tickets, I would create issues in our JIRA based on the existing GitHub issues in the original repo. Probably make them sub-tasks of HSEARCH-2594 [4]. I'll work on this later this week if nobody is against it. As to the planning, I'd say our problem isn't so much the amount of work (there shouldn't be much more than 2 or 3 man-weeks remaning) than the amount of time we can put into it. Mincong isn't studying anymore and has a full-time job; however, he generously proposed to work on this during his week-ends. But it obviously wouldn't be reasonable to expect him to work on this every week-end, all week-end long. As for Sanne and myself, we'll be working on ES5 integration + Search 5.8 + Search 6, so we also have a lot to do. I think I'll book some time slots (1 day a week maybe) to work on JSR-352 until we consider the module ready. Any opinions on all this? [1] https://github.com/yrodiere/hibernate-search/tree/jsr352 [2] https://travis-ci.org/yrodiere/hibernate-search/builds/203727344 [3] https://github.com/mincong-h/gsoc-hsearch/issues [4] https://hibernate.atlassian.net/browse/HSEARCH-2594 Yoann Rodi?re Hibernate NoORM Team From davide at hibernate.org Wed Feb 22 05:47:50 2017 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 22 Feb 2017 10:47:50 +0000 Subject: [hibernate-dev] Removing the BlueOcean plugin on CI Message-ID: Hi. I'm going to remove the BlueOcean plugin from Ci. Currently, when we receive an email because a build is failed, the link to the job is wrong and it seems that BlueOcena is the cause. I don't think anybody is actually using it but if there are some objections, let me know. Regards, Davide From yoann at hibernate.org Wed Feb 22 08:49:03 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 22 Feb 2017 14:49:03 +0100 Subject: [hibernate-dev] Hibernate Search 5.7.0.Final and 5.6.1.Final released Message-ID: Hello everyone, We just released Hibernate Search 5.7.0.Final, compatible with Hibernate ORM 5.2.8. As 5.7 is not compatible with Hibernate ORM 5.0/5.1 anymore, we also released a bugfix version for 5.6 with several backports: Hibernate Search 5.6.1.Final. Be sure to check out our blog for more information about those two releases: http://in.relation.to/2017/02/22/hibernate-search-5-7-0-Final/ Have a nice day, Yoann Rodi?re Hibernate NoORM Team From davide at hibernate.org Wed Feb 22 16:48:26 2017 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 22 Feb 2017 21:48:26 +0000 Subject: [hibernate-dev] Removing the BlueOcean plugin on CI In-Reply-To: References: Message-ID: I've removed the Blue Ocean plugin. Let me know if there are still some problems. I've also configured the jobs so that the website jobs can be executed in parallel with the others. This should make publishing of a page faster. Cheers, Davide On Wed, Feb 22, 2017 at 10:47 AM, Davide D'Alto wrote: > Hi. > I'm going to remove the BlueOcean plugin from Ci. > > Currently, when we receive an email because a build is failed, the > link to the job is wrong and it seems that BlueOcena is the cause. > > I don't think anybody is actually using it but if there are some > objections, let me know. > > Regards, > Davide From sanne at hibernate.org Thu Feb 23 05:24:30 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 23 Feb 2017 10:24:30 +0000 Subject: [hibernate-dev] Removing the BlueOcean plugin on CI In-Reply-To: References: Message-ID: Thanks Davide! All, we need your help now: please make sure that any job you enable which uses any network port (like using Byteman, Arquillian, WildFly, Databases, Elasticsearch, etc..) has set a "Job Weight" of 3. When failing to do so, we'll see sporadic failures of both your job and some other random job, so let's be nice to each other ;) I think the setup is not perfect yet, as I've reviewed some failure reports and they seem caused by an already running WildFly instance on the same machine. So either we have a bad job configuration somewhere, or a WildFly instance which didn't shut down correctly. Thanks, Sanne On 22 February 2017 at 21:48, Davide D'Alto wrote: > I've removed the Blue Ocean plugin. > > Let me know if there are still some problems. > > I've also configured the jobs so that the website jobs can be executed > in parallel with the others. > > This should make publishing of a page faster. > > Cheers, > Davide > > > On Wed, Feb 22, 2017 at 10:47 AM, Davide D'Alto wrote: >> Hi. >> I'm going to remove the BlueOcean plugin from Ci. >> >> Currently, when we receive an email because a build is failed, the >> link to the job is wrong and it seems that BlueOcena is the cause. >> >> I don't think anybody is actually using it but if there are some >> objections, let me know. >> >> Regards, >> Davide > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From davide at hibernate.org Thu Feb 23 05:35:38 2017 From: davide at hibernate.org (Davide D'Alto) Date: Thu, 23 Feb 2017 10:35:38 +0000 Subject: [hibernate-dev] Removing the BlueOcean plugin on CI In-Reply-To: References: Message-ID: I suspect the WildFLy instance was still active because I've aborted the job or restarted Jenkins at the wrong time while appying the changes. Speaking about the job weight, I didn't change the releases job, I'll let the owners of each job to do that but I think it would make sense to cahnge their weight to 2 (unless one don't mind to wait). Thanks, Davide On Thu, Feb 23, 2017 at 10:24 AM, Sanne Grinovero wrote: > Thanks Davide! > > All, we need your help now: please make sure that any job you enable > which uses any network port (like using Byteman, Arquillian, WildFly, > Databases, Elasticsearch, etc..) has set a "Job Weight" of 3. > > When failing to do so, we'll see sporadic failures of both your job > and some other random job, so let's be nice to each other ;) > > I think the setup is not perfect yet, as I've reviewed some failure > reports and they seem caused by an already running WildFly instance on > the same machine. So either we have a bad job configuration somewhere, > or a WildFly instance which didn't shut down correctly. > > Thanks, > Sanne > > > > On 22 February 2017 at 21:48, Davide D'Alto wrote: >> I've removed the Blue Ocean plugin. >> >> Let me know if there are still some problems. >> >> I've also configured the jobs so that the website jobs can be executed >> in parallel with the others. >> >> This should make publishing of a page faster. >> >> Cheers, >> Davide >> >> >> On Wed, Feb 22, 2017 at 10:47 AM, Davide D'Alto wrote: >>> Hi. >>> I'm going to remove the BlueOcean plugin from Ci. >>> >>> Currently, when we receive an email because a build is failed, the >>> link to the job is wrong and it seems that BlueOcena is the cause. >>> >>> I don't think anybody is actually using it but if there are some >>> objections, let me know. >>> >>> Regards, >>> 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 coladict at gmail.com Thu Feb 23 06:09:44 2017 From: coladict at gmail.com (Jordan Gigov) Date: Thu, 23 Feb 2017 13:09:44 +0200 Subject: [hibernate-dev] Removing the BlueOcean plugin on CI In-Reply-To: References: Message-ID: On 23 February 2017 at 12:24, Sanne Grinovero wrote: > I think the setup is not perfect yet, as I've reviewed some failure > reports and they seem caused by an already running WildFly instance on > the same machine. So either we have a bad job configuration somewhere, > or a WildFly instance which didn't shut down correctly. There is a configuration problem with WildFly, partly due to an arquillian bug, partly due to a bug in the wildfly-arquillian runner, but both can be bypassed using this patch http://pastebin.com/q2Nt0Ent From sanne at hibernate.org Thu Feb 23 06:21:52 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 23 Feb 2017 11:21:52 +0000 Subject: [hibernate-dev] Removing the BlueOcean plugin on CI In-Reply-To: References: Message-ID: Thanks Jordan! Can you explain why we need to define the "managementPort" property? Do you have a link to the issue maybe? I'd like to understand that better, especially as we have several other projects to patch. Sanne On 23 February 2017 at 11:09, Jordan Gigov wrote: > On 23 February 2017 at 12:24, Sanne Grinovero wrote: >> I think the setup is not perfect yet, as I've reviewed some failure >> reports and they seem caused by an already running WildFly instance on >> the same machine. So either we have a bad job configuration somewhere, >> or a WildFly instance which didn't shut down correctly. > > There is a configuration problem with WildFly, partly due to an > arquillian bug, partly due to a bug in the wildfly-arquillian runner, > but both can be bypassed using this patch > http://pastebin.com/q2Nt0Ent From coladict at gmail.com Thu Feb 23 06:54:58 2017 From: coladict at gmail.com (Jordan Gigov) Date: Thu, 23 Feb 2017 13:54:58 +0200 Subject: [hibernate-dev] Removing the BlueOcean plugin on CI In-Reply-To: References: Message-ID: First the comment needs to be outside the property, otherwise it's not detected as a text-only node. Secondly managementPort has to be set, because while arquillian passes on jboss.socket.binding.port-offset but does not take it into account. Because of port-offset the management port is moved from 9990 to 10127, but it's the runner framework doesn't know that. It gets stuck waiting to confirm server start, but it's looking at port 9990 to check it. And it looks like I've made the patch with tabs, while the rest of the file is spaces. Don't commit it mixed like that. On 23 February 2017 at 13:21, Sanne Grinovero wrote: > Thanks Jordan! > > Can you explain why we need to define the "managementPort" property? > Do you have a link to the issue maybe? > I'd like to understand that better, especially as we have several > other projects to patch. > > Sanne > > On 23 February 2017 at 11:09, Jordan Gigov wrote: >> On 23 February 2017 at 12:24, Sanne Grinovero wrote: >>> I think the setup is not perfect yet, as I've reviewed some failure >>> reports and they seem caused by an already running WildFly instance on >>> the same machine. So either we have a bad job configuration somewhere, >>> or a WildFly instance which didn't shut down correctly. >> >> There is a configuration problem with WildFly, partly due to an >> arquillian bug, partly due to a bug in the wildfly-arquillian runner, >> but both can be bypassed using this patch >> http://pastebin.com/q2Nt0Ent From emmanuel at hibernate.org Fri Feb 24 15:23:31 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 24 Feb 2017 21:23:31 +0100 Subject: [hibernate-dev] [HHH-11517] Cloud friendliness and delaying some DB operation at boot time Message-ID: <1EB3D109-A525-4B98-AF3E-11B1772D8CD1@hibernate.org> Hey all, I?ve been exploring making life easier for people using Hibernate ORM in cloud environments where the DB might be started or ready after the Hibernate ORM application has been started Here is the pull request https://github.com/hibernate/hibernate-orm/pull/1804 Feedback on the work so far very welcome :) Emmanuel From emmanuel at hibernate.org Mon Feb 27 07:39:47 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 27 Feb 2017 13:39:47 +0100 Subject: [hibernate-dev] [hibernate-demos] PR and issues and what to do about it Message-ID: There has been an effort to collect demos under a single repo. https://github.com/hibernate/hibernate-demos The good news is that people seem to like it enough that they send pull requests and issue reports to improve it. The bad news is that we did not reply to them. I think it?s because no one is notified of these. Can anyone enlist and be the guardian or even just the dispatcher for this kind of feedback? I?ve cleaned up and applied a couple of pull requests today. Emmanuel From chris at hibernate.org Mon Feb 27 08:22:09 2017 From: chris at hibernate.org (Chris Cranford) Date: Mon, 27 Feb 2017 08:22:09 -0500 Subject: [hibernate-dev] [hibernate-demos] PR and issues and what to do about it In-Reply-To: References: Message-ID: <91d99153-e175-b475-6c49-c5f7b37a410a@hibernate.org> Emmanuel - I don't mind. It's simple enough to check the PR tab couple times daily :). On 02/27/2017 07:39 AM, Emmanuel Bernard wrote: > There has been an effort to collect demos under a single repo. > https://github.com/hibernate/hibernate-demos > > The good news is that people seem to like it enough that they send pull requests and issue reports to improve it. The bad news is that we did not reply to them. I think it?s because no one is notified of these. Can anyone enlist and be the guardian or even just the dispatcher for this kind of feedback? > > I?ve cleaned up and applied a couple of pull requests today. > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Mon Feb 27 08:54:00 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 27 Feb 2017 14:54:00 +0100 Subject: [hibernate-dev] [hibernate-demos] PR and issues and what to do about it In-Reply-To: <91d99153-e175-b475-6c49-c5f7b37a410a@hibernate.org> References: <91d99153-e175-b475-6c49-c5f7b37a410a@hibernate.org> Message-ID: Not sure whether you are joking or not, so just in case :) You'll get notifications on new PRs when "watching" a repo: https://help.github.com/articles/watching-repositories/ --Gunnar 2017-02-27 14:22 GMT+01:00 Chris Cranford : > Emmanuel - > > I don't mind. It's simple enough to check the PR tab couple times daily :). > > On 02/27/2017 07:39 AM, Emmanuel Bernard wrote: >> There has been an effort to collect demos under a single repo. >> https://github.com/hibernate/hibernate-demos >> >> The good news is that people seem to like it enough that they send pull requests and issue reports to improve it. The bad news is that we did not reply to them. I think it?s because no one is notified of these. Can anyone enlist and be the guardian or even just the dispatcher for this kind of feedback? >> >> I?ve cleaned up and applied a couple of pull requests today. >> >> Emmanuel >> _______________________________________________ >> 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 chris at hibernate.org Mon Feb 27 09:48:52 2017 From: chris at hibernate.org (Chris Cranford) Date: Mon, 27 Feb 2017 09:48:52 -0500 Subject: [hibernate-dev] [hibernate-demos] PR and issues and what to do about it In-Reply-To: References: <91d99153-e175-b475-6c49-c5f7b37a410a@hibernate.org> Message-ID: <4b5bced7-bf98-3777-af0d-e4e43e69ab58@hibernate.org> You'll never know ;) On 02/27/2017 08:54 AM, Gunnar Morling wrote: > Not sure whether you are joking or not, so just in case :) > > You'll get notifications on new PRs when "watching" a repo: > > https://help.github.com/articles/watching-repositories/ > > --Gunnar > > > 2017-02-27 14:22 GMT+01:00 Chris Cranford : >> Emmanuel - >> >> I don't mind. It's simple enough to check the PR tab couple times daily :). >> >> On 02/27/2017 07:39 AM, Emmanuel Bernard wrote: >>> There has been an effort to collect demos under a single repo. >>> https://github.com/hibernate/hibernate-demos >>> >>> The good news is that people seem to like it enough that they send pull requests and issue reports to improve it. The bad news is that we did not reply to them. I think it?s because no one is notified of these. Can anyone enlist and be the guardian or even just the dispatcher for this kind of feedback? >>> >>> I?ve cleaned up and applied a couple of pull requests today. >>> >>> Emmanuel >>> _______________________________________________ >>> 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 Feb 27 10:51:56 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 27 Feb 2017 09:51:56 -0600 Subject: [hibernate-dev] 6.0 - Proposed org.hibernate.mapping changes In-Reply-To: References: Message-ID: No replies, so changing... On Mon, Feb 20, 2017 at 11:02 AM, Steve Ebersole wrote: > For 6.0, what do y'all think of these changes proposed below to the > org.hibernate.mapping package? > > *Koen, this affects tools so really would like your thoughts...* > > Mostly this comes from the definition of a `#finishInitialization` method > on ManagedTypeImplementor (which covers mapped-superclass, entity and > embeddable/embedded). Currently this method takes its supertype as > PersistentClass; however PersistentClass is generally understood to model > an entity and tooling certainly uses it as such. Keeping this in mind to > hopefully minimize impact I propose the following: > > > 1. Define a new org.hibernate.mapping.ManagedTypeMapping that > represents mappings for any "managed type" in the normal JPA meaning of > that term (mapped-superclass, entity, embeddable) > 2. Define a new org.hibernate.mapping.EmbeddedTypeMapping extending > ManagedTypeMapping (org.hibernate.mapping.Composite). Or should we > split EmbeddableTypeMapping and "EmbeddedMapping"? > 3. Define a new org.hibernate.mapping.IdentifiableTypeMapping > extending ManagedTypeMapping > 4. Define a new org.hibernate.mapping.MappedSuperclassTypeMapping > extending IdentifiableTypeMapping > 5. Define a new org.hibernate.mapping.EntityTypeMapping extending > IdentifiableTypeMapping > 6. Make PersistentClass extend EntityTypeMapping and deprecate > 7. Make Composite extend EmbeddedTypeMapping and deprecate > 8. Make MapppedSuperclass extend MappedSuperclassTypeMapping and > deprecate > 9. Re-work the hierarchies here to better fit this new model > > > /** > * ... > * > * @todo (6.0) Use ManagedTypeMapping here as super-type rather than > PersistentClass > */ > void finishInitialization( > ManagedTypeImplementor superType, > PersistentClass entityBinding, > PersisterCreationContext creationContext); > From guillaume.smet at gmail.com Tue Feb 28 10:05:47 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 28 Feb 2017 16:05:47 +0100 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, The minutes are there: 16:03 < jbott> Ending meeting. Generating minutes. Be patient :) 16:03 < jbott> Meeting ended Tue Feb 28 15:03:46 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:03 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-02-28-14.11.html 16:03 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-02-28-14.11.txt 16:03 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-02-28-14.11.log.html The start of the meeting (Davide's part) is missing. Here it is: 15:02 < gsmet> #topic Progress Davide 15:02 < gmorling> i can literally hear the cracking of @gsmet?s whip ;) 15:02 < DavideD> So this week I clean up a bit the Hibernate OGM documentation and added a testcase to check the mapping in the remote case 15:03 -!- hardy [~hardy at redhat/jboss/hardy] has quit [Read error: Connection reset by peer] 15:03 < DavideD> The idea is to release 5.1.Final today so that I can start to include the changes for 5.2 15:03 -!- hardy [~hardy at redhat/jboss/hardy] has joined #hibernate-dev 15:03 < gsmet> OK, cool 15:03 < DavideD> While doing that I found an error in the mapping for Neo4j 15:03 -!- rvansa [rvansa at nat/redhat/x-zpsbqauumvnztuke] has quit [Ping timeout: 260 seconds] 15:04 < DavideD> So It slowed me down a bit, but It should have been fix now and I'm sending a PR 15:04 < gmorling> cool with the release; what version of orm is it based on again? 15:04 < emmanuel> @DavideD I had a discussion with Sanne on 5.2 as there seem there was confusion on what 5.2 was vs 5.3 15:04 -!- sannegrinovero_ [~sannegrin at redhat/jboss/sannegrinovero] has joined #hibernate-dev 15:04 < gsmet> DavideD: a new PR on top of what has already been committed this morning? 15:04 < DavideD> gsmet, yes 15:04 < emmanuel> make sure to check again the paper midnmap picture that we took at the f2f 15:04 < gsmet> ok 15:04 < sannegrinovero_> hi all 15:05 < DavideD> I've figured out why the bolt job is not working 15:05 < gsmet> ah, cool, curious to see that :) 15:05 < emmanuel> gmorling: only 5.3 will move to a new ORM version 15:05 < emmanuel> (could be 5.4 if the ISPN 9 work is done first :)) 15:06 < DavideD> gmorling, OGM 5.1 is based on ORM 5.1.2 15:06 < gmorling> ok, thanks 15:06 < DavideD> emmanuel, ok 15:06 < gsmet> DavideD: maybe it could be bumped to 5.1.4? 15:06 < gsmet> would make sense before the final release 15:06 < sannegrinovero_> +1 15:07 < DavideD> ok 15:06 < sannegrinovero_> +1 15:07 < DavideD> ok 15:07 < DavideD> I also spent some time On CI 15:08 < DavideD> Now the website job can be run in parallel with the other jobs 15:08 < gsmet> is it the same for the blog? 15:08 < DavideD> I removed the Blueocean plugin and updated the git plugins 15:08 < DavideD> yes, the blog as well 15:08 < gsmet> cool! 15:08 < DavideD> but if you see that one job does not run in parallel 15:08 < DavideD> you can change the weight 15:09 < sannegrinovero_> FYI I updated the git plugins as well.. yesterday. 15:09 < gsmet> ok 15:09 < DavideD> for example, I didn't update the weight of the release jobs 15:09 < gsmet> ok so now, they are really up to date :) 15:10 < DavideD> well OK 15:10 < DavideD> I think that's all from me 15:10 < gsmet> ok, thanks 15:10 < DavideD> After the release 15:10 < gsmet> #topic Next 2 weeks Davide 15:10 < DavideD> I need to create the new repository for the contrib dialects