From davide at hibernate.org Tue Feb 2 07:46:45 2016 From: davide at hibernate.org (Davide D'Alto) Date: Tue, 2 Feb 2016 12:46:45 +0000 Subject: [hibernate-dev] HipChat rooms Message-ID: Hi, lately there is some interest in OrientDB for Hibernate OGM. This is not currently in the OGM roadmap but I wanted to help potential contributros. I've createad a room for OGM-855 using the JIRA funcitonality accessible by Guests. It seems though theat Guest cannot see the log of the room and that when a user send me an invite it becomes part of the hibernate team. Is that OK? Or do we have some limitation about accepting new users? Am I doing something wrong? Cheers, Davide From davide at hibernate.org Tue Feb 2 07:49:57 2016 From: davide at hibernate.org (Davide D'Alto) Date: Tue, 2 Feb 2016 12:49:57 +0000 Subject: [hibernate-dev] HipChat rooms In-Reply-To: References: Message-ID: I was wrong about the log for guests, the HipChat documentation states: "The room's chat history, including files, are only visible to guests from the point they logged in. " So, it's better than I thought On Tue, Feb 2, 2016 at 12:46 PM, Davide D'Alto wrote: > Hi, > lately there is some interest in OrientDB for Hibernate OGM. > This is not currently in the OGM roadmap but I wanted to help potential > contributros. > > I've createad a room for OGM-855 using the JIRA funcitonality accessible > by Guests. > It seems though theat Guest cannot see the log of the room and that when a > user send me an invite it becomes part of the hibernate team. > > Is that OK? Or do we have some limitation about accepting new users? > Am I doing something wrong? > > Cheers, > Davide > From sanne at hibernate.org Tue Feb 2 09:24:21 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 2 Feb 2016 14:24:21 +0000 Subject: [hibernate-dev] HipChat rooms In-Reply-To: References: Message-ID: +1 to approve any reasonable request to join us. I think the functionality is there only to be prevent spammers and kick out misbehaving people; we have no intent of keeping any goodwilling developer out. On 2 February 2016 at 12:49, Davide D'Alto wrote: > I was wrong about the log for guests, the HipChat documentation states: > > "The room's chat history, including files, are only visible to guests from > the point they logged in. " > > So, it's better than I thought > > > On Tue, Feb 2, 2016 at 12:46 PM, Davide D'Alto wrote: > >> Hi, >> lately there is some interest in OrientDB for Hibernate OGM. >> This is not currently in the OGM roadmap but I wanted to help potential >> contributros. >> >> I've createad a room for OGM-855 using the JIRA funcitonality accessible >> by Guests. >> It seems though theat Guest cannot see the log of the room and that when a >> user send me an invite it becomes part of the hibernate team. >> >> Is that OK? Or do we have some limitation about accepting new users? >> Am I doing something wrong? >> >> Cheers, >> Davide >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Tue Feb 2 09:38:53 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 2 Feb 2016 15:38:53 +0100 Subject: [hibernate-dev] HipChat rooms In-Reply-To: References: Message-ID: <73D4A502-8554-438C-BEB0-FFC94BEBF11A@hibernate.org> +1, this is not for the hibernate team. Rather for everyone. > On 02 Feb 2016, at 15:24, Sanne Grinovero wrote: > > +1 to approve any reasonable request to join us. > I think the functionality is there only to be prevent spammers and > kick out misbehaving people; we have no intent of keeping any > goodwilling developer out. > > On 2 February 2016 at 12:49, Davide D'Alto wrote: >> I was wrong about the log for guests, the HipChat documentation states: >> >> "The room's chat history, including files, are only visible to guests from >> the point they logged in. " >> >> So, it's better than I thought >> >> >> On Tue, Feb 2, 2016 at 12:46 PM, Davide D'Alto wrote: >> >>> Hi, >>> lately there is some interest in OrientDB for Hibernate OGM. >>> This is not currently in the OGM roadmap but I wanted to help potential >>> contributros. >>> >>> I've createad a room for OGM-855 using the JIRA funcitonality accessible >>> by Guests. >>> It seems though theat Guest cannot see the log of the room and that when a >>> user send me an invite it becomes part of the hibernate team. >>> >>> Is that OK? Or do we have some limitation about accepting new users? >>> Am I doing something wrong? >>> >>> Cheers, >>> 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 guillaume.smet at gmail.com Tue Feb 2 09:40:59 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 2 Feb 2016 15:40:59 +0100 Subject: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded Message-ID: Hi, While playing with ElasticSearch faceting (and having tests failing due to that), I noticed that for Longs and Dates, the preexisting range faceting doesn't take into account facetRequest.hasZeroCountsIncluded(). See https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/query/engine/impl/QueryHits.java#L308 and a few lines below for floating point ranges which take into account this very parameter. Is this something expected? Should I prepare a PR to fix it? -- Guillaume From guillaume.smet at gmail.com Tue Feb 2 09:46:44 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 2 Feb 2016 15:46:44 +0100 Subject: [hibernate-dev] [Search] Travis support In-Reply-To: References: Message-ID: Hi, FWIW, I also added Travis support to OGM (mostly to see if we could do it easily with all the NoSQL databases supported) here: https://travis-ci.org/gsmet/hibernate-ogm/ https://github.com/gsmet/hibernate-ogm/blob/travis-support/.travis.yml What I also find interesting in Travis is that you can easily enable CI for your own fork once the .travis.yml is committed to the main repository. -- Guillaume On Thu, Jan 28, 2016 at 6:26 PM, Guillaume Smet wrote: > Hi Sanne, > > On Thu, Jan 28, 2016 at 3:23 PM, Sanne Grinovero > wrote: > >> I am a bit skeptical as we have CI working already on ci.hibernate.org >> and having limited people we can't really afford to fix things which >> already work. >> > > I perfectly understand that. I wanted to experiment it without bothering > you about it. > > >> To summarize what I like of Travis: >> - simple configuration >> - not much maintenance from our side >> - your recommendation counts >> - they pay the bills? >> - you say that it's very popular among Java developers. >> >> About the popularity point, you surprised me. I honestly thought that >> we should stay on Jenkins because that was the most popular one. Do >> you have some data to back that nowadays people are more familiar with >> Travis? >> > > It's very widespread in the Open Source projects running on GitHub, either > in Java, Ruby, PHP, Python and so on. > > HikariCP for instance uses Travis and there are a lot of others projects > using it: https://github.com/brettwooldridge/HikariCP . > > We use Jenkins at my company too for our private projects but we use > Travis for our Open Source ones. > > >> Finally I have been burned several times by not having "root access" >> on the whole thing. I guess Docker might make this reasoning moot now, >> but it's something to consider. >> It's also quite important that we make sure our releases are created >> in a reliable environment, so there's the trust issue of delegating >> the keys to the kingdom to a third party. I'd even like it we could >> start "signing" the artifacts we release as some users mentioned that >> this would be important for them. >> > > Yes, Travis won't replace the release tasks. I think it's good for the day > to day builds and PR builds and we should only use it for that - if we > decide to use it. > > >> Sorry to be skeptical, I didn't mean to stress the negative aspects >> but to clarify that there are many aspects to consider for such a >> move. >> I'm definitely open to consider using it for a subset of jobs, like >> you mentioned the PR review system might be a good fit. >> It's also a good thing for sure to test in additional environments: >> can it also run jobs on Windows and OSX ? We're missing that.. we >> could fix the lack of Windows via AWS but that has a steep price tag.. >> I'll rather volunteer an old laptop from home. >> > > They have OSX support but it's sparse. It's mostly here to test MacOS and > iOS apps. They don't have Windows support. > > -- > Guillaume > > From steve at hibernate.org Tue Feb 2 16:10:40 2016 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 02 Feb 2016 21:10:40 +0000 Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date) In-Reply-To: References: <56900F9A.2010305@redhat.com> <569077E3.9070201@redhat.com> <56952518.4090700@redhat.com> Message-ID: Part of the work here is going to require significant changes to org.hibernate.tool.hbm2ddl.SchemaExport, org.hibernate.tool.hbm2ddl.SchemaUpdate and org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current usages would not work at all. So does it make sense to do those changes, or to simply drop those classes? On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole wrote: > I am debating with myself about > reusing `javax.persistence.schema-generation.database.action` and `javax.persistence.schema-generation.scripts.action` > in terms of this new unified support. The debate point being the fact that > we'd have to have those accept an extended range of values which > potentially hurts users in terms of JPA provider portability. For example, > if they have: > > javax.persistence.schema-generation.database.action=validate > > Hibernate would understand that, but other providers likely would not. > This is beyond the concept of "strict compliance" I started in SQM in my > opinion. Here we are moving toward a unification, meaning we expect people > to use this. > > So do we reuse the JPA names? > > On a related note.. in regards to the fact that JPA splits action between > script and database target whereas hbm2ddl defines just a singular action > value... does anyone know of a real case where someone defines different > actions between script and database? I mean aside from one being NONE. I > mean cases where they say we should do "create" for scripts but send > "drop-and-create" to the database? That just seems odd to me. I think we > have to account for the split since we have to account for JPA, and that > model fits both. I was just curious > > > > > On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole > wrote: > >> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling >> wrote: >> >>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole : >>> > I also plan on adding an @Incubating annotation for just such things :) >>> >>> Yes, please. We have an annotation @Experimental in OGM which we use >>> for tagging APIs under development. >>> >> >> See https://hibernate.atlassian.net/browse/HHH-10487. I also started a >> separate discussion about this on the dev list. >> >> >> BTW, as an extension to changing SchemaManagementTool another thing I'd >> like to add is some hook account for Envers use cases. Specifically the >> idea there is to be able to do a few things: >> 1) perform a selective create/drop. selective in terms of just certain >> objects. This may be achievable through the new filter concept, although >> we'd at least need a way to identify Envers tables from non-Envers tables. >> Think of starting to use Hibernate+Envers on a schema that already exists. >> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps it >> is more of a SessionFactory boot concept. But one thing Envers misses >> today that would be good to add is the ability to "prime" the audit >> tables. Meaning, for audited entities that do not have entries in their >> audit table, create one. This for sure goes beyond simple SQL statements >> though. >> > From dreborier at gmail.com Tue Feb 2 16:21:34 2016 From: dreborier at gmail.com (andrea boriero) Date: Tue, 2 Feb 2016 21:21:34 +0000 Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date) In-Reply-To: References: <56900F9A.2010305@redhat.com> <569077E3.9070201@redhat.com> <56952518.4090700@redhat.com> Message-ID: i think it's better to drop On 2 February 2016 at 21:10, Steve Ebersole wrote: > Part of the work here is going to require significant changes > to org.hibernate.tool.hbm2ddl.SchemaExport, > org.hibernate.tool.hbm2ddl.SchemaUpdate > and org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current > usages would not work at all. So does it make sense to do those changes, > or to simply drop those classes? > > > On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole > wrote: > > > I am debating with myself about > > reusing `javax.persistence.schema-generation.database.action` and > `javax.persistence.schema-generation.scripts.action` > > in terms of this new unified support. The debate point being the fact > that > > we'd have to have those accept an extended range of values which > > potentially hurts users in terms of JPA provider portability. For > example, > > if they have: > > > > javax.persistence.schema-generation.database.action=validate > > > > Hibernate would understand that, but other providers likely would not. > > This is beyond the concept of "strict compliance" I started in SQM in my > > opinion. Here we are moving toward a unification, meaning we expect > people > > to use this. > > > > So do we reuse the JPA names? > > > > On a related note.. in regards to the fact that JPA splits action between > > script and database target whereas hbm2ddl defines just a singular action > > value... does anyone know of a real case where someone defines different > > actions between script and database? I mean aside from one being NONE. > I > > mean cases where they say we should do "create" for scripts but send > > "drop-and-create" to the database? That just seems odd to me. I think > we > > have to account for the split since we have to account for JPA, and that > > model fits both. I was just curious > > > > > > > > > > On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole > > wrote: > > > >> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling > >> wrote: > >> > >>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole : > >>> > I also plan on adding an @Incubating annotation for just such things > :) > >>> > >>> Yes, please. We have an annotation @Experimental in OGM which we use > >>> for tagging APIs under development. > >>> > >> > >> See https://hibernate.atlassian.net/browse/HHH-10487. I also started a > >> separate discussion about this on the dev list. > >> > >> > >> BTW, as an extension to changing SchemaManagementTool another thing I'd > >> like to add is some hook account for Envers use cases. Specifically the > >> idea there is to be able to do a few things: > >> 1) perform a selective create/drop. selective in terms of just certain > >> objects. This may be achievable through the new filter concept, > although > >> we'd at least need a way to identify Envers tables from non-Envers > tables. > >> Think of starting to use Hibernate+Envers on a schema that already > exists. > >> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps it > >> is more of a SessionFactory boot concept. But one thing Envers misses > >> today that would be good to add is the ability to "prime" the audit > >> tables. Meaning, for audited entities that do not have entries in their > >> audit table, create one. This for sure goes beyond simple SQL > statements > >> though. > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Wed Feb 3 01:58:27 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 3 Feb 2016 07:58:27 +0100 Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date) In-Reply-To: References: <56900F9A.2010305@redhat.com> <569077E3.9070201@redhat.com> <56952518.4090700@redhat.com> Message-ID: When you say dropping, what would be the alternative for CLI users? It seems like a strong change to do in a minor revision. What are the required changes you need to do here? My hope would have been that the API of these tools would not have to change. 2016-02-02 22:10 GMT+01:00 Steve Ebersole : > Part of the work here is going to require significant changes to > org.hibernate.tool.hbm2ddl.SchemaExport, > org.hibernate.tool.hbm2ddl.SchemaUpdate and > org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current > usages would not work at all. So does it make sense to do those changes, or > to simply drop those classes? > > > On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole wrote: >> >> I am debating with myself about reusing >> `javax.persistence.schema-generation.database.action` and >> `javax.persistence.schema-generation.scripts.action` in terms of this new >> unified support. The debate point being the fact that we'd have to have >> those accept an extended range of values which potentially hurts users in >> terms of JPA provider portability. For example, if they have: >> >> javax.persistence.schema-generation.database.action=validate >> >> Hibernate would understand that, but other providers likely would not. >> This is beyond the concept of "strict compliance" I started in SQM in my >> opinion. Here we are moving toward a unification, meaning we expect people >> to use this. >> >> So do we reuse the JPA names? >> >> On a related note.. in regards to the fact that JPA splits action between >> script and database target whereas hbm2ddl defines just a singular action >> value... does anyone know of a real case where someone defines different >> actions between script and database? I mean aside from one being NONE. I >> mean cases where they say we should do "create" for scripts but send >> "drop-and-create" to the database? That just seems odd to me. I think we >> have to account for the split since we have to account for JPA, and that >> model fits both. I was just curious >> >> >> >> >> On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole >> wrote: >>> >>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling >>> wrote: >>>> >>>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole : >>>> > I also plan on adding an @Incubating annotation for just such things >>>> > :) >>>> >>>> Yes, please. We have an annotation @Experimental in OGM which we use >>>> for tagging APIs under development. >>> >>> >>> See https://hibernate.atlassian.net/browse/HHH-10487. I also started a >>> separate discussion about this on the dev list. >>> >>> >>> BTW, as an extension to changing SchemaManagementTool another thing I'd >>> like to add is some hook account for Envers use cases. Specifically the >>> idea there is to be able to do a few things: >>> 1) perform a selective create/drop. selective in terms of just certain >>> objects. This may be achievable through the new filter concept, although >>> we'd at least need a way to identify Envers tables from non-Envers tables. >>> Think of starting to use Hibernate+Envers on a schema that already exists. >>> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps it >>> is more of a SessionFactory boot concept. But one thing Envers misses today >>> that would be good to add is the ability to "prime" the audit tables. >>> Meaning, for audited entities that do not have entries in their audit table, >>> create one. This for sure goes beyond simple SQL statements though. From emmanuel at hibernate.org Wed Feb 3 03:15:31 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 3 Feb 2016 09:15:31 +0100 Subject: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded In-Reply-To: References: Message-ID: <20160203081531.GM96313@hibernate.org> It's probably a bug, Hardy, you confirm? On Tue 2016-02-02 15:40, Guillaume Smet wrote: > Hi, > > While playing with ElasticSearch faceting (and having tests failing due to > that), I noticed that for Longs and Dates, the preexisting range faceting > doesn't take into account facetRequest.hasZeroCountsIncluded(). > > See > https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/query/engine/impl/QueryHits.java#L308 > and a few lines below for floating point ranges which take into account > this very parameter. > > Is this something expected? Should I prepare a PR to fix it? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Wed Feb 3 03:32:49 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 3 Feb 2016 09:32:49 +0100 Subject: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded In-Reply-To: <20160203081531.GM96313@hibernate.org> References: <20160203081531.GM96313@hibernate.org> Message-ID: Guillaume, just in case, if you plan to work on stuff around the ES backend, I'd recommend you do so based on my pending PR https://github.com/hibernate/hibernate-search/pull/960. This changes quit a bit, so you may be in merge hell otherwise. 2016-02-03 9:15 GMT+01:00 Emmanuel Bernard : > It's probably a bug, Hardy, you confirm? > > On Tue 2016-02-02 15:40, Guillaume Smet wrote: >> Hi, >> >> While playing with ElasticSearch faceting (and having tests failing due to >> that), I noticed that for Longs and Dates, the preexisting range faceting >> doesn't take into account facetRequest.hasZeroCountsIncluded(). >> >> See >> https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/query/engine/impl/QueryHits.java#L308 >> and a few lines below for floating point ranges which take into account >> this very parameter. >> >> Is this something expected? Should I prepare a PR to fix it? >> >> -- >> 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 hardy at hibernate.org Wed Feb 3 05:45:57 2016 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 3 Feb 2016 11:45:57 +0100 Subject: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded In-Reply-To: <20160203081531.GM96313@hibernate.org> References: <20160203081531.GM96313@hibernate.org> Message-ID: <20160203104557.GA96181@Nineveh.local> Hi, On Wed, Feb 03, 2016 at 09:15:31AM +0100, Emmanuel Bernard wrote: > It's probably a bug, Hardy, you confirm? Sounds like an oversight. I would add it, make sure tests still pass and add some new ones ;-) --Hardy > > On Tue 2016-02-02 15:40, Guillaume Smet wrote: > > Hi, > > > > While playing with ElasticSearch faceting (and having tests failing due to > > that), I noticed that for Longs and Dates, the preexisting range faceting > > doesn't take into account facetRequest.hasZeroCountsIncluded(). > > > > See > > https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/query/engine/impl/QueryHits.java#L308 > > and a few lines below for floating point ranges which take into account > > this very parameter. > > > > Is this something expected? Should I prepare a PR to fix it? > > > > -- > > Guillaume > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20160203/a9409b8e/attachment.bin From guillaume.smet at gmail.com Wed Feb 3 06:10:55 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 3 Feb 2016 12:10:55 +0100 Subject: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded In-Reply-To: <20160203104557.GA96181@Nineveh.local> References: <20160203081531.GM96313@hibernate.org> <20160203104557.GA96181@Nineveh.local> Message-ID: On Wed, Feb 3, 2016 at 11:45 AM, Hardy Ferentschik wrote: > Sounds like an oversight. I would add it, make sure tests still pass and > add some new ones ;-) > Will do. Thanks for the confirmation. From sanne at hibernate.org Wed Feb 3 06:13:53 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 3 Feb 2016 11:13:53 +0000 Subject: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded In-Reply-To: References: <20160203081531.GM96313@hibernate.org> <20160203104557.GA96181@Nineveh.local> Message-ID: Good catch! Make sure to open a JIRA issue as first step, to not forget about this even in case you get distracted. On 3 February 2016 at 11:10, Guillaume Smet wrote: > On Wed, Feb 3, 2016 at 11:45 AM, Hardy Ferentschik > wrote: > >> Sounds like an oversight. I would add it, make sure tests still pass and >> add some new ones ;-) >> > > Will do. > > Thanks for the confirmation. > _______________________________________________ > 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 3 06:19:57 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 3 Feb 2016 12:19:57 +0100 Subject: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded In-Reply-To: References: <20160203081531.GM96313@hibernate.org> <20160203104557.GA96181@Nineveh.local> Message-ID: On Wed, Feb 3, 2016 at 12:13 PM, Sanne Grinovero wrote: > Good catch! > Make sure to open a JIRA issue as first step, to not forget about this > even in case you get distracted. > I'm in the process of opening it :). From guillaume.smet at gmail.com Wed Feb 3 06:49:03 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 3 Feb 2016 12:49:03 +0100 Subject: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded In-Reply-To: References: <20160203081531.GM96313@hibernate.org> Message-ID: On Wed, Feb 3, 2016 at 9:32 AM, Gunnar Morling wrote: > Guillaume, just in case, if you plan to work on stuff around the ES > backend, I'd recommend you do so based on my pending PR > https://github.com/hibernate/hibernate-search/pull/960. This changes > quit a bit, so you may be in merge hell otherwise. > Yes, I have seen it and I have based my work on it! Cheers. From steve at hibernate.org Wed Feb 3 07:50:26 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 03 Feb 2016 12:50:26 +0000 Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date) In-Reply-To: References: <56900F9A.2010305@redhat.com> <569077E3.9070201@redhat.com> <56952518.4090700@redhat.com> Message-ID: The API does need to change. So we can leave the classes, but every usage of them would need to be adjusted. Well every usage other than CLI, which you mention, which is a decent point. So I'll leave the classes in place, but change the contracts. On Wed, Feb 3, 2016 at 12:58 AM Gunnar Morling wrote: > When you say dropping, what would be the alternative for CLI users? It > seems like a strong change to do in a minor revision. > > What are the required changes you need to do here? My hope would have > been that the API of these tools would not have to change. > > 2016-02-02 22:10 GMT+01:00 Steve Ebersole : > > Part of the work here is going to require significant changes to > > org.hibernate.tool.hbm2ddl.SchemaExport, > > org.hibernate.tool.hbm2ddl.SchemaUpdate and > > org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current > > usages would not work at all. So does it make sense to do those > changes, or > > to simply drop those classes? > > > > > > On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole > wrote: > >> > >> I am debating with myself about reusing > >> `javax.persistence.schema-generation.database.action` and > >> `javax.persistence.schema-generation.scripts.action` in terms of this > new > >> unified support. The debate point being the fact that we'd have to have > >> those accept an extended range of values which potentially hurts users > in > >> terms of JPA provider portability. For example, if they have: > >> > >> javax.persistence.schema-generation.database.action=validate > >> > >> Hibernate would understand that, but other providers likely would not. > >> This is beyond the concept of "strict compliance" I started in SQM in my > >> opinion. Here we are moving toward a unification, meaning we expect > people > >> to use this. > >> > >> So do we reuse the JPA names? > >> > >> On a related note.. in regards to the fact that JPA splits action > between > >> script and database target whereas hbm2ddl defines just a singular > action > >> value... does anyone know of a real case where someone defines different > >> actions between script and database? I mean aside from one being > NONE. I > >> mean cases where they say we should do "create" for scripts but send > >> "drop-and-create" to the database? That just seems odd to me. I think > we > >> have to account for the split since we have to account for JPA, and that > >> model fits both. I was just curious > >> > >> > >> > >> > >> On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole > >> wrote: > >>> > >>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling > >>> wrote: > >>>> > >>>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole : > >>>> > I also plan on adding an @Incubating annotation for just such things > >>>> > :) > >>>> > >>>> Yes, please. We have an annotation @Experimental in OGM which we use > >>>> for tagging APIs under development. > >>> > >>> > >>> See https://hibernate.atlassian.net/browse/HHH-10487. I also started > a > >>> separate discussion about this on the dev list. > >>> > >>> > >>> BTW, as an extension to changing SchemaManagementTool another thing > I'd > >>> like to add is some hook account for Envers use cases. Specifically > the > >>> idea there is to be able to do a few things: > >>> 1) perform a selective create/drop. selective in terms of just certain > >>> objects. This may be achievable through the new filter concept, > although > >>> we'd at least need a way to identify Envers tables from non-Envers > tables. > >>> Think of starting to use Hibernate+Envers on a schema that already > exists. > >>> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps > it > >>> is more of a SessionFactory boot concept. But one thing Envers misses > today > >>> that would be good to add is the ability to "prime" the audit tables. > >>> Meaning, for audited entities that do not have entries in their audit > table, > >>> create one. This for sure goes beyond simple SQL statements though. > From smarlow at redhat.com Wed Feb 3 08:53:56 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 3 Feb 2016 08:53:56 -0500 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... Message-ID: <56B20674.6040903@redhat.com> As modular classloading environments become more popular (e.g. WildFly, OSGi, Openjdk Jigsaw), it is more important that applications can include their own version of Javassist classes. This is not possible if the application classpath also needs to include the Hibernate (needed) version of Javassist. My question is how would/should this be accomplished? Some proposals are below: 1. Clone the Javassist runtime classes into Hibernate ORM and maintain them as a fork. I don't think this is practical but still wanted to mention it as a possible solution. 2. Stop using the parts of the Javassist api that generate bytecode that depends on the Javassist runtime classes. I have no idea how hard this would be. I don't think we have a jira for this yet, although we have talked about it occasionally for years. Any volunteers to help? Scott From steve at hibernate.org Wed Feb 3 08:58:56 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 03 Feb 2016 13:58:56 +0000 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: <56B20674.6040903@redhat.com> References: <56B20674.6040903@redhat.com> Message-ID: Just as a suggestion, we do not need to go to a "full on" clone for your (1). A fat-jar, shaded-jar, should also do the trick. On Wed, Feb 3, 2016 at 7:54 AM Scott Marlow wrote: > As modular classloading environments become more popular (e.g. WildFly, > OSGi, Openjdk Jigsaw), it is more important that applications can > include their own version of Javassist classes. This is not possible if > the application classpath also needs to include the Hibernate (needed) > version of Javassist. > > My question is how would/should this be accomplished? Some proposals > are below: > > 1. Clone the Javassist runtime classes into Hibernate ORM and maintain > them as a fork. I don't think this is practical but still wanted to > mention it as a possible solution. > > 2. Stop using the parts of the Javassist api that generate bytecode > that depends on the Javassist runtime classes. I have no idea how hard > this would be. > > I don't think we have a jira for this yet, although we have talked about > it occasionally for years. > > Any volunteers to help? > > Scott > _______________________________________________ > 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 3 09:01:25 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 03 Feb 2016 14:01:25 +0000 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: References: <56B20674.6040903@redhat.com> Message-ID: I should point out... The big drawback with that (and with cloning in general since its the Javassist package renaming that is important in both) is that its no longer a simple matter update (bug-fixes, etc) Javassist usage in Hibernate. Its certainly no longer simple as in drop-in the replacement from upstream. On Wed, Feb 3, 2016 at 7:58 AM Steve Ebersole wrote: > Just as a suggestion, we do not need to go to a "full on" clone for your > (1). A fat-jar, shaded-jar, should also do the > trick. > > > On Wed, Feb 3, 2016 at 7:54 AM Scott Marlow wrote: > >> As modular classloading environments become more popular (e.g. WildFly, >> OSGi, Openjdk Jigsaw), it is more important that applications can >> include their own version of Javassist classes. This is not possible if >> the application classpath also needs to include the Hibernate (needed) >> version of Javassist. >> >> My question is how would/should this be accomplished? Some proposals >> are below: >> >> 1. Clone the Javassist runtime classes into Hibernate ORM and maintain >> them as a fork. I don't think this is practical but still wanted to >> mention it as a possible solution. >> >> 2. Stop using the parts of the Javassist api that generate bytecode >> that depends on the Javassist runtime classes. I have no idea how hard >> this would be. >> >> I don't think we have a jira for this yet, although we have talked about >> it occasionally for years. >> >> Any volunteers to help? >> >> Scott >> _______________________________________________ >> 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 3 09:02:32 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 3 Feb 2016 14:02:32 +0000 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: <56B20674.6040903@redhat.com> References: <56B20674.6040903@redhat.com> Message-ID: Hi Scott, I'm missing something here: I think there is a 3rd option which is to not require the user's classpath to "see" the Javassist at all, even though Hibernate uses it. But I've said this before in other context, and yet we're back at discussing only options 1 and 2, so I'm guessing that we either didn't understand each other, or I'm missing some complexity in the use case (I haven't seen the code!). To make progress I think I could try to help out with a proposal, but I can only do that if you could share a unit test. What do you think of that? Of course there's the possibility that I'd give you a solution which is valid only in the specific use case of that single test, but at least it might clarify to you what I have in mind.. an example worth more than a 1000 emails :) Thanks! Sanne On 3 February 2016 at 13:53, Scott Marlow wrote: > As modular classloading environments become more popular (e.g. WildFly, > OSGi, Openjdk Jigsaw), it is more important that applications can > include their own version of Javassist classes. This is not possible if > the application classpath also needs to include the Hibernate (needed) > version of Javassist. > > My question is how would/should this be accomplished? Some proposals > are below: > > 1. Clone the Javassist runtime classes into Hibernate ORM and maintain > them as a fork. I don't think this is practical but still wanted to > mention it as a possible solution. > > 2. Stop using the parts of the Javassist api that generate bytecode > that depends on the Javassist runtime classes. I have no idea how hard > this would be. > > I don't think we have a jira for this yet, although we have talked about > it occasionally for years. > > Any volunteers to help? > > Scott > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Wed Feb 3 09:55:57 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 3 Feb 2016 15:55:57 +0100 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: References: <56B20674.6040903@redhat.com> Message-ID: <20160203145557.GB1495@hibernate.org> Sanne, proxies generated by Hibernate do depend on the Javassist code at runtime. So a lazy object would CNFE if Javassist was not in the classpath. On Wed 2016-02-03 14:02, Sanne Grinovero wrote: > Hi Scott, > I'm missing something here: I think there is a 3rd option which is to > not require the user's classpath to "see" the Javassist at all, even > though Hibernate uses it. > > But I've said this before in other context, and yet we're back at > discussing only options 1 and 2, so I'm guessing that we either didn't > understand each other, or I'm missing some complexity in the use case > (I haven't seen the code!). > > To make progress I think I could try to help out with a proposal, but > I can only do that if you could share a unit test. What do you think > of that? > Of course there's the possibility that I'd give you a solution which > is valid only in the specific use case of that single test, but at > least it might clarify to you what I have in mind.. > > an example worth more than a 1000 emails :) > > Thanks! > Sanne > > On 3 February 2016 at 13:53, Scott Marlow wrote: > > As modular classloading environments become more popular (e.g. WildFly, > > OSGi, Openjdk Jigsaw), it is more important that applications can > > include their own version of Javassist classes. This is not possible if > > the application classpath also needs to include the Hibernate (needed) > > version of Javassist. > > > > My question is how would/should this be accomplished? Some proposals > > are below: > > > > 1. Clone the Javassist runtime classes into Hibernate ORM and maintain > > them as a fork. I don't think this is practical but still wanted to > > mention it as a possible solution. > > > > 2. Stop using the parts of the Javassist api that generate bytecode > > that depends on the Javassist runtime classes. I have no idea how hard > > this would be. > > > > I don't think we have a jira for this yet, although we have talked about > > it occasionally for years. > > > > Any volunteers to help? > > > > Scott > > _______________________________________________ > > 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 3 10:08:26 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 3 Feb 2016 17:08:26 +0200 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: <20160203145557.GB1495@hibernate.org> References: <56B20674.6040903@redhat.com> <20160203145557.GB1495@hibernate.org> Message-ID: Hi, If the user has used bytecode enhancement, the generated transformed entity classes depend on Javassist too, and that's even more complicated because it requires the client to regenerate those classes if we drop support for Javassist. Vlad On Wed, Feb 3, 2016 at 4:55 PM, Emmanuel Bernard wrote: > Sanne, proxies generated by Hibernate do depend on the Javassist code at > runtime. So a lazy object would CNFE if Javassist was not in the > classpath. > > On Wed 2016-02-03 14:02, Sanne Grinovero wrote: > > Hi Scott, > > I'm missing something here: I think there is a 3rd option which is to > > not require the user's classpath to "see" the Javassist at all, even > > though Hibernate uses it. > > > > But I've said this before in other context, and yet we're back at > > discussing only options 1 and 2, so I'm guessing that we either didn't > > understand each other, or I'm missing some complexity in the use case > > (I haven't seen the code!). > > > > To make progress I think I could try to help out with a proposal, but > > I can only do that if you could share a unit test. What do you think > > of that? > > Of course there's the possibility that I'd give you a solution which > > is valid only in the specific use case of that single test, but at > > least it might clarify to you what I have in mind.. > > > > an example worth more than a 1000 emails :) > > > > Thanks! > > Sanne > > > > On 3 February 2016 at 13:53, Scott Marlow wrote: > > > As modular classloading environments become more popular (e.g. WildFly, > > > OSGi, Openjdk Jigsaw), it is more important that applications can > > > include their own version of Javassist classes. This is not possible > if > > > the application classpath also needs to include the Hibernate (needed) > > > version of Javassist. > > > > > > My question is how would/should this be accomplished? Some proposals > > > are below: > > > > > > 1. Clone the Javassist runtime classes into Hibernate ORM and maintain > > > them as a fork. I don't think this is practical but still wanted to > > > mention it as a possible solution. > > > > > > 2. Stop using the parts of the Javassist api that generate bytecode > > > that depends on the Javassist runtime classes. I have no idea how hard > > > this would be. > > > > > > I don't think we have a jira for this yet, although we have talked > about > > > it occasionally for years. > > > > > > Any volunteers to help? > > > > > > Scott > > > _______________________________________________ > > > 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 3 10:09:50 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 3 Feb 2016 15:09:50 +0000 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: <20160203145557.GB1495@hibernate.org> References: <56B20674.6040903@redhat.com> <20160203145557.GB1495@hibernate.org> Message-ID: On 3 February 2016 at 14:55, Emmanuel Bernard wrote: > Sanne, proxies generated by Hibernate do depend on the Javassist code at > runtime. So a lazy object would CNFE if Javassist was not in the > classpath. I get that. But *which classpath* matters. Classes are owned by a specific classloader, and the instrumented code can depend on javassist w/o this requiring the whole of the user code's classloader to include javassist. So I'm not saying that I definitely know how to solve it, but I think it should be possible.. details matter and I don't have them. For the record, people should be able to use JPA in WildFly without being able to see any org.hibernate class too. Sanne > > On Wed 2016-02-03 14:02, Sanne Grinovero wrote: >> Hi Scott, >> I'm missing something here: I think there is a 3rd option which is to >> not require the user's classpath to "see" the Javassist at all, even >> though Hibernate uses it. >> >> But I've said this before in other context, and yet we're back at >> discussing only options 1 and 2, so I'm guessing that we either didn't >> understand each other, or I'm missing some complexity in the use case >> (I haven't seen the code!). >> >> To make progress I think I could try to help out with a proposal, but >> I can only do that if you could share a unit test. What do you think >> of that? >> Of course there's the possibility that I'd give you a solution which >> is valid only in the specific use case of that single test, but at >> least it might clarify to you what I have in mind.. >> >> an example worth more than a 1000 emails :) >> >> Thanks! >> Sanne >> >> On 3 February 2016 at 13:53, Scott Marlow wrote: >> > As modular classloading environments become more popular (e.g. WildFly, >> > OSGi, Openjdk Jigsaw), it is more important that applications can >> > include their own version of Javassist classes. This is not possible if >> > the application classpath also needs to include the Hibernate (needed) >> > version of Javassist. >> > >> > My question is how would/should this be accomplished? Some proposals >> > are below: >> > >> > 1. Clone the Javassist runtime classes into Hibernate ORM and maintain >> > them as a fork. I don't think this is practical but still wanted to >> > mention it as a possible solution. >> > >> > 2. Stop using the parts of the Javassist api that generate bytecode >> > that depends on the Javassist runtime classes. I have no idea how hard >> > this would be. >> > >> > I don't think we have a jira for this yet, although we have talked about >> > it occasionally for years. >> > >> > Any volunteers to help? >> > >> > Scott >> > _______________________________________________ >> > 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 smarlow at redhat.com Wed Feb 3 10:11:24 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 3 Feb 2016 10:11:24 -0500 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: References: <56B20674.6040903@redhat.com> Message-ID: <56B2189C.3060701@redhat.com> On 02/03/2016 09:01 AM, Steve Ebersole wrote: > I should point out... The big drawback with that (and with cloning in > general since its the Javassist package renaming that is important in > both) is that its no longer a simple matter update (bug-fixes, etc) > Javassist usage in Hibernate. Its certainly no longer simple as in > drop-in the replacement from upstream. True, many users like to workaround Javassist issues by dropping a different Javassist version in. > > On Wed, Feb 3, 2016 at 7:58 AM Steve Ebersole > wrote: > > Just as a suggestion, we do not need to go to a "full on" clone for > your (1). A fat-jar, shaded-jar, should > also do the trick. > > > On Wed, Feb 3, 2016 at 7:54 AM Scott Marlow > wrote: > > As modular classloading environments become more popular (e.g. > WildFly, > OSGi, Openjdk Jigsaw), it is more important that applications can > include their own version of Javassist classes. This is not > possible if > the application classpath also needs to include the Hibernate > (needed) > version of Javassist. > > My question is how would/should this be accomplished? Some > proposals > are below: > > 1. Clone the Javassist runtime classes into Hibernate ORM and > maintain > them as a fork. I don't think this is practical but still wanted to > mention it as a possible solution. > > 2. Stop using the parts of the Javassist api that generate bytecode > that depends on the Javassist runtime classes. I have no idea > how hard > this would be. > > I don't think we have a jira for this yet, although we have > talked about > it occasionally for years. > > Any volunteers to help? > > Scott > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From ales.justin at gmail.com Wed Feb 3 10:24:46 2016 From: ales.justin at gmail.com (Ales Justin) Date: Wed, 3 Feb 2016 16:24:46 +0100 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: <56B2189C.3060701@redhat.com> References: <56B20674.6040903@redhat.com> <56B2189C.3060701@redhat.com> Message-ID: <6E3B4BBD-ADF8-4EB0-A42B-BB1A651DB06B@gmail.com> Perhaps check if the Classfilewriter is any better in this concern ? it might not need any own classes in proxies. * https://github.com/jbossas/jboss-classfilewriter (Weld now uses this ? it?s part of WildFly) But this means you would have to write a new Hibernate proxier. (if you don?t have it already) > On 03 Feb 2016, at 16:11, Scott Marlow wrote: > > > On 02/03/2016 09:01 AM, Steve Ebersole wrote: >> I should point out... The big drawback with that (and with cloning in >> general since its the Javassist package renaming that is important in >> both) is that its no longer a simple matter update (bug-fixes, etc) >> Javassist usage in Hibernate. Its certainly no longer simple as in >> drop-in the replacement from upstream. > > True, many users like to workaround Javassist issues by dropping a > different Javassist version in. From smarlow at redhat.com Wed Feb 3 10:27:15 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 3 Feb 2016 10:27:15 -0500 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: References: <56B20674.6040903@redhat.com> <20160203145557.GB1495@hibernate.org> Message-ID: <56B21C53.5090908@redhat.com> On 02/03/2016 10:09 AM, Sanne Grinovero wrote: > On 3 February 2016 at 14:55, Emmanuel Bernard wrote: >> Sanne, proxies generated by Hibernate do depend on the Javassist code at >> runtime. So a lazy object would CNFE if Javassist was not in the >> classpath. > > I get that. But *which classpath* matters. > > Classes are owned by a specific classloader, and the instrumented code > can depend on javassist w/o this requiring the whole of the user > code's classloader to include javassist. The user application code, does need javassist. Look at https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e which is an example of user code needing Javassist. > > So I'm not saying that I definitely know how to solve it, but I think > it should be possible.. details matter and I don't have them. I think that I responded to your previous comments on my WildFly pull request being wrong, since I exported the Javassist classes with Hibernate ORM (so that Hibernate native applications would not get a CNFE). I suspect that the details are too long to read or perhaps I was not clear on that thread. But, my pull request was pretty much shot down so far because Hibernate applications should not be required to have Javassist on the application classpath, as that could conflict with applications that want their own copy of Javassist. > > For the record, people should be able to use JPA in WildFly without > being able to see any org.hibernate class too. Are you saying that only JPA applications that contain a reference to a org.hibernate class should have the Hibernate classes on the application classpath? Or that the Hibernate runtime should not ever expect to find Hibernate classes on the application classpath? > > Sanne > >> >> On Wed 2016-02-03 14:02, Sanne Grinovero wrote: >>> Hi Scott, >>> I'm missing something here: I think there is a 3rd option which is to >>> not require the user's classpath to "see" the Javassist at all, even >>> though Hibernate uses it. >>> >>> But I've said this before in other context, and yet we're back at >>> discussing only options 1 and 2, so I'm guessing that we either didn't >>> understand each other, or I'm missing some complexity in the use case >>> (I haven't seen the code!). >>> >>> To make progress I think I could try to help out with a proposal, but >>> I can only do that if you could share a unit test. What do you think >>> of that? >>> Of course there's the possibility that I'd give you a solution which >>> is valid only in the specific use case of that single test, but at >>> least it might clarify to you what I have in mind.. >>> >>> an example worth more than a 1000 emails :) >>> >>> Thanks! >>> Sanne >>> >>> On 3 February 2016 at 13:53, Scott Marlow wrote: >>>> As modular classloading environments become more popular (e.g. WildFly, >>>> OSGi, Openjdk Jigsaw), it is more important that applications can >>>> include their own version of Javassist classes. This is not possible if >>>> the application classpath also needs to include the Hibernate (needed) >>>> version of Javassist. >>>> >>>> My question is how would/should this be accomplished? Some proposals >>>> are below: >>>> >>>> 1. Clone the Javassist runtime classes into Hibernate ORM and maintain >>>> them as a fork. I don't think this is practical but still wanted to >>>> mention it as a possible solution. >>>> >>>> 2. Stop using the parts of the Javassist api that generate bytecode >>>> that depends on the Javassist runtime classes. I have no idea how hard >>>> this would be. >>>> >>>> I don't think we have a jira for this yet, although we have talked about >>>> it occasionally for years. >>>> >>>> Any volunteers to help? >>>> >>>> Scott >>>> _______________________________________________ >>>> 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 sfikes at redhat.com Wed Feb 3 10:42:02 2016 From: sfikes at redhat.com (Stephen Fikes) Date: Wed, 03 Feb 2016 09:42:02 -0600 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: References: <56B20674.6040903@redhat.com> <20160203145557.GB1495@hibernate.org> Message-ID: <1454514122.29150.2.camel@redhat.com> On Wed, 2016-02-03 at 15:09 +0000, Sanne Grinovero wrote: > For the record, people should be able to use JPA in WildFly without > being able to see any org.hibernate class too. The background of the request/issue was a ClassNotFoundException when using the bundled Hibernate in an application leveraging the "native Hibernate" API (not using JPA). When using JPA, the issue did not occur. This may suggest a solution? From smarlow at redhat.com Wed Feb 3 10:52:22 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 3 Feb 2016 10:52:22 -0500 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: <1454514122.29150.2.camel@redhat.com> References: <56B20674.6040903@redhat.com> <20160203145557.GB1495@hibernate.org> <1454514122.29150.2.camel@redhat.com> Message-ID: <56B22236.7050806@redhat.com> On 02/03/2016 10:42 AM, Stephen Fikes wrote: > On Wed, 2016-02-03 at 15:09 +0000, Sanne Grinovero wrote: >> For the record, people should be able to use JPA in WildFly without >> being able to see any org.hibernate class too. > > The background of the request/issue was a ClassNotFoundException when > using the bundled Hibernate in an application leveraging the "native > Hibernate" API (not using JPA). > > When using JPA, the issue did not occur. > > This may suggest a solution? The WildFly/AS7 JPA container/deployer automatically adds the Hibernate ORM module to the application classpath. However, this doesn't help Hibernate native applications. With OSGi, there is no automatic solution, applications are expected to add Javassist to the application classpath. In other environments, Hibernate applications also need Javassist on the classpath but the other environments are more likely to add Hibernate + Javassist jars to their global classpath. No silver bullet here. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From smarlow at redhat.com Wed Feb 3 11:04:50 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 3 Feb 2016 11:04:50 -0500 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: <56B22236.7050806@redhat.com> References: <56B20674.6040903@redhat.com> <20160203145557.GB1495@hibernate.org> <1454514122.29150.2.camel@redhat.com> <56B22236.7050806@redhat.com> Message-ID: <56B22522.5060608@redhat.com> On 02/03/2016 10:52 AM, Scott Marlow wrote: > > > On 02/03/2016 10:42 AM, Stephen Fikes wrote: >> On Wed, 2016-02-03 at 15:09 +0000, Sanne Grinovero wrote: >>> For the record, people should be able to use JPA in WildFly without >>> being able to see any org.hibernate class too. >> >> The background of the request/issue was a ClassNotFoundException when >> using the bundled Hibernate in an application leveraging the "native >> Hibernate" API (not using JPA). >> >> When using JPA, the issue did not occur. >> >> This may suggest a solution? > > The WildFly/AS7 JPA container/deployer automatically adds the Hibernate > ORM module to the application classpath. However, this doesn't help > Hibernate native applications. The WildFly/AS7 JPA container/deployer also adds the Javassist module to the application classpath as well. > > With OSGi, there is no automatic solution, applications are expected to > add Javassist to the application classpath. > > In other environments, Hibernate applications also need Javassist on the > classpath but the other environments are more likely to add Hibernate + > Javassist jars to their global classpath. > > No silver bullet here. > >> _______________________________________________ >> 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 3 12:21:35 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 03 Feb 2016 17:21:35 +0000 Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date) In-Reply-To: References: <56900F9A.2010305@redhat.com> <569077E3.9070201@redhat.com> <56952518.4090700@redhat.com> Message-ID: For anyone familiar using SchemaExport from the command line... Am I interpreting this correctly when I see that `--create` means "just create" and `--drop` means "just drop"? From what I can tell, passing both seems to (looking at the code) cause just drop to happen. Anyone else find that extremely counter-intuitive? Any objection to instead exposing an `--action` option that can be one of "create", "drop", "create-and-drop", and "none"? And where "create-and-drop" is the default? On Wed, Feb 3, 2016 at 6:50 AM Steve Ebersole wrote: > The API does need to change. So we can leave the classes, but every usage > of them would need to be adjusted. Well every usage other than CLI, which > you mention, which is a decent point. So I'll leave the classes in place, > but change the contracts. > > On Wed, Feb 3, 2016 at 12:58 AM Gunnar Morling > wrote: > >> When you say dropping, what would be the alternative for CLI users? It >> seems like a strong change to do in a minor revision. >> >> What are the required changes you need to do here? My hope would have >> been that the API of these tools would not have to change. >> >> 2016-02-02 22:10 GMT+01:00 Steve Ebersole : >> > Part of the work here is going to require significant changes to >> > org.hibernate.tool.hbm2ddl.SchemaExport, >> > org.hibernate.tool.hbm2ddl.SchemaUpdate and >> > org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current >> > usages would not work at all. So does it make sense to do those >> changes, or >> > to simply drop those classes? >> > >> > >> > On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole >> wrote: >> >> >> >> I am debating with myself about reusing >> >> `javax.persistence.schema-generation.database.action` and >> >> `javax.persistence.schema-generation.scripts.action` in terms of this >> new >> >> unified support. The debate point being the fact that we'd have to >> have >> >> those accept an extended range of values which potentially hurts users >> in >> >> terms of JPA provider portability. For example, if they have: >> >> >> >> javax.persistence.schema-generation.database.action=validate >> >> >> >> Hibernate would understand that, but other providers likely would not. >> >> This is beyond the concept of "strict compliance" I started in SQM in >> my >> >> opinion. Here we are moving toward a unification, meaning we expect >> people >> >> to use this. >> >> >> >> So do we reuse the JPA names? >> >> >> >> On a related note.. in regards to the fact that JPA splits action >> between >> >> script and database target whereas hbm2ddl defines just a singular >> action >> >> value... does anyone know of a real case where someone defines >> different >> >> actions between script and database? I mean aside from one being >> NONE. I >> >> mean cases where they say we should do "create" for scripts but send >> >> "drop-and-create" to the database? That just seems odd to me. I >> think we >> >> have to account for the split since we have to account for JPA, and >> that >> >> model fits both. I was just curious >> >> >> >> >> >> >> >> >> >> On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole >> >> wrote: >> >>> >> >>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling > > >> >>> wrote: >> >>>> >> >>>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole : >> >>>> > I also plan on adding an @Incubating annotation for just such >> things >> >>>> > :) >> >>>> >> >>>> Yes, please. We have an annotation @Experimental in OGM which we use >> >>>> for tagging APIs under development. >> >>> >> >>> >> >>> See https://hibernate.atlassian.net/browse/HHH-10487. I also >> started a >> >>> separate discussion about this on the dev list. >> >>> >> >>> >> >>> BTW, as an extension to changing SchemaManagementTool another thing >> I'd >> >>> like to add is some hook account for Envers use cases. Specifically >> the >> >>> idea there is to be able to do a few things: >> >>> 1) perform a selective create/drop. selective in terms of just >> certain >> >>> objects. This may be achievable through the new filter concept, >> although >> >>> we'd at least need a way to identify Envers tables from non-Envers >> tables. >> >>> Think of starting to use Hibernate+Envers on a schema that already >> exists. >> >>> 2) perform "actions". This is maybe beyond "schema tooling"; perhaps >> it >> >>> is more of a SessionFactory boot concept. But one thing Envers >> misses today >> >>> that would be good to add is the ability to "prime" the audit tables. >> >>> Meaning, for audited entities that do not have entries in their audit >> table, >> >>> create one. This for sure goes beyond simple SQL statements though. >> > From dreborier at gmail.com Wed Feb 3 12:27:58 2016 From: dreborier at gmail.com (andrea boriero) Date: Wed, 3 Feb 2016 17:27:58 +0000 Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date) In-Reply-To: References: <56900F9A.2010305@redhat.com> <569077E3.9070201@redhat.com> <56952518.4090700@redhat.com> Message-ID: +1 for `--action` option with "create", "drop", "create-and-drop", and "none" not sure if as default value is better "create" or "create-and-drop" On 3 February 2016 at 17:21, Steve Ebersole wrote: > For anyone familiar using SchemaExport from the command line... Am I > interpreting this correctly when I see that `--create` means "just create" > and `--drop` means "just drop"? From what I can tell, passing both seems to > (looking at the code) cause just drop to happen. > > Anyone else find that extremely counter-intuitive? Any objection to > instead exposing an `--action` option that can be one of "create", "drop", > "create-and-drop", and "none"? And where "create-and-drop" is the default? > > On Wed, Feb 3, 2016 at 6:50 AM Steve Ebersole wrote: > > > The API does need to change. So we can leave the classes, but every > usage > > of them would need to be adjusted. Well every usage other than CLI, > which > > you mention, which is a decent point. So I'll leave the classes in > place, > > but change the contracts. > > > > On Wed, Feb 3, 2016 at 12:58 AM Gunnar Morling > > wrote: > > > >> When you say dropping, what would be the alternative for CLI users? It > >> seems like a strong change to do in a minor revision. > >> > >> What are the required changes you need to do here? My hope would have > >> been that the API of these tools would not have to change. > >> > >> 2016-02-02 22:10 GMT+01:00 Steve Ebersole : > >> > Part of the work here is going to require significant changes to > >> > org.hibernate.tool.hbm2ddl.SchemaExport, > >> > org.hibernate.tool.hbm2ddl.SchemaUpdate and > >> > org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in current > >> > usages would not work at all. So does it make sense to do those > >> changes, or > >> > to simply drop those classes? > >> > > >> > > >> > On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole > >> wrote: > >> >> > >> >> I am debating with myself about reusing > >> >> `javax.persistence.schema-generation.database.action` and > >> >> `javax.persistence.schema-generation.scripts.action` in terms of this > >> new > >> >> unified support. The debate point being the fact that we'd have to > >> have > >> >> those accept an extended range of values which potentially hurts > users > >> in > >> >> terms of JPA provider portability. For example, if they have: > >> >> > >> >> javax.persistence.schema-generation.database.action=validate > >> >> > >> >> Hibernate would understand that, but other providers likely would > not. > >> >> This is beyond the concept of "strict compliance" I started in SQM in > >> my > >> >> opinion. Here we are moving toward a unification, meaning we expect > >> people > >> >> to use this. > >> >> > >> >> So do we reuse the JPA names? > >> >> > >> >> On a related note.. in regards to the fact that JPA splits action > >> between > >> >> script and database target whereas hbm2ddl defines just a singular > >> action > >> >> value... does anyone know of a real case where someone defines > >> different > >> >> actions between script and database? I mean aside from one being > >> NONE. I > >> >> mean cases where they say we should do "create" for scripts but send > >> >> "drop-and-create" to the database? That just seems odd to me. I > >> think we > >> >> have to account for the split since we have to account for JPA, and > >> that > >> >> model fits both. I was just curious > >> >> > >> >> > >> >> > >> >> > >> >> On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole > > >> >> wrote: > >> >>> > >> >>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling < > gunnar at hibernate.org > >> > > >> >>> wrote: > >> >>>> > >> >>>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole : > >> >>>> > I also plan on adding an @Incubating annotation for just such > >> things > >> >>>> > :) > >> >>>> > >> >>>> Yes, please. We have an annotation @Experimental in OGM which we > use > >> >>>> for tagging APIs under development. > >> >>> > >> >>> > >> >>> See https://hibernate.atlassian.net/browse/HHH-10487. I also > >> started a > >> >>> separate discussion about this on the dev list. > >> >>> > >> >>> > >> >>> BTW, as an extension to changing SchemaManagementTool another thing > >> I'd > >> >>> like to add is some hook account for Envers use cases. Specifically > >> the > >> >>> idea there is to be able to do a few things: > >> >>> 1) perform a selective create/drop. selective in terms of just > >> certain > >> >>> objects. This may be achievable through the new filter concept, > >> although > >> >>> we'd at least need a way to identify Envers tables from non-Envers > >> tables. > >> >>> Think of starting to use Hibernate+Envers on a schema that already > >> exists. > >> >>> 2) perform "actions". This is maybe beyond "schema tooling"; > perhaps > >> it > >> >>> is more of a SessionFactory boot concept. But one thing Envers > >> misses today > >> >>> that would be good to add is the ability to "prime" the audit > tables. > >> >>> Meaning, for audited entities that do not have entries in their > audit > >> table, > >> >>> create one. This for sure goes beyond simple SQL statements though. > >> > > > _______________________________________________ > 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 3 13:03:47 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 03 Feb 2016 18:03:47 +0000 Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1 tentative release date) In-Reply-To: References: <56900F9A.2010305@redhat.com> <569077E3.9070201@redhat.com> <56952518.4090700@redhat.com> Message-ID: Sorry I mean to say "drop-and-create", not "create-and-drop", to follow the JPA. I guess if we are adding this it is a good time to address a confusion between JPA and our action names. So JPA defines an action "create" which we previously did not have in terms of hbm2ddl.auto' JPA's "create" is a "create only". hbm2ddl.auto did also defione a "create" action, but it is equivalent to what JPA calls "drop-and-create", meaning "drop the schema and then (re)create it". I think it is also a good idea to make this consistent with the hbm2ddl.auto options. To account for JPA's "create" I added a new enumeration called "create-only". So in terms of hbm2ddl.auto options we have: * none * create-only * drop * create (which is drop-and-create) * create-drop (drop-and-create + drop on SF-close) * update * validate Ideally we'd consolidate on JPA's terms in regards to create-only/create/drop-and-create, but that would mean a very surprising outcome for people using `hbm2ddl.auto=create` and expecting the legacy behavior. On Wed, Feb 3, 2016 at 11:28 AM andrea boriero wrote: > +1 for `--action` option with "create", "drop", "create-and-drop", and > "none" > not sure if as default value is better "create" or "create-and-drop" > > On 3 February 2016 at 17:21, Steve Ebersole wrote: > >> For anyone familiar using SchemaExport from the command line... Am I >> interpreting this correctly when I see that `--create` means "just create" >> and `--drop` means "just drop"? From what I can tell, passing both seems >> to >> (looking at the code) cause just drop to happen. >> >> Anyone else find that extremely counter-intuitive? Any objection to >> instead exposing an `--action` option that can be one of "create", "drop", >> "create-and-drop", and "none"? And where "create-and-drop" is the >> default? >> > >> On Wed, Feb 3, 2016 at 6:50 AM Steve Ebersole >> wrote: >> >> > The API does need to change. So we can leave the classes, but every >> usage >> > of them would need to be adjusted. Well every usage other than CLI, >> which >> > you mention, which is a decent point. So I'll leave the classes in >> place, >> > but change the contracts. >> > >> > On Wed, Feb 3, 2016 at 12:58 AM Gunnar Morling >> > wrote: >> > >> >> When you say dropping, what would be the alternative for CLI users? It >> >> seems like a strong change to do in a minor revision. >> >> >> >> What are the required changes you need to do here? My hope would have >> >> been that the API of these tools would not have to change. >> >> >> >> 2016-02-02 22:10 GMT+01:00 Steve Ebersole : >> >> > Part of the work here is going to require significant changes to >> >> > org.hibernate.tool.hbm2ddl.SchemaExport, >> >> > org.hibernate.tool.hbm2ddl.SchemaUpdate and >> >> > org.hibernate.tool.hbm2ddl.SchemaValidator. Significant as in >> current >> >> > usages would not work at all. So does it make sense to do those >> >> changes, or >> >> > to simply drop those classes? >> >> > >> >> > >> >> > On Fri, Jan 29, 2016 at 1:15 PM Steve Ebersole >> >> wrote: >> >> >> >> >> >> I am debating with myself about reusing >> >> >> `javax.persistence.schema-generation.database.action` and >> >> >> `javax.persistence.schema-generation.scripts.action` in terms of >> this >> >> new >> >> >> unified support. The debate point being the fact that we'd have to >> >> have >> >> >> those accept an extended range of values which potentially hurts >> users >> >> in >> >> >> terms of JPA provider portability. For example, if they have: >> >> >> >> >> >> javax.persistence.schema-generation.database.action=validate >> >> >> >> >> >> Hibernate would understand that, but other providers likely would >> not. >> >> >> This is beyond the concept of "strict compliance" I started in SQM >> in >> >> my >> >> >> opinion. Here we are moving toward a unification, meaning we expect >> >> people >> >> >> to use this. >> >> >> >> >> >> So do we reuse the JPA names? >> >> >> >> >> >> On a related note.. in regards to the fact that JPA splits action >> >> between >> >> >> script and database target whereas hbm2ddl defines just a singular >> >> action >> >> >> value... does anyone know of a real case where someone defines >> >> different >> >> >> actions between script and database? I mean aside from one being >> >> NONE. I >> >> >> mean cases where they say we should do "create" for scripts but send >> >> >> "drop-and-create" to the database? That just seems odd to me. I >> >> think we >> >> >> have to account for the split since we have to account for JPA, and >> >> that >> >> >> model fits both. I was just curious >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole < >> steve at hibernate.org> >> >> >> wrote: >> >> >>> >> >> >>> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling < >> gunnar at hibernate.org >> >> > >> >> >>> wrote: >> >> >>>> >> >> >>>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole : >> >> >>>> > I also plan on adding an @Incubating annotation for just such >> >> things >> >> >>>> > :) >> >> >>>> >> >> >>>> Yes, please. We have an annotation @Experimental in OGM which we >> use >> >> >>>> for tagging APIs under development. >> >> >>> >> >> >>> >> >> >>> See https://hibernate.atlassian.net/browse/HHH-10487. I also >> >> started a >> >> >>> separate discussion about this on the dev list. >> >> >>> >> >> >>> >> >> >>> BTW, as an extension to changing SchemaManagementTool another >> thing >> >> I'd >> >> >>> like to add is some hook account for Envers use cases. >> Specifically >> >> the >> >> >>> idea there is to be able to do a few things: >> >> >>> 1) perform a selective create/drop. selective in terms of just >> >> certain >> >> >>> objects. This may be achievable through the new filter concept, >> >> although >> >> >>> we'd at least need a way to identify Envers tables from non-Envers >> >> tables. >> >> >>> Think of starting to use Hibernate+Envers on a schema that already >> >> exists. >> >> >>> 2) perform "actions". This is maybe beyond "schema tooling"; >> perhaps >> >> it >> >> >>> is more of a SessionFactory boot concept. But one thing Envers >> >> misses today >> >> >>> that would be good to add is the ability to "prime" the audit >> tables. >> >> >>> Meaning, for audited entities that do not have entries in their >> audit >> >> table, >> >> >>> create one. This for sure goes beyond simple SQL statements >> though. >> >> >> > >> > _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From guillaume.smet at gmail.com Thu Feb 4 10:37:58 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 4 Feb 2016 16:37:58 +0100 Subject: [hibernate-dev] [Search] ElasticSearch - Progress on faceting Message-ID: Hi, So the good news: most of the faceting tests now pass with ES. I rebased the patch onto master. https://github.com/gsmet/hibernate-search/commits/elastic-facet2 and for now only one commit: https://github.com/gsmet/hibernate-search/commit/657ecfe684e6b4e952d11274523a4c5683e0c7eb It's not a PR yet as it's not feature complete and there are still (a few) tests failing. General infrastructure ================ - I introduced a JsonBuilder to make the gson API chainable: I think it's more readable this way. I haven't updated everything to use it (especially the Lucene Query -> Json part is not ported yet). Should I continue with it? Please, please, say yes :). - All the API is now based on JsonObject so you don't have to play with String -> Json -> String -> Json manipulation ---> would appreciate feedback on these 2 changes so that I can make everything consistent - I introduced a ToElasticSearch class which translates Lucene/HSearch objects to Json. I moved the existing query translator there. - I'm not sure building the exact same document we build for Lucene is the way to go. I'm wondering if we should have a distinct document builder for ES. I'll see how it works for facets not being fields. - I made a few fixes here and there: especially the indexing didn't support multiple values per field. I made something complicated, maybe we could just index a JsonArray even for single values? see https://github.com/gsmet/hibernate-search/commit/cb88b5790996442e137fab4aec330be04dfef587#diff-e832854d983fba756218944587fd5c57R234 Faceting ======= - The querying/extraction should be OK - ES doesn't support range bounds inclusion/exclusion for range faceting so I used the query faceting to build the range faceting - I have to work on the mapping as having multiple facets on the same field is not supported yet: currently I use the indexed field to build the facets, not specific fields - I have some additional work to do on indexing related to the above matter Various issues =========== - A few tests don't pass: . ElasticSearch returns facets results even if the field doesn't exist: not sure we can do anything about that . A test in the WebShopTest is failing as I don't support yet faceting based on a non existing field . CollectionUpdateEventTest is failing: this one is weird - I had to work around an issue with the EsDateBridge and faceting (marked as XXX in DocumentBuilderIndexedEntity): Dates are considered to be Long and for ES, we want them to be Strings. Would appreciate a comment on that. Comments and thoughts appreciated. -- Guillaume From gunnar at hibernate.org Thu Feb 4 13:01:23 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 4 Feb 2016 19:01:23 +0100 Subject: [hibernate-dev] [Search] ElasticSearch - Progress on faceting In-Reply-To: References: Message-ID: Hi Guillaume, Awesome, great to see you making progress here! I need to take a closer look, but some quick comments inline. @Sanne, this reminds me of that pending PR of mine; Any chance you spend some cycles reviewing and merging it? Guillaume's work is based on it and it'll also serve as base of my own future work. Thanks! 2016-02-04 16:37 GMT+01:00 Guillaume Smet : > Hi, > > So the good news: most of the faceting tests now pass with ES. > > I rebased the patch onto master. > > https://github.com/gsmet/hibernate-search/commits/elastic-facet2 > and for now only one commit: > https://github.com/gsmet/hibernate-search/commit/657ecfe684e6b4e952d11274523a4c5683e0c7eb > > It's not a PR yet as it's not feature complete and there are still (a few) > tests failing. > > General infrastructure > ================ > > - I introduced a JsonBuilder to make the gson API chainable: I think it's > more readable this way. I haven't updated everything to use it (especially > the Lucene Query -> Json part is not ported yet). Should I continue with > it? Please, please, say yes :). It's a great example of how subjective readability is, because I don't find it necessarily better than the previous version, it's just different :) An actual disadvantage is the higher number of object allocations due to the builders. In the end I don't really care about it that much; how the JSON is created is more a technical detail which we may change at any time. So if you feel strongly about it, feel free to do it. But I would not expose this builder and the usage of GSON through the public API so we actually have the freedom of future changes. > - All the API is now based on JsonObject so you don't have to play with > String -> Json -> String -> Json manipulation > ---> would appreciate feedback on these 2 changes so that I can make > everything consistent +1 very good that you avoided some forth-and-back cycles, that has been bugging me, too. > - I introduced a ToElasticSearch class which translates Lucene/HSearch > objects to Json. I moved the existing query translator there. > - I'm not sure building the exact same document we build for Lucene is the > way to go. I'm wondering if we should have a distinct document builder for > ES. I'll see how it works for facets not being fields. Yes, keep in mind that the route through creating a Lucene Document object is just temporary hack to have a PoC of integrating ES. For HS 6 we'll look into refactoring the required pieces and avoid that intermediary step. Not sure how much sense it makes to spend cycles on this right now, it'll be larger task for sure. > - I made a few fixes here and there: especially the indexing didn't support > multiple values per field. I made something complicated, maybe we could > just index a JsonArray even for single values? see > https://github.com/gsmet/hibernate-search/commit/cb88b5790996442e137fab4aec330be04dfef587#diff-e832854d983fba756218944587fd5c57R234 That's cool. Actually I had prepared that very thing locally, too, but your impl is even nicer :) I wouldn't use arrays for single values, the upgrade from single value to array if needed seems nicer. Btw. that's one of the cases where going through the Lucene document is limiting us. When having element collections of component types, we cannot assemble the JSON array in such way that's ensured that each array element represents one "row" from the collection. This is because we don't know which of the Lucene fields belong together. That'll change with the larger re-work in 6. Also the case of root.components[0].foo, root.components[0].bar, root.components[1].foo, root.components[1].bar where the array would have to be at the level of "components" and not at the leave level. > > Faceting > ======= > > - The querying/extraction should be OK > - ES doesn't support range bounds inclusion/exclusion for range faceting so > I used the query faceting to build the range faceting > - I have to work on the mapping as having multiple facets on the same field > is not supported yet: currently I use the indexed field to build the > facets, not specific fields > - I have some additional work to do on indexing related to the above matter > > Various issues > =========== > > - A few tests don't pass: > . ElasticSearch returns facets results even if the field doesn't exist: not > sure we can do anything about that > . A test in the WebShopTest is failing as I don't support yet faceting > based on a non existing field > . CollectionUpdateEventTest is failing: this one is weird > - I had to work around an issue with the EsDateBridge and faceting (marked > as XXX in DocumentBuilderIndexedEntity): Dates are considered to be Long > and for ES, we want them to be Strings. Would appreciate a comment on that. Couldn't you do the conversion in the ElasticSearchIndexWorkVisitor? > > Comments and thoughts appreciated. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From hardy at hibernate.org Thu Feb 4 13:57:54 2016 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 4 Feb 2016 19:57:54 +0100 Subject: [hibernate-dev] [Search] ElasticSearch - Progress on faceting In-Reply-To: References: Message-ID: <20160204185754.GA37694@Nineveh.local> Hi Guillaume, Awesome to see so much activity, especially in an area which I used to work on so much. I think it is great that we get some more eyes on the code now. What you say makes sense from a birds eye perspective. I am hoping that I will find some time soon to have a closer look at your suggested changes. Keep it coming --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20160204/5a2f26aa/attachment.bin From gbadner at redhat.com Fri Feb 5 04:44:35 2016 From: gbadner at redhat.com (Gail Badner) Date: Fri, 5 Feb 2016 01:44:35 -0800 Subject: [hibernate-dev] User guide test failure Message-ID: Hi, I just pulled and ran tests. I'm seeing the following test failing: org.hibernate.userguide.hql.HQLTest > test_hql_between_predicate_example_2 FAILED java.lang.AssertionError at HQLTest.java:1897 Regards, Gail From guillaume.smet at gmail.com Fri Feb 5 05:33:19 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 5 Feb 2016 11:33:19 +0100 Subject: [hibernate-dev] [Search] ElasticSearch - Progress on faceting In-Reply-To: References: Message-ID: Hi Gunnar, On Thu, Feb 4, 2016 at 7:01 PM, Gunnar Morling wrote: > > - I introduced a JsonBuilder to make the gson API chainable: I think it's > > more readable this way. I haven't updated everything to use it > (especially > > the Lucene Query -> Json part is not ported yet). Should I continue with > > it? Please, please, say yes :). > > It's a great example of how subjective readability is, because I don't > find it necessarily better than the previous version, it's just > different :) An actual disadvantage is the higher number of object > allocations due to the builders. > > In the end I don't really care about it that much; how the JSON is > created is more a technical detail which we may change at any time. So > if you feel strongly about it, feel free to do it. But I would not > expose this builder and the usage of GSON through the public API so we > actually have the freedom of future changes. > Maybe readability wasn't the best term. "Writeability" is better as what I really like about it is the capacity to write the code as I would write the JSON instead of writing it in the reverse way when I have to nest objects. > > - I introduced a ToElasticSearch class which translates Lucene/HSearch > > objects to Json. I moved the existing query translator there. > > - I'm not sure building the exact same document we build for Lucene is > the > > way to go. I'm wondering if we should have a distinct document builder > for > > ES. I'll see how it works for facets not being fields. > > Yes, keep in mind that the route through creating a Lucene Document > object is just temporary hack to have a PoC of integrating ES. For HS > 6 we'll look into refactoring the required pieces and avoid that > intermediary step. Not sure how much sense it makes to spend cycles on > this right now, it'll be larger task for sure. > OK. We're on the same page. I think we won't be able to support the WebShopTest without reworking that. We have this: @Facets({ @Facet(name = "cubicCapacity", forField = "cubicCapacity", encoding = FacetEncodingType.STRING), @Facet(name = "cubicCapacity_Numeric", forField = "cubicCapacity", encoding = FacetEncodingType.LONG) }) The original Lucene document would probably allow to do something about it but we lose a lot of information due to the call to doc = facetConfig.build( doc ) which applies the Lucene facet magic, removes interesting information and adds less qualified information. > > - I had to work around an issue with the EsDateBridge and faceting > (marked > > as XXX in DocumentBuilderIndexedEntity): Dates are considered to be Long > > and for ES, we want them to be Strings. Would appreciate a comment on > that. > > Couldn't you do the conversion in the ElasticSearchIndexWorkVisitor? > Not really. The preexisting code was failing with a class cast exception. That's why I had to fix it this way. I think the indexing type (STRING, LONG) should be determined per backend instead of being global. Should we create a JIRA issue to centralize all the API challenges related to ES for 6? -- Guillaume From mihalcea.vlad at gmail.com Fri Feb 5 05:36:26 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 5 Feb 2016 12:36:26 +0200 Subject: [hibernate-dev] User guide test failure In-Reply-To: References: Message-ID: Hi, I committed a fix. The issue was due to time zones, so the result set varies between 1 and 2 because the entities were added with a LocalDateTime. I'll check it on Jenkins too. Let me know if it works now. Vlad On Fri, Feb 5, 2016 at 11:44 AM, Gail Badner wrote: > Hi, > > I just pulled and ran tests. I'm seeing the following test failing: > > org.hibernate.userguide.hql.HQLTest > test_hql_between_predicate_example_2 > FAILED > java.lang.AssertionError at HQLTest.java:1897 > > Regards, > Gail > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From smarlow at redhat.com Fri Feb 5 09:44:28 2016 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 5 Feb 2016 09:44:28 -0500 Subject: [hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications... In-Reply-To: <56B2189C.3060701@redhat.com> References: <56B20674.6040903@redhat.com> <56B2189C.3060701@redhat.com> Message-ID: <56B4B54C.8050706@redhat.com> On 02/03/2016 10:11 AM, Scott Marlow wrote: > > On 02/03/2016 09:01 AM, Steve Ebersole wrote: >> I should point out... The big drawback with that (and with cloning in >> general since its the Javassist package renaming that is important in >> both) is that its no longer a simple matter update (bug-fixes, etc) >> Javassist usage in Hibernate. Its certainly no longer simple as in >> drop-in the replacement from upstream. > > True, many users like to workaround Javassist issues by dropping a > different Javassist version in. My vote is to change Hibernate to include its own Hibernate-Javassist (shaded or whatever repackaging tricks are needed) jar. Some recent cases that I have heard of users needing to use a different version of Javassist with Hibernate were: A. On certain application servers that included an older Javassist jar that an upgraded Hibernate ORM release was not compatible with the older Javassist jar. With a shaded Hibernate-javassist jar, we wouldn't have any conflicts between the Hibernate use of Javassist and the javassist.jar file (since users would have a separate global hibernate-javassist jar). B. Users needing to use some later release of Javassist to address a bug that they experienced with Hibernate's use of Javassist. I think that these users will need to upgrade to a later version of Hibernate to use the newer Javassist. Scott > >> >> On Wed, Feb 3, 2016 at 7:58 AM Steve Ebersole > > wrote: >> >> Just as a suggestion, we do not need to go to a "full on" clone for >> your (1). A fat-jar, shaded-jar, should >> also do the trick. >> >> >> On Wed, Feb 3, 2016 at 7:54 AM Scott Marlow > > wrote: >> >> As modular classloading environments become more popular (e.g. >> WildFly, >> OSGi, Openjdk Jigsaw), it is more important that applications can >> include their own version of Javassist classes. This is not >> possible if >> the application classpath also needs to include the Hibernate >> (needed) >> version of Javassist. >> >> My question is how would/should this be accomplished? Some >> proposals >> are below: >> >> 1. Clone the Javassist runtime classes into Hibernate ORM and >> maintain >> them as a fork. I don't think this is practical but still wanted to >> mention it as a possible solution. >> >> 2. Stop using the parts of the Javassist api that generate bytecode >> that depends on the Javassist runtime classes. I have no idea >> how hard >> this would be. >> >> I don't think we have a jira for this yet, although we have >> talked about >> it occasionally for years. >> >> Any volunteers to help? >> >> Scott >> _______________________________________________ >> 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 Fri Feb 5 16:47:39 2016 From: gbadner at redhat.com (Gail Badner) Date: Fri, 5 Feb 2016 13:47:39 -0800 Subject: [hibernate-dev] User guide test failure In-Reply-To: References: Message-ID: Hi Vlad, It works now. Thanks! Gail On Fri, Feb 5, 2016 at 2:36 AM, Vlad Mihalcea wrote: > Hi, > > I committed a fix. The issue was due to time zones, so the result set > varies between 1 and 2 because the entities were added with a LocalDateTime. > I'll check it on Jenkins too. Let me know if it works now. > > Vlad > > On Fri, Feb 5, 2016 at 11:44 AM, Gail Badner wrote: > >> Hi, >> >> I just pulled and ran tests. I'm seeing the following test failing: >> >> org.hibernate.userguide.hql.HQLTest > test_hql_between_predicate_example_2 >> FAILED >> java.lang.AssertionError at HQLTest.java:1897 >> >> Regards, >> Gail >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From gbadner at redhat.com Fri Feb 5 23:17:37 2016 From: gbadner at redhat.com (Gail Badner) Date: Fri, 5 Feb 2016 20:17:37 -0800 Subject: [hibernate-dev] HHH-10478 : OperationContext Message-ID: I've created a gist with an overview of the design: https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a new section tomorrow about possible shortcomings. Here is my POC: https://github.com/hibernate/hibernate-orm/compare/master...gbadner:HHH-10478-OperationContext . Although no tests fail, the approach may be too simple to model what is necessary. At this point the POC is squashed down to 1 commit: https://github.com/hibernate/hibernate-orm/commit/3d0e2378cb998788b3205afb1e15c443c5ba77e8 Have a look and feel free to comment. Thanks, Gail From gbadner at redhat.com Mon Feb 8 01:28:47 2016 From: gbadner at redhat.com (Gail Badner) Date: Sun, 7 Feb 2016 22:28:47 -0800 Subject: [hibernate-dev] HHH-10478 : OperationContext In-Reply-To: References: Message-ID: The POC [1] assumes that we only need a single OperationContext for each type of operation. OperationContextManager has a Map of OperationContext by OperationContextType. Each OperationContext object is lazily created on the first occurence of the corresponding type of operation. Currently, when an operation is initiated (e.g., by Session.merge( entity )), OperationContextManager [2] does the following: - calls ManageableOperationContext#beforeOperation, which puts the OperationContext "in progress"; - executes the operation, which performs cascades according to mappings; - calls ManageableOperationContext#afterOperation, which puts the OperationContext in an invalid state that is "not in progress". When an operation cascades to other entities, the same OperationContext is used. Obviously, OperationContextManager needs to know if an operation is "top-level" (meaning that the operation is on the original entity, and not cascaded). In the POC, if the relevant OperationContext is not in progress at the time that an opeation is initiated, then OperationContextManager assumes that the operation is top-level. If the OperationContext is "in progress", then OperationContextManager assumes that this is a cascaded operation. I am not sure this is always correct. Can anyone think of a case where this could break down? In the POC, the following EventSource methods that contain an argument for the operation cache has been deprecated and is no longer used because the contents of that argument has been moved into an OperationContext: public void merge(String entityName, Object object, Map copiedAlready) public void persist(String entityName, Object object, Map createdAlready) public void persistOnFlush(String entityName, Object object, Map copiedAlready) public void refresh(String entityName, Object object, Map refreshedAlready) public void delete(String entityName, Object child, boolean isCascadeDeleteEnabled, Set transientEntities) Before the POC, it was the above methods that indicated that it was not top-level. If it turns out that having a single OperationContext is not valid, then there needs to be some other way to determine if the operation was top-level. I had originally planned to use PersistenceContext#getCascadeLevel == 0 to indicate an operation was at the top-level, but I found that won't work for some operations. For example, the cascade level for a top-level delete can be > 1 when deleting orphans due to merge or save-or-update operations. Another example is that cascade level is not 0 on top-level save-or-update while flushing. I have some ideas to work around this, but I didn't want to get too far down that path if it wasn't an issue. Thanks, Gail [1] https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java [2] https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java#L132 On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner wrote: > I've created a gist with an overview of the design: > https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a new > section tomorrow about possible shortcomings. > > Here is my POC: > https://github.com/hibernate/hibernate-orm/compare/master...gbadner:HHH-10478-OperationContext > . Although no tests fail, the approach may be too simple to model what is > necessary. > > At this point the POC is squashed down to 1 commit: > https://github.com/hibernate/hibernate-orm/commit/3d0e2378cb998788b3205afb1e15c443c5ba77e8 > > Have a look and feel free to comment. > > Thanks, > Gail > From steve at hibernate.org Mon Feb 8 09:12:50 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 08 Feb 2016 14:12:50 +0000 Subject: [hibernate-dev] HHH-10478 : OperationContext In-Reply-To: References: Message-ID: This is going to have to wait post-5.1 as I mentioned earlier if this was not ready prior to last week. I have just too much on my plate to look at this over 2 days. On Mon, Feb 8, 2016 at 12:29 AM Gail Badner wrote: > The POC [1] assumes that we only need a single OperationContext for each > type of operation. OperationContextManager has a Map of OperationContext by > OperationContextType. Each OperationContext object is lazily created on the > first occurence of the corresponding type of operation. > > Currently, when an operation is initiated (e.g., by Session.merge( entity > )), OperationContextManager [2] does the following: > - calls ManageableOperationContext#beforeOperation, which puts the > OperationContext "in progress"; > - executes the operation, which performs cascades according to mappings; > - calls ManageableOperationContext#afterOperation, which puts the > OperationContext in an invalid state that is "not in progress". > > When an operation cascades to other entities, the same OperationContext is > used. > > Obviously, OperationContextManager needs to know if an operation is > "top-level" (meaning that the operation is on the original entity, and not > cascaded). In the POC, if the relevant OperationContext is not in progress > at the time that an opeation is initiated, then OperationContextManager > assumes that the operation is top-level. If the OperationContext is "in > progress", then OperationContextManager assumes that this is a cascaded > operation. > > I am not sure this is always correct. Can anyone think of a case where this > could break down? > > In the POC, the following EventSource methods that contain an argument for > the operation cache has been deprecated and is no longer used because the > contents of that argument has been moved into an OperationContext: > > public void merge(String entityName, Object object, Map copiedAlready) > public void persist(String entityName, Object object, Map createdAlready) > public void persistOnFlush(String entityName, Object object, Map > copiedAlready) > public void refresh(String entityName, Object object, Map refreshedAlready) > public void delete(String entityName, Object child, boolean > isCascadeDeleteEnabled, Set transientEntities) > > Before the POC, it was the above methods that indicated that it was not > top-level. If it turns out that having a single OperationContext is not > valid, then there needs to be some other way to determine if the operation > was top-level. > > I had originally planned to use PersistenceContext#getCascadeLevel == 0 to > indicate an operation was at the top-level, but I found that won't work for > some operations. For example, the cascade level for a top-level delete can > be > 1 when deleting orphans due to merge or save-or-update operations. > Another example is that cascade level is not 0 on top-level save-or-update > while flushing. > > I have some ideas to work around this, but I didn't want to get too far > down that path if it wasn't an issue. > > Thanks, > Gail > > [1] > > https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java > [2] > > https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java#L132 > > > On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner wrote: > > > I've created a gist with an overview of the design: > > https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a new > > section tomorrow about possible shortcomings. > > > > Here is my POC: > > > https://github.com/hibernate/hibernate-orm/compare/master...gbadner:HHH-10478-OperationContext > > . Although no tests fail, the approach may be too simple to model what is > > necessary. > > > > At this point the POC is squashed down to 1 commit: > > > https://github.com/hibernate/hibernate-orm/commit/3d0e2378cb998788b3205afb1e15c443c5ba77e8 > > > > Have a look and feel free to comment. > > > > Thanks, > > Gail > > > _______________________________________________ > 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 8 12:44:35 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 08 Feb 2016 17:44:35 +0000 Subject: [hibernate-dev] Entity-joins (HHH-16 and HHH-7321) Message-ID: I am working mainly on HHH-16 which requests adding support for entity-joins (aka "ad hoc" joins). So long-story-short, there is a simple solution with some limitations and then a more correct solution that unfortunately requires a lot of rework in the HQL parser. The crux of the problem is identifier scoping in the generated SQL and how Hibernate handles implicit joins currently in HQL. As an example, consider a query like: select f.id, f.customer.name, f.postDate, u.username from FinancialRecord f left join User u on f.lastUpdateBy = u.username As I currently process this entity-join ("... join User on ...") I have to attach it to the end of the FromClause. The reason I have to attach it there is a bit of a convoluted discussion that gets into the design of the current HQL AST model and some poor assumptions made there. Complicating the fact that I add the entity-join to the end of the FromClause is the fact that Hibernate currently always handles implicit joins as theta joins. So all told the query above is currently rendered to SQL as: select ... from financial_record f, customer c left outer join `user` u on f.last_updt_by = u.username where f.customer_id=c.id So the problem with scoping is the comma. In SQL terms, that delimits the start of a new "table reference". This is where a lot of databases diverge on what is supported in terms of scoping references to aliases between "table references". H2 for example is fine with this as long as the join to `user` is an inner join; but it chokes if the join is outer. The simply solution would seem to be to have Hibernate render the implicit join as an ANSI-style join rather than a theta-join. However this is where the poor design choices that I mentioned in the current parser come into play. Basically the parser overloads the flag for implicit joins to mean many, many things. So changing that one value really messes things up. So that's not realistically an option. It is definitely something we want to keep in mind for the new parser however! Another option is to introduce a concept similar to SQL's "table reference" into the AST model. This is essentially the same this I do in SQM with org.hibernate.sqm.query.from.FromElementSpace. However, this is a massive change in the parser. I am inclined for now to simply say that implicit joins and entity-joins cannot be combined, and to circle back to this later in terms of working out support for using them in combination. From sanne at hibernate.org Mon Feb 8 13:03:07 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 8 Feb 2016 18:03:07 +0000 Subject: [hibernate-dev] Entity-joins (HHH-16 and HHH-7321) In-Reply-To: References: Message-ID: On 8 February 2016 at 17:44, Steve Ebersole wrote: > I am working mainly on HHH-16 which requests adding support for > entity-joins (aka "ad hoc" joins). > > So long-story-short, there is a simple solution with some limitations and > then a more correct solution that unfortunately requires a lot of rework in > the HQL parser. > > The crux of the problem is identifier scoping in the generated SQL and how > Hibernate handles implicit joins currently in HQL. > > As an example, consider a query like: > > select f.id, f.customer.name, f.postDate, u.username > from FinancialRecord f > left join User u on f.lastUpdateBy = u.username > > As I currently process this entity-join ("... join User on ...") I have to > attach it to the end of the FromClause. The reason I have to attach it > there is a bit of a convoluted discussion that gets into the design of the > current HQL AST model and some poor assumptions made there. > > Complicating the fact that I add the entity-join to the end of the > FromClause is the fact that Hibernate currently always handles implicit > joins as theta joins. > > So all told the query above is currently rendered to SQL as: > > select ... > from financial_record f, > customer c > left outer join `user` u > on f.last_updt_by = u.username > where f.customer_id=c.id > > So the problem with scoping is the comma. In SQL terms, that delimits the > start of a new "table reference". This is where a lot of databases diverge > on what is supported in terms of scoping references to aliases between > "table references". H2 for example is fine with this as long as the join > to `user` is an inner join; but it chokes if the join is outer. > > The simply solution would seem to be to have Hibernate render the implicit > join as an ANSI-style join rather than a theta-join. However this is where > the poor design choices that I mentioned in the current parser come into > play. Basically the parser overloads the flag for implicit joins to mean > many, many things. So changing that one value really messes things up. So > that's not realistically an option. It is definitely something we want to > keep in mind for the new parser however! > > Another option is to introduce a concept similar to SQL's "table reference" > into the AST model. This is essentially the same this I do in SQM with > org.hibernate.sqm.query.from.FromElementSpace. However, this is a massive > change in the parser. > > I am inclined for now to simply say that implicit joins and entity-joins > cannot be combined, and to circle back to this later in terms of working > out support for using them in combination. +1 From steve at hibernate.org Mon Feb 8 18:06:17 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 08 Feb 2016 23:06:17 +0000 Subject: [hibernate-dev] HHH-9548 - stored procedures and null parameter values In-Reply-To: References: Message-ID: I have heard no feedback, especially in regards to my last comment on the Jira. So at this point I plan on simply not supporting that atm from the JPA APIs. Longer term I think the correct solution is to expose the underlying Hibernate parameter object and users can directly set it. Handling this via hints just feels completely icky to me. On Tue, Jan 5, 2016 at 12:11 PM Steve Ebersole wrote: > HHH-9548[1] presents an interesting conundrum in terms of how to handle > null parameter values in regards to stored procedures and specifically in > terms of any argument defaults that might be defined on the database. At > the moment our support decides to not pass along the null in the desire to > not "over power" any defined argument defaults - if we pass the NULL, the > database would use that rather than the defined argument default. > > Essentially it is one of those 50/50 calls. I started a discussion on the > JIRA, but please add your thoughts... > > [1] https://hibernate.atlassian.net/browse/HHH-9548 > From mihalcea.vlad at gmail.com Tue Feb 9 00:16:36 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 9 Feb 2016 07:16:36 +0200 Subject: [hibernate-dev] Entity-joins (HHH-16 and HHH-7321) In-Reply-To: References: Message-ID: Hi. It's fine to assume that implicit joins and entity-joins don't mix and document this behavior. When using explicit joins: select f.id, c.name, f.postDate, u.username from FinancialRecord f inner join f.customer c left join User u on f.lastUpdateBy = u.username We get a nice SQL join query, right? select ... from financial_record f inner join customer c on f.customer_id=c.id left outer join `user` u on f.last_updt_by = u.username Vlad On Mon, Feb 8, 2016 at 8:03 PM, Sanne Grinovero wrote: > On 8 February 2016 at 17:44, Steve Ebersole wrote: > > I am working mainly on HHH-16 which requests adding support for > > entity-joins (aka "ad hoc" joins). > > > > So long-story-short, there is a simple solution with some limitations and > > then a more correct solution that unfortunately requires a lot of rework > in > > the HQL parser. > > > > The crux of the problem is identifier scoping in the generated SQL and > how > > Hibernate handles implicit joins currently in HQL. > > > > As an example, consider a query like: > > > > select f.id, f.customer.name, f.postDate, u.username > > from FinancialRecord f > > left join User u on f.lastUpdateBy = u.username > > > > As I currently process this entity-join ("... join User on ...") I have > to > > attach it to the end of the FromClause. The reason I have to attach it > > there is a bit of a convoluted discussion that gets into the design of > the > > current HQL AST model and some poor assumptions made there. > > > > Complicating the fact that I add the entity-join to the end of the > > FromClause is the fact that Hibernate currently always handles implicit > > joins as theta joins. > > > > So all told the query above is currently rendered to SQL as: > > > > select ... > > from financial_record f, > > customer c > > left outer join `user` u > > on f.last_updt_by = u.username > > where f.customer_id=c.id > > > > So the problem with scoping is the comma. In SQL terms, that delimits > the > > start of a new "table reference". This is where a lot of databases > diverge > > on what is supported in terms of scoping references to aliases between > > "table references". H2 for example is fine with this as long as the join > > to `user` is an inner join; but it chokes if the join is outer. > > > > The simply solution would seem to be to have Hibernate render the > implicit > > join as an ANSI-style join rather than a theta-join. However this is > where > > the poor design choices that I mentioned in the current parser come into > > play. Basically the parser overloads the flag for implicit joins to mean > > many, many things. So changing that one value really messes things up. > So > > that's not realistically an option. It is definitely something we want > to > > keep in mind for the new parser however! > > > > Another option is to introduce a concept similar to SQL's "table > reference" > > into the AST model. This is essentially the same this I do in SQM with > > org.hibernate.sqm.query.from.FromElementSpace. However, this is a > massive > > change in the parser. > > > > I am inclined for now to simply say that implicit joins and entity-joins > > cannot be combined, and to circle back to this later in terms of working > > out support for using them in combination. > > +1 > _______________________________________________ > 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 9 00:22:26 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 9 Feb 2016 07:22:26 +0200 Subject: [hibernate-dev] HHH-9548 - stored procedures and null parameter values In-Reply-To: References: Message-ID: I agree that it looks quite strange, especially considering the existing API. I believe that, if JPA falls short on specifying something, we should rather cover that in the Hibernate-specific API. Vlad On Tue, Feb 9, 2016 at 1:06 AM, Steve Ebersole wrote: > I have heard no feedback, especially in regards to my last comment on the > Jira. So at this point I plan on simply not supporting that atm from the > JPA APIs. > > Longer term I think the correct solution is to expose the underlying > Hibernate parameter object and users can directly set it. Handling this > via hints just feels completely icky to me. > > On Tue, Jan 5, 2016 at 12:11 PM Steve Ebersole > wrote: > > > HHH-9548[1] presents an interesting conundrum in terms of how to handle > > null parameter values in regards to stored procedures and specifically in > > terms of any argument defaults that might be defined on the database. At > > the moment our support decides to not pass along the null in the desire > to > > not "over power" any defined argument defaults - if we pass the NULL, the > > database would use that rather than the defined argument default. > > > > Essentially it is one of those 50/50 calls. I started a discussion on > the > > JIRA, but please add your thoughts... > > > > [1] https://hibernate.atlassian.net/browse/HHH-9548 > > > _______________________________________________ > 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 9 00:58:34 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 9 Feb 2016 07:58:34 +0200 Subject: [hibernate-dev] Batch version data support in Dialect Message-ID: Hi, While browsing the PRs on GitHub, I stumbled on this issue: https://hibernate.atlassian.net/browse/HHH-10290 In the current implementation, the hibernate.jdbc.batch_versioned_data property is set to true and we override it at Dialect-level as follows: public Oracle12cDialect() { super(); getDefaultProperties().setProperty( Environment.BATCH_VERSIONED_DATA, "true" ); } Wouldn't it be better if the Dialect had a methods like: boolean supportsBatchVersionedData(); and we wouldn't change the environment setting? With this method added, the user can override the Dialect setting using the environment variable. With the current implementation, we always override that setting. Vlad From steve at hibernate.org Tue Feb 9 17:18:53 2016 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 09 Feb 2016 22:18:53 +0000 Subject: [hibernate-dev] SQM and Query#getReturnTypes In-Reply-To: References: Message-ID: Bueller... ? ;) Silence to me == I can do whatever I want... So if you have a need for this, please speak up On Tue, Jan 19, 2016 at 12:53 PM Steve Ebersole wrote: > There are a few reasons I want to remove Query#getReturnTypes. At least > in its current form. Currently it simply returns the Hibernate Type(s) > that the query will return. > > One of the big reasons I want to remove this method is that it is simply > not expressive enough to handle some not-so-edge-cases like dynamic > instantiation queries (we'd have no idea about a Type for the > instantiation). > > So the main question is whether to simply remove that method or whether > some representation of the Query return(s) is valuable. If this > information is deemed valuable, the idea would be to develop a contract > that caters to both "normal selections" and dynamic instantiations. > From steve at hibernate.org Wed Feb 10 10:29:26 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 10 Feb 2016 15:29:26 +0000 Subject: [hibernate-dev] Batch version data support in Dialect In-Reply-To: References: Message-ID: Dialect#defaultProperties is a broken concept IMO. It was an attempt to avoid an explosion of methods such as the one you propose. I personally agree that the specific methods are better. However, all that said.. I do not believe what you say is accurate. At least not looking at the code. In SessionFactoryOptionsStateStandardImpl we build a Map of settings as follows: 1) apply Dialect#defaultProperties 2) apply user settings over top of that So the user's setting should override the Dialect default. That's how settings should always work - something a user explicitly sets in their config should always have precedence. Are you seeing a case where that does not happen as described? Also, to clear up a misnomer... we don't "change the environment setting". That's not how SessionFactoryOptionsStateStandardImpl and the config map building works. On Mon, Feb 8, 2016 at 11:58 PM Vlad Mihalcea wrote: > Hi, > > While browsing the PRs on GitHub, I stumbled on this issue: > > https://hibernate.atlassian.net/browse/HHH-10290 > > In the current implementation, the hibernate.jdbc.batch_versioned_data > property is set to true and > we override it at Dialect-level as follows: > > public Oracle12cDialect() { > super(); > getDefaultProperties().setProperty( Environment.BATCH_VERSIONED_DATA, > "true" ); > } > > Wouldn't it be better if the Dialect had a methods like: > > boolean supportsBatchVersionedData(); > > and we wouldn't change the environment setting? > With this method added, the user can override the Dialect setting using the > environment variable. > With the current implementation, we always override that setting. > > 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 Wed Feb 10 11:16:50 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 10 Feb 2016 18:16:50 +0200 Subject: [hibernate-dev] Batch version data support in Dialect In-Reply-To: References: Message-ID: Hi, The user can override these settings, that's actually how the test failed for that user (although I wonder why he passed that environment variable to the test anyway). Thanks for clarifying the design decision for controlling some dialect-based properties. Vlad On Wed, Feb 10, 2016 at 5:29 PM, Steve Ebersole wrote: > Dialect#defaultProperties is a broken concept IMO. It was an attempt to > avoid an explosion of methods such as the one you propose. I personally > agree that the specific methods are better. > > However, all that said.. I do not believe what you say is accurate. At > least not looking at the code. In SessionFactoryOptionsStateStandardImpl > we build a Map of settings as follows: > > 1) apply Dialect#defaultProperties > 2) apply user settings over top of that > > So the user's setting should override the Dialect default. That's how > settings should always work - something a user explicitly sets in their > config should always have precedence. Are you seeing a case where that > does not happen as described? > > Also, to clear up a misnomer... we don't "change the environment > setting". That's not how SessionFactoryOptionsStateStandardImpl and the > config map building works. > > On Mon, Feb 8, 2016 at 11:58 PM Vlad Mihalcea > wrote: > >> Hi, >> >> While browsing the PRs on GitHub, I stumbled on this issue: >> >> https://hibernate.atlassian.net/browse/HHH-10290 >> >> In the current implementation, the hibernate.jdbc.batch_versioned_data >> property is set to true and >> we override it at Dialect-level as follows: >> >> public Oracle12cDialect() { >> super(); >> getDefaultProperties().setProperty( Environment.BATCH_VERSIONED_DATA, >> "true" ); >> } >> >> Wouldn't it be better if the Dialect had a methods like: >> >> boolean supportsBatchVersionedData(); >> >> and we wouldn't change the environment setting? >> With this method added, the user can override the Dialect setting using >> the >> environment variable. >> With the current implementation, we always override that setting. >> >> Vlad >> _______________________________________________ >> 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 10 12:14:01 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 10 Feb 2016 17:14:01 +0000 Subject: [hibernate-dev] Starting 5.1.0 release Message-ID: From steve at hibernate.org Wed Feb 10 13:16:11 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 10 Feb 2016 18:16:11 +0000 Subject: [hibernate-dev] Starting 5.1.0 release In-Reply-To: References: Message-ID: The release build is done. Push away! On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole wrote: > > From sanne at hibernate.org Wed Feb 10 13:20:55 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 10 Feb 2016 18:20:55 +0000 Subject: [hibernate-dev] Starting 5.1.0 release In-Reply-To: References: Message-ID: Congratulations!! On 10 February 2016 at 18:16, Steve Ebersole wrote: > The release build is done. Push away! > > > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole wrote: > >> >> > _______________________________________________ > 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 10 13:31:25 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 10 Feb 2016 20:31:25 +0200 Subject: [hibernate-dev] Starting 5.1.0 release In-Reply-To: References: Message-ID: Congrats! I checked the docs but the User Guide is still the old one: http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/ Should we make the switch in a future release? On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero wrote: > Congratulations!! > > On 10 February 2016 at 18:16, Steve Ebersole wrote: > > The release build is done. Push away! > > > > > > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole > wrote: > > > >> > >> > > _______________________________________________ > > 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 10 14:01:29 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 10 Feb 2016 19:01:29 +0000 Subject: [hibernate-dev] Starting 5.1.0 release In-Reply-To: References: Message-ID: I thought you had updated the documentation build to build this? On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea wrote: > Congrats! I checked the docs but the User Guide is still the old one: > > http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/ > > Should we make the switch in a future release? > > On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero > wrote: > >> Congratulations!! >> >> On 10 February 2016 at 18:16, Steve Ebersole wrote: >> > The release build is done. Push away! >> > >> > >> > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole >> wrote: >> > >> >> >> >> >> > _______________________________________________ >> > 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 10 14:05:54 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 10 Feb 2016 21:05:54 +0200 Subject: [hibernate-dev] Starting 5.1.0 release In-Reply-To: References: Message-ID: Hi, I haven't changed the current build process. I'll have to investigate where to make the change. On Wed, Feb 10, 2016 at 9:01 PM, Steve Ebersole wrote: > I thought you had updated the documentation build to build this? > > > On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea > wrote: > >> Congrats! I checked the docs but the User Guide is still the old one: >> >> http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/ >> >> Should we make the switch in a future release? >> >> On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero >> wrote: >> >>> Congratulations!! >>> >>> On 10 February 2016 at 18:16, Steve Ebersole >>> wrote: >>> > The release build is done. Push away! >>> > >>> > >>> > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole >>> wrote: >>> > >>> >> >>> >> >>> > _______________________________________________ >>> > 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 10 14:08:55 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 10 Feb 2016 19:08:55 +0000 Subject: [hibernate-dev] Starting 5.1.0 release In-Reply-To: References: Message-ID: no, I'll do it On Wed, Feb 10, 2016 at 1:05 PM Vlad Mihalcea wrote: > Hi, > > I haven't changed the current build process. I'll have to investigate > where to make the change. > > On Wed, Feb 10, 2016 at 9:01 PM, Steve Ebersole > wrote: > >> I thought you had updated the documentation build to build this? >> >> >> On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea >> wrote: >> >>> Congrats! I checked the docs but the User Guide is still the old one: >>> >>> http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/ >>> >>> Should we make the switch in a future release? >>> >>> On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero >>> wrote: >>> >>>> Congratulations!! >>>> >>>> On 10 February 2016 at 18:16, Steve Ebersole >>>> wrote: >>>> > The release build is done. Push away! >>>> > >>>> > >>>> > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole >>>> wrote: >>>> > >>>> >> >>>> >> >>>> > _______________________________________________ >>>> > 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 10 14:09:36 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 10 Feb 2016 19:09:36 +0000 Subject: [hibernate-dev] Starting 5.1.0 release In-Reply-To: References: Message-ID: I need to deal with the new link ontology we decided on for the doc server anyway On Wed, Feb 10, 2016 at 1:08 PM Steve Ebersole wrote: > no, I'll do it > > On Wed, Feb 10, 2016 at 1:05 PM Vlad Mihalcea > wrote: > >> Hi, >> >> I haven't changed the current build process. I'll have to investigate >> where to make the change. >> >> On Wed, Feb 10, 2016 at 9:01 PM, Steve Ebersole >> wrote: >> >>> I thought you had updated the documentation build to build this? >>> >>> >>> On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea >>> wrote: >>> >>>> Congrats! I checked the docs but the User Guide is still the old one: >>>> >>>> http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/ >>>> >>>> Should we make the switch in a future release? >>>> >>>> On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero >>>> wrote: >>>> >>>>> Congratulations!! >>>>> >>>>> On 10 February 2016 at 18:16, Steve Ebersole >>>>> wrote: >>>>> > The release build is done. Push away! >>>>> > >>>>> > >>>>> > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole >>>>> wrote: >>>>> > >>>>> >> >>>>> >> >>>>> > _______________________________________________ >>>>> > 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 10 14:40:58 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 10 Feb 2016 19:40:58 +0000 Subject: [hibernate-dev] Starting 5.1.0 release In-Reply-To: References: Message-ID: I fixed the symlinks on the doc server as follows: 1. created a `/orm/current` symlink pointing to `/orm/5.1` 2. updated `/stable/orm` to point to `/orm/current` 3. updated `/stable/core` to point to `/stable/orm` (I could not remember what it pointed to previously). So as of right now, all of the following urls point to orm/5.1... 1. http://docs.jboss.org/hibernate/orm/current/ 2. http://docs.jboss.org/hibernate/stable/orm 3. http://docs.jboss.org/hibernate/stable/core We will need to update all of the release builds that we still run. That includes: 1. 5.1 2. 5.0 3. 4.3 (?) 4. 4.2 (?) Gail, am I correct that you still run 4.2 and 4.3 as part of Red Hat productization? To be honest, I am not even sure those builds (and maybe even 5.0 at this point) should be updating the doc server. On Wed, Feb 10, 2016 at 1:09 PM Steve Ebersole wrote: > I need to deal with the new link ontology we decided on for the doc server > anyway > > On Wed, Feb 10, 2016 at 1:08 PM Steve Ebersole > wrote: > >> no, I'll do it >> >> On Wed, Feb 10, 2016 at 1:05 PM Vlad Mihalcea >> wrote: >> >>> Hi, >>> >>> I haven't changed the current build process. I'll have to investigate >>> where to make the change. >>> >>> On Wed, Feb 10, 2016 at 9:01 PM, Steve Ebersole >>> wrote: >>> >>>> I thought you had updated the documentation build to build this? >>>> >>>> >>>> On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea >>>> wrote: >>>> >>>>> Congrats! I checked the docs but the User Guide is still the old one: >>>>> >>>>> http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/ >>>>> >>>>> Should we make the switch in a future release? >>>>> >>>>> On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero >>>>> wrote: >>>>> >>>>>> Congratulations!! >>>>>> >>>>>> On 10 February 2016 at 18:16, Steve Ebersole >>>>>> wrote: >>>>>> > The release build is done. Push away! >>>>>> > >>>>>> > >>>>>> > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole < >>>>>> steve at hibernate.org> wrote: >>>>>> > >>>>>> >> >>>>>> >> >>>>>> > _______________________________________________ >>>>>> > 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 10 14:42:39 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 10 Feb 2016 19:42:39 +0000 Subject: [hibernate-dev] ORM 5.1 feature release Message-ID: ORM 5.1 has just been released. See details @ http://in.relation.to/2016/02/10/hibernate-orm-510-final-release/ From steve at hibernate.org Wed Feb 10 15:06:27 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 10 Feb 2016 20:06:27 +0000 Subject: [hibernate-dev] Version-specific data on hibernate.org (was Re: Starting 5.1.0 release) In-Reply-To: References: Message-ID: A related concern is a discussion I started before in regards to version specific information on hibernate.org Did we ever come to any conclusion about how (if) we were going to handle that? On Wed, Feb 10, 2016 at 1:40 PM Steve Ebersole wrote: > I fixed the symlinks on the doc server as follows: > > 1. created a `/orm/current` symlink pointing to `/orm/5.1` > 2. updated `/stable/orm` to point to `/orm/current` > 3. updated `/stable/core` to point to `/stable/orm` (I could not > remember what it pointed to previously). > > > So as of right now, all of the following urls point to orm/5.1... > > 1. http://docs.jboss.org/hibernate/orm/current/ > 2. http://docs.jboss.org/hibernate/stable/orm > 3. http://docs.jboss.org/hibernate/stable/core > > > We will need to update all of the release builds that we still run. That > includes: > > 1. 5.1 > 2. 5.0 > 3. 4.3 (?) > 4. 4.2 (?) > > Gail, am I correct that you still run 4.2 and 4.3 as part of Red Hat > productization? To be honest, I am not even sure those builds (and maybe > even 5.0 at this point) should be updating the doc server. > > > > On Wed, Feb 10, 2016 at 1:09 PM Steve Ebersole > wrote: > >> I need to deal with the new link ontology we decided on for the doc >> server anyway >> >> On Wed, Feb 10, 2016 at 1:08 PM Steve Ebersole >> wrote: >> >>> no, I'll do it >>> >>> On Wed, Feb 10, 2016 at 1:05 PM Vlad Mihalcea >>> wrote: >>> >>>> Hi, >>>> >>>> I haven't changed the current build process. I'll have to investigate >>>> where to make the change. >>>> >>>> On Wed, Feb 10, 2016 at 9:01 PM, Steve Ebersole >>>> wrote: >>>> >>>>> I thought you had updated the documentation build to build this? >>>>> >>>>> >>>>> On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> wrote: >>>>> >>>>>> Congrats! I checked the docs but the User Guide is still the old one: >>>>>> >>>>>> http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/ >>>>>> >>>>>> Should we make the switch in a future release? >>>>>> >>>>>> On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero >>>>> > wrote: >>>>>> >>>>>>> Congratulations!! >>>>>>> >>>>>>> On 10 February 2016 at 18:16, Steve Ebersole >>>>>>> wrote: >>>>>>> > The release build is done. Push away! >>>>>>> > >>>>>>> > >>>>>>> > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole < >>>>>>> steve at hibernate.org> wrote: >>>>>>> > >>>>>>> >> >>>>>>> >> >>>>>>> > _______________________________________________ >>>>>>> > 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 10 16:07:23 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 10 Feb 2016 23:07:23 +0200 Subject: [hibernate-dev] Version-specific data on hibernate.org (was Re: Starting 5.1.0 release) In-Reply-To: References: Message-ID: Hi Steve, I created this PR for switching to the new User Guide https://github.com/hibernate/hibernate-orm/pull/1260 The release build already copies from ascidocs folder so I think it's fine. On Wed, Feb 10, 2016 at 10:06 PM, Steve Ebersole wrote: > A related concern is a discussion I started before in regards to version > specific information on hibernate.org > > Did we ever come to any conclusion about how (if) we were going to handle > that? > > > On Wed, Feb 10, 2016 at 1:40 PM Steve Ebersole > wrote: > > > I fixed the symlinks on the doc server as follows: > > > > 1. created a `/orm/current` symlink pointing to `/orm/5.1` > > 2. updated `/stable/orm` to point to `/orm/current` > > 3. updated `/stable/core` to point to `/stable/orm` (I could not > > remember what it pointed to previously). > > > > > > So as of right now, all of the following urls point to orm/5.1... > > > > 1. http://docs.jboss.org/hibernate/orm/current/ > > 2. http://docs.jboss.org/hibernate/stable/orm > > 3. http://docs.jboss.org/hibernate/stable/core > > > > > > We will need to update all of the release builds that we still run. That > > includes: > > > > 1. 5.1 > > 2. 5.0 > > 3. 4.3 (?) > > 4. 4.2 (?) > > > > Gail, am I correct that you still run 4.2 and 4.3 as part of Red Hat > > productization? To be honest, I am not even sure those builds (and maybe > > even 5.0 at this point) should be updating the doc server. > > > > > > > > On Wed, Feb 10, 2016 at 1:09 PM Steve Ebersole > > wrote: > > > >> I need to deal with the new link ontology we decided on for the doc > >> server anyway > >> > >> On Wed, Feb 10, 2016 at 1:08 PM Steve Ebersole > >> wrote: > >> > >>> no, I'll do it > >>> > >>> On Wed, Feb 10, 2016 at 1:05 PM Vlad Mihalcea > > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> I haven't changed the current build process. I'll have to investigate > >>>> where to make the change. > >>>> > >>>> On Wed, Feb 10, 2016 at 9:01 PM, Steve Ebersole > >>>> wrote: > >>>> > >>>>> I thought you had updated the documentation build to build this? > >>>>> > >>>>> > >>>>> On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea < > >>>>> mihalcea.vlad at gmail.com> wrote: > >>>>> > >>>>>> Congrats! I checked the docs but the User Guide is still the old > one: > >>>>>> > >>>>>> > http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/ > >>>>>> > >>>>>> Should we make the switch in a future release? > >>>>>> > >>>>>> On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero < > sanne at hibernate.org > >>>>>> > wrote: > >>>>>> > >>>>>>> Congratulations!! > >>>>>>> > >>>>>>> On 10 February 2016 at 18:16, Steve Ebersole > >>>>>>> wrote: > >>>>>>> > The release build is done. Push away! > >>>>>>> > > >>>>>>> > > >>>>>>> > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole < > >>>>>>> steve at hibernate.org> wrote: > >>>>>>> > > >>>>>>> >> > >>>>>>> >> > >>>>>>> > _______________________________________________ > >>>>>>> > 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 10 17:25:14 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 10 Feb 2016 22:25:14 +0000 Subject: [hibernate-dev] Starting 5.1.0 release In-Reply-To: References: Message-ID: Maybe the better option is to have the build simply upload to the versioned docs dir (orm/5.0, orm/5.1, etc) and to manage the `current` symlink by hand. That really only needs to change when the next feature release becomes stable. On Wed, Feb 10, 2016 at 1:40 PM Steve Ebersole wrote: > I fixed the symlinks on the doc server as follows: > > 1. created a `/orm/current` symlink pointing to `/orm/5.1` > 2. updated `/stable/orm` to point to `/orm/current` > 3. updated `/stable/core` to point to `/stable/orm` (I could not > remember what it pointed to previously). > > > So as of right now, all of the following urls point to orm/5.1... > > 1. http://docs.jboss.org/hibernate/orm/current/ > 2. http://docs.jboss.org/hibernate/stable/orm > 3. http://docs.jboss.org/hibernate/stable/core > > > We will need to update all of the release builds that we still run. That > includes: > > 1. 5.1 > 2. 5.0 > 3. 4.3 (?) > 4. 4.2 (?) > > Gail, am I correct that you still run 4.2 and 4.3 as part of Red Hat > productization? To be honest, I am not even sure those builds (and maybe > even 5.0 at this point) should be updating the doc server. > > > > On Wed, Feb 10, 2016 at 1:09 PM Steve Ebersole > wrote: > >> I need to deal with the new link ontology we decided on for the doc >> server anyway >> >> On Wed, Feb 10, 2016 at 1:08 PM Steve Ebersole >> wrote: >> >>> no, I'll do it >>> >>> On Wed, Feb 10, 2016 at 1:05 PM Vlad Mihalcea >>> wrote: >>> >>>> Hi, >>>> >>>> I haven't changed the current build process. I'll have to investigate >>>> where to make the change. >>>> >>>> On Wed, Feb 10, 2016 at 9:01 PM, Steve Ebersole >>>> wrote: >>>> >>>>> I thought you had updated the documentation build to build this? >>>>> >>>>> >>>>> On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> wrote: >>>>> >>>>>> Congrats! I checked the docs but the User Guide is still the old one: >>>>>> >>>>>> http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/ >>>>>> >>>>>> Should we make the switch in a future release? >>>>>> >>>>>> On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero >>>>> > wrote: >>>>>> >>>>>>> Congratulations!! >>>>>>> >>>>>>> On 10 February 2016 at 18:16, Steve Ebersole >>>>>>> wrote: >>>>>>> > The release build is done. Push away! >>>>>>> > >>>>>>> > >>>>>>> > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole < >>>>>>> steve at hibernate.org> wrote: >>>>>>> > >>>>>>> >> >>>>>>> >> >>>>>>> > _______________________________________________ >>>>>>> > 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 Wed Feb 10 17:45:36 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 10 Feb 2016 23:45:36 +0100 Subject: [hibernate-dev] PropertyFactory and invocation of PropertyAccessStrategyResolver Message-ID: Hey, In ORM's PropertyFactory#getGetter() line 317 I see that mappingProperty.getClass() is passed to resolvePropertyAccessStrategy() [1]. I.e. the type org.hibernate.mapping.Property or similar will be passed here. Is this actually correct? It seems mappingProperty.getPersistentClass().getMappedClass() should be passed instead; As per the parameter docs it's "The java class of the entity" and the usage in PropertyAccessStrategyResolverStandardImpl confirms that. Thanks, --Gunnar [https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/tuple/PropertyFactory.java#L317] From emmanuel at hibernate.org Thu Feb 11 02:23:12 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 11 Feb 2016 08:23:12 +0100 Subject: [hibernate-dev] Version-specific data on hibernate.org (was Re: Starting 5.1.0 release) In-Reply-To: References: Message-ID: <5B552235-3E1D-4405-A9BB-B32C62ADEC70@hibernate.org> Nope. I don't remember a how we could discussion that explored the subject deeply. > On 10 f?vr. 2016, at 21:06, Steve Ebersole wrote: > > A related concern is a discussion I started before in regards to version > specific information on hibernate.org > > Did we ever come to any conclusion about how (if) we were going to handle > that? > > >> On Wed, Feb 10, 2016 at 1:40 PM Steve Ebersole wrote: >> >> I fixed the symlinks on the doc server as follows: >> >> 1. created a `/orm/current` symlink pointing to `/orm/5.1` >> 2. updated `/stable/orm` to point to `/orm/current` >> 3. updated `/stable/core` to point to `/stable/orm` (I could not >> remember what it pointed to previously). >> >> >> So as of right now, all of the following urls point to orm/5.1... >> >> 1. http://docs.jboss.org/hibernate/orm/current/ >> 2. http://docs.jboss.org/hibernate/stable/orm >> 3. http://docs.jboss.org/hibernate/stable/core >> >> >> We will need to update all of the release builds that we still run. That >> includes: >> >> 1. 5.1 >> 2. 5.0 >> 3. 4.3 (?) >> 4. 4.2 (?) >> >> Gail, am I correct that you still run 4.2 and 4.3 as part of Red Hat >> productization? To be honest, I am not even sure those builds (and maybe >> even 5.0 at this point) should be updating the doc server. >> >> >> >> On Wed, Feb 10, 2016 at 1:09 PM Steve Ebersole >> wrote: >> >>> I need to deal with the new link ontology we decided on for the doc >>> server anyway >>> >>> On Wed, Feb 10, 2016 at 1:08 PM Steve Ebersole >>> wrote: >>> >>>> no, I'll do it >>>> >>>> On Wed, Feb 10, 2016 at 1:05 PM Vlad Mihalcea >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I haven't changed the current build process. I'll have to investigate >>>>> where to make the change. >>>>> >>>>> On Wed, Feb 10, 2016 at 9:01 PM, Steve Ebersole >>>>> wrote: >>>>> >>>>>> I thought you had updated the documentation build to build this? >>>>>> >>>>>> >>>>>> On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea < >>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>> >>>>>>> Congrats! I checked the docs but the User Guide is still the old one: >>>>>>> >>>>>>> http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/ >>>>>>> >>>>>>> Should we make the switch in a future release? >>>>>>> >>>>>>> On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero >>>>>>> wrote: >>>>>>> >>>>>>>> Congratulations!! >>>>>>>> >>>>>>>> On 10 February 2016 at 18:16, Steve Ebersole >>>>>>>> wrote: >>>>>>>>> The release build is done. Push away! >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole < >>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 11 07:56:24 2016 From: steve at hibernate.org (sebersole) Date: Thu, 11 Feb 2016 04:56:24 -0800 (PST) Subject: [hibernate-dev] Hibernate site SEO optimization In-Reply-To: References: <20151209125751.GD10690@Nineveh.lan> <20151209135447.GH10690@Nineveh.lan> Message-ID: <1455195384429-1332.post@n6.nabble.com> Let's revive this discussion and work on getting a solid plan in place. I think the first question is whether we can get the proper header updates in place in the current doc server. As pointed out, we do not control the root of that machine. Additionally we do not even have our own doc root, meaning changes we make might affect others and conversely as well. And if we can, do we want to? If we can't or would simply prefer to host the docs ourselves as part of hibernate.org, then we have a bunch of other things to figure out. Personally I worry about our release builds having to deal with a different GitHub repo (hibernate.org). -- View this message in context: http://hibernate-development.74578.x6.nabble.com/hibernate-dev-Hibernate-site-SEO-optimization-tp839p1332.html Sent from the Hibernate Development mailing list archive at Nabble.com. From gunnar at hibernate.org Thu Feb 11 08:48:11 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 11 Feb 2016 14:48:11 +0100 Subject: [hibernate-dev] Eager fetch and duplicates of collection elements Message-ID: Hi, I understand that $subject is a known source of confusion for people when working with HQL/criteria queries and not applying something like DistinctRootEntityResultTransformer. I am seeing the same behaviour though when getting a root entity by id and join-fetching two (nested) collections. That's my model: @Entity public class Parent { @Id @GeneratedValue private Long id; @OneToMany(cascade = CascadeType.ALL, fetch=FetchType.EAGER) @JoinColumn(name = "parent_id") private List children = new ArrayList<>(); } @Entity public class Child { @Id @GeneratedValue private Long id; @ElementCollection(fetch=FetchType.EAGER) @JoinTable(name = "Child_Properties") @MapKeyColumn(name = "key") @Column(name = "value") private Map properties = new HashMap<>(); } I am persisting a parent with one Child which has three "properties" entries. Loading the Parent by id yields three elements in the "children" list: Parent loaded = session.get( Parent.class, 123 ); assert 1 == loaded.getConfigurations().size(); //