From christian.beikov at gmail.com Mon Jan 2 02:26:27 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Mon, 2 Jan 2017 08:26:27 +0100 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: Sounds good to me, but maybe we could do a poll to see if people are using this? I don't know if the filter also works for field based access strategy, but that could be a reason for keeping it around. Regards, Christian Am 31.12.2016 um 21:00 schrieb Steve Ebersole: > As I have not been hearing hardly any feedback on these 6.0 design > questions I have been trying to start, I'll be doing something different in > this and any additional emails.. I'll state what I propose to do and if > anyone has issue with it they can make a counter proposal. Otherwise I > plan on following through with my proposal. > > I plan on removing Session#createFilter. There are numerous reasons why > which I can discuss if anyone is interested in exploring this. > > Ultimately I think it makes sense to handle this via Java 8 streams[1] > although I am not sure that needs to happen in 6.0 > > [1] https://hibernate.atlassian.net/browse/HHH-10962 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From christian.beikov at gmail.com Mon Jan 2 02:33:13 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Mon, 2 Jan 2017 08:33:13 +0100 Subject: [hibernate-dev] 6.0 - Query literal rendering In-Reply-To: References: Message-ID: May I ask what happened to the idea of not rendering through the literals at all and just "inject" them into the result tuple? We could even go as far as allowing expressions on constant values to be evaluated in memory instead of sending that to the DB. Other than that, the settings seem ok, but how does that affect subqueries? The same way? Or are subqueries the exception? Regards, Christian Am 31.12.2016 um 15:25 schrieb Steve Ebersole: > Currently in 6.0 I have code in place to render query literals as > PreparedStatement parameters, but only outside the SELECT clause. Many DBs > require special handling for parameters defined in the SELECT clause > general requiring to wrap in cast functions calls. > > I think it may be beneficial to allow the user to control this via a > setting. Specifically a multi-valued (enum) value with the following > possibility set: > > 1. NEVER > 2. ALWAYS > 3. OUTSIDE_SELECT > > First, does anyone have an issue with this proposal? Secondly does anyone > see other concerns that should be take into account? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Jan 2 02:51:33 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 02 Jan 2017 07:51:33 +0000 Subject: [hibernate-dev] 6.0 - Query literal rendering In-Reply-To: References: Message-ID: I only have so many hours in the day :) Let's get comparable behavior working first and then attack more complex (although we all agree probably worthwhile in this case) after. On Mon, Jan 2, 2017 at 1:37 AM Christian Beikov wrote: > May I ask what happened to the idea of not rendering through the > literals at all and just "inject" them into the result tuple? We could > even go as far as allowing expressions on constant values to be > evaluated in memory instead of sending that to the DB. > > Other than that, the settings seem ok, but how does that affect > subqueries? The same way? Or are subqueries the exception? > > Regards, > > Christian > > Am 31.12.2016 um 15:25 schrieb Steve Ebersole: > > Currently in 6.0 I have code in place to render query literals as > > PreparedStatement parameters, but only outside the SELECT clause. Many > DBs > > require special handling for parameters defined in the SELECT clause > > general requiring to wrap in cast functions calls. > > > > I think it may be beneficial to allow the user to control this via a > > setting. Specifically a multi-valued (enum) value with the following > > possibility set: > > > > 1. NEVER > > 2. ALWAYS > > 3. OUTSIDE_SELECT > > > > First, does anyone have an issue with this proposal? Secondly does > anyone > > see other concerns that should be take into account? > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Jan 2 02:52:15 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 02 Jan 2017 07:52:15 +0000 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: Field-access would have zero bearing on this On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov wrote: > Sounds good to me, but maybe we could do a poll to see if people are > using this? I don't know if the filter also works for field based access > strategy, but that could be a reason for keeping it around. > > Regards, > > Christian > > > Am 31.12.2016 um 21:00 schrieb Steve Ebersole: > > As I have not been hearing hardly any feedback on these 6.0 design > > questions I have been trying to start, I'll be doing something different > in > > this and any additional emails.. I'll state what I propose to do and if > > anyone has issue with it they can make a counter proposal. Otherwise I > > plan on following through with my proposal. > > > > I plan on removing Session#createFilter. There are numerous reasons why > > which I can discuss if anyone is interested in exploring this. > > > > Ultimately I think it makes sense to handle this via Java 8 streams[1] > > although I am not sure that needs to happen in 6.0 > > > > [1] https://hibernate.atlassian.net/browse/HHH-10962 > > _______________________________________________ > > 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 christian.beikov at gmail.com Mon Jan 2 03:15:19 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Mon, 2 Jan 2017 09:15:19 +0100 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> Well it does when you consider that there might be no getter for a field. With createFilter you could still filter the result list without exposing direct access to the field via a getter. Am 02.01.2017 um 08:52 schrieb Steve Ebersole: > Field-access would have zero bearing on this > > On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov > > wrote: > > Sounds good to me, but maybe we could do a poll to see if people are > using this? I don't know if the filter also works for field based > access > strategy, but that could be a reason for keeping it around. > > Regards, > > Christian > > > Am 31.12.2016 um 21:00 schrieb Steve Ebersole: > > As I have not been hearing hardly any feedback on these 6.0 design > > questions I have been trying to start, I'll be doing something > different in > > this and any additional emails.. I'll state what I propose to do > and if > > anyone has issue with it they can make a counter proposal. > Otherwise I > > plan on following through with my proposal. > > > > I plan on removing Session#createFilter. There are numerous > reasons why > > which I can discuss if anyone is interested in exploring this. > > > > Ultimately I think it makes sense to handle this via Java 8 > streams[1] > > although I am not sure that needs to happen in 6.0 > > > > [1] https://hibernate.atlassian.net/browse/HHH-10962 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Jan 2 03:25:49 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 02 Jan 2017 08:25:49 +0000 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> References: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> Message-ID: Could you explain the situation where you would map a collection but not expose it? And btw even create createFilter would not work there because you have to pass createFilter the collection On Mon, Jan 2, 2017, 2:15 AM Christian Beikov wrote: > Well it does when you consider that there might be no getter for a field. > With createFilter you could still filter the result list without exposing > direct access to the field via a getter. > > Am 02.01.2017 um 08:52 schrieb Steve Ebersole: > > Field-access would have zero bearing on this > > On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > > Sounds good to me, but maybe we could do a poll to see if people are > using this? I don't know if the filter also works for field based access > strategy, but that could be a reason for keeping it around. > > Regards, > > Christian > > > Am 31.12.2016 um 21:00 schrieb Steve Ebersole: > > As I have not been hearing hardly any feedback on these 6.0 design > > questions I have been trying to start, I'll be doing something different > in > > this and any additional emails.. I'll state what I propose to do and if > > anyone has issue with it they can make a counter proposal. Otherwise I > > plan on following through with my proposal. > > > > I plan on removing Session#createFilter. There are numerous reasons why > > which I can discuss if anyone is interested in exploring this. > > > > Ultimately I think it makes sense to handle this via Java 8 streams[1] > > although I am not sure that needs to happen in 6.0 > > > > [1] https://hibernate.atlassian.net/browse/HHH-10962 > > _______________________________________________ > > 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 yoann at hibernate.org Mon Jan 2 03:35:53 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 2 Jan 2017 09:35:53 +0100 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: For what it's worth, changing the signature indeed seems appropriate to me: the fewer object arrays, the better. Your proposal would require making Query parameterized too, though. I'm not really up-to-date with the current state of 6.0, but I guess it's already done or being done. Anyway, the only think I wanted to say was: if we break the API, maybe we should try to make sure we won't have to break it again soon. There has been some discussions about adding scrolling to the JPA spec: https://java.net/jira/browse/JPA_SPEC-89 . Maybe it would be worth it to ask for advice on this ticket, so as to limit the risk of having to break this API again, because the spec would introduce an incompatible signature? Not sure there would be many reactions, judging by the low activity on the ticket, but who knows... Yoann Rodi?re Hibernate NoORM Team On 27 December 2016 at 22:02, Steve Ebersole wrote: > FWIW my inclination is to just change the existing signatures. 6.0 is a > major release with major changes already wrt querying. > > > On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole > wrote: > > > For 6.0 I'd like to also make ScrollableResults parameterized wrt the > "row > > type". E.g. > > > > ScrollableResults sr = session.createQuery( ..., Person.class > > ).scroll(); > > > > However that changes the signature of its methods returning a "row" > > (currently always defined as Object[]). > > > > How would everyone prefer we handle this? Do I just change the > signatures > > of the existing methods? Or add new methods? > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From christian.beikov at gmail.com Mon Jan 2 03:39:40 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Mon, 2 Jan 2017 09:39:40 +0100 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> Message-ID: <1126a39a-3a7d-c109-f60e-f1b2f45a04c5@gmail.com> Let's say we have this entity with an attribute that is not directly exposed. class EntityA { String field; } and then you pass a collection of EntityA instances to createFilter like Collection collection = ... collection = session.createFilter(collection, "field = 'abc%'").getResultList(); See my point? Since Hibernate can access the field directly, this works, but with streams you'd need to expose the field via a getter so you can filter for it. Am 02.01.2017 um 09:25 schrieb Steve Ebersole: > > Could you explain the situation where you would map a collection but > not expose it? And btw even create createFilter would not work there > because you have to pass createFilter the collection > > > On Mon, Jan 2, 2017, 2:15 AM Christian Beikov > > wrote: > > Well it does when you consider that there might be no getter for a > field. With createFilter you could still filter the result list > without exposing direct access to the field via a getter. > > Am 02.01.2017 um 08:52 schrieb Steve Ebersole: >> Field-access would have zero bearing on this >> >> On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov >> > >> wrote: >> >> Sounds good to me, but maybe we could do a poll to see if >> people are >> using this? I don't know if the filter also works for field >> based access >> strategy, but that could be a reason for keeping it around. >> >> Regards, >> >> Christian >> >> >> Am 31.12.2016 um 21:00 schrieb Steve Ebersole: >> > As I have not been hearing hardly any feedback on these 6.0 >> design >> > questions I have been trying to start, I'll be doing >> something different in >> > this and any additional emails.. I'll state what I propose >> to do and if >> > anyone has issue with it they can make a counter proposal. >> Otherwise I >> > plan on following through with my proposal. >> > >> > I plan on removing Session#createFilter. There are >> numerous reasons why >> > which I can discuss if anyone is interested in exploring this. >> > >> > Ultimately I think it makes sense to handle this via Java 8 >> streams[1] >> > although I am not sure that needs to happen in 6.0 >> > >> > [1] https://hibernate.atlassian.net/browse/HHH-10962 >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Mon Jan 2 06:37:36 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 02 Jan 2017 11:37:36 +0000 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: <1126a39a-3a7d-c109-f60e-f1b2f45a04c5@gmail.com> References: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> <1126a39a-3a7d-c109-f60e-f1b2f45a04c5@gmail.com> Message-ID: I think you are not understanding createFilter: http://docs.jboss.org/hibernate/orm/current/javadocs/org/hibernate/Session.html#createFilter Again, to call filter you'd have to have access to the Collection you want to filter. On Mon, Jan 2, 2017 at 2:40 AM Christian Beikov wrote: > Let's say we have this entity with an attribute that is not directly > exposed. > > class EntityA { String field; } > > and then you pass a collection of EntityA instances to createFilter like > > Collection collection = ... > collection = session.createFilter(collection, "field = > 'abc%'").getResultList(); > > See my point? Since Hibernate can access the field directly, this works, > but with streams you'd need to expose the field via a getter so you can > filter for it. > > > Am 02.01.2017 um 09:25 schrieb Steve Ebersole: > > Could you explain the situation where you would map a collection but not > expose it? And btw even create createFilter would not work there because > you have to pass createFilter the collection > > On Mon, Jan 2, 2017, 2:15 AM Christian Beikov > wrote: > > Well it does when you consider that there might be no getter for a field. > With createFilter you could still filter the result list without exposing > direct access to the field via a getter. > > Am 02.01.2017 um 08:52 schrieb Steve Ebersole: > > Field-access would have zero bearing on this > > On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > > Sounds good to me, but maybe we could do a poll to see if people are > using this? I don't know if the filter also works for field based access > strategy, but that could be a reason for keeping it around. > > Regards, > > Christian > > > Am 31.12.2016 um 21:00 schrieb Steve Ebersole: > > As I have not been hearing hardly any feedback on these 6.0 design > > questions I have been trying to start, I'll be doing something different > in > > this and any additional emails.. I'll state what I propose to do and if > > anyone has issue with it they can make a counter proposal. Otherwise I > > plan on following through with my proposal. > > > > I plan on removing Session#createFilter. There are numerous reasons why > > which I can discuss if anyone is interested in exploring this. > > > > Ultimately I think it makes sense to handle this via Java 8 streams[1] > > although I am not sure that needs to happen in 6.0 > > > > [1] https://hibernate.atlassian.net/browse/HHH-10962 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > From steve at hibernate.org Mon Jan 2 06:42:56 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 02 Jan 2017 11:42:56 +0000 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: org.hibernate.query.Query extends javax.persistence.TypedQuery since 5.2, so it already has been parameterized. Regarding JPA adopting scrolling as a feature, what I suggest simply follows what Hibernate ans JPA already do for other Query returns. Today it is completely inconsistent between Query#scroll and Query#list e.g.. I am just suggesting making that consistent. On Mon, Jan 2, 2017 at 2:36 AM Yoann Rodiere wrote: > For what it's worth, changing the signature indeed seems appropriate to > me: the fewer object arrays, the better. > Your proposal would require making Query parameterized too, though. I'm > not really up-to-date with the current state of 6.0, but I guess it's > already done or being done. > > Anyway, the only think I wanted to say was: if we break the API, maybe we > should try to make sure we won't have to break it again soon. There has > been some discussions about adding scrolling to the JPA spec: > https://java.net/jira/browse/JPA_SPEC-89 . Maybe it would be worth it to > ask for advice on this ticket, so as to limit the risk of having to break > this API again, because the spec would introduce an incompatible signature? > Not sure there would be many reactions, judging by the low activity on the > ticket, but who knows... > > Yoann Rodi?re > Hibernate NoORM Team > > On 27 December 2016 at 22:02, Steve Ebersole wrote: > > FWIW my inclination is to just change the existing signatures. 6.0 is a > major release with major changes already wrt querying. > > > > On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole > wrote: > > > For 6.0 I'd like to also make ScrollableResults parameterized wrt the > "row > > type". E.g. > > > > ScrollableResults sr = session.createQuery( ..., Person.class > > ).scroll(); > > > > However that changes the signature of its methods returning a "row" > > (currently always defined as Object[]). > > > > How would everyone prefer we handle this? Do I just change the > signatures > > of the existing methods? Or add new methods? > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From gunnar at hibernate.org Mon Jan 2 07:17:54 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 2 Jan 2017 13:17:54 +0100 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: What's the overall strategy for aligning the classic Query API with JPA for Hibernate ORM 6? Are you e.g. going to remove uniqueResult() as it's superseded by JPA's getSingleResult()? If so, I also vote for changing the existing method on ScrollableResults. Thinking about this, should there be support for type-safe retrieval of query results with multiple returns? E.g. something like this: ScrollableResults> sr = session.createQuery( "select p, a, c from ...", Person.class, Address.class, CustomerType.class ).scroll(); Person p = sr.get().get1(); Address a = sr.get().get2(); CustomerType c = sr.get().get3(); It'd require a few TupleN classes and an overload of createQuery() for each N. For a large number of returns one would still have to fall back to object arrays. Not sure whether it pulls its weight, but I thought I'd throw out the idea. 2017-01-02 12:42 GMT+01:00 Steve Ebersole : > org.hibernate.query.Query extends javax.persistence.TypedQuery since 5.2, > so it already has been parameterized. > > Regarding JPA adopting scrolling as a feature, what I suggest simply > follows what Hibernate ans JPA already do for other Query returns. Today > it is completely inconsistent between Query#scroll and Query#list e.g.. I > am just suggesting making that consistent. > > On Mon, Jan 2, 2017 at 2:36 AM Yoann Rodiere wrote: > > > For what it's worth, changing the signature indeed seems appropriate to > > me: the fewer object arrays, the better. > > Your proposal would require making Query parameterized too, though. I'm > > not really up-to-date with the current state of 6.0, but I guess it's > > already done or being done. > > > > Anyway, the only think I wanted to say was: if we break the API, maybe we > > should try to make sure we won't have to break it again soon. There has > > been some discussions about adding scrolling to the JPA spec: > > https://java.net/jira/browse/JPA_SPEC-89 . Maybe it would be worth it to > > ask for advice on this ticket, so as to limit the risk of having to break > > this API again, because the spec would introduce an incompatible > signature? > > Not sure there would be many reactions, judging by the low activity on > the > > ticket, but who knows... > > > > Yoann Rodi?re > > Hibernate NoORM Team > > > > On 27 December 2016 at 22:02, Steve Ebersole > wrote: > > > > FWIW my inclination is to just change the existing signatures. 6.0 is a > > major release with major changes already wrt querying. > > > > > > > > On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole > > wrote: > > > > > For 6.0 I'd like to also make ScrollableResults parameterized wrt the > > "row > > > type". E.g. > > > > > > ScrollableResults sr = session.createQuery( ..., Person.class > > > ).scroll(); > > > > > > However that changes the signature of its methods returning a "row" > > > (currently always defined as Object[]). > > > > > > How would everyone prefer we handle this? Do I just change the > > signatures > > > of the existing methods? Or add new methods? > > > > > > > _______________________________________________ > > 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 Mon Jan 2 08:08:34 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 2 Jan 2017 14:08:34 +0100 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: > I plan on removing Session#createFilter. There are numerous reasons why which I can discuss if anyone is interested in exploring this. I'm curious, what are the reasons for removing it? And if we remove it, what's the alternative for people to use? 2016-12-31 21:00 GMT+01:00 Steve Ebersole : > As I have not been hearing hardly any feedback on these 6.0 design > questions I have been trying to start, I'll be doing something different in > this and any additional emails.. I'll state what I propose to do and if > anyone has issue with it they can make a counter proposal. Otherwise I > plan on following through with my proposal. > > I plan on removing Session#createFilter. There are numerous reasons why > which I can discuss if anyone is interested in exploring this. > > Ultimately I think it makes sense to handle this via Java 8 streams[1] > although I am not sure that needs to happen in 6.0 > > [1] https://hibernate.atlassian.net/browse/HHH-10962 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Mon Jan 2 08:11:26 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 2 Jan 2017 14:11:26 +0100 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: > Regarding JPA adopting scrolling as a feature, what I suggest simply follows what Hibernate ans JPA already do for other Query returns. Today it is completely inconsistent between Query#scroll and Query#list e.g.. I am just suggesting making that consistent. Sure. I just wanted to point out that scrolling isn't part of JPA yet, but there are plans to add it, so we might as well try to know what form it will take in JPA 2.2 in order to make the change future-proof. To be perfectly clear: it was just a heads-up because I came accross this JPA ticket a few weeks ago, I don't have any specific concern in mind. If you think it's not relevant, sorry for the noise. Yoann Rodi?re Hibernate NoORM Team On 2 January 2017 at 12:42, Steve Ebersole wrote: > org.hibernate.query.Query extends javax.persistence.TypedQuery since 5.2, > so it already has been parameterized. > > Regarding JPA adopting scrolling as a feature, what I suggest simply > follows what Hibernate ans JPA already do for other Query returns. Today > it is completely inconsistent between Query#scroll and Query#list e.g.. I > am just suggesting making that consistent. > > On Mon, Jan 2, 2017 at 2:36 AM Yoann Rodiere wrote: > >> For what it's worth, changing the signature indeed seems appropriate to >> me: the fewer object arrays, the better. >> Your proposal would require making Query parameterized too, though. I'm >> not really up-to-date with the current state of 6.0, but I guess it's >> already done or being done. >> >> Anyway, the only think I wanted to say was: if we break the API, maybe we >> should try to make sure we won't have to break it again soon. There has >> been some discussions about adding scrolling to the JPA spec: >> https://java.net/jira/browse/JPA_SPEC-89 . Maybe it would be worth it to >> ask for advice on this ticket, so as to limit the risk of having to break >> this API again, because the spec would introduce an incompatible signature? >> Not sure there would be many reactions, judging by the low activity on >> the ticket, but who knows... >> >> Yoann Rodi?re >> Hibernate NoORM Team >> >> On 27 December 2016 at 22:02, Steve Ebersole wrote: >> >> FWIW my inclination is to just change the existing signatures. 6.0 is a >> major release with major changes already wrt querying. >> >> >> >> On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole >> wrote: >> >> > For 6.0 I'd like to also make ScrollableResults parameterized wrt the >> "row >> > type". E.g. >> > >> > ScrollableResults sr = session.createQuery( ..., Person.class >> > ).scroll(); >> > >> > However that changes the signature of its methods returning a "row" >> > (currently always defined as Object[]). >> > >> > How would everyone prefer we handle this? Do I just change the >> signatures >> > of the existing methods? Or add new methods? >> > >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> From steve at hibernate.org Mon Jan 2 09:09:19 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 02 Jan 2017 14:09:19 +0000 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: I knew of the request. Its just that on the EE group I am sure the decision will be consistency. On Mon, Jan 2, 2017 at 7:11 AM Yoann Rodiere wrote: > > Regarding JPA adopting scrolling as a feature, what I suggest simply > follows what Hibernate ans JPA already do for other Query returns. Today > it is completely inconsistent between Query#scroll and Query#list e.g.. I > am just suggesting making that consistent. > > Sure. I just wanted to point out that scrolling isn't part of JPA yet, but > there are plans to add it, so we might as well try to know what form it > will take in JPA 2.2 in order to make the change future-proof. > > To be perfectly clear: it was just a heads-up because I came accross this > JPA ticket a few weeks ago, I don't have any specific concern in mind. If > you think it's not relevant, sorry for the noise. > > > Yoann Rodi?re > Hibernate NoORM Team > > On 2 January 2017 at 12:42, Steve Ebersole wrote: > > org.hibernate.query.Query extends javax.persistence.TypedQuery since 5.2, > so it already has been parameterized. > > Regarding JPA adopting scrolling as a feature, what I suggest simply > follows what Hibernate ans JPA already do for other Query returns. Today > it is completely inconsistent between Query#scroll and Query#list e.g.. I > am just suggesting making that consistent. > > On Mon, Jan 2, 2017 at 2:36 AM Yoann Rodiere wrote: > > For what it's worth, changing the signature indeed seems appropriate to > me: the fewer object arrays, the better. > Your proposal would require making Query parameterized too, though. I'm > not really up-to-date with the current state of 6.0, but I guess it's > already done or being done. > > Anyway, the only think I wanted to say was: if we break the API, maybe we > should try to make sure we won't have to break it again soon. There has > been some discussions about adding scrolling to the JPA spec: > https://java.net/jira/browse/JPA_SPEC-89 . Maybe it would be worth it to > ask for advice on this ticket, so as to limit the risk of having to break > this API again, because the spec would introduce an incompatible signature? > Not sure there would be many reactions, judging by the low activity on the > ticket, but who knows... > > Yoann Rodi?re > Hibernate NoORM Team > > On 27 December 2016 at 22:02, Steve Ebersole wrote: > > FWIW my inclination is to just change the existing signatures. 6.0 is a > major release with major changes already wrt querying. > > > > On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole > wrote: > > > For 6.0 I'd like to also make ScrollableResults parameterized wrt the > "row > > type". E.g. > > > > ScrollableResults sr = session.createQuery( ..., Person.class > > ).scroll(); > > > > However that changes the signature of its methods returning a "row" > > (currently always defined as Object[]). > > > > How would everyone prefer we handle this? Do I just change the > signatures > > of the existing methods? Or add new methods? > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > From steve at hibernate.org Mon Jan 2 09:27:18 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 02 Jan 2017 14:27:18 +0000 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: The alternative atm is to directly query against the owning entity or directly against the element. Granted that last one assumes that the element defines a mapped reference back to the owner to be able to apply the restriction based on the FK, but that's the more normal mapping anyway. So e.g., if you have a filter like: `session.createFilter( customer.getOrders(), "orderDate < currentDate() - {3 months}" )`, instead you'd do: `select elements( c.orders ) from Customer c join c.orders where c.id = :customerId and o.orderDate < currentDate() - {3 months}` or `select o from Order o where o.customer = :customerId and o.orderDate < currentDate() - {3 months}`. Ultimately I'd also like to see "stream queries". This would take 2 forms: 1. Session#stream( Order.class )... 2. customer.getOrders().stream()... (this works because customer.getOrders() is a PersistentCollection and we'd control the stream() impl) The reasons for removing it are: 1. It dirties the HQL grammar. A valid filter string is literally"" (empty String) which means that the grammar needs to allow for that. 2. IMO it is a clunky API 3. I am pretty sure noone uses it. Not to pick on Christian, but he is a pretty advanced user and even he did not understand its use which speaks both to its obscurity as well as its clunkiness. On Mon, Jan 2, 2017 at 7:08 AM Gunnar Morling wrote: > > I plan on removing Session#createFilter. There are numerous reasons why > which I can discuss if anyone is interested in exploring this. > > I'm curious, what are the reasons for removing it? And if we remove it, > what's the alternative for people to use? > > > 2016-12-31 21:00 GMT+01:00 Steve Ebersole : > > As I have not been hearing hardly any feedback on these 6.0 design > questions I have been trying to start, I'll be doing something different in > this and any additional emails.. I'll state what I propose to do and if > anyone has issue with it they can make a counter proposal. Otherwise I > plan on following through with my proposal. > > I plan on removing Session#createFilter. There are numerous reasons why > which I can discuss if anyone is interested in exploring this. > > Ultimately I think it makes sense to handle this via Java 8 streams[1] > although I am not sure that needs to happen in 6.0 > > [1] https://hibernate.atlassian.net/browse/HHH-10962 > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From christian.beikov at gmail.com Mon Jan 2 09:45:23 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Mon, 2 Jan 2017 15:45:23 +0100 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> <1126a39a-3a7d-c109-f60e-f1b2f45a04c5@gmail.com> Message-ID: As far as I understand from the documentation(https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-filtering), it can be used to filter collections and arrays. I don't know if it only works for persistent collections but since arrays are also mentioned, I guess not. I'd expect the collection or array to be filtered and projected in-memory if possible, thus not executing a query unless needed for a lazy collection or additional from clause. If that understanding is wrong, please help me understand what the purpose is then. Am 02.01.2017 um 12:37 schrieb Steve Ebersole: > I think you are not understanding createFilter: > > http://docs.jboss.org/hibernate/orm/current/javadocs/org/hibernate/Session.html#createFilter > > Again, to call filter you'd have to have access to the Collection you > want to filter. > > On Mon, Jan 2, 2017 at 2:40 AM Christian Beikov > > wrote: > > Let's say we have this entity with an attribute that is not > directly exposed. > > class EntityA { String field; } > > and then you pass a collection of EntityA instances to > createFilter like > > Collection collection = ... > collection = session.createFilter(collection, "field = > 'abc%'").getResultList(); > > See my point? Since Hibernate can access the field directly, this > works, but with streams you'd need to expose the field via a > getter so you can filter for it. > > > Am 02.01.2017 um 09:25 schrieb Steve Ebersole: >> >> Could you explain the situation where you would map a collection >> but not expose it? And btw even create createFilter would not >> work there because you have to pass createFilter the collection >> >> >> On Mon, Jan 2, 2017, 2:15 AM Christian Beikov >> > >> wrote: >> >> Well it does when you consider that there might be no getter >> for a field. With createFilter you could still filter the >> result list without exposing direct access to the field via a >> getter. >> >> Am 02.01.2017 um 08:52 schrieb Steve Ebersole: >>> Field-access would have zero bearing on this >>> >>> On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov >>> >> > wrote: >>> >>> Sounds good to me, but maybe we could do a poll to see >>> if people are >>> using this? I don't know if the filter also works for >>> field based access >>> strategy, but that could be a reason for keeping it around. >>> >>> Regards, >>> >>> Christian >>> >>> >>> Am 31.12.2016 um 21:00 schrieb Steve Ebersole: >>> > As I have not been hearing hardly any feedback on >>> these 6.0 design >>> > questions I have been trying to start, I'll be doing >>> something different in >>> > this and any additional emails.. I'll state what I >>> propose to do and if >>> > anyone has issue with it they can make a counter >>> proposal. Otherwise I >>> > plan on following through with my proposal. >>> > >>> > I plan on removing Session#createFilter. There are >>> numerous reasons why >>> > which I can discuss if anyone is interested in >>> exploring this. >>> > >>> > Ultimately I think it makes sense to handle this via >>> Java 8 streams[1] >>> > although I am not sure that needs to happen in 6.0 >>> > >>> > [1] https://hibernate.atlassian.net/browse/HHH-10962 >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > From steve at hibernate.org Mon Jan 2 10:11:58 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 02 Jan 2017 15:11:58 +0000 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> <1126a39a-3a7d-c109-f60e-f1b2f45a04c5@gmail.com> Message-ID: Well stop and think about it... What do you expect session.filter( new ArrayList(), "") to do? Yes, it has to be a PersistentCollection. Hibernate handles "persistent arrays" as well (see org.hibernate.collection.internal.PersistentArrayHolder), although it is a discouraged feature. It is used to apply: 1. an implicit from-clause element for the collection owner (named "this") 2. a restriction on the PersistentCollection's owner. So a filter like I mentioned before (`session.createFilter( customer.getOrders(), "orderDate < currentDate() - {3 months}" )`) is really the same as (it is literally converted to this internally): `select elements( this.orders ) from Customer this where this.id = and orderDate < currentDate() - {3 months}` On Mon, Jan 2, 2017 at 8:45 AM Christian Beikov wrote: > As far as I understand from the documentation( > https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-filtering), > it can be used to filter collections and arrays. I don't know if it only > works for persistent collections but since arrays are also mentioned, I > guess not. > I'd expect the collection or array to be filtered and projected in-memory > if possible, thus not executing a query unless needed for a lazy collection > or additional from clause. > > If that understanding is wrong, please help me understand what the purpose > is then. > > > Am 02.01.2017 um 12:37 schrieb Steve Ebersole: > > I think you are not understanding createFilter: > > > http://docs.jboss.org/hibernate/orm/current/javadocs/org/hibernate/Session.html#createFilter > > Again, to call filter you'd have to have access to the Collection you want > to filter. > > On Mon, Jan 2, 2017 at 2:40 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > > Let's say we have this entity with an attribute that is not directly > exposed. > > class EntityA { String field; } > > and then you pass a collection of EntityA instances to createFilter like > > Collection collection = ... > collection = session.createFilter(collection, "field = > 'abc%'").getResultList(); > > See my point? Since Hibernate can access the field directly, this works, > but with streams you'd need to expose the field via a getter so you can > filter for it. > > > Am 02.01.2017 um 09:25 schrieb Steve Ebersole: > > Could you explain the situation where you would map a collection but not > expose it? And btw even create createFilter would not work there because > you have to pass createFilter the collection > > On Mon, Jan 2, 2017, 2:15 AM Christian Beikov > wrote: > > Well it does when you consider that there might be no getter for a field. > With createFilter you could still filter the result list without exposing > direct access to the field via a getter. > > Am 02.01.2017 um 08:52 schrieb Steve Ebersole: > > Field-access would have zero bearing on this > > On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > > Sounds good to me, but maybe we could do a poll to see if people are > using this? I don't know if the filter also works for field based access > strategy, but that could be a reason for keeping it around. > > Regards, > > Christian > > > Am 31.12.2016 um 21:00 schrieb Steve Ebersole: > > As I have not been hearing hardly any feedback on these 6.0 design > > questions I have been trying to start, I'll be doing something different > in > > this and any additional emails.. I'll state what I propose to do and if > > anyone has issue with it they can make a counter proposal. Otherwise I > > plan on following through with my proposal. > > > > I plan on removing Session#createFilter. There are numerous reasons why > > which I can discuss if anyone is interested in exploring this. > > > > Ultimately I think it makes sense to handle this via Java 8 streams[1] > > although I am not sure that needs to happen in 6.0 > > > > [1] https://hibernate.atlassian.net/browse/HHH-10962 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > From steve at hibernate.org Mon Jan 2 10:41:38 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 02 Jan 2017 15:41:38 +0000 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> <1126a39a-3a7d-c109-f60e-f1b2f45a04c5@gmail.com> Message-ID: Christian and I chatted on HipChat. It seems his confusion stems partially from misunderstanding #createFilter, but also the fact that I did not go into detail regarding the plans for this streaming support. I thought it would be a good idea to discuss that at a high level here. The main thing to bear in mind is that intention is such that there stream calls would be translated into SQL rather than resolved in memory (aka get a huge ResultSet and filter etc based on the stream calls). This email was just meant to discuss the removal of the #createFilter method so I did not go into detail. Also too, the design of that is still a discussion point. Initially I am thinking it would leverage the JPA metamodel, e.g. the static metamodel (the generated Order_ stuff). I should also point out that I completely plan to remove #createFilter in 6.0 and not introduce this streaming stuff until 6.x. 6.0 is already getting beyond its initial scope and I's much rather get 6.0 released earlier and "oftener" :) On Mon, Jan 2, 2017 at 9:11 AM Steve Ebersole wrote: > Well stop and think about it... What do you expect session.filter( new > ArrayList(), "") to do? > > Yes, it has to be a PersistentCollection. Hibernate handles "persistent > arrays" as well > (see org.hibernate.collection.internal.PersistentArrayHolder), although it > is a discouraged feature. > > It is used to apply: > > 1. an implicit from-clause element for the collection owner (named > "this") > 2. a restriction on the PersistentCollection's owner. > > So a filter like I mentioned before (`session.createFilter( > customer.getOrders(), "orderDate < currentDate() - {3 months}" )`) is > really the same as (it is literally converted to this internally): > > `select elements( this.orders ) from Customer this where this.id = > and orderDate < currentDate() - {3 months}` > > > On Mon, Jan 2, 2017 at 8:45 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > > As far as I understand from the documentation( > https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-filtering), > it can be used to filter collections and arrays. I don't know if it only > works for persistent collections but since arrays are also mentioned, I > guess not. > I'd expect the collection or array to be filtered and projected in-memory > if possible, thus not executing a query unless needed for a lazy collection > or additional from clause. > > If that understanding is wrong, please help me understand what the purpose > is then. > > > Am 02.01.2017 um 12:37 schrieb Steve Ebersole: > > I think you are not understanding createFilter: > > > http://docs.jboss.org/hibernate/orm/current/javadocs/org/hibernate/Session.html#createFilter > > Again, to call filter you'd have to have access to the Collection you want > to filter. > > On Mon, Jan 2, 2017 at 2:40 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > > Let's say we have this entity with an attribute that is not directly > exposed. > > class EntityA { String field; } > > and then you pass a collection of EntityA instances to createFilter like > > Collection collection = ... > collection = session.createFilter(collection, "field = > 'abc%'").getResultList(); > > See my point? Since Hibernate can access the field directly, this works, > but with streams you'd need to expose the field via a getter so you can > filter for it. > > > Am 02.01.2017 um 09:25 schrieb Steve Ebersole: > > Could you explain the situation where you would map a collection but not > expose it? And btw even create createFilter would not work there because > you have to pass createFilter the collection > > On Mon, Jan 2, 2017, 2:15 AM Christian Beikov > wrote: > > Well it does when you consider that there might be no getter for a field. > With createFilter you could still filter the result list without exposing > direct access to the field via a getter. > > Am 02.01.2017 um 08:52 schrieb Steve Ebersole: > > Field-access would have zero bearing on this > > On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > > Sounds good to me, but maybe we could do a poll to see if people are > using this? I don't know if the filter also works for field based access > strategy, but that could be a reason for keeping it around. > > Regards, > > Christian > > > Am 31.12.2016 um 21:00 schrieb Steve Ebersole: > > As I have not been hearing hardly any feedback on these 6.0 design > > questions I have been trying to start, I'll be doing something different > in > > this and any additional emails.. I'll state what I propose to do and if > > anyone has issue with it they can make a counter proposal. Otherwise I > > plan on following through with my proposal. > > > > I plan on removing Session#createFilter. There are numerous reasons why > > which I can discuss if anyone is interested in exploring this. > > > > Ultimately I think it makes sense to handle this via Java 8 streams[1] > > although I am not sure that needs to happen in 6.0 > > > > [1] https://hibernate.atlassian.net/browse/HHH-10962 > > _______________________________________________ > > 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 Tue Jan 3 05:41:25 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 3 Jan 2017 10:41:25 +0000 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> <1126a39a-3a7d-c109-f60e-f1b2f45a04c5@gmail.com> Message-ID: I wonder if "use streams" is a reasonable replacement for all power users who might have needed this? We know by experience there's loads of such people not reading this list, so maybe we'd need a deprecation cycle. I don't mean to dive deeply in implementation details and plans, but I suspect that the createFilter approach was able to limit the amount of data we pump out of the database into the Java heap, while a solution based on Java8 streams would post-filter the data, unless you plan to have Hibernate able to convert all filter predicates into SQL? (which sounds awesome but I wasn't expecting that soon..) Just wondering if that might be unacceptable to people mapping very large collections. Thanks, Sanne On 2 January 2017 at 15:41, Steve Ebersole wrote: > Christian and I chatted on HipChat. It seems his confusion stems partially > from misunderstanding #createFilter, but also the fact that I did not go > into detail regarding the plans for this streaming support. I thought it > would be a good idea to discuss that at a high level here. The main thing > to bear in mind is that intention is such that there stream calls would be > translated into SQL rather than resolved in memory (aka get a huge > ResultSet and filter etc based on the stream calls). > > This email was just meant to discuss the removal of the #createFilter > method so I did not go into detail. Also too, the design of that is still > a discussion point. Initially I am thinking it would leverage the JPA > metamodel, e.g. the static metamodel (the generated Order_ stuff). > > I should also point out that I completely plan to remove #createFilter in > 6.0 and not introduce this streaming stuff until 6.x. 6.0 is already > getting beyond its initial scope and I's much rather get 6.0 released > earlier and "oftener" :) > > On Mon, Jan 2, 2017 at 9:11 AM Steve Ebersole wrote: > >> Well stop and think about it... What do you expect session.filter( new >> ArrayList(), "") to do? >> >> Yes, it has to be a PersistentCollection. Hibernate handles "persistent >> arrays" as well >> (see org.hibernate.collection.internal.PersistentArrayHolder), although it >> is a discouraged feature. >> >> It is used to apply: >> >> 1. an implicit from-clause element for the collection owner (named >> "this") >> 2. a restriction on the PersistentCollection's owner. >> >> So a filter like I mentioned before (`session.createFilter( >> customer.getOrders(), "orderDate < currentDate() - {3 months}" )`) is >> really the same as (it is literally converted to this internally): >> >> `select elements( this.orders ) from Customer this where this.id = >> and orderDate < currentDate() - {3 months}` >> >> >> On Mon, Jan 2, 2017 at 8:45 AM Christian Beikov < >> christian.beikov at gmail.com> wrote: >> >> As far as I understand from the documentation( >> https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-filtering), >> it can be used to filter collections and arrays. I don't know if it only >> works for persistent collections but since arrays are also mentioned, I >> guess not. >> I'd expect the collection or array to be filtered and projected in-memory >> if possible, thus not executing a query unless needed for a lazy collection >> or additional from clause. >> >> If that understanding is wrong, please help me understand what the purpose >> is then. >> >> >> Am 02.01.2017 um 12:37 schrieb Steve Ebersole: >> >> I think you are not understanding createFilter: >> >> >> http://docs.jboss.org/hibernate/orm/current/javadocs/org/hibernate/Session.html#createFilter >> >> Again, to call filter you'd have to have access to the Collection you want >> to filter. >> >> On Mon, Jan 2, 2017 at 2:40 AM Christian Beikov < >> christian.beikov at gmail.com> wrote: >> >> Let's say we have this entity with an attribute that is not directly >> exposed. >> >> class EntityA { String field; } >> >> and then you pass a collection of EntityA instances to createFilter like >> >> Collection collection = ... >> collection = session.createFilter(collection, "field = >> 'abc%'").getResultList(); >> >> See my point? Since Hibernate can access the field directly, this works, >> but with streams you'd need to expose the field via a getter so you can >> filter for it. >> >> >> Am 02.01.2017 um 09:25 schrieb Steve Ebersole: >> >> Could you explain the situation where you would map a collection but not >> expose it? And btw even create createFilter would not work there because >> you have to pass createFilter the collection >> >> On Mon, Jan 2, 2017, 2:15 AM Christian Beikov >> wrote: >> >> Well it does when you consider that there might be no getter for a field. >> With createFilter you could still filter the result list without exposing >> direct access to the field via a getter. >> >> Am 02.01.2017 um 08:52 schrieb Steve Ebersole: >> >> Field-access would have zero bearing on this >> >> On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov < >> christian.beikov at gmail.com> wrote: >> >> Sounds good to me, but maybe we could do a poll to see if people are >> using this? I don't know if the filter also works for field based access >> strategy, but that could be a reason for keeping it around. >> >> Regards, >> >> Christian >> >> >> Am 31.12.2016 um 21:00 schrieb Steve Ebersole: >> > As I have not been hearing hardly any feedback on these 6.0 design >> > questions I have been trying to start, I'll be doing something different >> in >> > this and any additional emails.. I'll state what I propose to do and if >> > anyone has issue with it they can make a counter proposal. Otherwise I >> > plan on following through with my proposal. >> > >> > I plan on removing Session#createFilter. There are numerous reasons why >> > which I can discuss if anyone is interested in exploring this. >> > >> > Ultimately I think it makes sense to handle this via Java 8 streams[1] >> > although I am not sure that needs to happen in 6.0 >> > >> > [1] https://hibernate.atlassian.net/browse/HHH-10962 >> > _______________________________________________ >> > 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 Tue Jan 3 05:57:50 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 3 Jan 2017 10:57:50 +0000 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: It sounds great but I'm not sure it's possible? For example how would this handle projections? I guess it's a similar doubt as the one Gunnar shared, but while he suggests a semi-typesafe solution, I'm not sure how cool it is to give the feeling that types are being checked when they might actually blow at runtime, if the query string doesn't match expectations. Could an Annotation Processor verify the declared return types really match the HQL select? Assuming the answer is no, I'd prefer the return types to explicitly highlight the need for casting by using "Object[]": I suspect errors leading to a type mismatch would produce more understandable errors. On 2 January 2017 at 14:09, Steve Ebersole wrote: > I knew of the request. Its just that on the EE group I am sure the > decision will be consistency. > > On Mon, Jan 2, 2017 at 7:11 AM Yoann Rodiere wrote: > >> > Regarding JPA adopting scrolling as a feature, what I suggest simply >> follows what Hibernate ans JPA already do for other Query returns. Today >> it is completely inconsistent between Query#scroll and Query#list e.g.. I >> am just suggesting making that consistent. >> >> Sure. I just wanted to point out that scrolling isn't part of JPA yet, but >> there are plans to add it, so we might as well try to know what form it >> will take in JPA 2.2 in order to make the change future-proof. >> >> To be perfectly clear: it was just a heads-up because I came accross this >> JPA ticket a few weeks ago, I don't have any specific concern in mind. If >> you think it's not relevant, sorry for the noise. >> >> >> Yoann Rodi?re >> Hibernate NoORM Team >> >> On 2 January 2017 at 12:42, Steve Ebersole wrote: >> >> org.hibernate.query.Query extends javax.persistence.TypedQuery since 5.2, >> so it already has been parameterized. >> >> Regarding JPA adopting scrolling as a feature, what I suggest simply >> follows what Hibernate ans JPA already do for other Query returns. Today >> it is completely inconsistent between Query#scroll and Query#list e.g.. I >> am just suggesting making that consistent. >> >> On Mon, Jan 2, 2017 at 2:36 AM Yoann Rodiere wrote: >> >> For what it's worth, changing the signature indeed seems appropriate to >> me: the fewer object arrays, the better. >> Your proposal would require making Query parameterized too, though. I'm >> not really up-to-date with the current state of 6.0, but I guess it's >> already done or being done. >> >> Anyway, the only think I wanted to say was: if we break the API, maybe we >> should try to make sure we won't have to break it again soon. There has >> been some discussions about adding scrolling to the JPA spec: >> https://java.net/jira/browse/JPA_SPEC-89 . Maybe it would be worth it to >> ask for advice on this ticket, so as to limit the risk of having to break >> this API again, because the spec would introduce an incompatible signature? >> Not sure there would be many reactions, judging by the low activity on the >> ticket, but who knows... >> >> Yoann Rodi?re >> Hibernate NoORM Team >> >> On 27 December 2016 at 22:02, Steve Ebersole wrote: >> >> FWIW my inclination is to just change the existing signatures. 6.0 is a >> major release with major changes already wrt querying. >> >> >> >> On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole >> wrote: >> >> > For 6.0 I'd like to also make ScrollableResults parameterized wrt the >> "row >> > type". E.g. >> > >> > ScrollableResults sr = session.createQuery( ..., Person.class >> > ).scroll(); >> > >> > However that changes the signature of its methods returning a "row" >> > (currently always defined as Object[]). >> > >> > How would everyone prefer we handle this? Do I just change the >> signatures >> > of the existing methods? Or add new methods? >> > >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Tue Jan 3 06:31:22 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 3 Jan 2017 12:31:22 +0100 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: 2017-01-02 15:27 GMT+01:00 Steve Ebersole : > The alternative atm is to directly query against the owning entity or > directly against the element. Granted that last one assumes that the > element defines a mapped reference back to the owner to be able to apply > the restriction based on the FK, but that's the more normal mapping anyway. > I realize now that Session#createFilter() is only geared towards collections. So are you suggesting to only remove that method, but keep @Filter/@FilterDef? I've never used filters myself, but my understanding always was that it's meant for filtering out records on a global level. E.g. to only select enabled records (by means of an "enabled" flag present for all entities) without having to adjust each and every query for that. When used in that way, taking away filters altogether may be quite disruptive. But it's not clear to me whether that's actually what you are suggesting. So e.g., if you have a filter like: `session.createFilter( > customer.getOrders(), "orderDate < currentDate() - {3 months}" )`, instead > you'd do: `select elements( c.orders ) from Customer c join c.orders where > c.id = :customerId and o.orderDate < currentDate() - {3 months}` or > `select o from Order o where o.customer = :customerId and o.orderDate < > currentDate() - {3 months}`. > > Ultimately I'd also like to see "stream queries". This would take 2 forms: > > 1. Session#stream( Order.class )... > 2. customer.getOrders().stream()... (this works because > customer.getOrders() is a PersistentCollection and we'd control the > stream() impl) > > > The reasons for removing it are: > > 1. It dirties the HQL grammar. A valid filter string is literally"" > (empty String) which means that the grammar needs to allow for that. > 2. IMO it is a clunky API > 3. I am pretty sure noone uses it. Not to pick on Christian, but he > is a pretty advanced user and even he did not understand its use which > speaks both to its obscurity as well as its clunkiness. > > > On Mon, Jan 2, 2017 at 7:08 AM Gunnar Morling > wrote: > >> > I plan on removing Session#createFilter. There are numerous reasons >> why >> which I can discuss if anyone is interested in exploring this. >> >> I'm curious, what are the reasons for removing it? And if we remove it, >> what's the alternative for people to use? >> >> >> 2016-12-31 21:00 GMT+01:00 Steve Ebersole : >> >> As I have not been hearing hardly any feedback on these 6.0 design >> questions I have been trying to start, I'll be doing something different >> in >> this and any additional emails.. I'll state what I propose to do and if >> anyone has issue with it they can make a counter proposal. Otherwise I >> plan on following through with my proposal. >> >> I plan on removing Session#createFilter. There are numerous reasons why >> which I can discuss if anyone is interested in exploring this. >> >> Ultimately I think it makes sense to handle this via Java 8 streams[1] >> although I am not sure that needs to happen in 6.0 >> >> [1] https://hibernate.atlassian.net/browse/HHH-10962 >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> From gunnar at hibernate.org Tue Jan 3 06:39:34 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 3 Jan 2017 12:39:34 +0100 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: 2017-01-03 11:57 GMT+01:00 Sanne Grinovero : > It sounds great but I'm not sure it's possible? > WDYM specifically? For example how would this handle projections? I guess it's a similar > doubt as the one Gunnar shared, but while he suggests a semi-typesafe > solution, I'm not sure how cool it is to give the feeling that types > are being checked when they might actually blow at runtime, if the > query string doesn't match expectations. > Could an Annotation Processor verify the declared return types really > match the HQL select? > I understand your point, but isn't it the same for createQuery( "from Foo", Bar.class )? This also will only be detected at runtime. I.e. I don't see how it's worse for the tuple approach? Btw. we'd one Tuple type per number of returns, i.e. Tuple2, Tuple3 etc., each with the right number of type arguments. As said I'm not fully convinced myself, but some may find it nicer to use than casting the elements of an array. Assuming the answer is no, I'd prefer the return types to explicitly > highlight the need for casting by using "Object[]": I suspect errors > leading to a type mismatch would produce more understandable errors. > > > On 2 January 2017 at 14:09, Steve Ebersole wrote: > > I knew of the request. Its just that on the EE group I am sure the > > decision will be consistency. > > > > On Mon, Jan 2, 2017 at 7:11 AM Yoann Rodiere > wrote: > > > >> > Regarding JPA adopting scrolling as a feature, what I suggest simply > >> follows what Hibernate ans JPA already do for other Query returns. > Today > >> it is completely inconsistent between Query#scroll and Query#list > e.g.. I > >> am just suggesting making that consistent. > >> > >> Sure. I just wanted to point out that scrolling isn't part of JPA yet, > but > >> there are plans to add it, so we might as well try to know what form it > >> will take in JPA 2.2 in order to make the change future-proof. > >> > >> To be perfectly clear: it was just a heads-up because I came accross > this > >> JPA ticket a few weeks ago, I don't have any specific concern in mind. > If > >> you think it's not relevant, sorry for the noise. > >> > >> > >> Yoann Rodi?re > >> Hibernate NoORM Team > >> > >> On 2 January 2017 at 12:42, Steve Ebersole wrote: > >> > >> org.hibernate.query.Query extends javax.persistence.TypedQuery since > 5.2, > >> so it already has been parameterized. > >> > >> Regarding JPA adopting scrolling as a feature, what I suggest simply > >> follows what Hibernate ans JPA already do for other Query returns. > Today > >> it is completely inconsistent between Query#scroll and Query#list > e.g.. I > >> am just suggesting making that consistent. > >> > >> On Mon, Jan 2, 2017 at 2:36 AM Yoann Rodiere > wrote: > >> > >> For what it's worth, changing the signature indeed seems appropriate to > >> me: the fewer object arrays, the better. > >> Your proposal would require making Query parameterized too, though. I'm > >> not really up-to-date with the current state of 6.0, but I guess it's > >> already done or being done. > >> > >> Anyway, the only think I wanted to say was: if we break the API, maybe > we > >> should try to make sure we won't have to break it again soon. There has > >> been some discussions about adding scrolling to the JPA spec: > >> https://java.net/jira/browse/JPA_SPEC-89 . Maybe it would be worth it > to > >> ask for advice on this ticket, so as to limit the risk of having to > break > >> this API again, because the spec would introduce an incompatible > signature? > >> Not sure there would be many reactions, judging by the low activity on > the > >> ticket, but who knows... > >> > >> Yoann Rodi?re > >> Hibernate NoORM Team > >> > >> On 27 December 2016 at 22:02, Steve Ebersole > wrote: > >> > >> FWIW my inclination is to just change the existing signatures. 6.0 is a > >> major release with major changes already wrt querying. > >> > >> > >> > >> On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole > >> wrote: > >> > >> > For 6.0 I'd like to also make ScrollableResults parameterized wrt the > >> "row > >> > type". E.g. > >> > > >> > ScrollableResults sr = session.createQuery( ..., Person.class > >> > ).scroll(); > >> > > >> > However that changes the signature of its methods returning a "row" > >> > (currently always defined as Object[]). > >> > > >> > How would everyone prefer we handle this? Do I just change the > >> signatures > >> > of the existing methods? Or add new methods? > >> > > >> > >> _______________________________________________ > >> 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 Tue Jan 3 06:54:32 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 3 Jan 2017 11:54:32 +0000 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: On 3 January 2017 at 11:39, Gunnar Morling wrote: > 2017-01-03 11:57 GMT+01:00 Sanne Grinovero : >> >> It sounds great but I'm not sure it's possible? > > > WDYM specifically? > >> For example how would this handle projections? I guess it's a similar >> doubt as the one Gunnar shared, but while he suggests a semi-typesafe >> solution, I'm not sure how cool it is to give the feeling that types >> are being checked when they might actually blow at runtime, if the >> query string doesn't match expectations. >> Could an Annotation Processor verify the declared return types really >> match the HQL select? > > > I understand your point, but isn't it the same for createQuery( "from Foo", > Bar.class )? This also will only be detected at runtime. I.e. I don't see > how it's worse for the tuple approach? Yes it's the same problem: I wish we could fix that too. If only someone here was a expert of annotation processors maybe he could tell me if I'm dreaming :D From gunnar at hibernate.org Tue Jan 3 07:13:26 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 3 Jan 2017 13:13:26 +0100 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: > If only someone here was a expert of annotation processors maybe he > could tell me if I'm dreaming :D :) It's not something you could do with an AP officially as they don't see the AST below method level. You could do it by casting to internal implementation types of javac which will give you the full AST down to actual leave nodes. But it's not something I'd feel like doing as it ties you to com.sun.* APIs and won't be portable across compilers. The checker framework ( http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html) helps a bit with it. But the issue remains that it cannot be used with Eclipse's compiler. Probably the best way to address this concern is to not use JP-QL but a strongly typed query DSL altogether. --Gunnar 2017-01-03 12:54 GMT+01:00 Sanne Grinovero : > On 3 January 2017 at 11:39, Gunnar Morling wrote: > > 2017-01-03 11:57 GMT+01:00 Sanne Grinovero : > >> > >> It sounds great but I'm not sure it's possible? > > > > > > WDYM specifically? > > > >> For example how would this handle projections? I guess it's a similar > >> doubt as the one Gunnar shared, but while he suggests a semi-typesafe > >> solution, I'm not sure how cool it is to give the feeling that types > >> are being checked when they might actually blow at runtime, if the > >> query string doesn't match expectations. > >> Could an Annotation Processor verify the declared return types really > >> match the HQL select? > > > > > > I understand your point, but isn't it the same for createQuery( "from > Foo", > > Bar.class )? This also will only be detected at runtime. I.e. I don't see > > how it's worse for the tuple approach? > > Yes it's the same problem: I wish we could fix that too. > > If only someone here was a expert of annotation processors maybe he > could tell me if I'm dreaming :D > From davide at hibernate.org Tue Jan 3 07:31:21 2017 From: davide at hibernate.org (Davide D'Alto) Date: Tue, 3 Jan 2017 12:31:21 +0000 Subject: [hibernate-dev] CI Jenkins upgraded to version 2.38 In-Reply-To: References: Message-ID: Thanks for the feedback, header and footer should be fine now. Thanks, Davide On Thu, Dec 29, 2016 at 11:37 PM, Sanne Grinovero wrote: > Thanks Davide! > The builds seems to work just fine, the only minor defect I've noticed > is with the stylesheet doing some strange things when scrolling down: > the breadcrumbs will "float" down as well. Definitely not urgent, > great to have all updates! > > Thanks, > Sanne > > > On 28 December 2016 at 01:04, Davide D'Alto wrote: >> Hi, >> I hope you all had great holidays. >> >> I've upgraded our Jenkin on CI to version 2.38. >> >> As far as i can tell everything seems all right, but if you experience >> some unusual problems, >> please, let me know. >> >> >> Cheers, >> Davide >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Tue Jan 3 09:26:41 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 03 Jan 2017 14:26:41 +0000 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> <1126a39a-3a7d-c109-f60e-f1b2f45a04c5@gmail.com> Message-ID: The plan with Stream support here is exactly that... translate the map, filter etc calls into a SQL query. On Tue, Jan 3, 2017 at 4:41 AM Sanne Grinovero wrote: > I wonder if "use streams" is a reasonable replacement for all power > users who might have needed this? We know by experience there's loads > of such people not reading this list, so maybe we'd need a deprecation > cycle. > I don't mean to dive deeply in implementation details and plans, but I > suspect that the createFilter approach was able to limit the amount of > data we pump out of the database into the Java heap, while a solution > based on Java8 streams would post-filter the data, unless you plan to > have Hibernate able to convert all filter predicates into SQL? (which > sounds awesome but I wasn't expecting that soon..) > > Just wondering if that might be unacceptable to people mapping very > large collections. > > Thanks, > Sanne > > > On 2 January 2017 at 15:41, Steve Ebersole wrote: > > Christian and I chatted on HipChat. It seems his confusion stems > partially > > from misunderstanding #createFilter, but also the fact that I did not go > > into detail regarding the plans for this streaming support. I thought it > > would be a good idea to discuss that at a high level here. The main > thing > > to bear in mind is that intention is such that there stream calls would > be > > translated into SQL rather than resolved in memory (aka get a huge > > ResultSet and filter etc based on the stream calls). > > > > This email was just meant to discuss the removal of the #createFilter > > method so I did not go into detail. Also too, the design of that is > still > > a discussion point. Initially I am thinking it would leverage the JPA > > metamodel, e.g. the static metamodel (the generated Order_ stuff). > > > > I should also point out that I completely plan to remove #createFilter in > > 6.0 and not introduce this streaming stuff until 6.x. 6.0 is already > > getting beyond its initial scope and I's much rather get 6.0 released > > earlier and "oftener" :) > > > > On Mon, Jan 2, 2017 at 9:11 AM Steve Ebersole > wrote: > > > >> Well stop and think about it... What do you expect session.filter( new > >> ArrayList(), "") to do? > >> > >> Yes, it has to be a PersistentCollection. Hibernate handles "persistent > >> arrays" as well > >> (see org.hibernate.collection.internal.PersistentArrayHolder), although > it > >> is a discouraged feature. > >> > >> It is used to apply: > >> > >> 1. an implicit from-clause element for the collection owner (named > >> "this") > >> 2. a restriction on the PersistentCollection's owner. > >> > >> So a filter like I mentioned before (`session.createFilter( > >> customer.getOrders(), "orderDate < currentDate() - {3 months}" )`) is > >> really the same as (it is literally converted to this internally): > >> > >> `select elements( this.orders ) from Customer this where this.id = > >> and orderDate < currentDate() - {3 months}` > >> > >> > >> On Mon, Jan 2, 2017 at 8:45 AM Christian Beikov < > >> christian.beikov at gmail.com> wrote: > >> > >> As far as I understand from the documentation( > >> > https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-filtering > ), > >> it can be used to filter collections and arrays. I don't know if it only > >> works for persistent collections but since arrays are also mentioned, I > >> guess not. > >> I'd expect the collection or array to be filtered and projected > in-memory > >> if possible, thus not executing a query unless needed for a lazy > collection > >> or additional from clause. > >> > >> If that understanding is wrong, please help me understand what the > purpose > >> is then. > >> > >> > >> Am 02.01.2017 um 12:37 schrieb Steve Ebersole: > >> > >> I think you are not understanding createFilter: > >> > >> > >> > http://docs.jboss.org/hibernate/orm/current/javadocs/org/hibernate/Session.html#createFilter > >> > >> Again, to call filter you'd have to have access to the Collection you > want > >> to filter. > >> > >> On Mon, Jan 2, 2017 at 2:40 AM Christian Beikov < > >> christian.beikov at gmail.com> wrote: > >> > >> Let's say we have this entity with an attribute that is not directly > >> exposed. > >> > >> class EntityA { String field; } > >> > >> and then you pass a collection of EntityA instances to createFilter like > >> > >> Collection collection = ... > >> collection = session.createFilter(collection, "field = > >> 'abc%'").getResultList(); > >> > >> See my point? Since Hibernate can access the field directly, this works, > >> but with streams you'd need to expose the field via a getter so you can > >> filter for it. > >> > >> > >> Am 02.01.2017 um 09:25 schrieb Steve Ebersole: > >> > >> Could you explain the situation where you would map a collection but not > >> expose it? And btw even create createFilter would not work there > because > >> you have to pass createFilter the collection > >> > >> On Mon, Jan 2, 2017, 2:15 AM Christian Beikov < > christian.beikov at gmail.com> > >> wrote: > >> > >> Well it does when you consider that there might be no getter for a > field. > >> With createFilter you could still filter the result list without > exposing > >> direct access to the field via a getter. > >> > >> Am 02.01.2017 um 08:52 schrieb Steve Ebersole: > >> > >> Field-access would have zero bearing on this > >> > >> On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov < > >> christian.beikov at gmail.com> wrote: > >> > >> Sounds good to me, but maybe we could do a poll to see if people are > >> using this? I don't know if the filter also works for field based access > >> strategy, but that could be a reason for keeping it around. > >> > >> Regards, > >> > >> Christian > >> > >> > >> Am 31.12.2016 um 21:00 schrieb Steve Ebersole: > >> > As I have not been hearing hardly any feedback on these 6.0 design > >> > questions I have been trying to start, I'll be doing something > different > >> in > >> > this and any additional emails.. I'll state what I propose to do and > if > >> > anyone has issue with it they can make a counter proposal. Otherwise > I > >> > plan on following through with my proposal. > >> > > >> > I plan on removing Session#createFilter. There are numerous reasons > why > >> > which I can discuss if anyone is interested in exploring this. > >> > > >> > Ultimately I think it makes sense to handle this via Java 8 streams[1] > >> > although I am not sure that needs to happen in 6.0 > >> > > >> > [1] https://hibernate.atlassian.net/browse/HHH-10962 > >> > _______________________________________________ > >> > 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 Tue Jan 3 09:28:13 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 03 Jan 2017 14:28:13 +0000 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling wrote: > 2017-01-02 15:27 GMT+01:00 Steve Ebersole : > I realize now that Session#createFilter() is only geared towards > collections. So are you suggesting to only remove that method, but keep > @Filter/@FilterDef? > Correct. @Filter and @FilterDef are in NO WAY related to Session#createFilter From steve at hibernate.org Tue Jan 3 09:37:37 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 03 Jan 2017 14:37:37 +0000 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: Inline... On Tue, Jan 3, 2017 at 4:58 AM Sanne Grinovero wrote: > It sounds great but I'm not sure it's possible? > No idea what this means. Its more than possible. In fact its already largely done. What do you mean? For example how would this handle projections? Exactly the same way you'd handle them for list(), uniqueResult(), etc. E.g. using list(): List results = session.createQuery( "select p.name.first, p.name.last from Person p" ).list(); vs. ScrollableResults results = session.createQuery( "select p.name.first, p.name.last from Person p" ).scroll(); or using Tuples if you prefer: List results = session.createQuery( "select p.name.first, p.name.last from Person p", Tuple.class ).list(); vs. ScrollableResults results = session.createQuery( "select p.name.first, p.name.last from Person p", Tuple.class ).scroll(); > I guess it's a similar > doubt as the one Gunnar shared, but while he suggests a semi-typesafe > solution, I'm not sure how cool it is to give the feeling that types > are being checked when they might actually blow at runtime, if the > query string doesn't match expectations. > Could an Annotation Processor verify the declared return types really > match the HQL select? > I really have no idea what this is all about... From steve at hibernate.org Tue Jan 3 09:45:54 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 03 Jan 2017 14:45:54 +0000 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: Inline... On Tue, Jan 3, 2017 at 5:39 AM Gunnar Morling wrote: > 2017-01-03 11:57 GMT+01:00 Sanne Grinovero : > > Btw. we'd one Tuple type per number of returns, i.e. Tuple2, Tuple3 etc., > each with the right number of type arguments. As said I'm not fully > convinced myself, but some may find it nicer to use than casting the > elements of an array. > That is not how Tuple works in list()/uniqueResult() even. Look, ultimately all I am proposing here is to make Query#scroll work the same as, e.g., Query#list in terms of its return signature. For Query#list you do not get back multiple Tuple objects (per "row"). Why would you here? Perhaps y'all are getting hung up on the name Tuple. Tuple represents the entire row, each "column" in that row. E.g. List results = session.createQuery( "select e.prop1 as p1, e.prop2 as p2 from Entity e", Tuple.class ).list(); for ( Tuple tuple : results ) { // access "prop1": tuple.get(0) tuple.get("p1") ... // access "prop2": tuple.get(1) tuple.get("p2") ... } Tuple is really just a "nicer" (ymmv) way to deal with Object[]... From gunnar at hibernate.org Tue Jan 3 09:54:57 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 3 Jan 2017 15:54:57 +0100 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: 2017-01-03 15:28 GMT+01:00 Steve Ebersole : > On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling > wrote: > >> 2017-01-02 15:27 GMT+01:00 Steve Ebersole : >> I realize now that Session#createFilter() is only geared towards >> collections. So are you suggesting to only remove that method, but keep >> @Filter/@FilterDef? >> > > > Correct. @Filter and @FilterDef are in NO WAY related to > Session#createFilter > Ok. then +1 from my side for removing createFilter() . From andrea at hibernate.org Tue Jan 3 10:02:12 2017 From: andrea at hibernate.org (andrea boriero) Date: Tue, 3 Jan 2017 16:02:12 +0100 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: +1 for removing createFilter() On 3 January 2017 at 15:54, Gunnar Morling wrote: > 2017-01-03 15:28 GMT+01:00 Steve Ebersole : > > > On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling > > wrote: > > > >> 2017-01-02 15:27 GMT+01:00 Steve Ebersole : > >> I realize now that Session#createFilter() is only geared towards > >> collections. So are you suggesting to only remove that method, but keep > >> @Filter/@FilterDef? > >> > > > > > > Correct. @Filter and @FilterDef are in NO WAY related to > > Session#createFilter > > > > Ok. then +1 from my side for removing createFilter() . > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Tue Jan 3 10:03:50 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 3 Jan 2017 15:03:50 +0000 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: <5257ec41-490f-1896-7a77-951e89ca0cc7@gmail.com> <1126a39a-3a7d-c109-f60e-f1b2f45a04c5@gmail.com> Message-ID: On 3 January 2017 at 14:26, Steve Ebersole wrote: > The plan with Stream support here is exactly that... translate the map, > filter etc calls into a SQL query. Ah, that sounds awesome! > > > On Tue, Jan 3, 2017 at 4:41 AM Sanne Grinovero wrote: >> >> I wonder if "use streams" is a reasonable replacement for all power >> users who might have needed this? We know by experience there's loads >> of such people not reading this list, so maybe we'd need a deprecation >> cycle. >> I don't mean to dive deeply in implementation details and plans, but I >> suspect that the createFilter approach was able to limit the amount of >> data we pump out of the database into the Java heap, while a solution >> based on Java8 streams would post-filter the data, unless you plan to >> have Hibernate able to convert all filter predicates into SQL? (which >> sounds awesome but I wasn't expecting that soon..) >> >> Just wondering if that might be unacceptable to people mapping very >> large collections. >> >> Thanks, >> Sanne >> >> >> On 2 January 2017 at 15:41, Steve Ebersole wrote: >> > Christian and I chatted on HipChat. It seems his confusion stems >> > partially >> > from misunderstanding #createFilter, but also the fact that I did not go >> > into detail regarding the plans for this streaming support. I thought >> > it >> > would be a good idea to discuss that at a high level here. The main >> > thing >> > to bear in mind is that intention is such that there stream calls would >> > be >> > translated into SQL rather than resolved in memory (aka get a huge >> > ResultSet and filter etc based on the stream calls). >> > >> > This email was just meant to discuss the removal of the #createFilter >> > method so I did not go into detail. Also too, the design of that is >> > still >> > a discussion point. Initially I am thinking it would leverage the JPA >> > metamodel, e.g. the static metamodel (the generated Order_ stuff). >> > >> > I should also point out that I completely plan to remove #createFilter >> > in >> > 6.0 and not introduce this streaming stuff until 6.x. 6.0 is already >> > getting beyond its initial scope and I's much rather get 6.0 released >> > earlier and "oftener" :) >> > >> > On Mon, Jan 2, 2017 at 9:11 AM Steve Ebersole >> > wrote: >> > >> >> Well stop and think about it... What do you expect session.filter( new >> >> ArrayList(), "") to do? >> >> >> >> Yes, it has to be a PersistentCollection. Hibernate handles >> >> "persistent >> >> arrays" as well >> >> (see org.hibernate.collection.internal.PersistentArrayHolder), although >> >> it >> >> is a discouraged feature. >> >> >> >> It is used to apply: >> >> >> >> 1. an implicit from-clause element for the collection owner (named >> >> "this") >> >> 2. a restriction on the PersistentCollection's owner. >> >> >> >> So a filter like I mentioned before (`session.createFilter( >> >> customer.getOrders(), "orderDate < currentDate() - {3 months}" )`) is >> >> really the same as (it is literally converted to this internally): >> >> >> >> `select elements( this.orders ) from Customer this where this.id = >> >> and orderDate < currentDate() - {3 months}` >> >> >> >> >> >> On Mon, Jan 2, 2017 at 8:45 AM Christian Beikov < >> >> christian.beikov at gmail.com> wrote: >> >> >> >> As far as I understand from the documentation( >> >> >> >> https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-filtering), >> >> it can be used to filter collections and arrays. I don't know if it >> >> only >> >> works for persistent collections but since arrays are also mentioned, I >> >> guess not. >> >> I'd expect the collection or array to be filtered and projected >> >> in-memory >> >> if possible, thus not executing a query unless needed for a lazy >> >> collection >> >> or additional from clause. >> >> >> >> If that understanding is wrong, please help me understand what the >> >> purpose >> >> is then. >> >> >> >> >> >> Am 02.01.2017 um 12:37 schrieb Steve Ebersole: >> >> >> >> I think you are not understanding createFilter: >> >> >> >> >> >> >> >> http://docs.jboss.org/hibernate/orm/current/javadocs/org/hibernate/Session.html#createFilter >> >> >> >> Again, to call filter you'd have to have access to the Collection you >> >> want >> >> to filter. >> >> >> >> On Mon, Jan 2, 2017 at 2:40 AM Christian Beikov < >> >> christian.beikov at gmail.com> wrote: >> >> >> >> Let's say we have this entity with an attribute that is not directly >> >> exposed. >> >> >> >> class EntityA { String field; } >> >> >> >> and then you pass a collection of EntityA instances to createFilter >> >> like >> >> >> >> Collection collection = ... >> >> collection = session.createFilter(collection, "field = >> >> 'abc%'").getResultList(); >> >> >> >> See my point? Since Hibernate can access the field directly, this >> >> works, >> >> but with streams you'd need to expose the field via a getter so you can >> >> filter for it. >> >> >> >> >> >> Am 02.01.2017 um 09:25 schrieb Steve Ebersole: >> >> >> >> Could you explain the situation where you would map a collection but >> >> not >> >> expose it? And btw even create createFilter would not work there >> >> because >> >> you have to pass createFilter the collection >> >> >> >> On Mon, Jan 2, 2017, 2:15 AM Christian Beikov >> >> >> >> wrote: >> >> >> >> Well it does when you consider that there might be no getter for a >> >> field. >> >> With createFilter you could still filter the result list without >> >> exposing >> >> direct access to the field via a getter. >> >> >> >> Am 02.01.2017 um 08:52 schrieb Steve Ebersole: >> >> >> >> Field-access would have zero bearing on this >> >> >> >> On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov < >> >> christian.beikov at gmail.com> wrote: >> >> >> >> Sounds good to me, but maybe we could do a poll to see if people are >> >> using this? I don't know if the filter also works for field based >> >> access >> >> strategy, but that could be a reason for keeping it around. >> >> >> >> Regards, >> >> >> >> Christian >> >> >> >> >> >> Am 31.12.2016 um 21:00 schrieb Steve Ebersole: >> >> > As I have not been hearing hardly any feedback on these 6.0 design >> >> > questions I have been trying to start, I'll be doing something >> >> > different >> >> in >> >> > this and any additional emails.. I'll state what I propose to do and >> >> > if >> >> > anyone has issue with it they can make a counter proposal. Otherwise >> >> > I >> >> > plan on following through with my proposal. >> >> > >> >> > I plan on removing Session#createFilter. There are numerous reasons >> >> > why >> >> > which I can discuss if anyone is interested in exploring this. >> >> > >> >> > Ultimately I think it makes sense to handle this via Java 8 >> >> > streams[1] >> >> > although I am not sure that needs to happen in 6.0 >> >> > >> >> > [1] https://hibernate.atlassian.net/browse/HHH-10962 >> >> > _______________________________________________ >> >> > hibernate-dev mailing list >> >> > hibernate-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> >> >> >> >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Tue Jan 3 10:19:21 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 3 Jan 2017 16:19:21 +0100 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of our biweekly IRC meeting: 16:17 < jbott> Meeting ended Tue Jan 3 15:16:17 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:17 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-01-03-14.02.html 16:17 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-01-03-14.02.txt 16:17 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-01-03-14.02.log.html Cheers, -- Guillaume From yoann at hibernate.org Tue Jan 3 12:23:46 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 3 Jan 2017 18:23:46 +0100 Subject: [hibernate-dev] CI Jenkins upgraded to version 2.38 In-Reply-To: References: Message-ID: Thanks! Looking forward to using pipelines :) It seems PR jobs for Hibernate Search do not trigger anymore, though: * https://github.com/hibernate/hibernate-search/pull/1273 was submitted yesterday * there is no build on http://ci.hibernate.org/view/Pull%20Requests/job/ hibernate-search-PR/ since december 23 * and I tried to restart the build explicitly from the PR, with no luck It's a bit odd, because the OGM PR job seems to work fine... From what I can see there hasn't been any particular change on the OGM job. I can't look at the trigger options on GitHub (I lack the access rights), but maybe the difference between OGM and Search lies there? Anyway... I'm going for today, maybe I'll see something obvious tomorrow morning! Cheers, Yoann Rodi?re Hibernate NoORM Team On 3 January 2017 at 18:22, Yoann Rodiere wrote: > Thanks! Looking forward to using pipelines :) > > It seems PR jobs for Hibernate Search do not trigger anymore, though: > > * https://github.com/hibernate/hibernate-search/pull/1273 was submitted > yesterday > * there is no build on http://ci.hibernate.org/view/Pull%20Requests/job/ > hibernate-search-PR/ since december 23 > * and I tried to restart the build explicitly from the PR, with no luck > > It's a bit odd, because the OGM PR job seems to work fine... From what I > can see there hasn't been any particular change on the OGM job. > > I can't look at the trigger options on GitHub (I lack the access rights), > but maybe the difference between OGM and Search lies there? > > Anyway... I'm going for today, maybe I'll see something obvious tomorrow > morning! > > Cheers, > > Yoann Rodi?re > Software Engineer > Red Hat / Hibernate NoORM Team > > On 3 January 2017 at 13:31, Davide D'Alto wrote: > >> Thanks for the feedback, >> >> header and footer should be fine now. >> >> Thanks, >> Davide >> >> On Thu, Dec 29, 2016 at 11:37 PM, Sanne Grinovero >> wrote: >> > Thanks Davide! >> > The builds seems to work just fine, the only minor defect I've noticed >> > is with the stylesheet doing some strange things when scrolling down: >> > the breadcrumbs will "float" down as well. Definitely not urgent, >> > great to have all updates! >> > >> > Thanks, >> > Sanne >> > >> > >> > On 28 December 2016 at 01:04, Davide D'Alto >> wrote: >> >> Hi, >> >> I hope you all had great holidays. >> >> >> >> I've upgraded our Jenkin on CI to version 2.38. >> >> >> >> As far as i can tell everything seems all right, but if you experience >> >> some unusual problems, >> >> please, let me know. >> >> >> >> >> >> 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 crancran at gmail.com Tue Jan 3 15:39:18 2017 From: crancran at gmail.com (Chris Cranford) Date: Tue, 3 Jan 2017 15:39:18 -0500 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: References: Message-ID: <55b8bf2e-246e-fe8a-6431-b5b19ef85c70@gmail.com> Steve - I'm inclined to agree that changing signatures makes the most sense at this point. Chris On 12/27/2016 04:02 PM, Steve Ebersole wrote: > FWIW my inclination is to just change the existing signatures. 6.0 is a > major release with major changes already wrt querying. > > > On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole wrote: > >> For 6.0 I'd like to also make ScrollableResults parameterized wrt the "row >> type". E.g. >> >> ScrollableResults sr = session.createQuery( ..., Person.class >> ).scroll(); >> >> However that changes the signature of its methods returning a "row" >> (currently always defined as Object[]). >> >> How would everyone prefer we handle this? Do I just change the signatures >> of the existing methods? Or add new methods? >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From chris at hibernate.org Tue Jan 3 15:54:20 2017 From: chris at hibernate.org (Chris Cranford) Date: Tue, 3 Jan 2017 15:54:20 -0500 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: +1 On 01/03/2017 10:02 AM, andrea boriero wrote: > +1 for removing createFilter() > > On 3 January 2017 at 15:54, Gunnar Morling wrote: > >> 2017-01-03 15:28 GMT+01:00 Steve Ebersole : >> >>> On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling >>> wrote: >>> >>>> 2017-01-02 15:27 GMT+01:00 Steve Ebersole : >>>> I realize now that Session#createFilter() is only geared towards >>>> collections. So are you suggesting to only remove that method, but keep >>>> @Filter/@FilterDef? >>>> >>> >>> Correct. @Filter and @FilterDef are in NO WAY related to >>> Session#createFilter >>> >> Ok. then +1 from my side for removing createFilter() . >> _______________________________________________ >> 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 Jan 3 17:39:40 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 3 Jan 2017 23:39:40 +0100 Subject: [hibernate-dev] CI Jenkins upgraded to version 2.38 In-Reply-To: References: Message-ID: On Tue, Jan 3, 2017 at 6:23 PM, Yoann Rodiere wrote: > It's a bit odd, because the OGM PR job seems to work fine... From what I > can see there hasn't been any particular change on the OGM job. > As for OGM, the build is triggered but does not report back to GitHub. I pinged Davide about it a few hours ago, he's working on it. -- Guillaume From yoann at hibernate.org Wed Jan 4 11:00:37 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 4 Jan 2017 17:00:37 +0100 Subject: [hibernate-dev] [SEARCH] Query-only analyzers with Elasticsearch - new annotation? Message-ID: Hello team, I'm currently working on HSEARCH-2534, "Query-only analyzer definitions are never added to the index settings with Elasticsearch". This issue is about using analyzers only when querying with Elasticsearch. It is already possible with Lucene, but not in Elasticsearch, because we assume that any analyzer definition that is not referenced by a @Analyzer annotation is a Lucene analyzer [1]. To be precise, the exact place where query-only analyzers are used is in EntityContext.overridesForField [2], and the overrides are leveraged even with Elasticsearch, for instance in ConnectedMultiFieldsTermQueryBuilder [3]. I can see two solutions to the issue: 1. Make all analyzer definitions available for all indexing services. 2. Allow users to define, for each entity, which analyzer definitions will be necessary when querying, even though the definitions are not used when indexing. Solution 1 seems quite hard to implement correctly. First we'd have to have a different namespace for each indexing service, but I've already implemented that much. Second, some analyzer definitions are only valid for one indexing service, and not for the other. For instance, analyzer definitions using ElasticsearchTokenFilterFactory are specific to Elasticsearch. And Analyzer definitions using the WhitespaceTokenizerFactory with the "rule" parameter are only valid with embedded Lucene. And so on. To sum up, I'm not sure we can do something smart. Solution 2 is easier to implement, but requires to add a bit of API: the way for users to declare that a given analyzer definition is to be available when querying a given entity. I would add type-level @QueryAnalyzer(definition = "foo") and @QueryAnalyzers annotation. I know nobody wants to add new annotations in a minor, but right now that seems to be the only workable solution. What do you think? [1] https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/engine/impl/ConfigContext.java#L277 [2] https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/query/dsl/EntityContext.java#L14 [3] https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/query/dsl/impl/ConnectedMultiFieldsTermQueryBuilder.java#L222 Yoann Rodi?re Hibernate NoORM Team From sanne at hibernate.org Thu Jan 5 07:04:29 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 5 Jan 2017 12:04:29 +0000 Subject: [hibernate-dev] [SEARCH] Query-only analyzers with Elasticsearch - new annotation? In-Reply-To: References: Message-ID: Hello, I'm wondering how you'd all feel about the third solution: 3. don't do it. This depends of course how far it is blocking in practice. Maybe I'm missing something, but couldn't a user simply use an additional @AnalyzerDef, so that the analyzer definition is associated to a name, and use that? I guess that I'm missing why you'd want to force people to express that a specific Analyzer is meant to be used only at query time differently than one which is used at indexing time. If there is need to clearly make such discrimination then this should be made very clear to our users too, so I'd prefer if we could avoid introducing new concepts for people to learn.. unless there's strong need of course. Is this issue relating to a specific user request? Thanks, Sanne On 4 January 2017 at 16:00, Yoann Rodiere wrote: > Hello team, > > I'm currently working on HSEARCH-2534, "Query-only analyzer definitions are > never added to the index settings with Elasticsearch". > This issue is about using analyzers only when querying with Elasticsearch. > It is already possible with Lucene, but not in Elasticsearch, because we > assume that any analyzer definition that is not referenced by a @Analyzer > annotation is a Lucene analyzer [1]. > > To be precise, the exact place where query-only analyzers are used is in > EntityContext.overridesForField [2], and the overrides are leveraged even > with Elasticsearch, for instance in ConnectedMultiFieldsTermQueryBuilder > [3]. > > I can see two solutions to the issue: > > 1. Make all analyzer definitions available for all indexing services. > 2. Allow users to define, for each entity, which analyzer definitions > will be necessary when querying, even though the definitions are not used > when indexing. > > Solution 1 seems quite hard to implement correctly. > First we'd have to have a different namespace for each indexing service, > but I've already implemented that much. > Second, some analyzer definitions are only valid for one indexing service, > and not for the other. > For instance, analyzer definitions using ElasticsearchTokenFilterFactory > are specific to Elasticsearch. And Analyzer definitions using > the WhitespaceTokenizerFactory with the "rule" parameter are only valid > with embedded Lucene. And so on. To sum up, I'm not sure we can do > something smart. > > Solution 2 is easier to implement, but requires to add a bit of API: the > way for users to declare that a given analyzer definition is to be > available when querying a given entity. I would add type-level > @QueryAnalyzer(definition = "foo") and @QueryAnalyzers annotation. > > I know nobody wants to add new annotations in a minor, but right now that > seems to be the only workable solution. > > What do you think? > > [1] > https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/engine/impl/ConfigContext.java#L277 > [2] > https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/query/dsl/EntityContext.java#L14 > [3] > https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/query/dsl/impl/ConnectedMultiFieldsTermQueryBuilder.java#L222 > > > Yoann Rodi?re > Hibernate NoORM Team > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Thu Jan 5 08:06:48 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 5 Jan 2017 14:06:48 +0100 Subject: [hibernate-dev] [SEARCH] Query-only analyzers with Elasticsearch - new annotation? In-Reply-To: References: Message-ID: > I'm wondering how you'd all feel about the third solution: > 3. don't do it. > This depends of course how far it is blocking in practice. "Don't do it until 6.0" would be acceptable, I guess, since it's still just a technical preview. Though we would introduce a limitation that would only be our fault (since Elasticsearch supports query-time analyzers) and that would not exist with the Lucene integration. "Don't do it ever" seems really bad. As we've already discussed at length (multiple times), not being able to define analyzers from Hibernate Search would be a real pain for users, especially in Elasticsearch 5. That's true for indexing analyzers, and that's also true for querying-only analyzers. I wouldn't say that query-only analyzers are widespread, but they're at least useful, and I'm sure there are problems that can *only* be solved by using a different analyzer when querying than when indexing... > I guess that I'm missing why you'd want to force people to express > that a specific Analyzer is meant to be used only at query time > differently than one which is used at indexing time. > If there is need to clearly make such discrimination then this should > be made very clear to our users too, so I'd prefer if we could avoid > introducing new concepts for people to learn.. unless there's strong > need of course. Analyzer definitions are interpreted as either Lucene analyzers (to be instantiated) or Elasticsearch analyzers (to be pushed to the ES index settings) based on where they are referenced (using @Analyzer). When I say an analyzer definition is query-only, it means there is an @AnalyzerDefinition but there isn't any @Analyzer referencing it. So Hibernate Search wouldn't know how to interpret it (ES or Lucene). Currently, the default for those definitions is to interpret them as Lucene analyzers, which leads to HSEARCH-2534: we can't have Elasticsearch query-only analyzers. Maybe with this piece of information, my original message makes more sense? I.e.: 1. Solution 1, interpret those definitions as both Lucene and Elasticsearch analyzer (there are problems with that, see my first message) 2. Solution 2, make users "reference" those definitions using a new @QueryAnalyzer annotation. > Maybe I'm > missing something, but couldn't a user simply use an additional > @AnalyzerDef, so that the analyzer definition is associated to a name, > and use that? As mentioned above, an @AnalyzerDef that is not referenced is considered as a Lucene analyzer, so it's not pushed to Elasticsearch and it can't be used when querying Elasticsearch. The only workaround I see would be to add a dummy, always-empty field like that: @Transient @Field(name = "__dummy", analyzer = @Analyzer(definition = "myQueryOnlyAnalyzer)) public String getMyQueryOnlyAnalyzerDummyField() { return null; } Which means there will be a useless field in the schema just to make Hibernate Search happy. > Is this issue relating to a specific user request? No, it's just a feature that is available for Lucene but not for Elasticsearch. Yoann Rodi?re Hibernate NoORM Team On 5 January 2017 at 13:04, Sanne Grinovero wrote: > Hello, > > I'm wondering how you'd all feel about the third solution: > > 3. don't do it. > > This depends of course how far it is blocking in practice. Maybe I'm > missing something, but couldn't a user simply use an additional > @AnalyzerDef, so that the analyzer definition is associated to a name, > and use that? > > I guess that I'm missing why you'd want to force people to express > that a specific Analyzer is meant to be used only at query time > differently than one which is used at indexing time. > If there is need to clearly make such discrimination then this should > be made very clear to our users too, so I'd prefer if we could avoid > introducing new concepts for people to learn.. unless there's strong > need of course. > > Is this issue relating to a specific user request? > > Thanks, > Sanne > > > > On 4 January 2017 at 16:00, Yoann Rodiere wrote: > > Hello team, > > > > I'm currently working on HSEARCH-2534, "Query-only analyzer definitions > are > > never added to the index settings with Elasticsearch". > > This issue is about using analyzers only when querying with > Elasticsearch. > > It is already possible with Lucene, but not in Elasticsearch, because we > > assume that any analyzer definition that is not referenced by a @Analyzer > > annotation is a Lucene analyzer [1]. > > > > To be precise, the exact place where query-only analyzers are used is in > > EntityContext.overridesForField [2], and the overrides are leveraged > even > > with Elasticsearch, for instance in ConnectedMultiFieldsTermQueryBuilder > > [3]. > > > > I can see two solutions to the issue: > > > > 1. Make all analyzer definitions available for all indexing services. > > 2. Allow users to define, for each entity, which analyzer definitions > > will be necessary when querying, even though the definitions are not > used > > when indexing. > > > > Solution 1 seems quite hard to implement correctly. > > First we'd have to have a different namespace for each indexing service, > > but I've already implemented that much. > > Second, some analyzer definitions are only valid for one indexing > service, > > and not for the other. > > For instance, analyzer definitions using ElasticsearchTokenFilterFactory > > are specific to Elasticsearch. And Analyzer definitions using > > the WhitespaceTokenizerFactory with the "rule" parameter are only valid > > with embedded Lucene. And so on. To sum up, I'm not sure we can do > > something smart. > > > > Solution 2 is easier to implement, but requires to add a bit of API: the > > way for users to declare that a given analyzer definition is to be > > available when querying a given entity. I would add type-level > > @QueryAnalyzer(definition = "foo") and @QueryAnalyzers annotation. > > > > I know nobody wants to add new annotations in a minor, but right now that > > seems to be the only workable solution. > > > > What do you think? > > > > [1] > > https://github.com/hibernate/hibernate-search/blob/ > 1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/ > java/org/hibernate/search/engine/impl/ConfigContext.java#L277 > > [2] > > https://github.com/hibernate/hibernate-search/blob/ > 1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/ > java/org/hibernate/search/query/dsl/EntityContext.java#L14 > > [3] > > https://github.com/hibernate/hibernate-search/blob/ > 1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/ > java/org/hibernate/search/query/dsl/impl/ConnectedMultiFieldsTermQueryB > uilder.java#L222 > > > > > > Yoann Rodi?re > > Hibernate NoORM Team > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Thu Jan 5 09:06:43 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 5 Jan 2017 14:06:43 +0000 Subject: [hibernate-dev] [SEARCH] Query-only analyzers with Elasticsearch - new annotation? In-Reply-To: References: Message-ID: On 5 January 2017 at 13:06, Yoann Rodiere wrote: >> I'm wondering how you'd all feel about the third solution: >> 3. don't do it. >> This depends of course how far it is blocking in practice. > > "Don't do it until 6.0" would be acceptable, I guess, since it's still just > a technical preview. Though we would introduce a limitation that would only > be our fault (since Elasticsearch supports query-time analyzers) and that > would not exist with the Lucene integration. > > "Don't do it ever" seems really bad. As we've already discussed at length > (multiple times), not being able to define analyzers from Hibernate Search > would be a real pain for users, especially in Elasticsearch 5. That's true > for indexing analyzers, and that's also true for querying-only analyzers. > I wouldn't say that query-only analyzers are widespread, but they're at > least useful, and I'm sure there are problems that can only be solved by > using a different analyzer when querying than when indexing... I don't disagree, I'm merely aiming to have in future Analyzer(s) defined in a non-Lucene specific way, possibly allowing controlled exceptions. When changing the definitions API we'll be able to reconsider if we want Analyzer definitions to be scoped per index like Elasticsearch does. But since today the Analyzer map is "global" (as in one map per SearchIntegrator), I don't see why we can't treat them consistently on both technologies and consider them global on one ES as well, i.e. we'd copy all definitions to each ES index definition. Sure that wouldn't allow to map on Hibernate Search an existing ES cluster which uses conflicting names on different indexes, but reverse engineering of existing ES clusters isn't our focus at this time; people badly needing it can change their names to saner choices (as I'd argue that name reuse for different things wouldn't be a sane configuration, probably it won't be common either). > >> I guess that I'm missing why you'd want to force people to express >> that a specific Analyzer is meant to be used only at query time >> differently than one which is used at indexing time. >> If there is need to clearly make such discrimination then this should >> be made very clear to our users too, so I'd prefer if we could avoid >> introducing new concepts for people to learn.. unless there's strong >> need of course. > > Analyzer definitions are interpreted as either Lucene analyzers (to be > instantiated) or Elasticsearch analyzers (to be pushed to the ES index > settings) based on where they are referenced (using @Analyzer). > When I say an analyzer definition is query-only, it means there is an > @AnalyzerDefinition but there isn't any @Analyzer referencing it. So > Hibernate Search wouldn't know how to interpret it (ES or Lucene). > Currently, the default for those definitions is to interpret them as Lucene > analyzers, which leads to HSEARCH-2534: we can't have Elasticsearch > query-only analyzers. Ok, I understand the status quo, but is there something which prevents us to refine this decision and rather generate ES definitions out of all known Analyzer definitions, rather than just the ones being referred? Let's keep in mind that we're only able "translate" a very limited set of well-known Analyzer definitions so - while it's cool to help migrations were we can - our primary focus is to make sure that people can use any custom Analyzer configuration which they have defined "manually" on ES. In short, I think what matters most now is not how to define such analyzers as there are viable (better?) alternatives, but we need to make sure one can run a query with the right query-time overrides, especially be able to refer to an Analyzer which has been manually defined on ES but is possibly not known to us. (As discussed previously with the exception of More-Like-This Queries which will have to wait). Thanks, Sanne > > Maybe with this piece of information, my original message makes more sense? > I.e.: > > Solution 1, interpret those definitions as both Lucene and Elasticsearch > analyzer (there are problems with that, see my first message) > Solution 2, make users "reference" those definitions using a new > @QueryAnalyzer annotation. > >> Maybe I'm >> missing something, but couldn't a user simply use an additional >> @AnalyzerDef, so that the analyzer definition is associated to a name, >> and use that? > > As mentioned above, an @AnalyzerDef that is not referenced is considered as > a Lucene analyzer, so it's not pushed to Elasticsearch and it can't be used > when querying Elasticsearch. > The only workaround I see would be to add a dummy, always-empty field like > that: > > @Transient > @Field(name = "__dummy", analyzer = @Analyzer(definition = > "myQueryOnlyAnalyzer)) > public String getMyQueryOnlyAnalyzerDummyField() { > return null; > } > > Which means there will be a useless field in the schema just to make > Hibernate Search happy. > >> Is this issue relating to a specific user request? > > No, it's just a feature that is available for Lucene but not for > Elasticsearch. > > > Yoann Rodi?re > Hibernate NoORM Team > > On 5 January 2017 at 13:04, Sanne Grinovero wrote: >> >> Hello, >> >> I'm wondering how you'd all feel about the third solution: >> >> 3. don't do it. >> >> This depends of course how far it is blocking in practice. Maybe I'm >> missing something, but couldn't a user simply use an additional >> @AnalyzerDef, so that the analyzer definition is associated to a name, >> and use that? >> >> I guess that I'm missing why you'd want to force people to express >> that a specific Analyzer is meant to be used only at query time >> differently than one which is used at indexing time. >> If there is need to clearly make such discrimination then this should >> be made very clear to our users too, so I'd prefer if we could avoid >> introducing new concepts for people to learn.. unless there's strong >> need of course. >> >> Is this issue relating to a specific user request? >> >> Thanks, >> Sanne >> >> >> >> On 4 January 2017 at 16:00, Yoann Rodiere wrote: >> > Hello team, >> > >> > I'm currently working on HSEARCH-2534, "Query-only analyzer definitions >> > are >> > never added to the index settings with Elasticsearch". >> > This issue is about using analyzers only when querying with >> > Elasticsearch. >> > It is already possible with Lucene, but not in Elasticsearch, because we >> > assume that any analyzer definition that is not referenced by a >> > @Analyzer >> > annotation is a Lucene analyzer [1]. >> > >> > To be precise, the exact place where query-only analyzers are used is in >> > EntityContext.overridesForField [2], and the overrides are leveraged >> > even >> > with Elasticsearch, for instance in ConnectedMultiFieldsTermQueryBuilder >> > [3]. >> > >> > I can see two solutions to the issue: >> > >> > 1. Make all analyzer definitions available for all indexing services. >> > 2. Allow users to define, for each entity, which analyzer definitions >> > will be necessary when querying, even though the definitions are not >> > used >> > when indexing. >> > >> > Solution 1 seems quite hard to implement correctly. >> > First we'd have to have a different namespace for each indexing service, >> > but I've already implemented that much. >> > Second, some analyzer definitions are only valid for one indexing >> > service, >> > and not for the other. >> > For instance, analyzer definitions using ElasticsearchTokenFilterFactory >> > are specific to Elasticsearch. And Analyzer definitions using >> > the WhitespaceTokenizerFactory with the "rule" parameter are only valid >> > with embedded Lucene. And so on. To sum up, I'm not sure we can do >> > something smart. >> > >> > Solution 2 is easier to implement, but requires to add a bit of API: the >> > way for users to declare that a given analyzer definition is to be >> > available when querying a given entity. I would add type-level >> > @QueryAnalyzer(definition = "foo") and @QueryAnalyzers annotation. >> > >> > I know nobody wants to add new annotations in a minor, but right now >> > that >> > seems to be the only workable solution. >> > >> > What do you think? >> > >> > [1] >> > >> > https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/engine/impl/ConfigContext.java#L277 >> > [2] >> > >> > https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/query/dsl/EntityContext.java#L14 >> > [3] >> > >> > https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/query/dsl/impl/ConnectedMultiFieldsTermQueryBuilder.java#L222 >> > >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From yoann at hibernate.org Thu Jan 5 09:42:00 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 5 Jan 2017 15:42:00 +0100 Subject: [hibernate-dev] [SEARCH] Query-only analyzers with Elasticsearch - new annotation? In-Reply-To: References: Message-ID: > I don't disagree, I'm merely aiming to have in future Analyzer(s) > defined in a non-Lucene specific way, possibly allowing controlled > exceptions. > When changing the definitions API we'll be able to reconsider if we > want Analyzer definitions to be scoped per index like Elasticsearch > does. Actually, for HSEARCH-2534, it would be enough if analyzer definitions were scoped by indexing service (Lucene/ES). But sure, that would be a good solution. If we wait for 6.0. > Sure that wouldn't allow to map on Hibernate Search an existing ES > cluster which uses conflicting names on different indexes, but reverse > engineering of existing ES clusters isn't our focus at this time; > people badly needing it can change their names to saner choices (as > I'd argue that name reuse for different things wouldn't be a sane > configuration, probably it won't be common either). I agree with you on that. To be honest I didn't even think of such an issue, since currently the analyzer definitions are scoped globally. > is there something which prevents > us to refine this decision and rather generate ES definitions out of > all known Analyzer definitions, rather than just the ones being > referred? Well, yes, that was in my first message; see below: > First we'd have to have a different namespace for each indexing service, > but I've already implemented that much. > Second, some analyzer definitions are only valid for one indexing service, > and not for the other. > For instance, analyzer definitions using ElasticsearchTokenFilterFactory > are specific to Elasticsearch. And Analyzer definitions using the > WhitespaceTokenizerFactory with the "rule" parameter are only valid with > embedded Lucene. And so on. To sum up, I'm not sure we can do > something smart. What prevents us to generate ES definitions out of all known analyzer definitions is that there may be definitions that *cannot* be translated to ES, simply because they are supposed to be used only with Lucene. I guess we could say "let's try to generate ES definitions, and if it fails just ignore it and log a warning", but it seems a bit unsafe... > Let's keep in mind that we're only able "translate" a very limited set > of well-known Analyzer definitions [...] For translations it's true, but any ES analyzer definition can be expressed with Hibernate Search by using Elasticsearch*Factory. In fact, it's the recommended approach. See https://docs.jboss.org/hibernate/search/5.6/reference/en-US/html_single/#_custom_analyzers . > In short, I think what matters most now is not how to define such > analyzers as there are viable (better?) alternatives, but we need to > make sure one can run a query with the right query-time overrides, > especially be able to refer to an Analyzer which has been manually > defined on ES but is possibly not known to us. (As discussed > previously with the exception of More-Like-This Queries which will > have to wait). We already have discussed this many times, but once again: users will not be able to define their analyzers manually on ES starting from ES 5.0 for various reasons. So that's clearly not a long-term solution. It's "viable" for now, but since it's not future-proof it's certainly not better. As for the short term, if I understand correctly, what you're proposing is that users don't add an @AnalyzerDef for query-only analyzers, and that we allow using unknown analyzers in queries? I guess we could do that, but that basically amounts to solution 3 "don't do it". Which is fine as long as we plan to fix it later. Also note we'd still have to explain users that query-only analyzer definitions are not supported with Elasticsearch. Yoann Rodi?re Hibernate NoORM Team On 5 January 2017 at 15:06, Sanne Grinovero wrote: > On 5 January 2017 at 13:06, Yoann Rodiere wrote: > >> I'm wondering how you'd all feel about the third solution: > >> 3. don't do it. > >> This depends of course how far it is blocking in practice. > > > > "Don't do it until 6.0" would be acceptable, I guess, since it's still > just > > a technical preview. Though we would introduce a limitation that would > only > > be our fault (since Elasticsearch supports query-time analyzers) and that > > would not exist with the Lucene integration. > > > > "Don't do it ever" seems really bad. As we've already discussed at length > > (multiple times), not being able to define analyzers from Hibernate > Search > > would be a real pain for users, especially in Elasticsearch 5. That's > true > > for indexing analyzers, and that's also true for querying-only analyzers. > > I wouldn't say that query-only analyzers are widespread, but they're at > > least useful, and I'm sure there are problems that can only be solved by > > using a different analyzer when querying than when indexing... > > I don't disagree, I'm merely aiming to have in future Analyzer(s) > defined in a non-Lucene specific way, possibly allowing controlled > exceptions. > When changing the definitions API we'll be able to reconsider if we > want Analyzer definitions to be scoped per index like Elasticsearch > does. > > But since today the Analyzer map is "global" (as in one map per > SearchIntegrator), I don't see why we can't treat them consistently on > both technologies and consider them global on one ES as well, i.e. > we'd copy all definitions to each ES index definition. > Sure that wouldn't allow to map on Hibernate Search an existing ES > cluster which uses conflicting names on different indexes, but reverse > engineering of existing ES clusters isn't our focus at this time; > people badly needing it can change their names to saner choices (as > I'd argue that name reuse for different things wouldn't be a sane > configuration, probably it won't be common either). > > > > >> I guess that I'm missing why you'd want to force people to express > >> that a specific Analyzer is meant to be used only at query time > >> differently than one which is used at indexing time. > >> If there is need to clearly make such discrimination then this should > >> be made very clear to our users too, so I'd prefer if we could avoid > >> introducing new concepts for people to learn.. unless there's strong > >> need of course. > > > > Analyzer definitions are interpreted as either Lucene analyzers (to be > > instantiated) or Elasticsearch analyzers (to be pushed to the ES index > > settings) based on where they are referenced (using @Analyzer). > > When I say an analyzer definition is query-only, it means there is an > > @AnalyzerDefinition but there isn't any @Analyzer referencing it. So > > Hibernate Search wouldn't know how to interpret it (ES or Lucene). > > Currently, the default for those definitions is to interpret them as > Lucene > > analyzers, which leads to HSEARCH-2534: we can't have Elasticsearch > > query-only analyzers. > > Ok, I understand the status quo, but is there something which prevents > us to refine this decision and rather generate ES definitions out of > all known Analyzer definitions, rather than just the ones being > referred? > > Let's keep in mind that we're only able "translate" a very limited set > of well-known Analyzer definitions so - while it's cool to help > migrations were we can - our primary focus is to make sure that people > can use any custom Analyzer configuration which they have defined > "manually" on ES. > > In short, I think what matters most now is not how to define such > analyzers as there are viable (better?) alternatives, but we need to > make sure one can run a query with the right query-time overrides, > especially be able to refer to an Analyzer which has been manually > defined on ES but is possibly not known to us. (As discussed > previously with the exception of More-Like-This Queries which will > have to wait). > > Thanks, > Sanne > > > > > Maybe with this piece of information, my original message makes more > sense? > > I.e.: > > > > Solution 1, interpret those definitions as both Lucene and Elasticsearch > > analyzer (there are problems with that, see my first message) > > Solution 2, make users "reference" those definitions using a new > > @QueryAnalyzer annotation. > > > >> Maybe I'm > >> missing something, but couldn't a user simply use an additional > >> @AnalyzerDef, so that the analyzer definition is associated to a name, > >> and use that? > > > > As mentioned above, an @AnalyzerDef that is not referenced is considered > as > > a Lucene analyzer, so it's not pushed to Elasticsearch and it can't be > used > > when querying Elasticsearch. > > The only workaround I see would be to add a dummy, always-empty field > like > > that: > > > > @Transient > > @Field(name = "__dummy", analyzer = @Analyzer(definition = > > "myQueryOnlyAnalyzer)) > > public String getMyQueryOnlyAnalyzerDummyField() { > > return null; > > } > > > > Which means there will be a useless field in the schema just to make > > Hibernate Search happy. > > > >> Is this issue relating to a specific user request? > > > > No, it's just a feature that is available for Lucene but not for > > Elasticsearch. > > > > > > Yoann Rodi?re > > Hibernate NoORM Team > > > > On 5 January 2017 at 13:04, Sanne Grinovero wrote: > >> > >> Hello, > >> > >> I'm wondering how you'd all feel about the third solution: > >> > >> 3. don't do it. > >> > >> This depends of course how far it is blocking in practice. Maybe I'm > >> missing something, but couldn't a user simply use an additional > >> @AnalyzerDef, so that the analyzer definition is associated to a name, > >> and use that? > >> > >> I guess that I'm missing why you'd want to force people to express > >> that a specific Analyzer is meant to be used only at query time > >> differently than one which is used at indexing time. > >> If there is need to clearly make such discrimination then this should > >> be made very clear to our users too, so I'd prefer if we could avoid > >> introducing new concepts for people to learn.. unless there's strong > >> need of course. > >> > >> Is this issue relating to a specific user request? > >> > >> Thanks, > >> Sanne > >> > >> > >> > >> On 4 January 2017 at 16:00, Yoann Rodiere wrote: > >> > Hello team, > >> > > >> > I'm currently working on HSEARCH-2534, "Query-only analyzer > definitions > >> > are > >> > never added to the index settings with Elasticsearch". > >> > This issue is about using analyzers only when querying with > >> > Elasticsearch. > >> > It is already possible with Lucene, but not in Elasticsearch, because > we > >> > assume that any analyzer definition that is not referenced by a > >> > @Analyzer > >> > annotation is a Lucene analyzer [1]. > >> > > >> > To be precise, the exact place where query-only analyzers are used is > in > >> > EntityContext.overridesForField [2], and the overrides are leveraged > >> > even > >> > with Elasticsearch, for instance in ConnectedMultiFieldsTermQueryB > uilder > >> > [3]. > >> > > >> > I can see two solutions to the issue: > >> > > >> > 1. Make all analyzer definitions available for all indexing > services. > >> > 2. Allow users to define, for each entity, which analyzer > definitions > >> > will be necessary when querying, even though the definitions are > not > >> > used > >> > when indexing. > >> > > >> > Solution 1 seems quite hard to implement correctly. > >> > First we'd have to have a different namespace for each indexing > service, > >> > but I've already implemented that much. > >> > Second, some analyzer definitions are only valid for one indexing > >> > service, > >> > and not for the other. > >> > For instance, analyzer definitions using > ElasticsearchTokenFilterFactory > >> > are specific to Elasticsearch. And Analyzer definitions using > >> > the WhitespaceTokenizerFactory with the "rule" parameter are only > valid > >> > with embedded Lucene. And so on. To sum up, I'm not sure we can do > >> > something smart. > >> > > >> > Solution 2 is easier to implement, but requires to add a bit of API: > the > >> > way for users to declare that a given analyzer definition is to be > >> > available when querying a given entity. I would add type-level > >> > @QueryAnalyzer(definition = "foo") and @QueryAnalyzers annotation. > >> > > >> > I know nobody wants to add new annotations in a minor, but right now > >> > that > >> > seems to be the only workable solution. > >> > > >> > What do you think? > >> > > >> > [1] > >> > > >> > https://github.com/hibernate/hibernate-search/blob/ > 1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/ > java/org/hibernate/search/engine/impl/ConfigContext.java#L277 > >> > [2] > >> > > >> > https://github.com/hibernate/hibernate-search/blob/ > 1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/ > java/org/hibernate/search/query/dsl/EntityContext.java#L14 > >> > [3] > >> > > >> > https://github.com/hibernate/hibernate-search/blob/ > 1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/ > java/org/hibernate/search/query/dsl/impl/ConnectedMultiFieldsTermQueryB > uilder.java#L222 > >> > > >> > > >> > Yoann Rodi?re > >> > Hibernate NoORM Team > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > From daltodavide at gmail.com Thu Jan 5 10:56:55 2017 From: daltodavide at gmail.com (Davide D'Alto) Date: Thu, 5 Jan 2017 15:56:55 +0000 Subject: [hibernate-dev] Hibernate OGM 5.1 Beta3 and 5.0.4 released Message-ID: Hello everybody, holidays are over and we decided to start back with a small release. Hibernate OGM 5.1 Beta3 and a new 5.0 maintainance releases are now available. In these releases we fixed some issues around sequence generation and queries on entities using the single table per class inheritance strategy. An update is highly recommended. You can find all the details in the blog post [1]. Thanks, Davide [1] http://in.relation.to/2017/01/05/hibernate-ogm-5-beta3-and-5/ From davide at hibernate.org Thu Jan 5 11:04:05 2017 From: davide at hibernate.org (Davide D'Alto) Date: Thu, 5 Jan 2017 16:04:05 +0000 Subject: [hibernate-dev] CI Jenkins upgraded to version 2.38 In-Reply-To: References: Message-ID: For future reference, these problems should be fixed now. If a job build does not trigger from a PR and everything seems right, check the advance configuration option under: Build Triggers > GitHub Pull Request Builder > Trigger phrase If it's blank try set it to something like: .*test\W+this\W+please.* This might change on future Jenkins updates. Cheers On Tue, Jan 3, 2017 at 10:39 PM, Guillaume Smet wrote: > On Tue, Jan 3, 2017 at 6:23 PM, Yoann Rodiere wrote: >> >> It's a bit odd, because the OGM PR job seems to work fine... From what I >> can see there hasn't been any particular change on the OGM job. > > > As for OGM, the build is triggered but does not report back to GitHub. I > pinged Davide about it a few hours ago, he's working on it. > > -- > Guillaume From davide at hibernate.org Thu Jan 5 11:05:45 2017 From: davide at hibernate.org (Davide D'Alto) Date: Thu, 5 Jan 2017 16:05:45 +0000 Subject: [hibernate-dev] CI Jenkins upgraded to version 2.38 In-Reply-To: References: Message-ID: > If a job build does not trigger from a PR and everything seems right, > check the advance configuration option under: I meant, if a build does not start when you leave the comment: "Jenkins, rebuild this please" On Thu, Jan 5, 2017 at 4:04 PM, Davide D'Alto wrote: > For future reference, > these problems should be fixed now. > > If a job build does not trigger from a PR and everything seems right, > check the advance configuration option under: > > Build Triggers > GitHub Pull Request Builder > Trigger phrase > > If it's blank try set it to something like: .*test\W+this\W+please.* > > This might change on future Jenkins updates. > > Cheers > > On Tue, Jan 3, 2017 at 10:39 PM, Guillaume Smet > wrote: >> On Tue, Jan 3, 2017 at 6:23 PM, Yoann Rodiere wrote: >>> >>> It's a bit odd, because the OGM PR job seems to work fine... From what I >>> can see there hasn't been any particular change on the OGM job. >> >> >> As for OGM, the build is triggered but does not report back to GitHub. I >> pinged Davide about it a few hours ago, he's working on it. >> >> -- >> Guillaume From yoann at hibernate.org Thu Jan 5 11:20:56 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 5 Jan 2017 17:20:56 +0100 Subject: [hibernate-dev] [SEARCH] Remove support for (or deprecate) date/calendar resolution? Message-ID: Hi, That's a catchy subject, now I'm sure I got Guillaume's (angry) attention :) Sanne wanted us to think about feature removal... Here's a proposal. The feature I'd like to deprecate/remove: automatic truncation of date/calendars to a given resolution. It's used like that: @Field @CalendarBridge(resolution = Resolution.DAY) private Calendar dateSent; I've been working on date-related tests for the past few hours (well, months, too), and I'm becoming more and more convinced that this resolution thing is the wrong solution to an admittedly common issue. The other (in my opinion right) solution being to use range queries. When we truncate a date to a given resolution, we must use a particular timezone, obviously. It makes no sense to truncate to the day when we don't choose a particular timezone. Then the truncated date will match only if we search for dates whose truncation is identical in this timezone. And guess what? In the current implementation, we use... GMT. Always. See how org.apache.lucene.document.DateTools.round(long, Resolution) works, getting the calendar used for truncation from TL_CAL, which uses the GMT timezone. What it means is that the truncation currently produces rather unexpected results as soon as applications use a timezone different from GMT. So it's likely to be considered as broken: - for multi-timezone applications - for single-timezone applications using a different timezone than GMT For instance, let's index 2016-01-01T00:00:00+01:00 and query 2016-01-01T12:00:00+01:00 with a DAY resolution: - We'll index 2015-12-31 (2016-01-01T00:00:00+01:00 is 2015-12-31T23:00:00+00:00, which once truncated is 2015-12-31+00:00) - We'll query 2016-01-01 (2016-01-01T12:00:00+01:00 is 2016-01-01T11:00:00+00:00, which once truncated is 2016-01-01+00:00) That won't match, but from the point of view of a single-timezone user it should have. Of course I'm exaggerating a bit, and the issue probably hasn't been noticed by many, because: - there is no problem with the MINUTES, SECONDS and MILISECONDS resolutions, which are not affected by timezones - there is no problem with the HOUR resolution in most timezones (there is a problem, however, when the timezone is something like -11:30) - the problem is less likely to be detected when the user timezone is close to GMT, because then only date/times close to midnight (i.e. outside business hours) will be affected. But my point is: the current solution produces counter-intuitive, sometimes even useless results. It was useful when dates were indexed as strings, but now that we (mostly) index them as integers, this does not seem relevant. Even the DateTools javadoc hints that DateTools (including "round") are not relevant for numeric dates: Another approach is {@link NumericUtils}, which provides > a sortable binary representation (prefix encoded) of numeric values, which > date/time are. > For indexing a {@link Date} or {@link Calendar}, just get the unix > timestamp as > long using {@link Date#getTime} or {@link > Calendar#getTimeInMillis} and > index this as a numeric value with {@link LongField} > and use {@link NumericRangeQuery} to query it. What I'd like to propose is to deprecate or remove date/calendar resolution, or limit it to STRING encoding, and instead encourage users to query their dates with range queries whenever they don't want exact matches. Of course we could also implement a way for users to customize the timezone to be used when truncating. But range queries have other advantages: - they fit the multi-timezone use case - they allow to query the same field with multiple resolutions At the very least, I'd like us to agree that in the future, we will only implement automatic truncation with date/time types where the timezone is either irrelevant or included (for instance ZonedDateTime or LocalDate or LocalTime, but *not* Instant). Relevant ticket: https://hibernate.atlassian.net/browse/HSEARCH-2378. What do you think? Yoann Rodi?re Hibernate NoORM Team From sanne at hibernate.org Fri Jan 6 18:09:12 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 6 Jan 2017 23:09:12 +0000 Subject: [hibernate-dev] "Sister projects" need to be compatible with latest Hibernate ORM Message-ID: Hi all, as you know we've been late in delivering a version of Hibernate Search version compatible with Hibernate ORM 5.2, this caused many questions. Turns out OGM is also late to this club and this is causing some headaches too: people simply assume that our latest stuff will work with each other, and I can't blame them for expecting that. We need to improve on this; I screwed up scheduling on Search, but looking forward I hope we can improve on this. So... let's ramp up the tempo for an OGM 5.2 ? Thanks, Sanne From mihalcea.vlad at gmail.com Mon Jan 9 06:50:41 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 9 Jan 2017 13:50:41 +0200 Subject: [hibernate-dev] 6.0 - Session#createFilter In-Reply-To: References: Message-ID: +1. Session#createFilter should be removed. Entity queries (HQL, Criteria API) are way more flexible anyway. Vlad On Tue, Jan 3, 2017 at 10:54 PM, Chris Cranford wrote: > +1 > > > On 01/03/2017 10:02 AM, andrea boriero wrote: > > +1 for removing createFilter() > > > > On 3 January 2017 at 15:54, Gunnar Morling wrote: > > > >> 2017-01-03 15:28 GMT+01:00 Steve Ebersole : > >> > >>> On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling > >>> wrote: > >>> > >>>> 2017-01-02 15:27 GMT+01:00 Steve Ebersole : > >>>> I realize now that Session#createFilter() is only geared towards > >>>> collections. So are you suggesting to only remove that method, but > keep > >>>> @Filter/@FilterDef? > >>>> > >>> > >>> Correct. @Filter and @FilterDef are in NO WAY related to > >>> Session#createFilter > >>> > >> Ok. then +1 from my side for removing createFilter() . > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Mon Jan 9 06:53:21 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 9 Jan 2017 12:53:21 +0100 Subject: [hibernate-dev] [SEARCH] Remove support for (or deprecate) date/calendar resolution? In-Reply-To: References: Message-ID: Hi, On Thu, Jan 5, 2017 at 5:20 PM, Yoann Rodiere wrote: > That's a catchy subject, now I'm sure I got Guillaume's (angry) attention > :) > > Sanne wanted us to think about feature removal... Here's a proposal. > > The feature I'd like to deprecate/remove: automatic truncation of > date/calendars to a given resolution. It's used like that: > Yeah, as you can imagine, I'm pretty reluctant to the idea of removing this feature. We used it a lot at OW and I'm sure it's pretty widespread out there (and even when we didn't use HS but Solr, we needed an equivalent feature). Using range queries is a solution but it's a bit cumbersome for such a common requirement. I agree the current behavior might lead to unexpected results. To be honest, I think we should simply ignore the timezone when truncating. I mean, when I want to index at a day resolution, I want to index the user facing day, not the one in the server time zone or in GMT. So for instance, for 2016-01-01T00:00:00+01:00, I would index 2016-01-01, not 2015-12-31. So, as long as the resolution is less precise than day included, what I would do is in fact remove our call to DateTools.round and have something like: - create a GMT GregorianCalendar - don't set the calendar value using the time in millis but with the original fields from the calendar passed in parameter (or 0/1 depending on the resolution) - index this value I think this new behavior would fix most of the issues you mention. And if you really need the behavior when dates in one time zone might be a different date in a different time zone, then you definitely wouldn't use the resolution option and stick to the full date with range queries. So I agree the current behavior is probably not what user expects but I think it has value. I would pay to see your face while reading this email :). -- Guillaume From mihalcea.vlad at gmail.com Mon Jan 9 06:54:55 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 9 Jan 2017 13:54:55 +0200 Subject: [hibernate-dev] ScrollableResults and 6.0 In-Reply-To: <55b8bf2e-246e-fe8a-6431-b5b19ef85c70@gmail.com> References: <55b8bf2e-246e-fe8a-6431-b5b19ef85c70@gmail.com> Message-ID: I'm also for changing the signature, therefore simplifying the implementation. We've had some issues due to the fact that it expects Object[] and Chris and I had to do some hacks to fix them. Vlad On Tue, Jan 3, 2017 at 10:39 PM, Chris Cranford wrote: > Steve - > > I'm inclined to agree that changing signatures makes the most sense at > this point. > > Chris > > > On 12/27/2016 04:02 PM, Steve Ebersole wrote: > > FWIW my inclination is to just change the existing signatures. 6.0 is a > > major release with major changes already wrt querying. > > > > > > On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole > wrote: > > > >> For 6.0 I'd like to also make ScrollableResults parameterized wrt the > "row > >> type". E.g. > >> > >> ScrollableResults sr = session.createQuery( ..., Person.class > >> ).scroll(); > >> > >> However that changes the signature of its methods returning a "row" > >> (currently always defined as Object[]). > >> > >> How would everyone prefer we handle this? Do I just change the > signatures > >> of the existing methods? Or add new methods? > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Mon Jan 9 07:02:44 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 9 Jan 2017 14:02:44 +0200 Subject: [hibernate-dev] Preventing duplicate ForeignKey generation In-Reply-To: References: Message-ID: Thanks, Please send a Pull Request with a replicating test case. Vlad On Wed, Dec 28, 2016 at 12:05 AM, Milo van der Zee wrote: > Hello all, > > During development of applications I'm used to set the schema creation > to 'update' (hbm2ddl.auto = update). This makes life a bit easier. > Issue with the newer version of Hibernate is that the name of the > generated keys changed and so all keys are regenerated. For the large > databases I use this takes hours and has to be done every time a fresh > copy from production is taken to the development environment. > > I do use meaningful names for the indexes where possible. But when using > abstract classes used by the entities that is not possible because the > same fields from the abstract are used by many entity classes and so > would end up having the same index names. > > I checked the code that decides if the index needs to be created and > found that it only checks the name of the index. Not what the index > actually does. This is why I changed that piece of code to be a bit > smarter. It is desinged for simple constraints from one column to > another column. Not for multi to multi column indexes and constraints. > > I created a Jira issue for it but nobody notices it and there are no > comments or anything else. So now I try it here :) > Jira HHH-10934 (https://hibernate.atlassian.net/browse/HHH-10934) > > Code fragment I put in SchemaMigratorImpl.java: > > private ForeignKeyInformation findMatchingForeignKey(ForeignKey > foreignKey, TableInformation tableInformation) { > if (foreignKey.getName() ==null) { > return null; > } > > /* > * Find existing keys based on referencing column and > referencedTable > */ > String referencingColumn = foreignKey.getColumn(0).getName(); > String referencedTableName = foreignKey.getReferencedTable( > ).getName(); > Iterable existingForeignKeys = > tableInformation.getForeignKeys(); > for (ForeignKeyInformation existingKey : existingForeignKeys) { > Iterable columnReferenceMappings > = existingKey.getColumnReferenceMappings(); > for (ColumnReferenceMapping mapping : > columnReferenceMappings) { > String existingReferencingColumn = mapping. > getReferencingColumnMetadata().getColumnIdentifier().getText(); > String existingReferencedTableName = mapping. > getReferencedColumnMetadata().getContainingTableInformation( > ).getName().getTableName().getCanonicalName(); > if (referencingColumn.equals(existingReferencingColumn) > && referencedTableName.equals(existingReferencedTableName)) { > return existingKey; > } > } > } > > // If not yet found check based on key name return > tableInformation.getForeignKey(Identifier.toIdentifier(foreignKey. > getName())); > } > > Or if you prever the Java 8 way: > > private ForeignKeyInformation findMatchingForeignKey(ForeignKey > foreignKey, TableInformation tableInformation) { > log.debug("findMatchingForeignKey"); > if (foreignKey.getName() ==null)return null; > > /* > * Find existing keys based on referencing column and > referencedTable > */ > String referencingColumn = foreignKey.getColumn(0).getName(); > String referencedTableName = foreignKey.getReferencedTable( > ).getName(); > Predicate mappingPredicate = m -> > referencingColumn.equals(m.getReferencingColumnMetadata() > .getColumnIdentifier().getText()) > && referencedTableName.equals(m. > getReferencedColumnMetadata().getContainingTableInformation( > ).getName().getTableName().getCanonicalName()); > for (ForeignKeyInformation existingKey : tableInformation.getForeignKeys()) > { > boolean found = StreamSupport.stream(existingKey. > getColumnReferenceMappings().spliterator(),false).anyMatch( > mappingPredicate); > if (found)return existingKey; > } > > // If not yet found check based on key name return > tableInformation.getForeignKey(Identifier.toIdentifier(foreignKey. > getName())); > } > > The calling method does not use the returned value. It only checks if > the returned value is null or not. So this could also be cleaned by > changing the method to return a boolean and then remove the for loop in > java-8 and use flatmap. But first let us agree on the validity of the > idea to change this piece of code. > > I hope anybody would like to have a look at it and if there is any > change that the idea (not this actual very quick/dirty implementation) > goes into the system I'll clean it up and do some actual tests for more > complex database structures. I did not even check the junit tests yet. > At the moment it is good enough for me but I think it could be something > more people would benefit from. > > Thanks, > Milo van der Zee > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Mon Jan 9 08:28:14 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 9 Jan 2017 14:28:14 +0100 Subject: [hibernate-dev] [SEARCH] Remove support for (or deprecate) date/calendar resolution? In-Reply-To: References: Message-ID: > We used it a lot at OW and I'm sure it's pretty widespread out there (and even when we didn't use HS but Solr, we needed an equivalent feature). Using range queries is a solution but it's a bit cumbersome for such a common requirement. Please note that Hibernate Search queries are now built using a wrapper in OWSI-Core in most recent applications, and it could easily be adapted to add a Date match method (using method overloading). In fact, if I remember correctly I had to do exactly that for one application. One thing to note about the OW use case, too: I've never seen anything other than a Date being used in business models of single-timezone applications at Open Wide. See below why it's relevant. > I think this new behavior would fix most of the issues you mention. An easier implementation would be what you did with Elasticsearch using the clone() method. But anyway, this would only fix the issue for Calendar. For Date, we basically only have a GMT timestamp with no timezone data nor field-based data, so there's really nothing we can do. If we want to fix the default behavior for dates, the only solution I can see is to use the default JVM timezone instead of GMT, maybe... > And if you really need the behavior when dates in one time zone might be a different date in a different time zone, then you definitely wouldn't use the resolution option and stick to the full date with range queries. All dates in one time zone may be a different date in a different time zone... In fact, I'm pretty sure all dates in one time zone *are* a different date in one different time zone. I see what you mean, but I just wanted to point out how difficult it will be to explain properly in the documentation. I don't know about you, but I really don't want to explain in the docs that "this feature should only be used with java.util.Date if your timezone is close to GMT", and I want even less to explain why... Anyway, you do understand we're offering a feature that won't work properly in most time zones, and will simply not work most of the time in time zones such as, for instance, the one for the US west coast (UTC-8)? (in that specific case it won't work after 4 PM). Could we agree the current behavior should change, not only for java.util.Calendar but also for java.util.Date? If we do, we'll probably have to wait for 6.0, because users will have to perform a full reindex after upgrading to a version of Hibernate Search with the fix, even if they previously weren't affected by the bug. Also: > At the very least, I'd like us to agree that in the future, we will only implement automatic truncation with date/time types where the timezone is either irrelevant or included (for instance ZonedDateTime or LocalDate or LocalTime, but *not* Instant). Do you agree with the statement above? > I would pay to see your face while reading this email :). Yeah, well, not much surprise here :) Yoann Rodi?re Hibernate NoORM Team On 9 January 2017 at 12:53, Guillaume Smet wrote: > Hi, > > On Thu, Jan 5, 2017 at 5:20 PM, Yoann Rodiere wrote: > >> That's a catchy subject, now I'm sure I got Guillaume's (angry) attention >> :) >> >> Sanne wanted us to think about feature removal... Here's a proposal. >> >> The feature I'd like to deprecate/remove: automatic truncation of >> date/calendars to a given resolution. It's used like that: >> > > Yeah, as you can imagine, I'm pretty reluctant to the idea of removing > this feature. We used it a lot at OW and I'm sure it's pretty widespread > out there (and even when we didn't use HS but Solr, we needed an equivalent > feature). Using range queries is a solution but it's a bit cumbersome for > such a common requirement. > > I agree the current behavior might lead to unexpected results. To be > honest, I think we should simply ignore the timezone when truncating. I > mean, when I want to index at a day resolution, I want to index the user > facing day, not the one in the server time zone or in GMT. > > So for instance, for 2016-01-01T00:00:00+01:00, I would index 2016-01-01, > not 2015-12-31. > > So, as long as the resolution is less precise than day included, what I > would do is in fact remove our call to DateTools.round and have something > like: > - create a GMT GregorianCalendar > - don't set the calendar value using the time in millis but with the > original fields from the calendar passed in parameter (or 0/1 depending on > the resolution) > - index this value > > I think this new behavior would fix most of the issues you mention. And if > you really need the behavior when dates in one time zone might be a > different date in a different time zone, then you definitely wouldn't use > the resolution option and stick to the full date with range queries. > > So I agree the current behavior is probably not what user expects but I > think it has value. > > I would pay to see your face while reading this email :). > > -- > Guillaume > From yoann at hibernate.org Mon Jan 9 10:04:22 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 9 Jan 2017 16:04:22 +0100 Subject: [hibernate-dev] Hibernate Search 5.5.6.Final released Message-ID: Hello everyone, We just released Hibernate Search 5.5.6.Final with the latest bugfixes. For more information, please see our blog: http://in.relation.to/2017/01/09/hibernate-search-5-5-6-Final/ Yoann Rodi?re Hibernate NoORM Team From rory.odonnell at oracle.com Tue Jan 10 05:29:16 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 10 Jan 2017 10:29:16 +0000 Subject: [hibernate-dev] JDK 9 EA Build 151 is available on java.net Message-ID: <243f10fe-3333-8da9-a451-25c0a75ca34a@oracle.com> Hi Sanne, Best wishes for the New Year. Dalibor and I will be at FOSDEM '17, Brussels 4 & 5 February. Let us know if you will be there, hopefully we can meet up ! *JDK 9 Early Access* b151 is available on java.net There have been a number of fixes to bugs reported by Open Source projects since the last availability email : * JDK-8171377 : Add sun.misc.Unsafe::invokeCleaner * JDK-8075793 : Source incompatibility for inference using -source 7 * JDK-8087303 : LSSerializer pretty print does not work anymore * JDK-8167143 :CLDR timezone parsing does not work for all locales Other changes that maybe of interest: * JDK-8066474 : Remove the lib/$ARCH directory from Linux and Solaris images * JDK-8170428 : Move src.zip to JDK/lib/src.zip *JEPs intergrated:* * JEP 295 : Ahead-of-Time Compilation has been integrated in b150. *Schedule - Milestones since last availability email * * *Feature Extension Complete 22nd of December 2016* * *Rampdown Started 5th of January 2017 * o Phases in which increasing levels of scrutiny are applied to incoming changes. o In phase 1, only P1-P3 bugs can be fixed. In phase 2 only showstopper bugs can be fixed. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From sanne at hibernate.org Wed Jan 11 05:52:12 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 11 Jan 2017 10:52:12 +0000 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules Message-ID: Hi all, I'm finding several issues around this subject. While I tried several workarounds, I'd like us to agree on a strategy to address the root problem which is that Hibernate ORM might not necessarily want to use the Javassist version provided by WildFly, yet this is currently being forced on us. #Manifestation The problem manifests itself as a ClassCastException on casting the enhanced entity to a Javassist Proxy: it has been enhanced by a different Javassist instance than the one being used by ORM during runtime. #Need more tests First of, let me clarify that these issues are highlighted only the Hibernate Search testsuite, as we're trying to use these modules. Apparently the two tests we have in ORM to cover for the modules were not enough to highlight this problem.. we'll need to expand them. #The problem: duplicate dependency The WildFly modules include the Javassist version which ORM is using during the build, but also depends on the one provided by WildFly: - https://github.com/hibernate/hibernate-orm/blob/master/hibernate-orm-modules/src/main/modules/org/hibernate/core/module.xml#L12-L31 [There seems to be a comment about this but I guess we forgot to actually comment out the next line] #Which one? So I tried to comment out the reference to the WildFly module, but that gets me in more trouble as the JipiJapa integration will (my guess) use the "WildFly edition" of Javassist. Doing the opposite actually seems to work fine, but I guess there are reasons for ORM to have upgraded Javassist? #Failed workarounds I tried to disable class enhancement by setting either (and both!) of: - jboss.as.jpa.classtransformer = false - hibernate.ejb.use_class_enhancer = false I found these on the WildFly JPA Wiki [1], but it looks like they are not effective? #Viable workaround Removing the new Javassist version from the ORM module fixed my problems, but I'm not comfortable with this unless someone could confirm the version upgrade can wait, at least for the purpose of what we package in these modules? #Better fix I suspect the better solution would be for ORM to fully re-package the JipiJapa integration, so that we're able to be in control of version upgrade needs without having to wait for WildFly release cycles and other planets to align. #Wishlist: Modules refactoring Another reason for which I'd like ORM to "own" these modules, is that we could evolve them better. For example: - it seems the JipiJapa integration is having loads of dependencies which I suspect it doesn't really need. - we should hide Javassist & Byte Buddy from being exposed to the application - make Byte Buddy an option: I guess improve the JipiJapa itegration to support it and move it into its own private module. ## Suggestions? I'm stuck again on Hibernate Search upgrading to latest ORM so I'll see to apply the workaround without waiting for the proper solution. Not sure which actions I should take on ORM? Personally I think I'd just patch the modules to use the older Javassist when running on WildFly; that upgrade should wait for either WildFly to upgrade, or use to rethink these modules. Scott, could you help me by verifying if and were I should open a JIRA for those properties being ignored? Thanks, Sanne 1 - https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Hibernateproperties From smarlow at redhat.com Wed Jan 11 09:59:45 2017 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 11 Jan 2017 09:59:45 -0500 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: On Wed, Jan 11, 2017 at 5:52 AM, Sanne Grinovero wrote: > Hi all, > I'm finding several issues around this subject. While I tried several > workarounds, I'd like us to agree on a strategy to address the root > problem which is that Hibernate ORM might not necessarily want to use > the Javassist version provided by WildFly, yet this is currently being > forced on us. We talked about this not long ago and possible solutions, the only agreed on solution was to eliminate the ORM requirement for Javassist classes to be on the application classpath, by switching to ByteBuddy. Could you could use one of the previously suggested solutions in your testing? For example, your application could use a shaded Javassist jar, that doesn't interfere with the ORM Javassist. > > #Manifestation > The problem manifests itself as a ClassCastException on casting the > enhanced entity to a Javassist Proxy: it has been enhanced by a > different Javassist instance than the one being used by ORM during > runtime. > > #Need more tests > First of, let me clarify that these issues are highlighted only the > Hibernate Search testsuite, as we're trying to use these modules. > Apparently the two tests we have in ORM to cover for the modules were > not enough to highlight this problem.. we'll need to expand them. > > #The problem: duplicate dependency > The WildFly modules include the Javassist version which ORM is using > during the build, but also depends on the one provided by WildFly: > > - https://github.com/hibernate/hibernate-orm/blob/master/hibernate-orm-modules/src/main/modules/org/hibernate/core/module.xml#L12-L31 > > [There seems to be a comment about this but I guess we forgot to > actually comment out the next line] > > #Which one? > So I tried to comment out the reference to the WildFly module, but > that gets me in more trouble as the JipiJapa integration will (my > guess) use the "WildFly edition" of Javassist. > Doing the opposite actually seems to work fine, but I guess there are > reasons for ORM to have upgraded Javassist? > > #Failed workarounds > I tried to disable class enhancement by setting either (and both!) of: > - jboss.as.jpa.classtransformer = false > - hibernate.ejb.use_class_enhancer = false > I found these on the WildFly JPA Wiki [1], but it looks like they are > not effective? I believe that ORM is always rewriting entity classes by default. Is the default ORM entity enhancement, occurring when the entity classes are mapped (eagerly)? That could be the only reason that I can think of why, setting "jboss.as.jpa.classtransformer=false" wouldn't help. If that is not the case, let me know. > > #Viable workaround > Removing the new Javassist version from the ORM module fixed my > problems, but I'm not comfortable with this unless someone could > confirm the version upgrade can wait, at least for the purpose of what > we package in these modules? > > #Better fix > I suspect the better solution would be for ORM to fully re-package the > JipiJapa integration, so that we're able to be in control of version > upgrade needs without having to wait for WildFly release cycles and > other planets to align. > > #Wishlist: Modules refactoring > Another reason for which I'd like ORM to "own" these modules, is that > we could evolve them better. For example: > - it seems the JipiJapa integration is having loads of dependencies > which I suspect it doesn't really need. Why don't you contribute code changes instead to WildFly? I did create a pull request for https://issues.jboss.org/browse/WFLY-5773 that is still pending, to remove some unneeded dependencies. This won't get merged without an EAP jira that goes with it, which I don't plan to create, since there is no EAP need for the change. Pull request is https://github.com/wildfly/wildfly/pull/9305. > - we should hide Javassist & Byte Buddy from being exposed to the application Yes, I agree. You said this before but its ORM that requires Javassist classes to be on the application classpath. ORM does not require the Byte Buddy classes to be on the application classpath. > - make Byte Buddy an option: I guess improve the JipiJapa itegration > to support it and move it into its own private module. No, ORM doesn't require Byte Buddy to be on the application classpath, which means that Byte Buddy can be what you want, a separate private ORM module. This is a feature of WildFly modules, not JipiJapa. > > ## Suggestions? > I'm stuck again on Hibernate Search upgrading to latest ORM so I'll > see to apply the workaround without waiting for the proper solution. > Not sure which actions I should take on ORM? > > Personally I think I'd just patch the modules to use the older > Javassist when running on WildFly; that upgrade should wait for either > WildFly to upgrade, or use to rethink these modules. > > Scott, could you help me by verifying if and were I should open a JIRA > for those properties being ignored? I'm surprised that setting jboss.as.jpa.classtransformer to false, doesn't help. WildFly does have a org.jboss.as.test.integration.jpa.mockprovider.classtransformer.ClassFileTransformerTestCase test that ensures that jboss.as.jpa.classtransformer=true works but doesn't verify that jboss.as.jpa.classtransformer=false also works. This would probably help verify that it works. Scott > > Thanks, > Sanne > > 1 - https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Hibernateproperties > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Wed Jan 11 10:09:34 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 11 Jan 2017 16:09:34 +0100 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: Didn't we want to migrate off of Javassist for ORM 6, going for ByteBuddy exclusively? https://hibernate.atlassian.net/browse/HHH-11253 discusses that. 2017-01-11 15:59 GMT+01:00 Scott Marlow : > On Wed, Jan 11, 2017 at 5:52 AM, Sanne Grinovero wrote: >> Hi all, >> I'm finding several issues around this subject. While I tried several >> workarounds, I'd like us to agree on a strategy to address the root >> problem which is that Hibernate ORM might not necessarily want to use >> the Javassist version provided by WildFly, yet this is currently being >> forced on us. > > We talked about this not long ago and possible solutions, the only > agreed on solution was to eliminate the ORM requirement for Javassist > classes to be on the application classpath, by switching to ByteBuddy. > > Could you could use one of the previously suggested solutions in your > testing? For example, your application could use a shaded Javassist > jar, that doesn't interfere with the ORM Javassist. > >> >> #Manifestation >> The problem manifests itself as a ClassCastException on casting the >> enhanced entity to a Javassist Proxy: it has been enhanced by a >> different Javassist instance than the one being used by ORM during >> runtime. >> >> #Need more tests >> First of, let me clarify that these issues are highlighted only the >> Hibernate Search testsuite, as we're trying to use these modules. >> Apparently the two tests we have in ORM to cover for the modules were >> not enough to highlight this problem.. we'll need to expand them. >> >> #The problem: duplicate dependency >> The WildFly modules include the Javassist version which ORM is using >> during the build, but also depends on the one provided by WildFly: >> >> - https://github.com/hibernate/hibernate-orm/blob/master/hibernate-orm-modules/src/main/modules/org/hibernate/core/module.xml#L12-L31 >> >> [There seems to be a comment about this but I guess we forgot to >> actually comment out the next line] >> >> #Which one? >> So I tried to comment out the reference to the WildFly module, but >> that gets me in more trouble as the JipiJapa integration will (my >> guess) use the "WildFly edition" of Javassist. >> Doing the opposite actually seems to work fine, but I guess there are >> reasons for ORM to have upgraded Javassist? >> >> #Failed workarounds >> I tried to disable class enhancement by setting either (and both!) of: >> - jboss.as.jpa.classtransformer = false >> - hibernate.ejb.use_class_enhancer = false >> I found these on the WildFly JPA Wiki [1], but it looks like they are >> not effective? > > I believe that ORM is always rewriting entity classes by default. Is > the default ORM entity enhancement, occurring when the entity classes > are mapped (eagerly)? That could be the only reason that I can think > of why, setting "jboss.as.jpa.classtransformer=false" wouldn't help. > If that is not the case, let me know. > >> >> #Viable workaround >> Removing the new Javassist version from the ORM module fixed my >> problems, but I'm not comfortable with this unless someone could >> confirm the version upgrade can wait, at least for the purpose of what >> we package in these modules? >> >> #Better fix >> I suspect the better solution would be for ORM to fully re-package the >> JipiJapa integration, so that we're able to be in control of version >> upgrade needs without having to wait for WildFly release cycles and >> other planets to align. >> >> #Wishlist: Modules refactoring >> Another reason for which I'd like ORM to "own" these modules, is that >> we could evolve them better. For example: >> - it seems the JipiJapa integration is having loads of dependencies >> which I suspect it doesn't really need. > > Why don't you contribute code changes instead to WildFly? I did > create a pull request for https://issues.jboss.org/browse/WFLY-5773 > that is still pending, to remove some unneeded dependencies. This > won't get merged without an EAP jira that goes with it, which I don't > plan to create, since there is no EAP need for the change. Pull > request is https://github.com/wildfly/wildfly/pull/9305. > >> - we should hide Javassist & Byte Buddy from being exposed to the application > > Yes, I agree. You said this before but its ORM that requires > Javassist classes to be on the application classpath. ORM does not > require the Byte Buddy classes to be on the application classpath. > >> - make Byte Buddy an option: I guess improve the JipiJapa itegration >> to support it and move it into its own private module. > > No, ORM doesn't require Byte Buddy to be on the application classpath, > which means that Byte Buddy can be what you want, a separate private > ORM module. This is a feature of WildFly modules, not JipiJapa. > >> >> ## Suggestions? >> I'm stuck again on Hibernate Search upgrading to latest ORM so I'll >> see to apply the workaround without waiting for the proper solution. >> Not sure which actions I should take on ORM? >> >> Personally I think I'd just patch the modules to use the older >> Javassist when running on WildFly; that upgrade should wait for either >> WildFly to upgrade, or use to rethink these modules. >> >> Scott, could you help me by verifying if and were I should open a JIRA >> for those properties being ignored? > > I'm surprised that setting jboss.as.jpa.classtransformer to false, > doesn't help. WildFly does have a > org.jboss.as.test.integration.jpa.mockprovider.classtransformer.ClassFileTransformerTestCase > test that ensures that jboss.as.jpa.classtransformer=true works but > doesn't verify that jboss.as.jpa.classtransformer=false also works. > This would probably help verify that it works. > > Scott >> >> Thanks, >> Sanne >> >> 1 - https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Hibernateproperties >> _______________________________________________ >> 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 Jan 11 10:28:42 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 11 Jan 2017 15:28:42 +0000 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: On 11 January 2017 at 15:09, Gunnar Morling wrote: > Didn't we want to migrate off of Javassist for ORM 6, going for > ByteBuddy exclusively? > https://hibernate.atlassian.net/browse/HHH-11253 discusses that. Sure Byte Buddy looks great but we'll still need to support existing users for a while. AFAIR we'd like to move away from Javassist primarily as it needs to be exposed to the application, but I'm highlighting a different problem now. I was hoping to use these modules to test Search first, and then OGM, on ORM 5.2 but it sounds like you're telling me they are unsalvageable garbage? :D Surely we can fix them, it's just exposing the wrong Javassist version. BTW with Byte Buddy in future we could have the same conceptual problem as we want to upgrade it (for wathever reason) and WildFly will have the previous version we recommended. I see no other solution than for us to be "in control" of which dependencies we need. Surely you're not suggesting we should change bytecode enhancer for every WildFly release :) Thanks, Sanne From sanne at hibernate.org Wed Jan 11 10:43:52 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 11 Jan 2017 15:43:52 +0000 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: On 11 January 2017 at 14:59, Scott Marlow wrote: > On Wed, Jan 11, 2017 at 5:52 AM, Sanne Grinovero wrote: >> Hi all, >> I'm finding several issues around this subject. While I tried several >> workarounds, I'd like us to agree on a strategy to address the root >> problem which is that Hibernate ORM might not necessarily want to use >> the Javassist version provided by WildFly, yet this is currently being >> forced on us. > > We talked about this not long ago and possible solutions, the only > agreed on solution was to eliminate the ORM requirement for Javassist > classes to be on the application classpath, by switching to ByteBuddy. Like I replied to Gunnar, that's a different problem. Sorry all for the confusion! In this case it's Hibernate ORM which is being fed two different versions of Javassist simultaneously; clearly that's our fault. The application classpath is not affected. > Could you could use one of the previously suggested solutions in your > testing? For example, your application could use a shaded Javassist > jar, that doesn't interfere with the ORM Javassist. I'm not trying to use Javassist. If only the flags to disable it would work I'd be happy to disable it ;-) >> #Manifestation >> The problem manifests itself as a ClassCastException on casting the >> enhanced entity to a Javassist Proxy: it has been enhanced by a >> different Javassist instance than the one being used by ORM during >> runtime. >> >> #Need more tests >> First of, let me clarify that these issues are highlighted only the >> Hibernate Search testsuite, as we're trying to use these modules. >> Apparently the two tests we have in ORM to cover for the modules were >> not enough to highlight this problem.. we'll need to expand them. >> >> #The problem: duplicate dependency >> The WildFly modules include the Javassist version which ORM is using >> during the build, but also depends on the one provided by WildFly: >> >> - https://github.com/hibernate/hibernate-orm/blob/master/hibernate-orm-modules/src/main/modules/org/hibernate/core/module.xml#L12-L31 >> >> [There seems to be a comment about this but I guess we forgot to >> actually comment out the next line] >> >> #Which one? >> So I tried to comment out the reference to the WildFly module, but >> that gets me in more trouble as the JipiJapa integration will (my >> guess) use the "WildFly edition" of Javassist. >> Doing the opposite actually seems to work fine, but I guess there are >> reasons for ORM to have upgraded Javassist? >> >> #Failed workarounds >> I tried to disable class enhancement by setting either (and both!) of: >> - jboss.as.jpa.classtransformer = false >> - hibernate.ejb.use_class_enhancer = false >> I found these on the WildFly JPA Wiki [1], but it looks like they are >> not effective? > > I believe that ORM is always rewriting entity classes by default. Is > the default ORM entity enhancement, occurring when the entity classes > are mapped (eagerly)? That could be the only reason that I can think > of why, setting "jboss.as.jpa.classtransformer=false" wouldn't help. > If that is not the case, let me know. > >> >> #Viable workaround >> Removing the new Javassist version from the ORM module fixed my >> problems, but I'm not comfortable with this unless someone could >> confirm the version upgrade can wait, at least for the purpose of what >> we package in these modules? >> >> #Better fix >> I suspect the better solution would be for ORM to fully re-package the >> JipiJapa integration, so that we're able to be in control of version >> upgrade needs without having to wait for WildFly release cycles and >> other planets to align. >> >> #Wishlist: Modules refactoring >> Another reason for which I'd like ORM to "own" these modules, is that >> we could evolve them better. For example: >> - it seems the JipiJapa integration is having loads of dependencies >> which I suspect it doesn't really need. > > Why don't you contribute code changes instead to WildFly? I did > create a pull request for https://issues.jboss.org/browse/WFLY-5773 > that is still pending, to remove some unneeded dependencies. This > won't get merged without an EAP jira that goes with it, which I don't > plan to create, since there is no EAP need for the change. Pull > request is https://github.com/wildfly/wildfly/pull/9305. Thanks! Sure I'd be happy to contribute these to WildFly, but knowing which dependency is needed - or MIGHT be needed in certain configurations - requires in depth knowledge of the module one wants to cleanup. I just have the *impression* that some of these dependencies are no longer needed, but going back and forth between projects at different releases - and supposed to support various other versions - doesn't make it easy. So I suspect that if the adaptor code itself was bundled directly with the consuming JPA implementor, this would come more natural? Just an idea. See the problem is Hibernate Search needs to test with latest ORM way more regularly, so I can't wait for PRs to be included in WildFly, even less so if they are on hold because of even slower EAP cycles. > >> - we should hide Javassist & Byte Buddy from being exposed to the application > > Yes, I agree. You said this before but its ORM that requires > Javassist classes to be on the application classpath. ORM does not > require the Byte Buddy classes to be on the application classpath. > >> - make Byte Buddy an option: I guess improve the JipiJapa itegration >> to support it and move it into its own private module. > > No, ORM doesn't require Byte Buddy to be on the application classpath, > which means that Byte Buddy can be what you want, a separate private > ORM module. This is a feature of WildFly modules, not JipiJapa. What I mean is that JipiJapa is currently triggering enhancement via Javassist; it's not giving me an option to use Byte Buddy instead. So since the sources for that are in yet another project, it looks like I'd need 6 months to finish my ORM upgrade in Search. Luckily I'll aim for a different solution ;) >> ## Suggestions? >> I'm stuck again on Hibernate Search upgrading to latest ORM so I'll >> see to apply the workaround without waiting for the proper solution. >> Not sure which actions I should take on ORM? >> >> Personally I think I'd just patch the modules to use the older >> Javassist when running on WildFly; that upgrade should wait for either >> WildFly to upgrade, or use to rethink these modules. >> >> Scott, could you help me by verifying if and were I should open a JIRA >> for those properties being ignored? > > I'm surprised that setting jboss.as.jpa.classtransformer to false, > doesn't help. WildFly does have a > org.jboss.as.test.integration.jpa.mockprovider.classtransformer.ClassFileTransformerTestCase > test that ensures that jboss.as.jpa.classtransformer=true works but > doesn't verify that jboss.as.jpa.classtransformer=false also works. > This would probably help verify that it works. > > Scott >> >> Thanks, >> Sanne >> >> 1 - https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Hibernateproperties >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From smarlow at redhat.com Wed Jan 11 10:45:25 2017 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 11 Jan 2017 10:45:25 -0500 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: >> ## Suggestions? >> I'm stuck again on Hibernate Search upgrading to latest ORM so I'll >> see to apply the workaround without waiting for the proper solution. >> Not sure which actions I should take on ORM? >> >> Personally I think I'd just patch the modules to use the older >> Javassist when running on WildFly; that upgrade should wait for either >> WildFly to upgrade, or use to rethink these modules. >> >> Scott, could you help me by verifying if and were I should open a JIRA >> for those properties being ignored? > > I'm surprised that setting jboss.as.jpa.classtransformer to false, > doesn't help. WildFly does have a > org.jboss.as.test.integration.jpa.mockprovider.classtransformer.ClassFileTransformerTestCase > test that ensures that jboss.as.jpa.classtransformer=true works but > doesn't verify that jboss.as.jpa.classtransformer=false also works. > This would probably help verify that it works. I verified locally, that setting in the persistence.xml, ensures that the JPA persistence providers javax.persistence.spi.ClassTransformer is not called. If I instead set jboss.as.jpa.classtransformer=true, the javax.persistence.spi.ClassTransformer is called as expected (http://pastebin.com/AwjWkKb0 shows the call stack). > > Scott >> >> Thanks, >> Sanne >> >> 1 - https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Hibernateproperties >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From smarlow at redhat.com Wed Jan 11 11:05:27 2017 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 11 Jan 2017 11:05:27 -0500 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: Ahh, I was confused then, your talking about the WildFly ORM static module definition [1], which is not controlled by the JPA container or JipiJapa. >> >> We talked about this not long ago and possible solutions, the only >> agreed on solution was to eliminate the ORM requirement for Javassist >> classes to be on the application classpath, by switching to ByteBuddy. > > Like I replied to Gunnar, that's a different problem. Sorry all for > the confusion! > > In this case it's Hibernate ORM which is being fed two different > versions of Javassist simultaneously; clearly that's our fault. The > application classpath is not affected. > >> Could you could use one of the previously suggested solutions in your >> testing? For example, your application could use a shaded Javassist >> jar, that doesn't interfere with the ORM Javassist. > > I'm not trying to use Javassist. If only the flags to disable it would > work I'd be happy to disable it ;-) There are no flags for controlling [1], if you want control, just fork WildFly and make occasional changes to the static module definitions that meet your testing changes. Just keep the changes as minimal as possible, so it is easy to sync up the (test purposes) fork. The painful part though might be trying to push your fork to maven, so perhaps this is a bad idea, but still wanted to mention it, in case it could help. >> >> Why don't you contribute code changes instead to WildFly? I did >> create a pull request for https://issues.jboss.org/browse/WFLY-5773 >> that is still pending, to remove some unneeded dependencies. This >> won't get merged without an EAP jira that goes with it, which I don't >> plan to create, since there is no EAP need for the change. Pull >> request is https://github.com/wildfly/wildfly/pull/9305. > > Thanks! Sure I'd be happy to contribute these to WildFly, but knowing > which dependency is needed - or MIGHT be needed in certain > configurations - requires in depth knowledge of the module one wants > to cleanup. I'm not sure how you could dynamically update the ORM static module definition [1]. > I just have the *impression* that some of these dependencies are no > longer needed, but going back and forth between projects at different > releases - and supposed to support various other versions - doesn't > make it easy. ORM definitely still needs the Javassist dependency, but we should drop ASM, as that is not needed, as well as a few others. > > So I suspect that if the adaptor code itself was bundled directly with > the consuming JPA implementor, this would come more natural? Just an > idea. I agree, but others didn't when this came up on the JPA expert group mailing list before. > > See the problem is Hibernate Search needs to test with latest ORM way > more regularly, so I can't wait for PRs to be included in WildFly, > even less so if they are on hold because of even slower EAP cycles. I agree that you really need control over the static ORM module definitions. If you don't want to fork WildFly for testing, perhaps you could modify the static orm module definition before starting the app server, for the testing. Sounds like a pita. > >> >>> - we should hide Javassist & Byte Buddy from being exposed to the application >> >> Yes, I agree. You said this before but its ORM that requires >> Javassist classes to be on the application classpath. ORM does not >> require the Byte Buddy classes to be on the application classpath. >> >>> - make Byte Buddy an option: I guess improve the JipiJapa itegration >>> to support it and move it into its own private module. >> >> No, ORM doesn't require Byte Buddy to be on the application classpath, >> which means that Byte Buddy can be what you want, a separate private >> ORM module. This is a feature of WildFly modules, not JipiJapa. > > What I mean is that JipiJapa is currently triggering enhancement via > Javassist; it's not giving me an option to use Byte Buddy instead. Its more that the WildFly JPA container, allows the persistence provider to register a javax.persistence.spi.ClassTransformer instance, to be called when entity class definitions are loaded, as per the JPA requirements. JipiJapa doesn't get involved, as there is a standard JPA contract that ORM uses, so JipiJapa couldn't influence use of Byte Buddy or CGLIB or Javassist... > > So since the sources for that are in yet another project, it looks > like I'd need 6 months to finish my ORM upgrade in Search. Luckily > I'll aim for a different solution ;) :( Scott [1] https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml#L47 From steve at hibernate.org Wed Jan 11 11:19:15 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 11 Jan 2017 16:19:15 +0000 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: I think the best option in terms of supporting legacy ORM version users would be to incorporate a change in those branches to shade/shadow Javassist into ORM specific packages (in hibernate-core). As I understand it, it is always ORM that does the enhancement, right Scott? On Wed, Jan 11, 2017 at 10:12 AM Scott Marlow wrote: > Ahh, I was confused then, your talking about the WildFly ORM static > module definition [1], which is not controlled by the JPA container or > JipiJapa. > > >> > >> We talked about this not long ago and possible solutions, the only > >> agreed on solution was to eliminate the ORM requirement for Javassist > >> classes to be on the application classpath, by switching to ByteBuddy. > > > > Like I replied to Gunnar, that's a different problem. Sorry all for > > the confusion! > > > > In this case it's Hibernate ORM which is being fed two different > > versions of Javassist simultaneously; clearly that's our fault. The > > application classpath is not affected. > > > >> Could you could use one of the previously suggested solutions in your > >> testing? For example, your application could use a shaded Javassist > >> jar, that doesn't interfere with the ORM Javassist. > > > > I'm not trying to use Javassist. If only the flags to disable it would > > work I'd be happy to disable it ;-) > > There are no flags for controlling [1], if you want control, just fork > WildFly and make occasional changes to the static module definitions > that meet your testing changes. Just keep the changes as minimal as > possible, so it is easy to sync up the (test purposes) fork. The > painful part though might be trying to push your fork to maven, so > perhaps this is a bad idea, but still wanted to mention it, in case it > could help. > > >> > >> Why don't you contribute code changes instead to WildFly? I did > >> create a pull request for https://issues.jboss.org/browse/WFLY-5773 > >> that is still pending, to remove some unneeded dependencies. This > >> won't get merged without an EAP jira that goes with it, which I don't > >> plan to create, since there is no EAP need for the change. Pull > >> request is https://github.com/wildfly/wildfly/pull/9305. > > > > Thanks! Sure I'd be happy to contribute these to WildFly, but knowing > > which dependency is needed - or MIGHT be needed in certain > > configurations - requires in depth knowledge of the module one wants > > to cleanup. > > I'm not sure how you could dynamically update the ORM static module > definition [1]. > > > I just have the *impression* that some of these dependencies are no > > longer needed, but going back and forth between projects at different > > releases - and supposed to support various other versions - doesn't > > make it easy. > > ORM definitely still needs the Javassist dependency, but we should > drop ASM, as that is not needed, as well as a few others. > > > > > So I suspect that if the adaptor code itself was bundled directly with > > the consuming JPA implementor, this would come more natural? Just an > > idea. > > I agree, but others didn't when this came up on the JPA expert group > mailing list before. > > > > > See the problem is Hibernate Search needs to test with latest ORM way > > more regularly, so I can't wait for PRs to be included in WildFly, > > even less so if they are on hold because of even slower EAP cycles. > > I agree that you really need control over the static ORM module > definitions. If you don't want to fork WildFly for testing, perhaps > you could modify the static orm module definition before starting the > app server, for the testing. Sounds like a pita. > > > > >> > >>> - we should hide Javassist & Byte Buddy from being exposed to the > application > >> > >> Yes, I agree. You said this before but its ORM that requires > >> Javassist classes to be on the application classpath. ORM does not > >> require the Byte Buddy classes to be on the application classpath. > >> > >>> - make Byte Buddy an option: I guess improve the JipiJapa itegration > >>> to support it and move it into its own private module. > >> > >> No, ORM doesn't require Byte Buddy to be on the application classpath, > >> which means that Byte Buddy can be what you want, a separate private > >> ORM module. This is a feature of WildFly modules, not JipiJapa. > > > > What I mean is that JipiJapa is currently triggering enhancement via > > Javassist; it's not giving me an option to use Byte Buddy instead. > > Its more that the WildFly JPA container, allows the persistence > provider to register a javax.persistence.spi.ClassTransformer > instance, to be called when entity class definitions are loaded, as > per the JPA requirements. JipiJapa doesn't get involved, as there is > a standard JPA contract that ORM uses, so JipiJapa couldn't influence > use of Byte Buddy or CGLIB or Javassist... > > > > > So since the sources for that are in yet another project, it looks > > like I'd need 6 months to finish my ORM upgrade in Search. Luckily > > I'll aim for a different solution ;) > :( > > Scott > > [1] > https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml#L47 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From smarlow at redhat.com Wed Jan 11 11:35:37 2017 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 11 Jan 2017 11:35:37 -0500 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole wrote: > I think the best option in terms of supporting legacy ORM version users > would be to incorporate a change in those branches to shade/shadow Javassist > into ORM specific packages (in hibernate-core). +1 > > As I understand it, it is always ORM that does the enhancement, right Scott? Yes, ORM always does the enhancement. > > On Wed, Jan 11, 2017 at 10:12 AM Scott Marlow wrote: >> >> Ahh, I was confused then, your talking about the WildFly ORM static >> module definition [1], which is not controlled by the JPA container or >> JipiJapa. >> >> >> >> >> We talked about this not long ago and possible solutions, the only >> >> agreed on solution was to eliminate the ORM requirement for Javassist >> >> classes to be on the application classpath, by switching to ByteBuddy. >> > >> > Like I replied to Gunnar, that's a different problem. Sorry all for >> > the confusion! >> > >> > In this case it's Hibernate ORM which is being fed two different >> > versions of Javassist simultaneously; clearly that's our fault. The >> > application classpath is not affected. >> > >> >> Could you could use one of the previously suggested solutions in your >> >> testing? For example, your application could use a shaded Javassist >> >> jar, that doesn't interfere with the ORM Javassist. >> > >> > I'm not trying to use Javassist. If only the flags to disable it would >> > work I'd be happy to disable it ;-) >> >> There are no flags for controlling [1], if you want control, just fork >> WildFly and make occasional changes to the static module definitions >> that meet your testing changes. Just keep the changes as minimal as >> possible, so it is easy to sync up the (test purposes) fork. The >> painful part though might be trying to push your fork to maven, so >> perhaps this is a bad idea, but still wanted to mention it, in case it >> could help. >> >> >> >> >> Why don't you contribute code changes instead to WildFly? I did >> >> create a pull request for https://issues.jboss.org/browse/WFLY-5773 >> >> that is still pending, to remove some unneeded dependencies. This >> >> won't get merged without an EAP jira that goes with it, which I don't >> >> plan to create, since there is no EAP need for the change. Pull >> >> request is https://github.com/wildfly/wildfly/pull/9305. >> > >> > Thanks! Sure I'd be happy to contribute these to WildFly, but knowing >> > which dependency is needed - or MIGHT be needed in certain >> > configurations - requires in depth knowledge of the module one wants >> > to cleanup. >> >> I'm not sure how you could dynamically update the ORM static module >> definition [1]. >> >> > I just have the *impression* that some of these dependencies are no >> > longer needed, but going back and forth between projects at different >> > releases - and supposed to support various other versions - doesn't >> > make it easy. >> >> ORM definitely still needs the Javassist dependency, but we should >> drop ASM, as that is not needed, as well as a few others. >> >> > >> > So I suspect that if the adaptor code itself was bundled directly with >> > the consuming JPA implementor, this would come more natural? Just an >> > idea. >> >> I agree, but others didn't when this came up on the JPA expert group >> mailing list before. >> >> > >> > See the problem is Hibernate Search needs to test with latest ORM way >> > more regularly, so I can't wait for PRs to be included in WildFly, >> > even less so if they are on hold because of even slower EAP cycles. >> >> I agree that you really need control over the static ORM module >> definitions. If you don't want to fork WildFly for testing, perhaps >> you could modify the static orm module definition before starting the >> app server, for the testing. Sounds like a pita. >> >> > >> >> >> >>> - we should hide Javassist & Byte Buddy from being exposed to the >> >>> application >> >> >> >> Yes, I agree. You said this before but its ORM that requires >> >> Javassist classes to be on the application classpath. ORM does not >> >> require the Byte Buddy classes to be on the application classpath. >> >> >> >>> - make Byte Buddy an option: I guess improve the JipiJapa itegration >> >>> to support it and move it into its own private module. >> >> >> >> No, ORM doesn't require Byte Buddy to be on the application classpath, >> >> which means that Byte Buddy can be what you want, a separate private >> >> ORM module. This is a feature of WildFly modules, not JipiJapa. >> > >> > What I mean is that JipiJapa is currently triggering enhancement via >> > Javassist; it's not giving me an option to use Byte Buddy instead. >> >> Its more that the WildFly JPA container, allows the persistence >> provider to register a javax.persistence.spi.ClassTransformer >> instance, to be called when entity class definitions are loaded, as >> per the JPA requirements. JipiJapa doesn't get involved, as there is >> a standard JPA contract that ORM uses, so JipiJapa couldn't influence >> use of Byte Buddy or CGLIB or Javassist... >> >> > >> > So since the sources for that are in yet another project, it looks >> > like I'd need 6 months to finish my ORM upgrade in Search. Luckily >> > I'll aim for a different solution ;) >> :( >> >> Scott >> >> [1] >> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml#L47 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Wed Jan 11 11:48:42 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 11 Jan 2017 17:48:42 +0100 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: The one small issue is that if the user enhanced the classes at build time (i,e. not via the ClassTransformer), then shading in a newer version of Wildfly means that the same app using the later version will fail unless you rebuild the app. BTW is Javassist Shadable, some of these libs can?t due to string referencing classnames and other fun tricks like that. Emmanuel > On 11 Jan 2017, at 17:35, Scott Marlow wrote: > > On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole wrote: >> I think the best option in terms of supporting legacy ORM version users >> would be to incorporate a change in those branches to shade/shadow Javassist >> into ORM specific packages (in hibernate-core). > > +1 > >> >> As I understand it, it is always ORM that does the enhancement, right Scott? > > Yes, ORM always does the enhancement. > >> >> On Wed, Jan 11, 2017 at 10:12 AM Scott Marlow wrote: >>> >>> Ahh, I was confused then, your talking about the WildFly ORM static >>> module definition [1], which is not controlled by the JPA container or >>> JipiJapa. >>> >>>>> >>>>> We talked about this not long ago and possible solutions, the only >>>>> agreed on solution was to eliminate the ORM requirement for Javassist >>>>> classes to be on the application classpath, by switching to ByteBuddy. >>>> >>>> Like I replied to Gunnar, that's a different problem. Sorry all for >>>> the confusion! >>>> >>>> In this case it's Hibernate ORM which is being fed two different >>>> versions of Javassist simultaneously; clearly that's our fault. The >>>> application classpath is not affected. >>>> >>>>> Could you could use one of the previously suggested solutions in your >>>>> testing? For example, your application could use a shaded Javassist >>>>> jar, that doesn't interfere with the ORM Javassist. >>>> >>>> I'm not trying to use Javassist. If only the flags to disable it would >>>> work I'd be happy to disable it ;-) >>> >>> There are no flags for controlling [1], if you want control, just fork >>> WildFly and make occasional changes to the static module definitions >>> that meet your testing changes. Just keep the changes as minimal as >>> possible, so it is easy to sync up the (test purposes) fork. The >>> painful part though might be trying to push your fork to maven, so >>> perhaps this is a bad idea, but still wanted to mention it, in case it >>> could help. >>> >>>>> >>>>> Why don't you contribute code changes instead to WildFly? I did >>>>> create a pull request for https://issues.jboss.org/browse/WFLY-5773 >>>>> that is still pending, to remove some unneeded dependencies. This >>>>> won't get merged without an EAP jira that goes with it, which I don't >>>>> plan to create, since there is no EAP need for the change. Pull >>>>> request is https://github.com/wildfly/wildfly/pull/9305. >>>> >>>> Thanks! Sure I'd be happy to contribute these to WildFly, but knowing >>>> which dependency is needed - or MIGHT be needed in certain >>>> configurations - requires in depth knowledge of the module one wants >>>> to cleanup. >>> >>> I'm not sure how you could dynamically update the ORM static module >>> definition [1]. >>> >>>> I just have the *impression* that some of these dependencies are no >>>> longer needed, but going back and forth between projects at different >>>> releases - and supposed to support various other versions - doesn't >>>> make it easy. >>> >>> ORM definitely still needs the Javassist dependency, but we should >>> drop ASM, as that is not needed, as well as a few others. >>> >>>> >>>> So I suspect that if the adaptor code itself was bundled directly with >>>> the consuming JPA implementor, this would come more natural? Just an >>>> idea. >>> >>> I agree, but others didn't when this came up on the JPA expert group >>> mailing list before. >>> >>>> >>>> See the problem is Hibernate Search needs to test with latest ORM way >>>> more regularly, so I can't wait for PRs to be included in WildFly, >>>> even less so if they are on hold because of even slower EAP cycles. >>> >>> I agree that you really need control over the static ORM module >>> definitions. If you don't want to fork WildFly for testing, perhaps >>> you could modify the static orm module definition before starting the >>> app server, for the testing. Sounds like a pita. >>> >>>> >>>>> >>>>>> - we should hide Javassist & Byte Buddy from being exposed to the >>>>>> application >>>>> >>>>> Yes, I agree. You said this before but its ORM that requires >>>>> Javassist classes to be on the application classpath. ORM does not >>>>> require the Byte Buddy classes to be on the application classpath. >>>>> >>>>>> - make Byte Buddy an option: I guess improve the JipiJapa itegration >>>>>> to support it and move it into its own private module. >>>>> >>>>> No, ORM doesn't require Byte Buddy to be on the application classpath, >>>>> which means that Byte Buddy can be what you want, a separate private >>>>> ORM module. This is a feature of WildFly modules, not JipiJapa. >>>> >>>> What I mean is that JipiJapa is currently triggering enhancement via >>>> Javassist; it's not giving me an option to use Byte Buddy instead. >>> >>> Its more that the WildFly JPA container, allows the persistence >>> provider to register a javax.persistence.spi.ClassTransformer >>> instance, to be called when entity class definitions are loaded, as >>> per the JPA requirements. JipiJapa doesn't get involved, as there is >>> a standard JPA contract that ORM uses, so JipiJapa couldn't influence >>> use of Byte Buddy or CGLIB or Javassist... >>> >>>> >>>> So since the sources for that are in yet another project, it looks >>>> like I'd need 6 months to finish my ORM upgrade in Search. Luckily >>>> I'll aim for a different solution ;) >>> :( >>> >>> Scott >>> >>> [1] >>> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml#L47 >>> _______________________________________________ >>> 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 Jan 11 11:49:56 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 11 Jan 2017 16:49:56 +0000 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: On 11 January 2017 at 16:35, Scott Marlow wrote: > On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole wrote: >> I think the best option in terms of supporting legacy ORM version users >> would be to incorporate a change in those branches to shade/shadow Javassist >> into ORM specific packages (in hibernate-core). > > +1 > >> >> As I understand it, it is always ORM that does the enhancement, right Scott? > > Yes, ORM always does the enhancement. I had not realised that. This also means I should be able to change the ORM modules to benefit from full isolation from the Javassist copy included in WildFly, which could solve the problem. Going to try it now. Thanks! From smarlow at redhat.com Wed Jan 11 14:42:41 2017 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 11 Jan 2017 14:42:41 -0500 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: I'm not really sure but did notice that HikariCP [1] shaded the Javassist runtime classes in 2015 and still seems to be shading Javassist. Good point about about the compatibility impact, as build time instrumentation with the non-shaded Javassist will produce a Java archive that doesn't work with the shaded Javassist. The application will get a CNFE exception unless they add a dependency on the unshaded Javassist classes. I would expect the same problem when we change from using Javassist to using Byte Buddy. [1] https://github.com/brettwooldridge/HikariCP/search?utf8=%E2%9C%93&q=javassist On Wed, Jan 11, 2017 at 11:48 AM, Emmanuel Bernard wrote: > The one small issue is that if the user enhanced the classes at build time (i,e. not via the ClassTransformer), then shading in a newer version of Wildfly means that the same app using the later version will fail unless you rebuild the app. > BTW is Javassist Shadable, some of these libs can?t due to string referencing classnames and other fun tricks like that. > > Emmanuel > >> On 11 Jan 2017, at 17:35, Scott Marlow wrote: >> >> On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole wrote: >>> I think the best option in terms of supporting legacy ORM version users >>> would be to incorporate a change in those branches to shade/shadow Javassist >>> into ORM specific packages (in hibernate-core). >> >> +1 >> >>> >>> As I understand it, it is always ORM that does the enhancement, right Scott? >> >> Yes, ORM always does the enhancement. >> >>> >>> On Wed, Jan 11, 2017 at 10:12 AM Scott Marlow wrote: >>>> >>>> Ahh, I was confused then, your talking about the WildFly ORM static >>>> module definition [1], which is not controlled by the JPA container or >>>> JipiJapa. >>>> >>>>>> >>>>>> We talked about this not long ago and possible solutions, the only >>>>>> agreed on solution was to eliminate the ORM requirement for Javassist >>>>>> classes to be on the application classpath, by switching to ByteBuddy. >>>>> >>>>> Like I replied to Gunnar, that's a different problem. Sorry all for >>>>> the confusion! >>>>> >>>>> In this case it's Hibernate ORM which is being fed two different >>>>> versions of Javassist simultaneously; clearly that's our fault. The >>>>> application classpath is not affected. >>>>> >>>>>> Could you could use one of the previously suggested solutions in your >>>>>> testing? For example, your application could use a shaded Javassist >>>>>> jar, that doesn't interfere with the ORM Javassist. >>>>> >>>>> I'm not trying to use Javassist. If only the flags to disable it would >>>>> work I'd be happy to disable it ;-) >>>> >>>> There are no flags for controlling [1], if you want control, just fork >>>> WildFly and make occasional changes to the static module definitions >>>> that meet your testing changes. Just keep the changes as minimal as >>>> possible, so it is easy to sync up the (test purposes) fork. The >>>> painful part though might be trying to push your fork to maven, so >>>> perhaps this is a bad idea, but still wanted to mention it, in case it >>>> could help. >>>> >>>>>> >>>>>> Why don't you contribute code changes instead to WildFly? I did >>>>>> create a pull request for https://issues.jboss.org/browse/WFLY-5773 >>>>>> that is still pending, to remove some unneeded dependencies. This >>>>>> won't get merged without an EAP jira that goes with it, which I don't >>>>>> plan to create, since there is no EAP need for the change. Pull >>>>>> request is https://github.com/wildfly/wildfly/pull/9305. >>>>> >>>>> Thanks! Sure I'd be happy to contribute these to WildFly, but knowing >>>>> which dependency is needed - or MIGHT be needed in certain >>>>> configurations - requires in depth knowledge of the module one wants >>>>> to cleanup. >>>> >>>> I'm not sure how you could dynamically update the ORM static module >>>> definition [1]. >>>> >>>>> I just have the *impression* that some of these dependencies are no >>>>> longer needed, but going back and forth between projects at different >>>>> releases - and supposed to support various other versions - doesn't >>>>> make it easy. >>>> >>>> ORM definitely still needs the Javassist dependency, but we should >>>> drop ASM, as that is not needed, as well as a few others. >>>> >>>>> >>>>> So I suspect that if the adaptor code itself was bundled directly with >>>>> the consuming JPA implementor, this would come more natural? Just an >>>>> idea. >>>> >>>> I agree, but others didn't when this came up on the JPA expert group >>>> mailing list before. >>>> >>>>> >>>>> See the problem is Hibernate Search needs to test with latest ORM way >>>>> more regularly, so I can't wait for PRs to be included in WildFly, >>>>> even less so if they are on hold because of even slower EAP cycles. >>>> >>>> I agree that you really need control over the static ORM module >>>> definitions. If you don't want to fork WildFly for testing, perhaps >>>> you could modify the static orm module definition before starting the >>>> app server, for the testing. Sounds like a pita. >>>> >>>>> >>>>>> >>>>>>> - we should hide Javassist & Byte Buddy from being exposed to the >>>>>>> application >>>>>> >>>>>> Yes, I agree. You said this before but its ORM that requires >>>>>> Javassist classes to be on the application classpath. ORM does not >>>>>> require the Byte Buddy classes to be on the application classpath. >>>>>> >>>>>>> - make Byte Buddy an option: I guess improve the JipiJapa itegration >>>>>>> to support it and move it into its own private module. >>>>>> >>>>>> No, ORM doesn't require Byte Buddy to be on the application classpath, >>>>>> which means that Byte Buddy can be what you want, a separate private >>>>>> ORM module. This is a feature of WildFly modules, not JipiJapa. >>>>> >>>>> What I mean is that JipiJapa is currently triggering enhancement via >>>>> Javassist; it's not giving me an option to use Byte Buddy instead. >>>> >>>> Its more that the WildFly JPA container, allows the persistence >>>> provider to register a javax.persistence.spi.ClassTransformer >>>> instance, to be called when entity class definitions are loaded, as >>>> per the JPA requirements. JipiJapa doesn't get involved, as there is >>>> a standard JPA contract that ORM uses, so JipiJapa couldn't influence >>>> use of Byte Buddy or CGLIB or Javassist... >>>> >>>>> >>>>> So since the sources for that are in yet another project, it looks >>>>> like I'd need 6 months to finish my ORM upgrade in Search. Luckily >>>>> I'll aim for a different solution ;) >>>> :( >>>> >>>> Scott >>>> >>>> [1] >>>> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml#L47 >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Thu Jan 12 07:36:34 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 12 Jan 2017 12:36:34 +0000 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: Following Steve's suggestions I thought I had a reasonable and clean plan, but it's not working in practice. Turns out that even after me cleaning up all references to "org.javassist:main", it's still been forced on the classpath by hard-coded rules in the JPADependencyProcessor, so conflicting with the right version: - https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/jpa/subsystem/src/main/java/org/jboss/as/jpa/processor/JPADependencyProcessor.java#L95 Is there any way I can prevent this injection from happening? Can I override this JPADependencyProcessor? Thanks, Sanne On 11 January 2017 at 19:42, Scott Marlow wrote: > I'm not really sure but did notice that HikariCP [1] shaded the > Javassist runtime classes in 2015 and still seems to be shading > Javassist. > > Good point about about the compatibility impact, as build time > instrumentation with the non-shaded Javassist will produce a Java > archive that doesn't work with the shaded Javassist. The application > will get a CNFE exception unless they add a dependency on the unshaded > Javassist classes. I would expect the same problem when we change > from using Javassist to using Byte Buddy. > > [1] https://github.com/brettwooldridge/HikariCP/search?utf8=%E2%9C%93&q=javassist > > On Wed, Jan 11, 2017 at 11:48 AM, Emmanuel Bernard > wrote: >> The one small issue is that if the user enhanced the classes at build time (i,e. not via the ClassTransformer), then shading in a newer version of Wildfly means that the same app using the later version will fail unless you rebuild the app. >> BTW is Javassist Shadable, some of these libs can?t due to string referencing classnames and other fun tricks like that. >> >> Emmanuel >> >>> On 11 Jan 2017, at 17:35, Scott Marlow wrote: >>> >>> On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole wrote: >>>> I think the best option in terms of supporting legacy ORM version users >>>> would be to incorporate a change in those branches to shade/shadow Javassist >>>> into ORM specific packages (in hibernate-core). >>> >>> +1 >>> >>>> >>>> As I understand it, it is always ORM that does the enhancement, right Scott? >>> >>> Yes, ORM always does the enhancement. >>> >>>> >>>> On Wed, Jan 11, 2017 at 10:12 AM Scott Marlow wrote: >>>>> >>>>> Ahh, I was confused then, your talking about the WildFly ORM static >>>>> module definition [1], which is not controlled by the JPA container or >>>>> JipiJapa. >>>>> >>>>>>> >>>>>>> We talked about this not long ago and possible solutions, the only >>>>>>> agreed on solution was to eliminate the ORM requirement for Javassist >>>>>>> classes to be on the application classpath, by switching to ByteBuddy. >>>>>> >>>>>> Like I replied to Gunnar, that's a different problem. Sorry all for >>>>>> the confusion! >>>>>> >>>>>> In this case it's Hibernate ORM which is being fed two different >>>>>> versions of Javassist simultaneously; clearly that's our fault. The >>>>>> application classpath is not affected. >>>>>> >>>>>>> Could you could use one of the previously suggested solutions in your >>>>>>> testing? For example, your application could use a shaded Javassist >>>>>>> jar, that doesn't interfere with the ORM Javassist. >>>>>> >>>>>> I'm not trying to use Javassist. If only the flags to disable it would >>>>>> work I'd be happy to disable it ;-) >>>>> >>>>> There are no flags for controlling [1], if you want control, just fork >>>>> WildFly and make occasional changes to the static module definitions >>>>> that meet your testing changes. Just keep the changes as minimal as >>>>> possible, so it is easy to sync up the (test purposes) fork. The >>>>> painful part though might be trying to push your fork to maven, so >>>>> perhaps this is a bad idea, but still wanted to mention it, in case it >>>>> could help. >>>>> >>>>>>> >>>>>>> Why don't you contribute code changes instead to WildFly? I did >>>>>>> create a pull request for https://issues.jboss.org/browse/WFLY-5773 >>>>>>> that is still pending, to remove some unneeded dependencies. This >>>>>>> won't get merged without an EAP jira that goes with it, which I don't >>>>>>> plan to create, since there is no EAP need for the change. Pull >>>>>>> request is https://github.com/wildfly/wildfly/pull/9305. >>>>>> >>>>>> Thanks! Sure I'd be happy to contribute these to WildFly, but knowing >>>>>> which dependency is needed - or MIGHT be needed in certain >>>>>> configurations - requires in depth knowledge of the module one wants >>>>>> to cleanup. >>>>> >>>>> I'm not sure how you could dynamically update the ORM static module >>>>> definition [1]. >>>>> >>>>>> I just have the *impression* that some of these dependencies are no >>>>>> longer needed, but going back and forth between projects at different >>>>>> releases - and supposed to support various other versions - doesn't >>>>>> make it easy. >>>>> >>>>> ORM definitely still needs the Javassist dependency, but we should >>>>> drop ASM, as that is not needed, as well as a few others. >>>>> >>>>>> >>>>>> So I suspect that if the adaptor code itself was bundled directly with >>>>>> the consuming JPA implementor, this would come more natural? Just an >>>>>> idea. >>>>> >>>>> I agree, but others didn't when this came up on the JPA expert group >>>>> mailing list before. >>>>> >>>>>> >>>>>> See the problem is Hibernate Search needs to test with latest ORM way >>>>>> more regularly, so I can't wait for PRs to be included in WildFly, >>>>>> even less so if they are on hold because of even slower EAP cycles. >>>>> >>>>> I agree that you really need control over the static ORM module >>>>> definitions. If you don't want to fork WildFly for testing, perhaps >>>>> you could modify the static orm module definition before starting the >>>>> app server, for the testing. Sounds like a pita. >>>>> >>>>>> >>>>>>> >>>>>>>> - we should hide Javassist & Byte Buddy from being exposed to the >>>>>>>> application >>>>>>> >>>>>>> Yes, I agree. You said this before but its ORM that requires >>>>>>> Javassist classes to be on the application classpath. ORM does not >>>>>>> require the Byte Buddy classes to be on the application classpath. >>>>>>> >>>>>>>> - make Byte Buddy an option: I guess improve the JipiJapa itegration >>>>>>>> to support it and move it into its own private module. >>>>>>> >>>>>>> No, ORM doesn't require Byte Buddy to be on the application classpath, >>>>>>> which means that Byte Buddy can be what you want, a separate private >>>>>>> ORM module. This is a feature of WildFly modules, not JipiJapa. >>>>>> >>>>>> What I mean is that JipiJapa is currently triggering enhancement via >>>>>> Javassist; it's not giving me an option to use Byte Buddy instead. >>>>> >>>>> Its more that the WildFly JPA container, allows the persistence >>>>> provider to register a javax.persistence.spi.ClassTransformer >>>>> instance, to be called when entity class definitions are loaded, as >>>>> per the JPA requirements. JipiJapa doesn't get involved, as there is >>>>> a standard JPA contract that ORM uses, so JipiJapa couldn't influence >>>>> use of Byte Buddy or CGLIB or Javassist... >>>>> >>>>>> >>>>>> So since the sources for that are in yet another project, it looks >>>>>> like I'd need 6 months to finish my ORM upgrade in Search. Luckily >>>>>> I'll aim for a different solution ;) >>>>> :( >>>>> >>>>> Scott >>>>> >>>>> [1] >>>>> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml#L47 >>>>> _______________________________________________ >>>>> 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 smarlow at redhat.com Thu Jan 12 09:31:40 2017 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 12 Jan 2017 09:31:40 -0500 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: No, not currently. We created https://github.com/wildfly/wildfly/pull/8474 to move the exporting of Javassist, to the WildFly static ORM module, so that Hibernate native applications would automatically get the Javassist classes. That wouldn't of directly addressed your situation but it would of updated the WildFly JPA container (JPADependencyProcessor class) to no longer do the javassist export, so you would of had more control. I don't think that https://github.com/wildfly/wildfly/pull/8474 is likely to be merged. Instead, ORM needs to stop expecting the application classpath to include Javassist dependency and then we can update JPADependencyProcessor to stop exporting Javassist. Perhaps we could discuss this in person soon, to see if we are all on the same page. My current understanding is that this will be addressed when we switch to Byte Buddy, but the shading (Javassist) idea may also help, as we could stop exporting Javassist from the WildFly JPA container. On Thu, Jan 12, 2017 at 7:36 AM, Sanne Grinovero wrote: > Following Steve's suggestions I thought I had a reasonable and clean > plan, but it's not working in practice. > > Turns out that even after me cleaning up all references to > "org.javassist:main", it's still been forced on the classpath by > hard-coded rules in the JPADependencyProcessor, so conflicting with > the right version: > - https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/jpa/subsystem/src/main/java/org/jboss/as/jpa/processor/JPADependencyProcessor.java#L95 > > Is there any way I can prevent this injection from happening? Can I > override this JPADependencyProcessor? > > Thanks, > Sanne > > On 11 January 2017 at 19:42, Scott Marlow wrote: >> I'm not really sure but did notice that HikariCP [1] shaded the >> Javassist runtime classes in 2015 and still seems to be shading >> Javassist. >> >> Good point about about the compatibility impact, as build time >> instrumentation with the non-shaded Javassist will produce a Java >> archive that doesn't work with the shaded Javassist. The application >> will get a CNFE exception unless they add a dependency on the unshaded >> Javassist classes. I would expect the same problem when we change >> from using Javassist to using Byte Buddy. >> >> [1] https://github.com/brettwooldridge/HikariCP/search?utf8=%E2%9C%93&q=javassist >> >> On Wed, Jan 11, 2017 at 11:48 AM, Emmanuel Bernard >> wrote: >>> The one small issue is that if the user enhanced the classes at build time (i,e. not via the ClassTransformer), then shading in a newer version of Wildfly means that the same app using the later version will fail unless you rebuild the app. >>> BTW is Javassist Shadable, some of these libs can?t due to string referencing classnames and other fun tricks like that. >>> >>> Emmanuel >>> >>>> On 11 Jan 2017, at 17:35, Scott Marlow wrote: >>>> >>>> On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole wrote: >>>>> I think the best option in terms of supporting legacy ORM version users >>>>> would be to incorporate a change in those branches to shade/shadow Javassist >>>>> into ORM specific packages (in hibernate-core). >>>> >>>> +1 >>>> >>>>> >>>>> As I understand it, it is always ORM that does the enhancement, right Scott? >>>> >>>> Yes, ORM always does the enhancement. >>>> >>>>> >>>>> On Wed, Jan 11, 2017 at 10:12 AM Scott Marlow wrote: >>>>>> >>>>>> Ahh, I was confused then, your talking about the WildFly ORM static >>>>>> module definition [1], which is not controlled by the JPA container or >>>>>> JipiJapa. >>>>>> >>>>>>>> >>>>>>>> We talked about this not long ago and possible solutions, the only >>>>>>>> agreed on solution was to eliminate the ORM requirement for Javassist >>>>>>>> classes to be on the application classpath, by switching to ByteBuddy. >>>>>>> >>>>>>> Like I replied to Gunnar, that's a different problem. Sorry all for >>>>>>> the confusion! >>>>>>> >>>>>>> In this case it's Hibernate ORM which is being fed two different >>>>>>> versions of Javassist simultaneously; clearly that's our fault. The >>>>>>> application classpath is not affected. >>>>>>> >>>>>>>> Could you could use one of the previously suggested solutions in your >>>>>>>> testing? For example, your application could use a shaded Javassist >>>>>>>> jar, that doesn't interfere with the ORM Javassist. >>>>>>> >>>>>>> I'm not trying to use Javassist. If only the flags to disable it would >>>>>>> work I'd be happy to disable it ;-) >>>>>> >>>>>> There are no flags for controlling [1], if you want control, just fork >>>>>> WildFly and make occasional changes to the static module definitions >>>>>> that meet your testing changes. Just keep the changes as minimal as >>>>>> possible, so it is easy to sync up the (test purposes) fork. The >>>>>> painful part though might be trying to push your fork to maven, so >>>>>> perhaps this is a bad idea, but still wanted to mention it, in case it >>>>>> could help. >>>>>> >>>>>>>> >>>>>>>> Why don't you contribute code changes instead to WildFly? I did >>>>>>>> create a pull request for https://issues.jboss.org/browse/WFLY-5773 >>>>>>>> that is still pending, to remove some unneeded dependencies. This >>>>>>>> won't get merged without an EAP jira that goes with it, which I don't >>>>>>>> plan to create, since there is no EAP need for the change. Pull >>>>>>>> request is https://github.com/wildfly/wildfly/pull/9305. >>>>>>> >>>>>>> Thanks! Sure I'd be happy to contribute these to WildFly, but knowing >>>>>>> which dependency is needed - or MIGHT be needed in certain >>>>>>> configurations - requires in depth knowledge of the module one wants >>>>>>> to cleanup. >>>>>> >>>>>> I'm not sure how you could dynamically update the ORM static module >>>>>> definition [1]. >>>>>> >>>>>>> I just have the *impression* that some of these dependencies are no >>>>>>> longer needed, but going back and forth between projects at different >>>>>>> releases - and supposed to support various other versions - doesn't >>>>>>> make it easy. >>>>>> >>>>>> ORM definitely still needs the Javassist dependency, but we should >>>>>> drop ASM, as that is not needed, as well as a few others. >>>>>> >>>>>>> >>>>>>> So I suspect that if the adaptor code itself was bundled directly with >>>>>>> the consuming JPA implementor, this would come more natural? Just an >>>>>>> idea. >>>>>> >>>>>> I agree, but others didn't when this came up on the JPA expert group >>>>>> mailing list before. >>>>>> >>>>>>> >>>>>>> See the problem is Hibernate Search needs to test with latest ORM way >>>>>>> more regularly, so I can't wait for PRs to be included in WildFly, >>>>>>> even less so if they are on hold because of even slower EAP cycles. >>>>>> >>>>>> I agree that you really need control over the static ORM module >>>>>> definitions. If you don't want to fork WildFly for testing, perhaps >>>>>> you could modify the static orm module definition before starting the >>>>>> app server, for the testing. Sounds like a pita. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> - we should hide Javassist & Byte Buddy from being exposed to the >>>>>>>>> application >>>>>>>> >>>>>>>> Yes, I agree. You said this before but its ORM that requires >>>>>>>> Javassist classes to be on the application classpath. ORM does not >>>>>>>> require the Byte Buddy classes to be on the application classpath. >>>>>>>> >>>>>>>>> - make Byte Buddy an option: I guess improve the JipiJapa itegration >>>>>>>>> to support it and move it into its own private module. >>>>>>>> >>>>>>>> No, ORM doesn't require Byte Buddy to be on the application classpath, >>>>>>>> which means that Byte Buddy can be what you want, a separate private >>>>>>>> ORM module. This is a feature of WildFly modules, not JipiJapa. >>>>>>> >>>>>>> What I mean is that JipiJapa is currently triggering enhancement via >>>>>>> Javassist; it's not giving me an option to use Byte Buddy instead. >>>>>> >>>>>> Its more that the WildFly JPA container, allows the persistence >>>>>> provider to register a javax.persistence.spi.ClassTransformer >>>>>> instance, to be called when entity class definitions are loaded, as >>>>>> per the JPA requirements. JipiJapa doesn't get involved, as there is >>>>>> a standard JPA contract that ORM uses, so JipiJapa couldn't influence >>>>>> use of Byte Buddy or CGLIB or Javassist... >>>>>> >>>>>>> >>>>>>> So since the sources for that are in yet another project, it looks >>>>>>> like I'd need 6 months to finish my ORM upgrade in Search. Luckily >>>>>>> I'll aim for a different solution ;) >>>>>> :( >>>>>> >>>>>> Scott >>>>>> >>>>>> [1] >>>>>> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml#L47 >>>>>> _______________________________________________ >>>>>> 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 Jan 12 09:50:44 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 12 Jan 2017 14:50:44 +0000 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: To be clear... ORM is "expecting the application classpath to include Javassist dependency" because it will need it for the *proxies* Hibernate returns to be usable once they get them from Hibernate. It may or may not *need* the application classpath to include Javassist dependency if the application is using bytecode generation and *not proxies*. I have not played with this specifically. On the bytecode generation side I am pretty sure Rafeal said Byte Buddy would not be needed on the application's classpath. No idea about proxies. Just in general I think generated proxies are always going to need the underlying library available. On Thu, Jan 12, 2017, 8:36 AM Scott Marlow wrote: No, not currently. We created https://github.com/wildfly/wildfly/pull/8474 to move the exporting of Javassist, to the WildFly static ORM module, so that Hibernate native applications would automatically get the Javassist classes. That wouldn't of directly addressed your situation but it would of updated the WildFly JPA container (JPADependencyProcessor class) to no longer do the javassist export, so you would of had more control. I don't think that https://github.com/wildfly/wildfly/pull/8474 is likely to be merged. Instead, ORM needs to stop expecting the application classpath to include Javassist dependency and then we can update JPADependencyProcessor to stop exporting Javassist. Perhaps we could discuss this in person soon, to see if we are all on the same page. My current understanding is that this will be addressed when we switch to Byte Buddy, but the shading (Javassist) idea may also help, as we could stop exporting Javassist from the WildFly JPA container. On Thu, Jan 12, 2017 at 7:36 AM, Sanne Grinovero wrote: > Following Steve's suggestions I thought I had a reasonable and clean > plan, but it's not working in practice. > > Turns out that even after me cleaning up all references to > "org.javassist:main", it's still been forced on the classpath by > hard-coded rules in the JPADependencyProcessor, so conflicting with > the right version: > - https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/jpa/subsystem/src/main/java/org/jboss/as/jpa/processor/JPADependencyProcessor.java#L95 > > Is there any way I can prevent this injection from happening? Can I > override this JPADependencyProcessor? > > Thanks, > Sanne > > On 11 January 2017 at 19:42, Scott Marlow wrote: >> I'm not really sure but did notice that HikariCP [1] shaded the >> Javassist runtime classes in 2015 and still seems to be shading >> Javassist. >> >> Good point about about the compatibility impact, as build time >> instrumentation with the non-shaded Javassist will produce a Java >> archive that doesn't work with the shaded Javassist. The application >> will get a CNFE exception unless they add a dependency on the unshaded >> Javassist classes. I would expect the same problem when we change >> from using Javassist to using Byte Buddy. >> >> [1] https://github.com/brettwooldridge/HikariCP/search?utf8=%E2%9C%93&q=javassist >> >> On Wed, Jan 11, 2017 at 11:48 AM, Emmanuel Bernard >> wrote: >>> The one small issue is that if the user enhanced the classes at build time (i,e. not via the ClassTransformer), then shading in a newer version of Wildfly means that the same app using the later version will fail unless you rebuild the app. >>> BTW is Javassist Shadable, some of these libs can?t due to string referencing classnames and other fun tricks like that. >>> >>> Emmanuel >>> >>>> On 11 Jan 2017, at 17:35, Scott Marlow wrote: >>>> >>>> On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole wrote: >>>>> I think the best option in terms of supporting legacy ORM version users >>>>> would be to incorporate a change in those branches to shade/shadow Javassist >>>>> into ORM specific packages (in hibernate-core). >>>> >>>> +1 >>>> >>>>> >>>>> As I understand it, it is always ORM that does the enhancement, right Scott? >>>> >>>> Yes, ORM always does the enhancement. >>>> >>>>> >>>>> On Wed, Jan 11, 2017 at 10:12 AM Scott Marlow wrote: >>>>>> >>>>>> Ahh, I was confused then, your talking about the WildFly ORM static >>>>>> module definition [1], which is not controlled by the JPA container or >>>>>> JipiJapa. >>>>>> >>>>>>>> >>>>>>>> We talked about this not long ago and possible solutions, the only >>>>>>>> agreed on solution was to eliminate the ORM requirement for Javassist >>>>>>>> classes to be on the application classpath, by switching to ByteBuddy. >>>>>>> >>>>>>> Like I replied to Gunnar, that's a different problem. Sorry all for >>>>>>> the confusion! >>>>>>> >>>>>>> In this case it's Hibernate ORM which is being fed two different >>>>>>> versions of Javassist simultaneously; clearly that's our fault. The >>>>>>> application classpath is not affected. >>>>>>> >>>>>>>> Could you could use one of the previously suggested solutions in your >>>>>>>> testing? For example, your application could use a shaded Javassist >>>>>>>> jar, that doesn't interfere with the ORM Javassist. >>>>>>> >>>>>>> I'm not trying to use Javassist. If only the flags to disable it would >>>>>>> work I'd be happy to disable it ;-) >>>>>> >>>>>> There are no flags for controlling [1], if you want control, just fork >>>>>> WildFly and make occasional changes to the static module definitions >>>>>> that meet your testing changes. Just keep the changes as minimal as >>>>>> possible, so it is easy to sync up the (test purposes) fork. The >>>>>> painful part though might be trying to push your fork to maven, so >>>>>> perhaps this is a bad idea, but still wanted to mention it, in case it >>>>>> could help. >>>>>> >>>>>>>> >>>>>>>> Why don't you contribute code changes instead to WildFly? I did >>>>>>>> create a pull request for https://issues.jboss.org/browse/WFLY-5773 >>>>>>>> that is still pending, to remove some unneeded dependencies. This >>>>>>>> won't get merged without an EAP jira that goes with it, which I don't >>>>>>>> plan to create, since there is no EAP need for the change. Pull >>>>>>>> request is https://github.com/wildfly/wildfly/pull/9305. >>>>>>> >>>>>>> Thanks! Sure I'd be happy to contribute these to WildFly, but knowing >>>>>>> which dependency is needed - or MIGHT be needed in certain >>>>>>> configurations - requires in depth knowledge of the module one wants >>>>>>> to cleanup. >>>>>> >>>>>> I'm not sure how you could dynamically update the ORM static module >>>>>> definition [1]. >>>>>> >>>>>>> I just have the *impression* that some of these dependencies are no >>>>>>> longer needed, but going back and forth between projects at different >>>>>>> releases - and supposed to support various other versions - doesn't >>>>>>> make it easy. >>>>>> >>>>>> ORM definitely still needs the Javassist dependency, but we should >>>>>> drop ASM, as that is not needed, as well as a few others. >>>>>> >>>>>>> >>>>>>> So I suspect that if the adaptor code itself was bundled directly with >>>>>>> the consuming JPA implementor, this would come more natural? Just an >>>>>>> idea. >>>>>> >>>>>> I agree, but others didn't when this came up on the JPA expert group >>>>>> mailing list before. >>>>>> >>>>>>> >>>>>>> See the problem is Hibernate Search needs to test with latest ORM way >>>>>>> more regularly, so I can't wait for PRs to be included in WildFly, >>>>>>> even less so if they are on hold because of even slower EAP cycles. >>>>>> >>>>>> I agree that you really need control over the static ORM module >>>>>> definitions. If you don't want to fork WildFly for testing, perhaps >>>>>> you could modify the static orm module definition before starting the >>>>>> app server, for the testing. Sounds like a pita. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> - we should hide Javassist & Byte Buddy from being exposed to the >>>>>>>>> application >>>>>>>> >>>>>>>> Yes, I agree. You said this before but its ORM that requires >>>>>>>> Javassist classes to be on the application classpath. ORM does not >>>>>>>> require the Byte Buddy classes to be on the application classpath. >>>>>>>> >>>>>>>>> - make Byte Buddy an option: I guess improve the JipiJapa itegration >>>>>>>>> to support it and move it into its own private module. >>>>>>>> >>>>>>>> No, ORM doesn't require Byte Buddy to be on the application classpath, >>>>>>>> which means that Byte Buddy can be what you want, a separate private >>>>>>>> ORM module. This is a feature of WildFly modules, not JipiJapa. >>>>>>> >>>>>>> What I mean is that JipiJapa is currently triggering enhancement via >>>>>>> Javassist; it's not giving me an option to use Byte Buddy instead. >>>>>> >>>>>> Its more that the WildFly JPA container, allows the persistence >>>>>> provider to register a javax.persistence.spi.ClassTransformer >>>>>> instance, to be called when entity class definitions are loaded, as >>>>>> per the JPA requirements. JipiJapa doesn't get involved, as there is >>>>>> a standard JPA contract that ORM uses, so JipiJapa couldn't influence >>>>>> use of Byte Buddy or CGLIB or Javassist... >>>>>> >>>>>>> >>>>>>> So since the sources for that are in yet another project, it looks >>>>>>> like I'd need 6 months to finish my ORM upgrade in Search. Luckily >>>>>>> I'll aim for a different solution ;) >>>>>> :( >>>>>> >>>>>> Scott >>>>>> >>>>>> [1] >>>>>> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml#L47 >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at hibernate.org Thu Jan 12 11:41:03 2017 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Thu, 12 Jan 2017 17:41:03 +0100 Subject: [hibernate-dev] Hibernate Validator 5.4.0.CR1 is out Message-ID: Hi! It's with great pleasure that I announce you the release of Hibernate Validator 5.4.0.CR1. This candidate release brings a few improvements and bugfixes on top of our Beta1. For more information, see the announcement post here: http://in.relation.to/2017/01/12/hibernate-validator-540-cr1-final-out/ Please test it thoroughly as Final is pretty close. Thanks! -- Guillaume From sanne at hibernate.org Fri Jan 13 06:20:34 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 13 Jan 2017 11:20:34 +0000 Subject: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules In-Reply-To: References: Message-ID: I finally have a working solution which allows me to move on with the upgrade of Hibernate Search, yet the solution in the Search testsuite is essentially sweeping the problem "under the carpet". I'm taking it as it allows me to move out of stale-mate (and it's not a Search problem) but opened an ORM issue to eventually fix the real problem: - https://hibernate.atlassian.net/browse/HHH-11394 Scott: your PR 8474 looks great and it would solve the problem. I wish it was applied long ago! Steve: understood about the application needing Javassit. Even with PR 8474 the application using ORM would still be "infected" by a possibly undesired Javassist pushed on its classpath, but at least with this PR we can choose a version which matches the needs of Hibernate ORM, and/or eventually remove it when moving to Byte Buddy. The problem I have with the current JPADependencyProcessor in WildFly is not just that it pushes Javassist to the client classpath, but it even pushes the old (wrong) version and gives us no way to prevent this. In case you're curious, my workaround for Search is to remove the new Javassist version; the infamous JPADependencyProcessor will push the old version and it just happens to work good enough for the tests we have. I checked by running the ORM testsuite with the same old Javassit version, and some tests fail so I wouldn't recommend this solution for any other purpose. Thanks all! Sanne On 12 January 2017 at 14:50, Steve Ebersole wrote: > To be clear... ORM is "expecting the application classpath to include > Javassist dependency" because it will need it for the *proxies* Hibernate > returns to be usable once they get them from Hibernate. > > It may or may not *need* the application classpath to include Javassist > dependency if the application is using bytecode generation and *not > proxies*. I have not played with this specifically. > > On the bytecode generation side I am pretty sure Rafeal said Byte Buddy > would not be needed on the application's classpath. No idea about proxies. > Just in general I think generated proxies are always going to need the > underlying library available. > > > On Thu, Jan 12, 2017, 8:36 AM Scott Marlow wrote: >> >> No, not currently. We created >> https://github.com/wildfly/wildfly/pull/8474 to move the exporting of >> Javassist, to the WildFly static ORM module, so that Hibernate native >> applications would automatically get the Javassist classes. That >> wouldn't of directly addressed your situation but it would of updated >> the WildFly JPA container (JPADependencyProcessor class) to no longer >> do the javassist export, so you would of had more control. I don't >> think that https://github.com/wildfly/wildfly/pull/8474 is likely to >> be merged. Instead, ORM needs to stop expecting the application >> classpath to include Javassist dependency and then we can update >> JPADependencyProcessor to stop exporting Javassist. >> >> Perhaps we could discuss this in person soon, to see if we are all on >> the same page. My current understanding is that this will be >> addressed when we switch to Byte Buddy, but the shading (Javassist) >> idea may also help, as we could stop exporting Javassist from the >> WildFly JPA container. >> >> >> On Thu, Jan 12, 2017 at 7:36 AM, Sanne Grinovero >> wrote: >> > Following Steve's suggestions I thought I had a reasonable and clean >> > plan, but it's not working in practice. >> > >> > Turns out that even after me cleaning up all references to >> > "org.javassist:main", it's still been forced on the classpath by >> > hard-coded rules in the JPADependencyProcessor, so conflicting with >> > the right version: >> > - >> > https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/jpa/subsystem/src/main/java/org/jboss/as/jpa/processor/JPADependencyProcessor.java#L95 >> > >> > Is there any way I can prevent this injection from happening? Can I >> > override this JPADependencyProcessor? >> > >> > Thanks, >> > Sanne >> > >> > On 11 January 2017 at 19:42, Scott Marlow wrote: >> >> I'm not really sure but did notice that HikariCP [1] shaded the >> >> Javassist runtime classes in 2015 and still seems to be shading >> >> Javassist. >> >> >> >> Good point about about the compatibility impact, as build time >> >> instrumentation with the non-shaded Javassist will produce a Java >> >> archive that doesn't work with the shaded Javassist. The application >> >> will get a CNFE exception unless they add a dependency on the unshaded >> >> Javassist classes. I would expect the same problem when we change >> >> from using Javassist to using Byte Buddy. >> >> >> >> [1] >> >> https://github.com/brettwooldridge/HikariCP/search?utf8=%E2%9C%93&q=javassist >> >> >> >> On Wed, Jan 11, 2017 at 11:48 AM, Emmanuel Bernard >> >> wrote: >> >>> The one small issue is that if the user enhanced the classes at build >> >>> time (i,e. not via the ClassTransformer), then shading in a newer version of >> >>> Wildfly means that the same app using the later version will fail unless you >> >>> rebuild the app. >> >>> BTW is Javassist Shadable, some of these libs can?t due to string >> >>> referencing classnames and other fun tricks like that. >> >>> >> >>> Emmanuel >> >>> >> >>>> On 11 Jan 2017, at 17:35, Scott Marlow wrote: >> >>>> >> >>>> On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole >> >>>> wrote: >> >>>>> I think the best option in terms of supporting legacy ORM version >> >>>>> users >> >>>>> would be to incorporate a change in those branches to shade/shadow >> >>>>> Javassist >> >>>>> into ORM specific packages (in hibernate-core). >> >>>> >> >>>> +1 >> >>>> >> >>>>> >> >>>>> As I understand it, it is always ORM that does the enhancement, >> >>>>> right Scott? >> >>>> >> >>>> Yes, ORM always does the enhancement. >> >>>> >> >>>>> >> >>>>> On Wed, Jan 11, 2017 at 10:12 AM Scott Marlow >> >>>>> wrote: >> >>>>>> >> >>>>>> Ahh, I was confused then, your talking about the WildFly ORM static >> >>>>>> module definition [1], which is not controlled by the JPA container >> >>>>>> or >> >>>>>> JipiJapa. >> >>>>>> >> >>>>>>>> >> >>>>>>>> We talked about this not long ago and possible solutions, the >> >>>>>>>> only >> >>>>>>>> agreed on solution was to eliminate the ORM requirement for >> >>>>>>>> Javassist >> >>>>>>>> classes to be on the application classpath, by switching to >> >>>>>>>> ByteBuddy. >> >>>>>>> >> >>>>>>> Like I replied to Gunnar, that's a different problem. Sorry all >> >>>>>>> for >> >>>>>>> the confusion! >> >>>>>>> >> >>>>>>> In this case it's Hibernate ORM which is being fed two different >> >>>>>>> versions of Javassist simultaneously; clearly that's our fault. >> >>>>>>> The >> >>>>>>> application classpath is not affected. >> >>>>>>> >> >>>>>>>> Could you could use one of the previously suggested solutions in >> >>>>>>>> your >> >>>>>>>> testing? For example, your application could use a shaded >> >>>>>>>> Javassist >> >>>>>>>> jar, that doesn't interfere with the ORM Javassist. >> >>>>>>> >> >>>>>>> I'm not trying to use Javassist. If only the flags to disable it >> >>>>>>> would >> >>>>>>> work I'd be happy to disable it ;-) >> >>>>>> >> >>>>>> There are no flags for controlling [1], if you want control, just >> >>>>>> fork >> >>>>>> WildFly and make occasional changes to the static module >> >>>>>> definitions >> >>>>>> that meet your testing changes. Just keep the changes as minimal >> >>>>>> as >> >>>>>> possible, so it is easy to sync up the (test purposes) fork. The >> >>>>>> painful part though might be trying to push your fork to maven, so >> >>>>>> perhaps this is a bad idea, but still wanted to mention it, in case >> >>>>>> it >> >>>>>> could help. >> >>>>>> >> >>>>>>>> >> >>>>>>>> Why don't you contribute code changes instead to WildFly? I did >> >>>>>>>> create a pull request for >> >>>>>>>> https://issues.jboss.org/browse/WFLY-5773 >> >>>>>>>> that is still pending, to remove some unneeded dependencies. >> >>>>>>>> This >> >>>>>>>> won't get merged without an EAP jira that goes with it, which I >> >>>>>>>> don't >> >>>>>>>> plan to create, since there is no EAP need for the change. Pull >> >>>>>>>> request is https://github.com/wildfly/wildfly/pull/9305. >> >>>>>>> >> >>>>>>> Thanks! Sure I'd be happy to contribute these to WildFly, but >> >>>>>>> knowing >> >>>>>>> which dependency is needed - or MIGHT be needed in certain >> >>>>>>> configurations - requires in depth knowledge of the module one >> >>>>>>> wants >> >>>>>>> to cleanup. >> >>>>>> >> >>>>>> I'm not sure how you could dynamically update the ORM static module >> >>>>>> definition [1]. >> >>>>>> >> >>>>>>> I just have the *impression* that some of these dependencies are >> >>>>>>> no >> >>>>>>> longer needed, but going back and forth between projects at >> >>>>>>> different >> >>>>>>> releases - and supposed to support various other versions - >> >>>>>>> doesn't >> >>>>>>> make it easy. >> >>>>>> >> >>>>>> ORM definitely still needs the Javassist dependency, but we should >> >>>>>> drop ASM, as that is not needed, as well as a few others. >> >>>>>> >> >>>>>>> >> >>>>>>> So I suspect that if the adaptor code itself was bundled directly >> >>>>>>> with >> >>>>>>> the consuming JPA implementor, this would come more natural? Just >> >>>>>>> an >> >>>>>>> idea. >> >>>>>> >> >>>>>> I agree, but others didn't when this came up on the JPA expert >> >>>>>> group >> >>>>>> mailing list before. >> >>>>>> >> >>>>>>> >> >>>>>>> See the problem is Hibernate Search needs to test with latest ORM >> >>>>>>> way >> >>>>>>> more regularly, so I can't wait for PRs to be included in WildFly, >> >>>>>>> even less so if they are on hold because of even slower EAP >> >>>>>>> cycles. >> >>>>>> >> >>>>>> I agree that you really need control over the static ORM module >> >>>>>> definitions. If you don't want to fork WildFly for testing, >> >>>>>> perhaps >> >>>>>> you could modify the static orm module definition before starting >> >>>>>> the >> >>>>>> app server, for the testing. Sounds like a pita. >> >>>>>> >> >>>>>>> >> >>>>>>>> >> >>>>>>>>> - we should hide Javassist & Byte Buddy from being exposed to >> >>>>>>>>> the >> >>>>>>>>> application >> >>>>>>>> >> >>>>>>>> Yes, I agree. You said this before but its ORM that requires >> >>>>>>>> Javassist classes to be on the application classpath. ORM does >> >>>>>>>> not >> >>>>>>>> require the Byte Buddy classes to be on the application >> >>>>>>>> classpath. >> >>>>>>>> >> >>>>>>>>> - make Byte Buddy an option: I guess improve the JipiJapa >> >>>>>>>>> itegration >> >>>>>>>>> to support it and move it into its own private module. >> >>>>>>>> >> >>>>>>>> No, ORM doesn't require Byte Buddy to be on the application >> >>>>>>>> classpath, >> >>>>>>>> which means that Byte Buddy can be what you want, a separate >> >>>>>>>> private >> >>>>>>>> ORM module. This is a feature of WildFly modules, not JipiJapa. >> >>>>>>> >> >>>>>>> What I mean is that JipiJapa is currently triggering enhancement >> >>>>>>> via >> >>>>>>> Javassist; it's not giving me an option to use Byte Buddy instead. >> >>>>>> >> >>>>>> Its more that the WildFly JPA container, allows the persistence >> >>>>>> provider to register a javax.persistence.spi.ClassTransformer >> >>>>>> instance, to be called when entity class definitions are loaded, as >> >>>>>> per the JPA requirements. JipiJapa doesn't get involved, as there >> >>>>>> is >> >>>>>> a standard JPA contract that ORM uses, so JipiJapa couldn't >> >>>>>> influence >> >>>>>> use of Byte Buddy or CGLIB or Javassist... >> >>>>>> >> >>>>>>> >> >>>>>>> So since the sources for that are in yet another project, it looks >> >>>>>>> like I'd need 6 months to finish my ORM upgrade in Search. Luckily >> >>>>>>> I'll aim for a different solution ;) >> >>>>>> :( >> >>>>>> >> >>>>>> Scott >> >>>>>> >> >>>>>> [1] >> >>>>>> >> >>>>>> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml#L47 >> >>>>>> _______________________________________________ >> >>>>>> hibernate-dev mailing list >> >>>>>> hibernate-dev at lists.jboss.org >> >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>>> _______________________________________________ >> >>>> hibernate-dev mailing list >> >>>> hibernate-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> >> >> >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From davide at hibernate.org Fri Jan 13 07:18:47 2017 From: davide at hibernate.org (Davide D'Alto) Date: Fri, 13 Jan 2017 12:18:47 +0000 Subject: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB Message-ID: Hi, it seems that when using Collection of elements in MongoDB, users expect to have the elements in the same order as in the db. You can see the question on the forum here: https://forum.hibernate.org/viewtopic.php?f=31&t=1043903&p=2491218#p2491218 I also found this StackOverflow question: http://stackoverflow.com/questions/9013916/do-arrays-stored-in-mongodb-keep-their-order What do you think? Is it something that we should support? Cheers, Davide From sanne at hibernate.org Fri Jan 13 07:48:14 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 13 Jan 2017 12:48:14 +0000 Subject: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB In-Reply-To: References: Message-ID: I think it's a reasonable expectation, as long as we're talking specifically about mapping a *List* and not just a generic Collection. On 13 January 2017 at 12:18, Davide D'Alto wrote: > Hi, > it seems that when using Collection of elements in MongoDB, users > expect to have the elements in the same order as in the db. You can > see the question on the forum here: > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903&p=2491218#p2491218 > > I also found this StackOverflow question: > http://stackoverflow.com/questions/9013916/do-arrays-stored-in-mongodb-keep-their-order > > What do you think? Is it something that we should support? > > Cheers, > Davide > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Fri Jan 13 08:30:13 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 13 Jan 2017 14:30:13 +0100 Subject: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB In-Reply-To: References: Message-ID: > > I think it's a reasonable expectation, as long as we're talking > specifically about mapping a *List* and not just a generic Collection. > Ah, this topic again :) I know I'll be all lone, but I'll try anyway! If we do it for List, and unless there are technical issues that prevent us from doing so, I would be in favor of doing it for any kind of collection. In Collections, the fact that iteration order is deterministic is mostly up to the implementation, which is different from saying it's not deterministic. From the javadoc for Collection#iterator(): There are no guarantees concerning the order in which the elements are > returned > (unless this collection is an instance of some class that provides a > guarantee). Deterministic, and even predictable order is not exclusive to List, either: for instance, LinkedHashSet is not a List, it has a specific iteration order, but there is nothing in its implemented interfaces (Collection, Set) that defines this order. My point is, we can't rely on the implemented interface to decide whether the iteration order is important or not, so we may as well decide it is always important. Unless there are annoying technical challenges, of course. Yoann Rodi?re Hibernate NoORM Team On 13 January 2017 at 13:48, Sanne Grinovero wrote: > I think it's a reasonable expectation, as long as we're talking > specifically about mapping a *List* and not just a generic Collection. > > On 13 January 2017 at 12:18, Davide D'Alto wrote: > > Hi, > > it seems that when using Collection of elements in MongoDB, users > > expect to have the elements in the same order as in the db. You can > > see the question on the forum here: > > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903& > p=2491218#p2491218 > > > > I also found this StackOverflow question: > > http://stackoverflow.com/questions/9013916/do-arrays- > stored-in-mongodb-keep-their-order > > > > What do you think? Is it something that we should support? > > > > 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 sanne at hibernate.org Fri Jan 13 09:26:46 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 13 Jan 2017 14:26:46 +0000 Subject: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB In-Reply-To: References: Message-ID: Hi Yoann, while you might be using a specific implementation when persisting your new entities, when you're loading the object back from the database how is Hibernate supposed to know A) which implementation you want it to use B) which order to use, if you didn't map e.g. an order column to store the ordering information (MongoDB not needing a strategy is an exception) The entity model expresses the intent of the end user, but also it expresses its requirements which will be taken into account by ORM when it needs to provide an implementation for the "Collection" interface. A List expresses the ordering requirement by contract; if you map a relation as "Collection" I wage you're not interested in the order, but you're rather more interested in accepting a wide range of implementations, some of which might ignore the ordering requirement. By doing so, you're explicitly telling both ORM and your other code interacting with the model that ignoring the order is acceptable. BTW I suspect mapping things as a generic Collection is a very unusual (or lazy) choice; I don't remember ever using it as it's quite ambiguous, and there's no way any specification diagram will lead you to recommend using a Collection (other than cleanly and explicitly wanting to express you don't care about ordering, nor other properties like uniqueness...) Thanks, Sanne On 13 January 2017 at 13:29, Yoann Rodiere wrote: >> I think it's a reasonable expectation, as long as we're talking >> specifically about mapping a *List* and not just a generic Collection. > > > Ah, this topic again :) I know I'll be all lone, but I'll try anyway! > > If we do it for List, and unless there are technical issues that prevent us > from doing so, I would be in favor of doing it for any kind of collection. > > In Collections, the fact that iteration order is deterministic is mostly up > to the implementation, which is different from saying it's not > deterministic. From the javadoc for Collection#iterator(): > >> There are no guarantees concerning the order in which the elements are >> returned >> (unless this collection is an instance of some class that provides a >> guarantee). > > > Deterministic, and even predictable order is not exclusive to List, either: > for instance, LinkedHashSet is not a List, it has a specific iteration > order, but there is nothing in its implemented interfaces (Collection, Set) > that defines this order. > > My point is, we can't rely on the implemented interface to decide whether > the iteration order is important or not, so we may as well decide it is > always important. Unless there are annoying technical challenges, of course. > > Yoann Rodi?re > Software Engineer > Red Hat / Hibernate NoORM Team > > On 13 January 2017 at 13:48, Sanne Grinovero wrote: >> >> I think it's a reasonable expectation, as long as we're talking >> specifically about mapping a *List* and not just a generic Collection. >> >> On 13 January 2017 at 12:18, Davide D'Alto wrote: >> > Hi, >> > it seems that when using Collection of elements in MongoDB, users >> > expect to have the elements in the same order as in the db. You can >> > see the question on the forum here: >> > >> > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903&p=2491218#p2491218 >> > >> > I also found this StackOverflow question: >> > >> > http://stackoverflow.com/questions/9013916/do-arrays-stored-in-mongodb-keep-their-order >> > >> > What do you think? Is it something that we should support? >> > >> > 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 davide at hibernate.org Fri Jan 13 10:30:16 2017 From: davide at hibernate.org (Davide D'Alto) Date: Fri, 13 Jan 2017 15:30:16 +0000 Subject: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB In-Reply-To: References: Message-ID: I've created a JIRA for this https://hibernate.atlassian.net/browse/OGM-1236 Thanks On Fri, Jan 13, 2017 at 2:26 PM, Sanne Grinovero wrote: > Hi Yoann, > > while you might be using a specific implementation when persisting > your new entities, when you're loading the object back from the > database how is Hibernate supposed to know > A) which implementation you want it to use > B) which order to use, if you didn't map e.g. an order column to > store the ordering information (MongoDB not needing a strategy is an > exception) > > The entity model expresses the intent of the end user, but also it > expresses its requirements which will be taken into account by ORM > when it needs to provide an implementation for the "Collection" > interface. > > A List expresses the ordering requirement by contract; if you map a > relation as "Collection" I wage you're not interested in the order, > but you're rather more interested in accepting a wide range of > implementations, some of which might ignore the ordering requirement. > By doing so, you're explicitly telling both ORM and your other code > interacting with the model that ignoring the order is acceptable. > > BTW I suspect mapping things as a generic Collection is a very unusual > (or lazy) choice; I don't remember ever using it as it's quite > ambiguous, and there's no way any specification diagram will lead you > to recommend using a Collection (other than cleanly and explicitly > wanting to express you don't care about ordering, nor other properties > like uniqueness...) > > Thanks, > Sanne > > > On 13 January 2017 at 13:29, Yoann Rodiere wrote: >>> I think it's a reasonable expectation, as long as we're talking >>> specifically about mapping a *List* and not just a generic Collection. >> >> >> Ah, this topic again :) I know I'll be all lone, but I'll try anyway! >> >> If we do it for List, and unless there are technical issues that prevent us >> from doing so, I would be in favor of doing it for any kind of collection. >> >> In Collections, the fact that iteration order is deterministic is mostly up >> to the implementation, which is different from saying it's not >> deterministic. From the javadoc for Collection#iterator(): >> >>> There are no guarantees concerning the order in which the elements are >>> returned >>> (unless this collection is an instance of some class that provides a >>> guarantee). >> >> >> Deterministic, and even predictable order is not exclusive to List, either: >> for instance, LinkedHashSet is not a List, it has a specific iteration >> order, but there is nothing in its implemented interfaces (Collection, Set) >> that defines this order. >> >> My point is, we can't rely on the implemented interface to decide whether >> the iteration order is important or not, so we may as well decide it is >> always important. Unless there are annoying technical challenges, of course. >> >> Yoann Rodi?re >> Software Engineer >> Red Hat / Hibernate NoORM Team >> >> On 13 January 2017 at 13:48, Sanne Grinovero wrote: >>> >>> I think it's a reasonable expectation, as long as we're talking >>> specifically about mapping a *List* and not just a generic Collection. >>> >>> On 13 January 2017 at 12:18, Davide D'Alto wrote: >>> > Hi, >>> > it seems that when using Collection of elements in MongoDB, users >>> > expect to have the elements in the same order as in the db. You can >>> > see the question on the forum here: >>> > >>> > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903&p=2491218#p2491218 >>> > >>> > I also found this StackOverflow question: >>> > >>> > http://stackoverflow.com/questions/9013916/do-arrays-stored-in-mongodb-keep-their-order >>> > >>> > What do you think? Is it something that we should support? >>> > >>> > 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 yoann at hibernate.org Fri Jan 13 10:33:57 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 13 Jan 2017 16:33:57 +0100 Subject: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB In-Reply-To: References: Message-ID: Hi Sanne, > while you might be using a specific implementation when persisting > your new entities, when you're loading the object back from the > database how is Hibernate supposed to know > A) which implementation you want it to use Ok, that's true for most collection interfaces, but I'm not sure I understand why what Hibernate can guess is relevant here. Users are free to use custom collection types, at least in ORM. Is it not the case with OGM? Will it never be possible? I thought we were talking about making the collection persister persist/retrieve the elements in the same order as they were retrieved from the collection. If it's not the case, then yes, I'm missing something. However, even in the specific case of Collection, by default Hibernate instantiates a List behind the scene for such properties (well, a PersistentBag, but it's basically a List). Thus if the original collection had some kind of "ordering memory", at least this would be preserved, provided we persist elements in the same order we retrieved them from the original collection. B) which order to use, if you didn't map e.g. an order column to > store the ordering information (MongoDB not needing a strategy is an > exception) Well, we don't want to frustrate OGM users with limitations from the relational world, do we? Wouldn't other document datastores also allow to persist the elements' order? A List expresses the ordering requirement by contract; if you map a > relation as "Collection" I wage you're not interested in the order, > but you're rather more interested in accepting a wide range of > implementations, some of which might ignore the ordering requirement. > By doing so, you're explicitly telling both ORM and your other code > interacting with the model that ignoring the order is acceptable. > BTW I suspect mapping things as a generic Collection is a very unusual > (or lazy) choice; I don't remember ever using it as it's quite > ambiguous, and there's no way any specification diagram will lead you > to recommend using a Collection (other than cleanly and explicitly > wanting to express you don't care about ordering, nor other properties > like uniqueness...) By exposing a Collection, you're not telling the order isn't important, and certainly not that it can change for no reason (which is our concern here). In fact, you're not telling anything about the order. By exposing a List, you're telling more than just "the order is important". What you're telling is "the order can be managed explicitly by an external actor". Also, you're telling "random access is possible" (not necessarily efficient, but possible). So while I probably wouldn't bother myself, I can see why someone would choose Collection over List: to avoid unnecessarily exposing promises to users. You could add documentation on a getter stating what the expected ordering is (and, frankly, it may be relevant even with a List: how would you translate "the invoices are ordered by issuing date" in terms of a Java interface?). But what you cannot (or at least, shouldn't) do is contradicting the interfaces you expose ("yeah, I'm exposing a List because elements are ordered explicitly since we only ever add one at the end, but please be nice and don't try random access, it's a very long linked list"). And no, I don't consider that "instanceof RandomAccess" on the client side would be a clean solution... I'm not saying "it's super important, a critical use case, we can't ship a new release without this, let's spend 3 months working on it". I'm just saying it may be relevant for other collection types, so if we do it for lists, and if it's not much more difficult/inefficient to do it for other collection types, why wouldn't we? Cheers, Yoann Rodi?re Hibernate NoORM Team On 13 January 2017 at 15:26, Sanne Grinovero wrote: > Hi Yoann, > > while you might be using a specific implementation when persisting > your new entities, when you're loading the object back from the > database how is Hibernate supposed to know > A) which implementation you want it to use > B) which order to use, if you didn't map e.g. an order column to > store the ordering information (MongoDB not needing a strategy is an > exception) > > The entity model expresses the intent of the end user, but also it > expresses its requirements which will be taken into account by ORM > when it needs to provide an implementation for the "Collection" > interface. > > A List expresses the ordering requirement by contract; if you map a > relation as "Collection" I wage you're not interested in the order, > but you're rather more interested in accepting a wide range of > implementations, some of which might ignore the ordering requirement. > By doing so, you're explicitly telling both ORM and your other code > interacting with the model that ignoring the order is acceptable. > > BTW I suspect mapping things as a generic Collection is a very unusual > (or lazy) choice; I don't remember ever using it as it's quite > ambiguous, and there's no way any specification diagram will lead you > to recommend using a Collection (other than cleanly and explicitly > wanting to express you don't care about ordering, nor other properties > like uniqueness...) > > Thanks, > Sanne > > > On 13 January 2017 at 13:29, Yoann Rodiere wrote: > >> I think it's a reasonable expectation, as long as we're talking > >> specifically about mapping a *List* and not just a generic Collection. > > > > > > Ah, this topic again :) I know I'll be all lone, but I'll try anyway! > > > > If we do it for List, and unless there are technical issues that prevent > us > > from doing so, I would be in favor of doing it for any kind of > collection. > > > > In Collections, the fact that iteration order is deterministic is mostly > up > > to the implementation, which is different from saying it's not > > deterministic. From the javadoc for Collection#iterator(): > > > >> There are no guarantees concerning the order in which the elements are > >> returned > >> (unless this collection is an instance of some class that provides a > >> guarantee). > > > > > > Deterministic, and even predictable order is not exclusive to List, > either: > > for instance, LinkedHashSet is not a List, it has a specific iteration > > order, but there is nothing in its implemented interfaces (Collection, > Set) > > that defines this order. > > > > My point is, we can't rely on the implemented interface to decide whether > > the iteration order is important or not, so we may as well decide it is > > always important. Unless there are annoying technical challenges, of > course. > > > > Yoann Rodi?re > > Software Engineer > > Red Hat / Hibernate NoORM Team > > > > On 13 January 2017 at 13:48, Sanne Grinovero > wrote: > >> > >> I think it's a reasonable expectation, as long as we're talking > >> specifically about mapping a *List* and not just a generic Collection. > >> > >> On 13 January 2017 at 12:18, Davide D'Alto > wrote: > >> > Hi, > >> > it seems that when using Collection of elements in MongoDB, users > >> > expect to have the elements in the same order as in the db. You can > >> > see the question on the forum here: > >> > > >> > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903& > p=2491218#p2491218 > >> > > >> > I also found this StackOverflow question: > >> > > >> > http://stackoverflow.com/questions/9013916/do-arrays- > stored-in-mongodb-keep-their-order > >> > > >> > What do you think? Is it something that we should support? > >> > > >> > 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 sanne at hibernate.org Fri Jan 13 10:54:47 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 13 Jan 2017 15:54:47 +0000 Subject: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB In-Reply-To: References: Message-ID: On 13 January 2017 at 15:30, Yoann Rodiere wrote: > Hi Sanne, > >> >> while you might be using a specific implementation when persisting >> your new entities, when you're loading the object back from the >> database how is Hibernate supposed to know >> A) which implementation you want it to use > > Ok, that's true for most collection interfaces, but I'm not sure I > understand why what Hibernate can guess is relevant here. Users are free to > use custom collection types, at least in ORM. Is it not the case with OGM? > Will it never be possible? Sure, OGM should (eventually?) be able to do the same as ORM. But in this case we're not talking about the case in which you use a custom collection; my question is if you map a "Collection" with nothing else than a - for example - @OneToMany annotation, when you load it Hibernate core (OGM and/or ORM) will not use the same collection implementation which you used when you stored the object. > > I thought we were talking about making the collection persister > persist/retrieve the elements in the same order as they were retrieved from > the collection. If it's not the case, then yes, I'm missing something. > > However, even in the specific case of Collection, by default Hibernate > instantiates a List behind the scene for such properties (well, a > PersistentBag, but it's basically a List). Thus if the original collection > had some kind of "ordering memory", at least this would be preserved, > provided we persist elements in the same order we retrieved them from the > original collection. > >> B) which order to use, if you didn't map e.g. an order column to >> store the ordering information (MongoDB not needing a strategy is an >> exception) > > > Well, we don't want to frustrate OGM users with limitations from the > relational world, do we? Wouldn't other document datastores also allow to > persist the elements' order? But why wouldn't you use a List if you need a list? > >> A List expresses the ordering requirement by contract; if you map a >> relation as "Collection" I wage you're not interested in the order, >> but you're rather more interested in accepting a wide range of >> implementations, some of which might ignore the ordering requirement. >> By doing so, you're explicitly telling both ORM and your other code >> interacting with the model that ignoring the order is acceptable. >> BTW I suspect mapping things as a generic Collection is a very unusual >> (or lazy) choice; I don't remember ever using it as it's quite >> ambiguous, and there's no way any specification diagram will lead you >> to recommend using a Collection (other than cleanly and explicitly >> wanting to express you don't care about ordering, nor other properties >> like uniqueness...) > > > By exposing a Collection, you're not telling the order isn't important, and > certainly not that it can change for no reason (which is our concern here). > In fact, you're not telling anything about the order. > By exposing a List, you're telling more than just "the order is important". > What you're telling is "the order can be managed explicitly by an external > actor". Also, you're telling "random access is possible" (not necessarily > efficient, but possible). > > So while I probably wouldn't bother myself, I can see why someone would > choose Collection over List: to avoid unnecessarily exposing promises to > users. I'm a bit lost here. If you don't want to expose an "unnecessary promise" like ordering, why would you need OGM to maintain ordering? Keeping such ordering might come at a non-trivial cost; sometimes just computation wise, sometimes on query complexity and/or space when the order column needs to be stored. It just happens to be cheap and - apparently - "natural" on MongoDB. BTW I'm not even 100% convinced about my previous suggestion about supporting this, as maybe it would set a bad precedent? The risk is that after developing on OGM/MongoDB you start expecting this to work fine on other systems, so from this perspective our API would not have a clear contract on the expectations one should have. > You could add documentation on a getter stating what the expected ordering > is (and, frankly, it may be relevant even with a List: how would you > translate "the invoices are ordered by issuing date" in terms of a Java > interface?). But what you cannot (or at least, shouldn't) do is > contradicting the interfaces you expose ("yeah, I'm exposing a List because > elements are ordered explicitly since we only ever add one at the end, but > please be nice and don't try random access, it's a very long linked list"). > And no, I don't consider that "instanceof RandomAccess" on the client side > would be a clean solution... > > I'm not saying "it's super important, a critical use case, we can't ship a > new release without this, let's spend 3 months working on it". I'm just > saying it may be relevant for other collection types, so if we do it for > lists, and if it's not much more difficult to do it for other collection > types, why wouldn't we? ah, maybe I understand now. If you're proposing we do a similar thing for other specific collection types then sure we can discuss that. I had the impression you wanted to store ordering for properties literally using the *Collection* signature. > > > Yoann Rodi?re > Software Engineer > Red Hat / Hibernate NoORM Team > > On 13 January 2017 at 15:26, Sanne Grinovero wrote: >> >> Hi Yoann, >> >> while you might be using a specific implementation when persisting >> your new entities, when you're loading the object back from the >> database how is Hibernate supposed to know >> A) which implementation you want it to use >> B) which order to use, if you didn't map e.g. an order column to >> store the ordering information (MongoDB not needing a strategy is an >> exception) >> >> The entity model expresses the intent of the end user, but also it >> expresses its requirements which will be taken into account by ORM >> when it needs to provide an implementation for the "Collection" >> interface. >> >> A List expresses the ordering requirement by contract; if you map a >> relation as "Collection" I wage you're not interested in the order, >> but you're rather more interested in accepting a wide range of >> implementations, some of which might ignore the ordering requirement. >> By doing so, you're explicitly telling both ORM and your other code >> interacting with the model that ignoring the order is acceptable. >> >> BTW I suspect mapping things as a generic Collection is a very unusual >> (or lazy) choice; I don't remember ever using it as it's quite >> ambiguous, and there's no way any specification diagram will lead you >> to recommend using a Collection (other than cleanly and explicitly >> wanting to express you don't care about ordering, nor other properties >> like uniqueness...) >> >> Thanks, >> Sanne >> >> >> On 13 January 2017 at 13:29, Yoann Rodiere wrote: >> >> I think it's a reasonable expectation, as long as we're talking >> >> specifically about mapping a *List* and not just a generic Collection. >> > >> > >> > Ah, this topic again :) I know I'll be all lone, but I'll try anyway! >> > >> > If we do it for List, and unless there are technical issues that prevent >> > us >> > from doing so, I would be in favor of doing it for any kind of >> > collection. >> > >> > In Collections, the fact that iteration order is deterministic is mostly >> > up >> > to the implementation, which is different from saying it's not >> > deterministic. From the javadoc for Collection#iterator(): >> > >> >> There are no guarantees concerning the order in which the elements are >> >> returned >> >> (unless this collection is an instance of some class that provides a >> >> guarantee). >> > >> > >> > Deterministic, and even predictable order is not exclusive to List, >> > either: >> > for instance, LinkedHashSet is not a List, it has a specific iteration >> > order, but there is nothing in its implemented interfaces (Collection, >> > Set) >> > that defines this order. >> > >> > My point is, we can't rely on the implemented interface to decide >> > whether >> > the iteration order is important or not, so we may as well decide it is >> > always important. Unless there are annoying technical challenges, of >> > course. >> > >> > Yoann Rodi?re >> > Software Engineer >> > Red Hat / Hibernate NoORM Team >> > >> > On 13 January 2017 at 13:48, Sanne Grinovero >> > wrote: >> >> >> >> I think it's a reasonable expectation, as long as we're talking >> >> specifically about mapping a *List* and not just a generic Collection. >> >> >> >> On 13 January 2017 at 12:18, Davide D'Alto >> >> wrote: >> >> > Hi, >> >> > it seems that when using Collection of elements in MongoDB, users >> >> > expect to have the elements in the same order as in the db. You can >> >> > see the question on the forum here: >> >> > >> >> > >> >> > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903&p=2491218#p2491218 >> >> > >> >> > I also found this StackOverflow question: >> >> > >> >> > >> >> > http://stackoverflow.com/questions/9013916/do-arrays-stored-in-mongodb-keep-their-order >> >> > >> >> > What do you think? Is it something that we should support? >> >> > >> >> > 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 yoann at hibernate.org Fri Jan 13 11:47:23 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 13 Jan 2017 17:47:23 +0100 Subject: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB In-Reply-To: References: Message-ID: > > I'm a bit lost here. If you don't want to expose an "unnecessary > promise" like ordering, why would you need OGM to maintain ordering? As explained below: > You could add documentation on a getter stating what the expected ordering > is (and, frankly, it may be relevant even with a List: how would you > translate "the invoices are ordered by issuing date" in terms of a Java > interface?). But what you cannot (or at least, shouldn't) do is > contradicting the interfaces you expose ("yeah, I'm exposing a List because > elements are ordered explicitly since we only ever add one at the end, but > please be nice and don't try random access, it's a very long linked list"). > In my example, ordering *was* necessary (since we state that invoices are ordered by issuing date). What wasn't necessary was all the other contracts exposed by List ("you can do random access", "you can manage ordering explicitly", etc.), which is why someone may not want to use a List. In the real world I guess that people who find such thing annoying will have several layers of abstraction on top of their entities anyway, but still. ah, maybe I understand now. If you're proposing we do a similar thing > for other specific collection types then sure we can discuss that. I > had the impression you wanted to store ordering for properties > literally using the *Collection* signature. Well, I *also* wanted to store ordering for those, as long as "storing the ordering" only means putting the elements in the correct order in the resulting document. But I'll be happy if we do it only for the sake of custom collection types, since I suspect it means we will also do it for the default types :) By the way, a property can have a Collection signature and *also* have a custom type, it's not mutually exclusive. Actually, there's even an example in Hibernate ORM tests (and documentation, apparently): //tag::collections-custom-collection-mapping-example[] @Entity(name = "Person") public static class Person { @Id private Long id; @OneToMany(cascade = CascadeType.ALL) @CollectionType( type = "org.hibernate.userguide. collections.type.QueueType") private Collection phones = new LinkedList<>(); //Getters and setters are omitted for brevity //end::collections-custom-collection-mapping-example[] public Person() { } public Person(Long id) { this.id = id; } public Queue getPhones() { return (Queue) phones; } //tag::collections-custom-collection-mapping-example[] } Keeping such ordering might come at a non-trivial cost; sometimes just > computation wise, sometimes on query complexity and/or space when the > order column needs to be stored. It just happens to be cheap and - > apparently - "natural" on MongoDB. Sure, we should only do it where it's possible efficiently. BTW I'm not even 100% convinced about my previous suggestion about > supporting this, as maybe it would set a bad precedent? > The risk is that after developing on OGM/MongoDB you start expecting > this to work fine on other systems, so from this perspective our API > would not have a clear contract on the expectations one should have. True... On the other hand, not implementing something that *is* efficient for MongoDB would be annoying for users, too. And more rightly so. Also, it would require a fair bit of bad faith from users to blame us for not implementing an unspecified behavior... even if other dialects do implement it. If we really want to have a clear contract, it means we have to explicitly state somewhere that ordering is undefined unless one is using @OrderColumn / @OrderBy. If we really want to do this, we may as well add "unless you're using a document database" or something like this? Yoann Rodi?re Hibernate NoORM Team On 13 January 2017 at 16:54, Sanne Grinovero wrote: > On 13 January 2017 at 15:30, Yoann Rodiere wrote: > > Hi Sanne, > > > >> > >> while you might be using a specific implementation when persisting > >> your new entities, when you're loading the object back from the > >> database how is Hibernate supposed to know > >> A) which implementation you want it to use > > > > Ok, that's true for most collection interfaces, but I'm not sure I > > understand why what Hibernate can guess is relevant here. Users are free > to > > use custom collection types, at least in ORM. Is it not the case with > OGM? > > Will it never be possible? > > Sure, OGM should (eventually?) be able to do the same as ORM. > > But in this case we're not talking about the case in which you use a > custom collection; my question is if you map a "Collection" with > nothing else than a - for example - @OneToMany annotation, when you > load it Hibernate core (OGM and/or ORM) will not use the same > collection implementation which you used when you stored the object. > > > > > I thought we were talking about making the collection persister > > persist/retrieve the elements in the same order as they were retrieved > from > > the collection. If it's not the case, then yes, I'm missing something. > > > > However, even in the specific case of Collection, by default Hibernate > > instantiates a List behind the scene for such properties (well, a > > PersistentBag, but it's basically a List). Thus if the original > collection > > had some kind of "ordering memory", at least this would be preserved, > > provided we persist elements in the same order we retrieved them from the > > original collection. > > > >> B) which order to use, if you didn't map e.g. an order column to > >> store the ordering information (MongoDB not needing a strategy is an > >> exception) > > > > > > Well, we don't want to frustrate OGM users with limitations from the > > relational world, do we? Wouldn't other document datastores also allow to > > persist the elements' order? > > But why wouldn't you use a List if you need a list? > > > > >> A List expresses the ordering requirement by contract; if you map a > >> relation as "Collection" I wage you're not interested in the order, > >> but you're rather more interested in accepting a wide range of > >> implementations, some of which might ignore the ordering requirement. > >> By doing so, you're explicitly telling both ORM and your other code > >> interacting with the model that ignoring the order is acceptable. > >> BTW I suspect mapping things as a generic Collection is a very unusual > >> (or lazy) choice; I don't remember ever using it as it's quite > >> ambiguous, and there's no way any specification diagram will lead you > >> to recommend using a Collection (other than cleanly and explicitly > >> wanting to express you don't care about ordering, nor other properties > >> like uniqueness...) > > > > > > By exposing a Collection, you're not telling the order isn't important, > and > > certainly not that it can change for no reason (which is our concern > here). > > In fact, you're not telling anything about the order. > > By exposing a List, you're telling more than just "the order is > important". > > What you're telling is "the order can be managed explicitly by an > external > > actor". Also, you're telling "random access is possible" (not necessarily > > efficient, but possible). > > > > So while I probably wouldn't bother myself, I can see why someone would > > choose Collection over List: to avoid unnecessarily exposing promises to > > users. > > I'm a bit lost here. If you don't want to expose an "unnecessary > promise" like ordering, why would you need OGM to maintain ordering? > > Keeping such ordering might come at a non-trivial cost; sometimes just > computation wise, sometimes on query complexity and/or space when the > order column needs to be stored. It just happens to be cheap and - > apparently - "natural" on MongoDB. > > BTW I'm not even 100% convinced about my previous suggestion about > supporting this, as maybe it would set a bad precedent? > The risk is that after developing on OGM/MongoDB you start expecting > this to work fine on other systems, so from this perspective our API > would not have a clear contract on the expectations one should have. > > > > You could add documentation on a getter stating what the expected > ordering > > is (and, frankly, it may be relevant even with a List: how would you > > translate "the invoices are ordered by issuing date" in terms of a Java > > interface?). But what you cannot (or at least, shouldn't) do is > > contradicting the interfaces you expose ("yeah, I'm exposing a List > because > > elements are ordered explicitly since we only ever add one at the end, > but > > please be nice and don't try random access, it's a very long linked > list"). > > And no, I don't consider that "instanceof RandomAccess" on the client > side > > would be a clean solution... > > > > I'm not saying "it's super important, a critical use case, we can't ship > a > > new release without this, let's spend 3 months working on it". I'm just > > saying it may be relevant for other collection types, so if we do it for > > lists, and if it's not much more difficult to do it for other collection > > types, why wouldn't we? > > ah, maybe I understand now. If you're proposing we do a similar thing > for other specific collection types then sure we can discuss that. I > had the impression you wanted to store ordering for properties > literally using the *Collection* signature. > > > > > > > Yoann Rodi?re > > Software Engineer > > Red Hat / Hibernate NoORM Team > > > > On 13 January 2017 at 15:26, Sanne Grinovero > wrote: > >> > >> Hi Yoann, > >> > >> while you might be using a specific implementation when persisting > >> your new entities, when you're loading the object back from the > >> database how is Hibernate supposed to know > >> A) which implementation you want it to use > >> B) which order to use, if you didn't map e.g. an order column to > >> store the ordering information (MongoDB not needing a strategy is an > >> exception) > >> > >> The entity model expresses the intent of the end user, but also it > >> expresses its requirements which will be taken into account by ORM > >> when it needs to provide an implementation for the "Collection" > >> interface. > >> > >> A List expresses the ordering requirement by contract; if you map a > >> relation as "Collection" I wage you're not interested in the order, > >> but you're rather more interested in accepting a wide range of > >> implementations, some of which might ignore the ordering requirement. > >> By doing so, you're explicitly telling both ORM and your other code > >> interacting with the model that ignoring the order is acceptable. > >> > >> BTW I suspect mapping things as a generic Collection is a very unusual > >> (or lazy) choice; I don't remember ever using it as it's quite > >> ambiguous, and there's no way any specification diagram will lead you > >> to recommend using a Collection (other than cleanly and explicitly > >> wanting to express you don't care about ordering, nor other properties > >> like uniqueness...) > >> > >> Thanks, > >> Sanne > >> > >> > >> On 13 January 2017 at 13:29, Yoann Rodiere wrote: > >> >> I think it's a reasonable expectation, as long as we're talking > >> >> specifically about mapping a *List* and not just a generic > Collection. > >> > > >> > > >> > Ah, this topic again :) I know I'll be all lone, but I'll try anyway! > >> > > >> > If we do it for List, and unless there are technical issues that > prevent > >> > us > >> > from doing so, I would be in favor of doing it for any kind of > >> > collection. > >> > > >> > In Collections, the fact that iteration order is deterministic is > mostly > >> > up > >> > to the implementation, which is different from saying it's not > >> > deterministic. From the javadoc for Collection#iterator(): > >> > > >> >> There are no guarantees concerning the order in which the elements > are > >> >> returned > >> >> (unless this collection is an instance of some class that provides a > >> >> guarantee). > >> > > >> > > >> > Deterministic, and even predictable order is not exclusive to List, > >> > either: > >> > for instance, LinkedHashSet is not a List, it has a specific iteration > >> > order, but there is nothing in its implemented interfaces (Collection, > >> > Set) > >> > that defines this order. > >> > > >> > My point is, we can't rely on the implemented interface to decide > >> > whether > >> > the iteration order is important or not, so we may as well decide it > is > >> > always important. Unless there are annoying technical challenges, of > >> > course. > >> > > >> > Yoann Rodi?re > >> > Software Engineer > >> > Red Hat / Hibernate NoORM Team > >> > > >> > On 13 January 2017 at 13:48, Sanne Grinovero > >> > wrote: > >> >> > >> >> I think it's a reasonable expectation, as long as we're talking > >> >> specifically about mapping a *List* and not just a generic > Collection. > >> >> > >> >> On 13 January 2017 at 12:18, Davide D'Alto > >> >> wrote: > >> >> > Hi, > >> >> > it seems that when using Collection of elements in MongoDB, users > >> >> > expect to have the elements in the same order as in the db. You can > >> >> > see the question on the forum here: > >> >> > > >> >> > > >> >> > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903& > p=2491218#p2491218 > >> >> > > >> >> > I also found this StackOverflow question: > >> >> > > >> >> > > >> >> > http://stackoverflow.com/questions/9013916/do-arrays- > stored-in-mongodb-keep-their-order > >> >> > > >> >> > What do you think? Is it something that we should support? > >> >> > > >> >> > 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 steve at hibernate.org Sat Jan 14 15:21:44 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 14 Jan 2017 20:21:44 +0000 Subject: [hibernate-dev] MultiCollectionOwnerIdentifierLoadAccess? Message-ID: I'm curious if anyone sees value in a MultiCollectionOwnerIdentifierLoadAccess variant (or some more concise name) of MultiIdentifierLoadAccess for bulk initializing a collection role based on their owner ids? From sanne at hibernate.org Mon Jan 16 04:17:39 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 16 Jan 2017 09:17:39 +0000 Subject: [hibernate-dev] [Hibernate ORM] Javadoc missing in Maven repositories Message-ID: Hi all, I noticed some people [1] asking why we don't deploy the javadoc jarfile in Maven repositories. That's very helpful for IDE integrations; I never noticed - nor am I sure how to verify - as my IDE falls back to using the sources. Knowing how reliable Maven Central's directory listing are, I'm not even sure how to double check if this is true or at which level things might have gone wrong :) So I didn't open a JIRA yet. Someone more familiar with the ORM build could double check and take ownership of this please? Thanks, Sanne 1 - https://developer.jboss.org/wiki/MavenGettingStarted-Users?et=watches.email.document_comment#comment-16211 From guillaume.smet at gmail.com Mon Jan 16 04:24:48 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 16 Jan 2017 10:24:48 +0100 Subject: [hibernate-dev] [Hibernate ORM] Javadoc missing in Maven repositories In-Reply-To: References: Message-ID: Hi, It's an issue we have for several of our projects (ie also on NoORM projects), namely those building the javadoc in an aggregated task at the end of the build. It bugged me a little at first but as Eclipse defaults to using source anyway, I didn't care that much about this. It might be a good idea to fix it if it does change something for our users. -- Guillaume On Mon, Jan 16, 2017 at 10:17 AM, Sanne Grinovero wrote: > Hi all, > I noticed some people [1] asking why we don't deploy the javadoc > jarfile in Maven repositories. > > That's very helpful for IDE integrations; I never noticed - nor am I > sure how to verify - as my IDE falls back to using the sources. > > Knowing how reliable Maven Central's directory listing are, I'm not > even sure how to double check if this is true or at which level things > might have gone wrong :) > So I didn't open a JIRA yet. Someone more familiar with the ORM build > could double check and take ownership of this please? > > Thanks, > Sanne > > 1 - https://developer.jboss.org/wiki/MavenGettingStarted- > Users?et=watches.email.document_comment#comment-16211 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Jan 16 04:58:08 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 16 Jan 2017 09:58:08 +0000 Subject: [hibernate-dev] MultiCollectionOwnerIdentifierLoadAccess? In-Reply-To: References: Message-ID: It sounds interesting but I'm not sure I understand you. Could you elaborate please? Isn't this the same "thing" which I'd trigger when attempting to access a member of a non-initialized & attached collection? Thanks, Sanne On 14 January 2017 at 20:21, Steve Ebersole wrote: > I'm curious if anyone sees value in > a MultiCollectionOwnerIdentifierLoadAccess variant (or some more concise > name) of MultiIdentifierLoadAccess for bulk initializing a collection role > based on their owner ids? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Mon Jan 16 07:26:26 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 16 Jan 2017 12:26:26 +0000 Subject: [hibernate-dev] ORM 5.2.x: Deprecation of some Query methods? Message-ID: Some methods from org.hibernate.Query like - org.hibernate.Query.scroll() - org.hibernate.Query.iterate() are now flagged as "deprecated method usage" in the IDE as they are defined on the deprecated interface `org.hibernate.Query`, which is being replaced by `org.hibernate.query.Query`. The new interface extends the old one, I guess for drop-in compatibility reasons, however it doesn't explicitly re-define such methods making me unsure about their destiny. Are these really meant to be deprecated? Thanks, Sanne From steve at hibernate.org Mon Jan 16 09:41:35 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 16 Jan 2017 14:41:35 +0000 Subject: [hibernate-dev] Unbound type parameters and JPA metamodel Message-ID: We are having an interesting discussion on https://github.com/hibernate/hibernate-orm/pull/1723 in regards to ${subject} I do think this is something we need to clarify within the EG. One thing I'd like to do is to have a public poll to see how people tend to view this. The main reason being that I'd like to have a public opinion as opposed to simply following vendor-X's solution "just because". That's easier if we can show public tendency. I'll write up a blog post explaining the situation and then I'd like to see us blast this out via twitter, G+, etc to get people to respond. From steve at hibernate.org Mon Jan 16 09:43:33 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 16 Jan 2017 14:43:33 +0000 Subject: [hibernate-dev] [Hibernate ORM] Javadoc missing in Maven repositories In-Reply-To: References: Message-ID: I personally think that publishing Javadocs per artifact is silly so I do not do it for ORM. Its a limiting view. We already publish an "aggregated" Javadoc that (again imo) is far better. As you point out Sanne, we do publish sources to repo which at the IDE level is MUCH better On Mon, Jan 16, 2017 at 3:28 AM Guillaume Smet wrote: > Hi, > > It's an issue we have for several of our projects (ie also on NoORM > projects), namely those building the javadoc in an aggregated task at the > end of the build. > > It bugged me a little at first but as Eclipse defaults to using source > anyway, I didn't care that much about this. It might be a good idea to fix > it if it does change something for our users. > > -- > Guillaume > > On Mon, Jan 16, 2017 at 10:17 AM, Sanne Grinovero > wrote: > > > Hi all, > > I noticed some people [1] asking why we don't deploy the javadoc > > jarfile in Maven repositories. > > > > That's very helpful for IDE integrations; I never noticed - nor am I > > sure how to verify - as my IDE falls back to using the sources. > > > > Knowing how reliable Maven Central's directory listing are, I'm not > > even sure how to double check if this is true or at which level things > > might have gone wrong :) > > So I didn't open a JIRA yet. Someone more familiar with the ORM build > > could double check and take ownership of this please? > > > > Thanks, > > Sanne > > > > 1 - https://developer.jboss.org/wiki/MavenGettingStarted- > > Users?et=watches.email.document_comment#comment-16211 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Jan 16 10:06:31 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 16 Jan 2017 15:06:31 +0000 Subject: [hibernate-dev] MultiCollectionOwnerIdentifierLoadAccess? In-Reply-To: References: Message-ID: Sanne, yes and no. It depends on your fetch strategy for that collection. To review you have: 1. SELECT (eager or lazy) 2. JOIN (eager) 3. BATCH (lazy) 4. SUBSELECT (lazy) To illustrate let's consider a familiar collection role: Order#lineItems. I'll only consider LAZY scenarios, since eager would make no sense here... SUBSELECT comes closest to what you describe. That loads *all* collections of a given role that are attached to the Session, although it has no idea about which are initialized and which are not. If you have associated 50 Order entities with the Session, accessing one collection forces loading of all of them. But it queries for the collection elements for all 50, regardless of whether one or more were already initialized. BATCH is similar but limits the collections initialized to a certain number which it then queries for by FK. This approach does actually consider which collections have already been initialized and excludes them from the db query. SELECT is typical n+1. The collections are initialized one by one as they are accessed. What I propose is different from all of these, but BATCH comes closest (just like we saw with entity multi-id loading). The idea is to allow the application to control the batches. It would look something like: session.byMultipleCollectionKeys( "com.acme.Order.lineItems" ).initialize( 1, 2, 3, 4 ); I am not a fan of the `byMultipleCollectionKeys` name. Also, should this be based on the collection key (the FK) or the collection's owner id? Probably the latter makes more sense. But the general idea is that the application knows which collections are needed next and can initialize just those. The method has no return as it works on the collections associated with the Session. On Mon, Jan 16, 2017 at 3:58 AM Sanne Grinovero wrote: > It sounds interesting but I'm not sure I understand you. Could you > elaborate please? Isn't this the same "thing" which I'd trigger when > attempting to access a member of a non-initialized & attached > collection? > > Thanks, > Sanne > > > On 14 January 2017 at 20:21, Steve Ebersole wrote: > > I'm curious if anyone sees value in > > a MultiCollectionOwnerIdentifierLoadAccess variant (or some more concise > > name) of MultiIdentifierLoadAccess for bulk initializing a collection > role > > based on their owner ids? > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Jan 16 10:08:29 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 16 Jan 2017 15:08:29 +0000 Subject: [hibernate-dev] ORM 5.2.x: Deprecation of some Query methods? In-Reply-To: References: Message-ID: Well to be clear these methods are "deprecated" simply by the fact that org.hibernate.Query itself being deprecated. All that said... - #scroll is not going away - #iterate I already started a discussion about earlier on the dev list. I personally would like to do away with it, but that needs to be a group decision depending on how useful that is and how widely used it is (not necessarily the same thing). On Mon, Jan 16, 2017 at 6:31 AM Sanne Grinovero wrote: Some methods from org.hibernate.Query like - org.hibernate.Query.scroll() - org.hibernate.Query.iterate() are now flagged as "deprecated method usage" in the IDE as they are defined on the deprecated interface `org.hibernate.Query`, which is being replaced by `org.hibernate.query.Query`. The new interface extends the old one, I guess for drop-in compatibility reasons, however it doesn't explicitly re-define such methods making me unsure about their destiny. Are these really meant to be deprecated? Thanks, Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Mon Jan 16 10:41:49 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 16 Jan 2017 16:41:49 +0100 Subject: [hibernate-dev] [Hibernate ORM] Javadoc missing in Maven repositories In-Reply-To: References: Message-ID: +1 The source JARs are the important thing here. Just tried out the JavaDoc view in Eclipse for the first time as you're mentioning it. Can't say I find it overly useful nor that I've been missing it for all these years :) 2017-01-16 15:43 GMT+01:00 Steve Ebersole : > I personally think that publishing Javadocs per artifact is silly so I do > not do it for ORM. Its a limiting view. We already publish an > "aggregated" Javadoc that (again imo) is far better. As you point out > Sanne, we do publish sources to repo which at the IDE level is MUCH better > > On Mon, Jan 16, 2017 at 3:28 AM Guillaume Smet > wrote: > >> Hi, >> >> It's an issue we have for several of our projects (ie also on NoORM >> projects), namely those building the javadoc in an aggregated task at the >> end of the build. >> >> It bugged me a little at first but as Eclipse defaults to using source >> anyway, I didn't care that much about this. It might be a good idea to fix >> it if it does change something for our users. >> >> -- >> Guillaume >> >> On Mon, Jan 16, 2017 at 10:17 AM, Sanne Grinovero >> wrote: >> >> > Hi all, >> > I noticed some people [1] asking why we don't deploy the javadoc >> > jarfile in Maven repositories. >> > >> > That's very helpful for IDE integrations; I never noticed - nor am I >> > sure how to verify - as my IDE falls back to using the sources. >> > >> > Knowing how reliable Maven Central's directory listing are, I'm not >> > even sure how to double check if this is true or at which level things >> > might have gone wrong :) >> > So I didn't open a JIRA yet. Someone more familiar with the ORM build >> > could double check and take ownership of this please? >> > >> > Thanks, >> > Sanne >> > >> > 1 - https://developer.jboss.org/wiki/MavenGettingStarted- >> > Users?et=watches.email.document_comment#comment-16211 >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From andrea at hibernate.org Mon Jan 16 10:55:35 2017 From: andrea at hibernate.org (andrea boriero) Date: Mon, 16 Jan 2017 15:55:35 +0000 Subject: [hibernate-dev] [Hibernate ORM] Javadoc missing in Maven repositories In-Reply-To: References: Message-ID: I agree with Steve and Gunnar. On 16 January 2017 at 15:41, Gunnar Morling wrote: > +1 The source JARs are the important thing here. > > Just tried out the JavaDoc view in Eclipse for the first time as > you're mentioning it. Can't say I find it overly useful nor that I've > been missing it for all these years :) > > 2017-01-16 15:43 GMT+01:00 Steve Ebersole : > > I personally think that publishing Javadocs per artifact is silly so I do > > not do it for ORM. Its a limiting view. We already publish an > > "aggregated" Javadoc that (again imo) is far better. As you point out > > Sanne, we do publish sources to repo which at the IDE level is MUCH > better > > > > On Mon, Jan 16, 2017 at 3:28 AM Guillaume Smet > > > wrote: > > > >> Hi, > >> > >> It's an issue we have for several of our projects (ie also on NoORM > >> projects), namely those building the javadoc in an aggregated task at > the > >> end of the build. > >> > >> It bugged me a little at first but as Eclipse defaults to using source > >> anyway, I didn't care that much about this. It might be a good idea to > fix > >> it if it does change something for our users. > >> > >> -- > >> Guillaume > >> > >> On Mon, Jan 16, 2017 at 10:17 AM, Sanne Grinovero > >> wrote: > >> > >> > Hi all, > >> > I noticed some people [1] asking why we don't deploy the javadoc > >> > jarfile in Maven repositories. > >> > > >> > That's very helpful for IDE integrations; I never noticed - nor am I > >> > sure how to verify - as my IDE falls back to using the sources. > >> > > >> > Knowing how reliable Maven Central's directory listing are, I'm not > >> > even sure how to double check if this is true or at which level things > >> > might have gone wrong :) > >> > So I didn't open a JIRA yet. Someone more familiar with the ORM build > >> > could double check and take ownership of this please? > >> > > >> > Thanks, > >> > Sanne > >> > > >> > 1 - https://developer.jboss.org/wiki/MavenGettingStarted- > >> > Users?et=watches.email.document_comment#comment-16211 > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Jan 16 11:11:29 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 16 Jan 2017 16:11:29 +0000 Subject: [hibernate-dev] [Hibernate ORM] Javadoc missing in Maven repositories In-Reply-To: References: Message-ID: I'm not sure if the agreement is in wanting to keep the status quo, or if it's simply not worth our time to chase such things. In other words: may I suggest to such users that we'd accept a pull request, or you'd rather not waste bandwidth during releases? Either way is fine by me, but I wonder if users from other IDEs and tools are getting left in the dark for something which we'd have a script do. On 16 January 2017 at 15:55, andrea boriero wrote: > I agree with Steve and Gunnar. > > On 16 January 2017 at 15:41, Gunnar Morling wrote: > >> +1 The source JARs are the important thing here. >> >> Just tried out the JavaDoc view in Eclipse for the first time as >> you're mentioning it. Can't say I find it overly useful nor that I've >> been missing it for all these years :) >> >> 2017-01-16 15:43 GMT+01:00 Steve Ebersole : >> > I personally think that publishing Javadocs per artifact is silly so I do >> > not do it for ORM. Its a limiting view. We already publish an >> > "aggregated" Javadoc that (again imo) is far better. As you point out >> > Sanne, we do publish sources to repo which at the IDE level is MUCH >> better >> > >> > On Mon, Jan 16, 2017 at 3:28 AM Guillaume Smet > > >> > wrote: >> > >> >> Hi, >> >> >> >> It's an issue we have for several of our projects (ie also on NoORM >> >> projects), namely those building the javadoc in an aggregated task at >> the >> >> end of the build. >> >> >> >> It bugged me a little at first but as Eclipse defaults to using source >> >> anyway, I didn't care that much about this. It might be a good idea to >> fix >> >> it if it does change something for our users. >> >> >> >> -- >> >> Guillaume >> >> >> >> On Mon, Jan 16, 2017 at 10:17 AM, Sanne Grinovero >> >> wrote: >> >> >> >> > Hi all, >> >> > I noticed some people [1] asking why we don't deploy the javadoc >> >> > jarfile in Maven repositories. >> >> > >> >> > That's very helpful for IDE integrations; I never noticed - nor am I >> >> > sure how to verify - as my IDE falls back to using the sources. >> >> > >> >> > Knowing how reliable Maven Central's directory listing are, I'm not >> >> > even sure how to double check if this is true or at which level things >> >> > might have gone wrong :) >> >> > So I didn't open a JIRA yet. Someone more familiar with the ORM build >> >> > could double check and take ownership of this please? >> >> > >> >> > Thanks, >> >> > Sanne >> >> > >> >> > 1 - https://developer.jboss.org/wiki/MavenGettingStarted- >> >> > Users?et=watches.email.document_comment#comment-16211 >> >> > _______________________________________________ >> >> > hibernate-dev mailing list >> >> > hibernate-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Jan 16 13:49:34 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 16 Jan 2017 18:49:34 +0000 Subject: [hibernate-dev] [Hibernate ORM] Javadoc missing in Maven repositories In-Reply-To: References: Message-ID: I think we are all saying that we personally find it far more useful to have the sources (which have the Javadoc btw ;) available in the IDE compared to having just the Javadoc. It's not a question of easy to generate/publish, it's a question of what is useful. If someone finds it useful they can certainly submit a PR And btw I use IntelliJ which has had this forever. I have used it in the past and as I have stated I find it less useful than having the sources available. On Mon, Jan 16, 2017, 10:25 AM Sanne Grinovero wrote: > I'm not sure if the agreement is in wanting to keep the status quo, or > if it's simply not worth our time to chase such things. In other > words: may I suggest to such users that we'd accept a pull request, or > you'd rather not waste bandwidth during releases? > > Either way is fine by me, but I wonder if users from other IDEs and > tools are getting left in the dark for something which we'd have a > script do. > > On 16 January 2017 at 15:55, andrea boriero wrote: > > I agree with Steve and Gunnar. > > > > On 16 January 2017 at 15:41, Gunnar Morling > wrote: > > > >> +1 The source JARs are the important thing here. > >> > >> Just tried out the JavaDoc view in Eclipse for the first time as > >> you're mentioning it. Can't say I find it overly useful nor that I've > >> been missing it for all these years :) > >> > >> 2017-01-16 15:43 GMT+01:00 Steve Ebersole : > >> > I personally think that publishing Javadocs per artifact is silly so > I do > >> > not do it for ORM. Its a limiting view. We already publish an > >> > "aggregated" Javadoc that (again imo) is far better. As you point out > >> > Sanne, we do publish sources to repo which at the IDE level is MUCH > >> better > >> > > >> > On Mon, Jan 16, 2017 at 3:28 AM Guillaume Smet < > guillaume.smet at gmail.com > >> > > >> > wrote: > >> > > >> >> Hi, > >> >> > >> >> It's an issue we have for several of our projects (ie also on NoORM > >> >> projects), namely those building the javadoc in an aggregated task at > >> the > >> >> end of the build. > >> >> > >> >> It bugged me a little at first but as Eclipse defaults to using > source > >> >> anyway, I didn't care that much about this. It might be a good idea > to > >> fix > >> >> it if it does change something for our users. > >> >> > >> >> -- > >> >> Guillaume > >> >> > >> >> On Mon, Jan 16, 2017 at 10:17 AM, Sanne Grinovero < > sanne at hibernate.org> > >> >> wrote: > >> >> > >> >> > Hi all, > >> >> > I noticed some people [1] asking why we don't deploy the javadoc > >> >> > jarfile in Maven repositories. > >> >> > > >> >> > That's very helpful for IDE integrations; I never noticed - nor am > I > >> >> > sure how to verify - as my IDE falls back to using the sources. > >> >> > > >> >> > Knowing how reliable Maven Central's directory listing are, I'm not > >> >> > even sure how to double check if this is true or at which level > things > >> >> > might have gone wrong :) > >> >> > So I didn't open a JIRA yet. Someone more familiar with the ORM > build > >> >> > could double check and take ownership of this please? > >> >> > > >> >> > Thanks, > >> >> > Sanne > >> >> > > >> >> > 1 - https://developer.jboss.org/wiki/MavenGettingStarted- > >> >> > Users?et=watches.email.document_comment#comment-16211 > >> >> > _______________________________________________ > >> >> > hibernate-dev mailing list > >> >> > hibernate-dev at lists.jboss.org > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> > > >> >> _______________________________________________ > >> >> hibernate-dev mailing list > >> >> hibernate-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Jan 16 13:53:42 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 16 Jan 2017 18:53:42 +0000 Subject: [hibernate-dev] [Hibernate ORM] Javadoc missing in Maven repositories In-Reply-To: References: Message-ID: On 16 January 2017 at 18:49, Steve Ebersole wrote: > I think we are all saying that we personally find it far more useful to have > the sources (which have the Javadoc btw ;) available in the IDE compared to > having just the Javadoc. I definitely agree but it's not an exclusive either/or ;) > It's not a question of easy to generate/publish, it's a question of what is > useful. If someone finds it useful they can certainly submit a PR Cool, that's what I'll tell them then. Thanks > > And btw I use IntelliJ which has had this forever. I have used it in the > past and as I have stated I find it less useful than having the sources > available. > > > On Mon, Jan 16, 2017, 10:25 AM Sanne Grinovero wrote: >> >> I'm not sure if the agreement is in wanting to keep the status quo, or >> if it's simply not worth our time to chase such things. In other >> words: may I suggest to such users that we'd accept a pull request, or >> you'd rather not waste bandwidth during releases? >> >> Either way is fine by me, but I wonder if users from other IDEs and >> tools are getting left in the dark for something which we'd have a >> script do. >> >> On 16 January 2017 at 15:55, andrea boriero wrote: >> > I agree with Steve and Gunnar. >> > >> > On 16 January 2017 at 15:41, Gunnar Morling >> > wrote: >> > >> >> +1 The source JARs are the important thing here. >> >> >> >> Just tried out the JavaDoc view in Eclipse for the first time as >> >> you're mentioning it. Can't say I find it overly useful nor that I've >> >> been missing it for all these years :) >> >> >> >> 2017-01-16 15:43 GMT+01:00 Steve Ebersole : >> >> > I personally think that publishing Javadocs per artifact is silly so >> >> > I do >> >> > not do it for ORM. Its a limiting view. We already publish an >> >> > "aggregated" Javadoc that (again imo) is far better. As you point >> >> > out >> >> > Sanne, we do publish sources to repo which at the IDE level is MUCH >> >> better >> >> > >> >> > On Mon, Jan 16, 2017 at 3:28 AM Guillaume Smet >> >> > > >> > >> >> > wrote: >> >> > >> >> >> Hi, >> >> >> >> >> >> It's an issue we have for several of our projects (ie also on NoORM >> >> >> projects), namely those building the javadoc in an aggregated task >> >> >> at >> >> the >> >> >> end of the build. >> >> >> >> >> >> It bugged me a little at first but as Eclipse defaults to using >> >> >> source >> >> >> anyway, I didn't care that much about this. It might be a good idea >> >> >> to >> >> fix >> >> >> it if it does change something for our users. >> >> >> >> >> >> -- >> >> >> Guillaume >> >> >> >> >> >> On Mon, Jan 16, 2017 at 10:17 AM, Sanne Grinovero >> >> >> >> >> >> wrote: >> >> >> >> >> >> > Hi all, >> >> >> > I noticed some people [1] asking why we don't deploy the javadoc >> >> >> > jarfile in Maven repositories. >> >> >> > >> >> >> > That's very helpful for IDE integrations; I never noticed - nor am >> >> >> > I >> >> >> > sure how to verify - as my IDE falls back to using the sources. >> >> >> > >> >> >> > Knowing how reliable Maven Central's directory listing are, I'm >> >> >> > not >> >> >> > even sure how to double check if this is true or at which level >> >> >> > things >> >> >> > might have gone wrong :) >> >> >> > So I didn't open a JIRA yet. Someone more familiar with the ORM >> >> >> > build >> >> >> > could double check and take ownership of this please? >> >> >> > >> >> >> > Thanks, >> >> >> > Sanne >> >> >> > >> >> >> > 1 - https://developer.jboss.org/wiki/MavenGettingStarted- >> >> >> > Users?et=watches.email.document_comment#comment-16211 >> >> >> > _______________________________________________ >> >> >> > hibernate-dev mailing list >> >> >> > hibernate-dev at lists.jboss.org >> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > >> >> >> _______________________________________________ >> >> >> hibernate-dev mailing list >> >> >> hibernate-dev at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> > _______________________________________________ >> >> > hibernate-dev mailing list >> >> > hibernate-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Jan 16 19:06:58 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 17 Jan 2017 00:06:58 +0000 Subject: [hibernate-dev] 6.0 - BasicType resolution Message-ID: Love to get people's thoughts on https://hibernate.atlassian.net/browse/HHH-11391?focusedCommentId=88935&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-88935 From guillaume.smet at gmail.com Tue Jan 17 09:45:46 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 17 Jan 2017 15:45:46 +0100 Subject: [hibernate-dev] Hibernate NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of our biweekly meeting: 15:43 < jbott> Ending meeting. Generating minutes. Be patient :) 15:43 < jbott> Meeting ended Tue Jan 17 14:43:07 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:43 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-01-17-14.04.html 15:43 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-01-17-14.04.txt 15:43 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-01-17-14.04.log.html Cheers, -- Guillaume From davide at hibernate.org Tue Jan 17 11:56:55 2017 From: davide at hibernate.org (Davide D'Alto) Date: Tue, 17 Jan 2017 16:56:55 +0000 Subject: [hibernate-dev] Update Jenkins plugins Message-ID: Hi, there are some plugins to upgrade on Jenkins and it seems they have some non trivial changes. I'll do that on Thursday and hopefully it won't cause too many issues. Thanks, Davideb From guillaume.smet at gmail.com Wed Jan 18 05:28:58 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 18 Jan 2017 11:28:58 +0100 Subject: [hibernate-dev] JDK 9 EA Build 151 is available on java.net In-Reply-To: <243f10fe-3333-8da9-a451-25c0a75ca34a@oracle.com> References: <243f10fe-3333-8da9-a451-25c0a75ca34a@oracle.com> Message-ID: Hi Rory, So our Hibernate Validator test suite was also hit by the annotation processor issue introduced in b151 but I can confirm it's all OK with b152. Thanks! -- Guillaume On Tue, Jan 10, 2017 at 11:29 AM, Rory O'Donnell wrote: > > Hi Sanne, > > Best wishes for the New Year. > > Dalibor and I will be at FOSDEM '17, Brussels 4 & 5 February. Let us > know if you will be there, hopefully we can meet up ! > > *JDK 9 Early Access* b151 is > available on java.net > > There have been a number of fixes to bugs reported by Open Source > projects since the last availability email : > > * JDK-8171377 : Add sun.misc.Unsafe::invokeCleaner > * JDK-8075793 : Source incompatibility for inference using -source 7 > * JDK-8087303 : LSSerializer pretty print does not work anymore > * JDK-8167143 :CLDR timezone parsing does not work for all locales > > Other changes that maybe of interest: > > * JDK-8066474 : Remove the lib/$ARCH directory from Linux and Solaris > images > * JDK-8170428 : Move src.zip to JDK/lib/src.zip > > *JEPs intergrated:* > > * JEP 295 : Ahead-of-Time > Compilation has been integrated in b150. > > *Schedule - Milestones since last availability email * > > * *Feature Extension Complete 22nd of December 2016* > * *Rampdown Started 5th of January 2017 > * > o Phases in which increasing levels of scrutiny are applied to > incoming changes. > o In phase 1, only P1-P3 bugs can be fixed. In phase 2 only > showstopper bugs can be fixed. > > Rgds,Rory > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From rory.odonnell at oracle.com Wed Jan 18 05:42:24 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 18 Jan 2017 10:42:24 +0000 Subject: [hibernate-dev] JDK 9 EA Build 151 is available on java.net In-Reply-To: References: <243f10fe-3333-8da9-a451-25c0a75ca34a@oracle.com> Message-ID: Thanks for the update Guillaume! Rgds,Rory On 18/01/2017 10:28, Guillaume Smet wrote: > Hi Rory, > > So our Hibernate Validator test suite was also hit by the annotation > processor issue introduced in b151 but I can confirm it's all OK with > b152. > > Thanks! > > -- > Guillaume > > On Tue, Jan 10, 2017 at 11:29 AM, Rory O'Donnell > > wrote: > > > Hi Sanne, > > Best wishes for the New Year. > > Dalibor and I will be at FOSDEM '17, Brussels 4 & 5 February. Let us > know if you will be there, hopefully we can meet up ! > > *JDK 9 Early Access* b151 > is > available on java.net > > There have been a number of fixes to bugs reported by Open Source > projects since the last availability email : > > * JDK-8171377 : Add sun.misc.Unsafe::invokeCleaner > * JDK-8075793 : Source incompatibility for inference using -source 7 > * JDK-8087303 : LSSerializer pretty print does not work anymore > * JDK-8167143 :CLDR timezone parsing does not work for all locales > > Other changes that maybe of interest: > > * JDK-8066474 : Remove the lib/$ARCH directory from Linux and > Solaris > images > * JDK-8170428 : Move src.zip to JDK/lib/src.zip > > *JEPs intergrated:* > > * JEP 295 >: Ahead-of-Time > Compilation has been integrated in b150. > > *Schedule - Milestones since last availability email * > > * *Feature Extension Complete 22nd of December 2016* > * *Rampdown Started 5th of January 2017 > * > o Phases in which increasing levels of scrutiny are applied to > incoming changes. > o In phase 1, only P1-P3 bugs can be fixed. In phase 2 only > showstopper bugs can be fixed. > > Rgds,Rory > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From gbadner at redhat.com Wed Jan 18 23:33:17 2017 From: gbadner at redhat.com (Gail Badner) Date: Wed, 18 Jan 2017 23:33:17 -0500 Subject: [hibernate-dev] Preparing to release 5.0.12 and 5.1.4 Message-ID: Please do not push anything to 5.0 or 5.1 branches. Thanks, Gail From andrea at hibernate.org Thu Jan 19 08:53:55 2017 From: andrea at hibernate.org (andrea boriero) Date: Thu, 19 Jan 2017 13:53:55 +0000 Subject: [hibernate-dev] Starting 5.2.7 release Message-ID: Please do not push anything to master branch. Thanks, Andrea From arena.valerie at gmail.com Thu Jan 19 10:51:34 2017 From: arena.valerie at gmail.com (Valerie Arena) Date: Thu, 19 Jan 2017 10:51:34 -0500 Subject: [hibernate-dev] Hibernate ORM Project - Getting Started on "SuitableForNewContributors" Jira Issues Message-ID: Hello, I would like to contribute to Hibernate ORM and would like to work on "SuitableForNewContributors" Jira Issues. How do I get assigned to an issue? Thank You! Valerie Arena https://www.linkedin.com/in/arenavalerie From andrea at hibernate.org Thu Jan 19 11:05:19 2017 From: andrea at hibernate.org (andrea boriero) Date: Thu, 19 Jan 2017 16:05:19 +0000 Subject: [hibernate-dev] Hibernate ORM 5.2.7.Final has been released Message-ID: For details: http://in.relation.to/2017/01/19/hibernate-orm-527-final-release From steve at hibernate.org Thu Jan 19 12:34:56 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 19 Jan 2017 17:34:56 +0000 Subject: [hibernate-dev] 6.0 - Type system Message-ID: We are getting pretty far along on the 6.0 changes and I wanted to start a(nother) discussion about Types in 6.0 to get feedback and thoughts on a few topics. First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types and "persisters"... (a lot of this is the same from pre-6.0, just making things more explicit) JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so let's start there. A JavaTypeDescriptor is a descriptor of a given Java type. That is, it provides Hibernate with information about the Java type. Is it a numeric type? How do we compare 2 values of this type? How do we make a deep copy of a value of this type? Etc. SqlTypeDescriptor is the same, but for a database type (VARCHAR, BLOB, etc). These 2 work together to perform reading and writing at the JDBC-level. We decided to broadly categorize JavaTypeDescriptors based on the JPA type categorizations: 1. BASIC - BasicJavaDescriptor 1. TemporalJavaDescriptor 2. NumericJavaDescriptor 2. MANAGED - ManagedJavaDescriptor 1. EMBEDDABLE - EmbeddableJavaDescriptor 2. IDENTIFIABLE - IdentifiableJavaDescriptor 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor 2. ENTITY - EntityJavaDescriptor Type (org.hibernate.type.spi.Type) represents a combination of a JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a specific "non-root Navigable domain value". Navigable is a query-focused contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a high-level t is similar to JPA's Bindable except that it applies to Collection indices (or map-keys) and elements (or map-values) as well. Navigable essentially represents an named navigation one can perform in a query. The root Navigable is always an entity (EntityPersister). EntityPersister is the only Navigable that does not expose a Type. (There is an EntityType, but it represents entity-valued non-root Navigables such as a ManyToOne). All other navigables expose a Type. That is all a long-winded way to say that Types represents that Java/SqlTypeDescriptors for a role-based Navigable. Like the categorization discussed above for JavaTypeDescriptor, Type has a similar categorization: 1. Type 1. BasicType 1. TemporalType 2. AnyType 3. ManagedType 1. EmbeddedType 2. IdentifiableType 1. MappedSuperclassType 2. EntityType It is important to keep in mind that these represents a specific reference to thse things in regards to a Navigable. E.g. an EntityType is the "type" of a SingularPersistentAttribute that is a ManyToOne - it points to the corresponding EntityPersister but it also represents the FK columns to refer to the entity. It is a role-based Navigable. Historically reads and writes have all routed through the Type (with certain Types delegating much of that to persisters). That will no longer be the case in 6.0 as one of the main design goals for 6.0 is to re-write how Hibernate reads and writes (mainly reads) values from JDBC. The major shift here is to read all values from JDBC using a "SqlSelectionReader" equivalent to a BasicType. These values are read and held in an array that "readers" then know how to access (positionally) and use. Most of that design is beyond the discussion here, but it useful to understand. It is discussed in the design.adoc in my orm-sqm poc repo for those curious. Long story, short... Types no longer directly implement JDBC read/write which we will come back to later. PersistentAttribute and the other Navigables now take a role in JDBC reads/writes. AttributeConverters and other read/write-related concerns have been moved to these contracts. Again, most of this is covered in the mentioned design doc. Since Type no longer directly implements JDBC read/write operations I think it is important to ask ourselves what exactly we see as "customizable" wrt each Type. Is that different for each category, or the same across all Type categories? E.g. I know of no customization of EntityType as it exists in 5.x, and tbh I am not even sure what that would mean. BasicType obviously has some parts that we want to allow users to override, but is that really best achieved through a custom BasicType? Or is it better served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or SqlSelectionReader? What about EmbeddedType? CollectionType? This would affect @TypeDef and Type registration methods specific to customizations. Persisters for the most part continue to serve the same role they have in the past with a few additions and some changes... One addition was the creation of an EmbeddedPersister. *Embedded*. This, like CollectionPersister, models a "role" e.g. "Person.name" as opposed to the Embeddable Name.class. Note however that JPA calls it an EmbeddableType and expects info about the Embeddable (the Class). EmbeddedPersister is role-based (Embedded) instead, which is a mismatch. In the case there are more than 1 usage of the Embeddable in different Embedded roles then we have to decide which EmbeddedPersister to return. It affects the sub-Attributes information. We could just return "one of them" and deal with it for Alpha1, but we should answer what we want to do there long term. Collectively, these persisters now implement the JPA ManagedType model directly. Another addition was the creation of ManagedTypeImplementor, IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the persister hierarchy. Which means we can now directly return them in our JPA Metamodel impl. That also means implementing JPA's notion of Attributes. I also needed something similar for SQM's Navigable contract. Plus I have been working towards changing how Hibernate understands Attributes internally (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed well. There are some things we should discuss too in terms of user impact. We know up front that we need to move to reading values from JDBC ResultSets positionally, as opposed to nominally which is how it was exposed in Hibernate prior to 6.0. So we know already we will be asking implementors and consumers of those contracts to make changes. Given that, we have *some* liberty in changing these contracts some more. We just want to be cognizant of (a) how much we change, (b) who it affects (use cases) and (c) whether there are alternatives. For any use cases we determine to be "valid" use cases, I think we need to make certain that there is some way to handle that in the new alternatives. One use case, e.g., is setting Query parameters and being able to specify its Type. To a degree we want to be able to continue to support that. But I think we limit it to just references to org.hibernate.type.Type (though "gutted") specifically and remove all others; and temporarily have the new org.hibernate.type.spi.Type interface extend the old. This would allow them to continue to get these org.hibernate.type.Type references in some fashion and use them as Query parameter type hints. But I think we should look at implementing some other parameter type "hints" like accepting PersistentAttribute/Navigable references, JPA (static) metamodel references, etc. These are better, as they would include things like AttributeConverter whereas the Type reference would not. Sorry this got so long. I've had a lot floating around in my head the last few days as I have worked on 6.0 and I wanted to bring them up for discussion. The main thing I wonder about is what we mean by "custom types" in terms of what exactly is being customized? And how does that relate specifically to BasicType versus EmbeddedType versus ...? From steve at hibernate.org Thu Jan 19 13:32:15 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 19 Jan 2017 18:32:15 +0000 Subject: [hibernate-dev] Hibernate ORM Project - Getting Started on "SuitableForNewContributors" Jira Issues In-Reply-To: References: Message-ID: Hi Valerie! Just comment on the issue that you are giving it a try and work on it in a branch on your fork of hibernate-orm repo. When you are done, send us a pull request. Thanks for your interest On Thu, Jan 19, 2017, 9:57 AM Valerie Arena wrote: > Hello, > > I would like to contribute to Hibernate ORM and would like to work > on "SuitableForNewContributors" Jira Issues. How do I get assigned to an > issue? > > Thank You! > Valerie Arena > https://www.linkedin.com/in/arenavalerie > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Thu Jan 19 14:55:57 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 19 Jan 2017 21:55:57 +0200 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: References: Message-ID: There's a lot to dig in here. I'll have to get the branch and study the changes, to come back with some opinions. Vlad On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole wrote: > We are getting pretty far along on the 6.0 changes and I wanted to start > a(nother) discussion about Types in 6.0 to get feedback and thoughts on a > few topics. > > First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types > and "persisters"... > > (a lot of this is the same from pre-6.0, just making things more explicit) > > JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so let's > start there. A JavaTypeDescriptor is a descriptor of a given Java type. > That is, it provides Hibernate with information about the Java type. Is it > a numeric type? How do we compare 2 values of this type? How do we make a > deep copy of a value of this type? Etc. SqlTypeDescriptor is the same, > but for a database type (VARCHAR, BLOB, etc). These 2 work together to > perform reading and writing at the JDBC-level. > > We decided to broadly categorize JavaTypeDescriptors based on the JPA type > categorizations: > > 1. BASIC - BasicJavaDescriptor > 1. TemporalJavaDescriptor > 2. NumericJavaDescriptor > 2. MANAGED - ManagedJavaDescriptor > 1. EMBEDDABLE - EmbeddableJavaDescriptor > 2. IDENTIFIABLE - IdentifiableJavaDescriptor > 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor > 2. ENTITY - EntityJavaDescriptor > > > Type (org.hibernate.type.spi.Type) represents a combination of a > JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a > specific "non-root Navigable domain value". Navigable is a query-focused > contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a > high-level t is similar to JPA's Bindable except that it applies to > Collection indices (or map-keys) and elements (or map-values) as well. > Navigable essentially represents an named navigation one can perform in a > query. The root Navigable is always an entity (EntityPersister). > EntityPersister is the only Navigable that does not expose a Type. (There > is an EntityType, but it represents entity-valued non-root Navigables such > as a ManyToOne). All other navigables expose a Type. That is all a > long-winded way to say that Types represents that Java/SqlTypeDescriptors > for a role-based Navigable. > > Like the categorization discussed above for JavaTypeDescriptor, Type has a > similar categorization: > > 1. Type > 1. BasicType > 1. TemporalType > 2. AnyType > 3. ManagedType > 1. EmbeddedType > 2. IdentifiableType > 1. MappedSuperclassType > 2. EntityType > > It is important to keep in mind that these represents a specific reference > to thse things in regards to a Navigable. E.g. an EntityType is the "type" > of a SingularPersistentAttribute that is a ManyToOne - it points to the > corresponding EntityPersister but it also represents the FK columns to > refer to the entity. It is a role-based Navigable. > > Historically reads and writes have all routed through the Type (with > certain Types delegating much of that to persisters). That will no longer > be the case in 6.0 as one of the main design goals for 6.0 is to re-write > how Hibernate reads and writes (mainly reads) values from JDBC. The major > shift here is to read all values from JDBC using a "SqlSelectionReader" > equivalent to a BasicType. These values are read and held in an array that > "readers" then know how to access (positionally) and use. Most of that > design is beyond the discussion here, but it useful to understand. It is > discussed in the design.adoc in my orm-sqm poc repo for those curious. > Long story, short... Types no longer directly implement JDBC read/write > which we will come back to later. > > PersistentAttribute and the other Navigables now take a role in JDBC > reads/writes. AttributeConverters and other read/write-related concerns > have been moved to these contracts. Again, most of this is covered in the > mentioned design doc. > > Since Type no longer directly implements JDBC read/write operations I think > it is important to ask ourselves what exactly we see as "customizable" wrt > each Type. Is that different for each category, or the same across all > Type categories? E.g. I know of no customization of EntityType as it > exists in 5.x, and tbh I am not even sure what that would mean. BasicType > obviously has some parts that we want to allow users to override, but is > that really best achieved through a custom BasicType? Or is it better > served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or > SqlSelectionReader? What about EmbeddedType? CollectionType? This would > affect @TypeDef and Type registration methods specific to customizations. > > Persisters for the most part continue to serve the same role they have in > the past with a few additions and some changes... > > One addition was the creation of an EmbeddedPersister. *Embedded*. This, > like CollectionPersister, models a "role" e.g. "Person.name" as opposed to > the Embeddable Name.class. Note however that JPA calls it an > EmbeddableType and expects info about the Embeddable (the Class). > EmbeddedPersister is role-based (Embedded) instead, which is a mismatch. > In the case there are more than 1 usage of the Embeddable in different > Embedded roles then we have to decide which EmbeddedPersister to return. > It affects the sub-Attributes information. We could just return "one of > them" and deal with it for Alpha1, but we should answer what we want to do > there long term. > > Collectively, these persisters now implement the JPA ManagedType model > directly. Another addition was the creation of ManagedTypeImplementor, > IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the > persister hierarchy. Which means we can now directly return them in our > JPA Metamodel impl. > > That also means implementing JPA's notion of Attributes. I also needed > something similar for SQM's Navigable contract. Plus I have been working > towards changing how Hibernate understands Attributes internally > (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed > well. > > There are some things we should discuss too in terms of user impact. We > know up front that we need to move to reading values from JDBC ResultSets > positionally, as opposed to nominally which is how it was exposed in > Hibernate prior to 6.0. So we know already we will be asking implementors > and consumers of those contracts to make changes. Given that, we have > *some* liberty in changing these contracts some more. We just want to be > cognizant of (a) how much we change, (b) who it affects (use cases) and (c) > whether there are alternatives. For any use cases we determine to be > "valid" use cases, I think we need to make certain that there is some way > to handle that in the new alternatives. > > One use case, e.g., is setting Query parameters and being able to specify > its Type. To a degree we want to be able to continue to support that. But > I think we limit it to just references to org.hibernate.type.Type (though > "gutted") specifically and remove all others; and temporarily have the new > org.hibernate.type.spi.Type interface extend the old. This would allow > them to continue to get these org.hibernate.type.Type references in some > fashion and use them as Query parameter type hints. But I think we should > look at implementing some other parameter type "hints" like accepting > PersistentAttribute/Navigable references, JPA (static) metamodel > references, etc. These are better, as they would include things like > AttributeConverter whereas the Type reference would not. > > Sorry this got so long. I've had a lot floating around in my head the last > few days as I have worked on 6.0 and I wanted to bring them up for > discussion. The main thing I wonder about is what we mean by "custom > types" in terms of what exactly is being customized? And how does that > relate specifically to BasicType versus EmbeddedType versus ...? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Thu Jan 19 16:57:39 2017 From: gbadner at redhat.com (Gail Badner) Date: Thu, 19 Jan 2017 16:57:39 -0500 Subject: [hibernate-dev] Hibernate ORM 5.0.12.Final and 5.1.4.Final released! Message-ID: Note: These are the last releases in the 5.0/5.1 series. You will need to migrate to 5.2 for future bugfixes. http://in.relation.to/2017/01/19/hibernate-orm-5012-final-and-514-final-release/ From sanne at hibernate.org Sun Jan 22 03:50:39 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Sun, 22 Jan 2017 08:50:39 +0000 Subject: [hibernate-dev] Nexus: staging repositories still open Message-ID: Hi all, there are several staging repositories on Nexus which haven't been dropped. There are 3 unclosed repos for Hibernate ORM, from around January 19th. There is one close but unreleased/undropped repository for Hibernate Validator, from January the 14th. They all seem to contain releases (tagged versions)? Please check & cleanup as needed.. Thanks, Sanne From guillaume.smet at gmail.com Sun Jan 22 14:06:43 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sun, 22 Jan 2017 20:06:43 +0100 Subject: [hibernate-dev] Nexus: staging repositories still open In-Reply-To: References: Message-ID: Hi Sanne, On Sun, Jan 22, 2017 at 9:50 AM, Sanne Grinovero wrote: > There is one close but unreleased/undropped repository for Hibernate > Validator, from January the 14th. > Yes, this is the second attempt to release 5.4.0.CR1 which fails as the artifacts did indeed exist somewhere on Nexus even if they didn't show up anywhere. I just dropped it. Thanks for the reminder. -- Guillaume From gbadner at redhat.com Mon Jan 23 06:17:40 2017 From: gbadner at redhat.com (Gail Badner) Date: Mon, 23 Jan 2017 11:17:40 +0000 Subject: [hibernate-dev] HHH-11144 In-Reply-To: References: Message-ID: This fell through the cracks. Emmanuel or Steve, please provide some feedback. Thanks, Gail On Wed, Oct 26, 2016 at 6:48 AM, Gail Badner wrote: > HHH-11144 involves an entity that has 2 one-to-many associations with the > same type of entity, and both associations have orphanRemoval = true. > Andrea created a PR with test case at [1] > > I am not sure if this is a valid mapping. I I would like your thoughts on > this. > > Here is an excerpt of the relevant bits: > > @Entity(name = "Item") > public static class Item { > @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, > orphanRemoval = true) > protected Set lowerItemRelations = new LinkedHashSet<>(); > @OneToMany(mappedBy = "child", cascade = CascadeType.ALL, orphanRemoval > = true) > protected Set higherItemRelations = new LinkedHashSet<> > (); > } > > @Entity(name = "ItemRelation") > public static class ItemRelation { > @ManyToOne(optional = false) > @JoinColumn(name = "PARENT_ID") > private Item parent; > @ManyToOne(optional = false) > @JoinColumn(name = "CHILD_ID") > private Item child; > } > > HHH-11144 describes inconsistent behavior observed when > Item#lowerItemRelations and Item#higherItemRelations both contain the same > ItemRelation, then one of the collections is cleared. > > If the non-cleared collection is uninitialized, then the ItemRelation is > orphan deleted. > > If the non-cleared collection is initialized, then the orphan-deleted > ItemRelation is rescued when PERSIST_ON_FLUSH cascades to the non-cleared > collection elements. The next time the collections are loaded from the > database, both will still contain that same ItemRelation. > > The spec says: > > "Portable applications must otherwise not depend upon a specific order of > removal, and must not reassign an entity that has been orphaned to another > relationship or *otherwise attempt to persist it*" > > Is Hibernate doing the right thing by rescuing an orphan-deleted entity? > > In addition, this mapping allows a particular EntityRelation to be > associated with 2 different Item entities, which would mean that the same > ItemRelation would have 2 different owners with respect to orphan deletion.. > > The spec says: > > "The orphanRemoval functionality is intended for entities that are privately > ?owned? by their parent entity." > > Does this mean that the mapping is invalid, since it would allow multiple > parent entities, or does it mean that the resulting behavior is undefined > (thus non-portable)? > > Please let me know your thoughts. > > Thanks, > Gail > > [1] https://github.com/hibernate/hibernate-orm/pull/1607 > From sanne at hibernate.org Mon Jan 23 06:39:30 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 23 Jan 2017 11:39:30 +0000 Subject: [hibernate-dev] [HSEARCH] heads up git users! Message-ID: Hi all, I'm soon going to rename branches on the reference repository [https://github.com/hibernate/hibernate-search] "master" branch is going to be renamed "5.6" "5.7" branch is going to be renamed "master" If you keep this in mind, you should be able to avoid any trouble: rebase as usual before sending PRs, just make sure you updated your local references to match the reference and then use the new names during the rebase. If you get in trouble.. I'm open to help out. Reminder: with git what matters is the commit signature: "renaming" just means we're moving the labels from one branch to the other; the branch itself is not being affected. Thanks, Sanne From mihalcea.vlad at gmail.com Mon Jan 23 08:00:27 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 23 Jan 2017 15:00:27 +0200 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: References: Message-ID: Hi, Related to your questions: he main thing I wonder about is what we mean by "custom > types" in terms of what exactly is being customized? And how does that > relate specifically to BasicType versus EmbeddedType versus ...? Most of the time, the users want to take advantage of various database types that are not universally supported by all RDBMS: JSON, Money (SQL Server). On the Java side, I don't see what we can customize because we already provide all the basic types, and for everything else, users can compose those into Embeddables. The Java 1.8 Date/Time are an example of what users would like to customize in case we didn't support this already. But even if Java 1.9 adds other basic types, chances are that we are going to support them natively, meaning that users will still not need to add a custom Type. So, I don't see how a Hibernate user will customize the way Embeddables, Enums, Entities or Collections are being stored or loaded from the database. The exception to the rule is a recent Pull Request from someone who wants to support PostgreSQL arrays. But this falls back into the same category as before: database types that are not universally supported by all RDBMS. Vlad On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea wrote: > There's a lot to dig in here. I'll have to get the branch and study the > changes, to come back with some opinions. > > Vlad > > On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole > wrote: > >> We are getting pretty far along on the 6.0 changes and I wanted to start >> a(nother) discussion about Types in 6.0 to get feedback and thoughts on a >> few topics. >> >> First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types >> and "persisters"... >> >> (a lot of this is the same from pre-6.0, just making things more explicit) >> >> JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so >> let's >> start there. A JavaTypeDescriptor is a descriptor of a given Java type. >> That is, it provides Hibernate with information about the Java type. Is >> it >> a numeric type? How do we compare 2 values of this type? How do we make >> a >> deep copy of a value of this type? Etc. SqlTypeDescriptor is the same, >> but for a database type (VARCHAR, BLOB, etc). These 2 work together to >> perform reading and writing at the JDBC-level. >> >> We decided to broadly categorize JavaTypeDescriptors based on the JPA type >> categorizations: >> >> 1. BASIC - BasicJavaDescriptor >> 1. TemporalJavaDescriptor >> 2. NumericJavaDescriptor >> 2. MANAGED - ManagedJavaDescriptor >> 1. EMBEDDABLE - EmbeddableJavaDescriptor >> 2. IDENTIFIABLE - IdentifiableJavaDescriptor >> 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor >> 2. ENTITY - EntityJavaDescriptor >> >> >> Type (org.hibernate.type.spi.Type) represents a combination of a >> JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a >> specific "non-root Navigable domain value". Navigable is a query-focused >> contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a >> high-level t is similar to JPA's Bindable except that it applies to >> Collection indices (or map-keys) and elements (or map-values) as well. >> Navigable essentially represents an named navigation one can perform in a >> query. The root Navigable is always an entity (EntityPersister). >> EntityPersister is the only Navigable that does not expose a Type. (There >> is an EntityType, but it represents entity-valued non-root Navigables such >> as a ManyToOne). All other navigables expose a Type. That is all a >> long-winded way to say that Types represents that Java/SqlTypeDescriptors >> for a role-based Navigable. >> >> Like the categorization discussed above for JavaTypeDescriptor, Type has a >> similar categorization: >> >> 1. Type >> 1. BasicType >> 1. TemporalType >> 2. AnyType >> 3. ManagedType >> 1. EmbeddedType >> 2. IdentifiableType >> 1. MappedSuperclassType >> 2. EntityType >> >> It is important to keep in mind that these represents a specific reference >> to thse things in regards to a Navigable. E.g. an EntityType is the >> "type" >> of a SingularPersistentAttribute that is a ManyToOne - it points to the >> corresponding EntityPersister but it also represents the FK columns to >> refer to the entity. It is a role-based Navigable. >> >> Historically reads and writes have all routed through the Type (with >> certain Types delegating much of that to persisters). That will no longer >> be the case in 6.0 as one of the main design goals for 6.0 is to re-write >> how Hibernate reads and writes (mainly reads) values from JDBC. The major >> shift here is to read all values from JDBC using a "SqlSelectionReader" >> equivalent to a BasicType. These values are read and held in an array >> that >> "readers" then know how to access (positionally) and use. Most of that >> design is beyond the discussion here, but it useful to understand. It is >> discussed in the design.adoc in my orm-sqm poc repo for those curious. >> Long story, short... Types no longer directly implement JDBC read/write >> which we will come back to later. >> >> PersistentAttribute and the other Navigables now take a role in JDBC >> reads/writes. AttributeConverters and other read/write-related concerns >> have been moved to these contracts. Again, most of this is covered in the >> mentioned design doc. >> >> Since Type no longer directly implements JDBC read/write operations I >> think >> it is important to ask ourselves what exactly we see as "customizable" wrt >> each Type. Is that different for each category, or the same across all >> Type categories? E.g. I know of no customization of EntityType as it >> exists in 5.x, and tbh I am not even sure what that would mean. BasicType >> obviously has some parts that we want to allow users to override, but is >> that really best achieved through a custom BasicType? Or is it better >> served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or >> SqlSelectionReader? What about EmbeddedType? CollectionType? This would >> affect @TypeDef and Type registration methods specific to customizations. >> >> Persisters for the most part continue to serve the same role they have in >> the past with a few additions and some changes... >> >> One addition was the creation of an EmbeddedPersister. *Embedded*. This, >> like CollectionPersister, models a "role" e.g. "Person.name" as opposed to >> the Embeddable Name.class. Note however that JPA calls it an >> EmbeddableType and expects info about the Embeddable (the Class). >> EmbeddedPersister is role-based (Embedded) instead, which is a mismatch. >> In the case there are more than 1 usage of the Embeddable in different >> Embedded roles then we have to decide which EmbeddedPersister to return. >> It affects the sub-Attributes information. We could just return "one of >> them" and deal with it for Alpha1, but we should answer what we want to do >> there long term. >> >> Collectively, these persisters now implement the JPA ManagedType model >> directly. Another addition was the creation of ManagedTypeImplementor, >> IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the >> persister hierarchy. Which means we can now directly return them in our >> JPA Metamodel impl. >> >> That also means implementing JPA's notion of Attributes. I also needed >> something similar for SQM's Navigable contract. Plus I have been working >> towards changing how Hibernate understands Attributes internally >> (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed >> well. >> >> There are some things we should discuss too in terms of user impact. We >> know up front that we need to move to reading values from JDBC ResultSets >> positionally, as opposed to nominally which is how it was exposed in >> Hibernate prior to 6.0. So we know already we will be asking implementors >> and consumers of those contracts to make changes. Given that, we have >> *some* liberty in changing these contracts some more. We just want to be >> cognizant of (a) how much we change, (b) who it affects (use cases) and >> (c) >> whether there are alternatives. For any use cases we determine to be >> "valid" use cases, I think we need to make certain that there is some way >> to handle that in the new alternatives. >> >> One use case, e.g., is setting Query parameters and being able to specify >> its Type. To a degree we want to be able to continue to support that. >> But >> I think we limit it to just references to org.hibernate.type.Type (though >> "gutted") specifically and remove all others; and temporarily have the new >> org.hibernate.type.spi.Type interface extend the old. This would allow >> them to continue to get these org.hibernate.type.Type references in some >> fashion and use them as Query parameter type hints. But I think we should >> look at implementing some other parameter type "hints" like accepting >> PersistentAttribute/Navigable references, JPA (static) metamodel >> references, etc. These are better, as they would include things like >> AttributeConverter whereas the Type reference would not. >> >> Sorry this got so long. I've had a lot floating around in my head the >> last >> few days as I have worked on 6.0 and I wanted to bring them up for >> discussion. The main thing I wonder about is what we mean by "custom >> types" in terms of what exactly is being customized? And how does that >> relate specifically to BasicType versus EmbeddedType versus ...? >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From steve at hibernate.org Mon Jan 23 08:37:38 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 23 Jan 2017 13:37:38 +0000 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: References: Message-ID: Right, and that exactly lines up with what I am proposing. If the intent of "customize" is to describe new Java types (e.g. Java 8 temporals prior to our explicit support) the tht is the role of a JavaTypeDescriptor, specifically a BasicJavaDescriptor. They would register a BasicJavaDescriptor describing the type. If the intent is to model a non-supported SQL type then that would mean adding a new SqlTypeDescriptor describing that type, although that will often also mean adding a new BasicJavaDescriptor describing the Java mapping of that SQL type. On Mon, Jan 23, 2017 at 7:00 AM Vlad Mihalcea wrote: Hi, Related to your questions: he main thing I wonder about is what we mean by "custom types" in terms of what exactly is being customized? And how does that relate specifically to BasicType versus EmbeddedType versus ...? Most of the time, the users want to take advantage of various database types that are not universally supported by all RDBMS: JSON, Money (SQL Server). On the Java side, I don't see what we can customize because we already provide all the basic types, and for everything else, users can compose those into Embeddables. The Java 1.8 Date/Time are an example of what users would like to customize in case we didn't support this already. But even if Java 1.9 adds other basic types, chances are that we are going to support them natively, meaning that users will still not need to add a custom Type. So, I don't see how a Hibernate user will customize the way Embeddables, Enums, Entities or Collections are being stored or loaded from the database. The exception to the rule is a recent Pull Request from someone who wants to support PostgreSQL arrays. But this falls back into the same category as before: database types that are not universally supported by all RDBMS. Vlad On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea wrote: There's a lot to dig in here. I'll have to get the branch and study the changes, to come back with some opinions. Vlad On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole wrote: We are getting pretty far along on the 6.0 changes and I wanted to start a(nother) discussion about Types in 6.0 to get feedback and thoughts on a few topics. First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types and "persisters"... (a lot of this is the same from pre-6.0, just making things more explicit) JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so let's start there. A JavaTypeDescriptor is a descriptor of a given Java type. That is, it provides Hibernate with information about the Java type. Is it a numeric type? How do we compare 2 values of this type? How do we make a deep copy of a value of this type? Etc. SqlTypeDescriptor is the same, but for a database type (VARCHAR, BLOB, etc). These 2 work together to perform reading and writing at the JDBC-level. We decided to broadly categorize JavaTypeDescriptors based on the JPA type categorizations: 1. BASIC - BasicJavaDescriptor 1. TemporalJavaDescriptor 2. NumericJavaDescriptor 2. MANAGED - ManagedJavaDescriptor 1. EMBEDDABLE - EmbeddableJavaDescriptor 2. IDENTIFIABLE - IdentifiableJavaDescriptor 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor 2. ENTITY - EntityJavaDescriptor Type (org.hibernate.type.spi.Type) represents a combination of a JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a specific "non-root Navigable domain value". Navigable is a query-focused contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a high-level t is similar to JPA's Bindable except that it applies to Collection indices (or map-keys) and elements (or map-values) as well. Navigable essentially represents an named navigation one can perform in a query. The root Navigable is always an entity (EntityPersister). EntityPersister is the only Navigable that does not expose a Type. (There is an EntityType, but it represents entity-valued non-root Navigables such as a ManyToOne). All other navigables expose a Type. That is all a long-winded way to say that Types represents that Java/SqlTypeDescriptors for a role-based Navigable. Like the categorization discussed above for JavaTypeDescriptor, Type has a similar categorization: 1. Type 1. BasicType 1. TemporalType 2. AnyType 3. ManagedType 1. EmbeddedType 2. IdentifiableType 1. MappedSuperclassType 2. EntityType It is important to keep in mind that these represents a specific reference to thse things in regards to a Navigable. E.g. an EntityType is the "type" of a SingularPersistentAttribute that is a ManyToOne - it points to the corresponding EntityPersister but it also represents the FK columns to refer to the entity. It is a role-based Navigable. Historically reads and writes have all routed through the Type (with certain Types delegating much of that to persisters). That will no longer be the case in 6.0 as one of the main design goals for 6.0 is to re-write how Hibernate reads and writes (mainly reads) values from JDBC. The major shift here is to read all values from JDBC using a "SqlSelectionReader" equivalent to a BasicType. These values are read and held in an array that "readers" then know how to access (positionally) and use. Most of that design is beyond the discussion here, but it useful to understand. It is discussed in the design.adoc in my orm-sqm poc repo for those curious. Long story, short... Types no longer directly implement JDBC read/write which we will come back to later. PersistentAttribute and the other Navigables now take a role in JDBC reads/writes. AttributeConverters and other read/write-related concerns have been moved to these contracts. Again, most of this is covered in the mentioned design doc. Since Type no longer directly implements JDBC read/write operations I think it is important to ask ourselves what exactly we see as "customizable" wrt each Type. Is that different for each category, or the same across all Type categories? E.g. I know of no customization of EntityType as it exists in 5.x, and tbh I am not even sure what that would mean. BasicType obviously has some parts that we want to allow users to override, but is that really best achieved through a custom BasicType? Or is it better served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or SqlSelectionReader? What about EmbeddedType? CollectionType? This would affect @TypeDef and Type registration methods specific to customizations. Persisters for the most part continue to serve the same role they have in the past with a few additions and some changes... One addition was the creation of an EmbeddedPersister. *Embedded*. This, like CollectionPersister, models a "role" e.g. "Person.name" as opposed to the Embeddable Name.class. Note however that JPA calls it an EmbeddableType and expects info about the Embeddable (the Class). EmbeddedPersister is role-based (Embedded) instead, which is a mismatch. In the case there are more than 1 usage of the Embeddable in different Embedded roles then we have to decide which EmbeddedPersister to return. It affects the sub-Attributes information. We could just return "one of them" and deal with it for Alpha1, but we should answer what we want to do there long term. Collectively, these persisters now implement the JPA ManagedType model directly. Another addition was the creation of ManagedTypeImplementor, IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the persister hierarchy. Which means we can now directly return them in our JPA Metamodel impl. That also means implementing JPA's notion of Attributes. I also needed something similar for SQM's Navigable contract. Plus I have been working towards changing how Hibernate understands Attributes internally (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed well. There are some things we should discuss too in terms of user impact. We know up front that we need to move to reading values from JDBC ResultSets positionally, as opposed to nominally which is how it was exposed in Hibernate prior to 6.0. So we know already we will be asking implementors and consumers of those contracts to make changes. Given that, we have *some* liberty in changing these contracts some more. We just want to be cognizant of (a) how much we change, (b) who it affects (use cases) and (c) whether there are alternatives. For any use cases we determine to be "valid" use cases, I think we need to make certain that there is some way to handle that in the new alternatives. One use case, e.g., is setting Query parameters and being able to specify its Type. To a degree we want to be able to continue to support that. But I think we limit it to just references to org.hibernate.type.Type (though "gutted") specifically and remove all others; and temporarily have the new org.hibernate.type.spi.Type interface extend the old. This would allow them to continue to get these org.hibernate.type.Type references in some fashion and use them as Query parameter type hints. But I think we should look at implementing some other parameter type "hints" like accepting PersistentAttribute/Navigable references, JPA (static) metamodel references, etc. These are better, as they would include things like AttributeConverter whereas the Type reference would not. Sorry this got so long. I've had a lot floating around in my head the last few days as I have worked on 6.0 and I wanted to bring them up for discussion. The main thing I wonder about is what we mean by "custom types" in terms of what exactly is being customized? And how does that relate specifically to BasicType versus EmbeddedType versus ...? _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From mihalcea.vlad at gmail.com Mon Jan 23 08:48:40 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 23 Jan 2017 15:48:40 +0200 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: References: Message-ID: Hi, I like the SqlTypeDescriptor and JavaTypeDescriptor much better than UserType, which we should probably deprecate in 6.0. I wrote an article on my blog in which I demonstrate how to create a JSON type using JavaTypeDescriptor and SqlTypeDescriptor: https://vladmihalcea.com/2016/06/20/how-to-map-json-objects- using-generic-hibernate-types/ I like this example because it shows how you can reuse the same JavaTypeDescriptor for two different JSON SQL types: String or Binary, for which we have two distinct SqlTypeDescriptor objects. The new User Guide shows ho to implement Custom Types using the Java and SQL descriptors as well: http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#basic-custom-type Vlad On Mon, Jan 23, 2017 at 3:37 PM, Steve Ebersole wrote: > Right, and that exactly lines up with what I am proposing. > > If the intent of "customize" is to describe new Java types (e.g. Java 8 > temporals prior to our explicit support) the tht is the role of a > JavaTypeDescriptor, specifically a BasicJavaDescriptor. They would > register a BasicJavaDescriptor describing the type. > > If the intent is to model a non-supported SQL type then that would mean > adding a new SqlTypeDescriptor describing that type, although that will > often also mean adding a new BasicJavaDescriptor describing the Java > mapping of that SQL type. > > > On Mon, Jan 23, 2017 at 7:00 AM Vlad Mihalcea > wrote: > > Hi, > > Related to your questions: > > he main thing I wonder about is what we mean by "custom > types" in terms of what exactly is being customized? And how does that > relate specifically to BasicType versus EmbeddedType versus ...? > > > Most of the time, the users want to take advantage of various database > types that are not universally supported by all RDBMS: JSON, Money (SQL > Server). > > On the Java side, I don't see what we can customize because we already > provide all the basic types, and for everything else, users can compose > those into Embeddables. The Java 1.8 Date/Time are an example of what users > would like to customize in case we didn't support this already. But even if > Java 1.9 adds other basic types, chances are that we are going to support > them natively, meaning that users will still not need to add a custom Type. > > So, I don't see how a Hibernate user will customize the way Embeddables, > Enums, Entities or Collections are being stored or loaded from the > database. The exception to the rule is a recent Pull Request from someone > who wants to support PostgreSQL arrays. But this falls back into the same > category as before: database types that are not universally supported by > all RDBMS. > > Vlad > > On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea > wrote: > > There's a lot to dig in here. I'll have to get the branch and study the > changes, to come back with some opinions. > > Vlad > > On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole > wrote: > > We are getting pretty far along on the 6.0 changes and I wanted to start > a(nother) discussion about Types in 6.0 to get feedback and thoughts on a > few topics. > > First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types > and "persisters"... > > (a lot of this is the same from pre-6.0, just making things more explicit) > > JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so let's > start there. A JavaTypeDescriptor is a descriptor of a given Java type. > That is, it provides Hibernate with information about the Java type. Is it > a numeric type? How do we compare 2 values of this type? How do we make a > deep copy of a value of this type? Etc. SqlTypeDescriptor is the same, > but for a database type (VARCHAR, BLOB, etc). These 2 work together to > perform reading and writing at the JDBC-level. > > We decided to broadly categorize JavaTypeDescriptors based on the JPA type > categorizations: > > 1. BASIC - BasicJavaDescriptor > 1. TemporalJavaDescriptor > 2. NumericJavaDescriptor > 2. MANAGED - ManagedJavaDescriptor > 1. EMBEDDABLE - EmbeddableJavaDescriptor > 2. IDENTIFIABLE - IdentifiableJavaDescriptor > 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor > 2. ENTITY - EntityJavaDescriptor > > > Type (org.hibernate.type.spi.Type) represents a combination of a > JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a > specific "non-root Navigable domain value". Navigable is a query-focused > contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a > high-level t is similar to JPA's Bindable except that it applies to > Collection indices (or map-keys) and elements (or map-values) as well. > Navigable essentially represents an named navigation one can perform in a > query. The root Navigable is always an entity (EntityPersister). > EntityPersister is the only Navigable that does not expose a Type. (There > is an EntityType, but it represents entity-valued non-root Navigables such > as a ManyToOne). All other navigables expose a Type. That is all a > long-winded way to say that Types represents that Java/SqlTypeDescriptors > for a role-based Navigable. > > Like the categorization discussed above for JavaTypeDescriptor, Type has a > similar categorization: > > 1. Type > 1. BasicType > 1. TemporalType > 2. AnyType > 3. ManagedType > 1. EmbeddedType > 2. IdentifiableType > 1. MappedSuperclassType > 2. EntityType > > It is important to keep in mind that these represents a specific reference > to thse things in regards to a Navigable. E.g. an EntityType is the "type" > of a SingularPersistentAttribute that is a ManyToOne - it points to the > corresponding EntityPersister but it also represents the FK columns to > refer to the entity. It is a role-based Navigable. > > Historically reads and writes have all routed through the Type (with > certain Types delegating much of that to persisters). That will no longer > be the case in 6.0 as one of the main design goals for 6.0 is to re-write > how Hibernate reads and writes (mainly reads) values from JDBC. The major > shift here is to read all values from JDBC using a "SqlSelectionReader" > equivalent to a BasicType. These values are read and held in an array that > "readers" then know how to access (positionally) and use. Most of that > design is beyond the discussion here, but it useful to understand. It is > discussed in the design.adoc in my orm-sqm poc repo for those curious. > Long story, short... Types no longer directly implement JDBC read/write > which we will come back to later. > > PersistentAttribute and the other Navigables now take a role in JDBC > reads/writes. AttributeConverters and other read/write-related concerns > have been moved to these contracts. Again, most of this is covered in the > mentioned design doc. > > Since Type no longer directly implements JDBC read/write operations I think > it is important to ask ourselves what exactly we see as "customizable" wrt > each Type. Is that different for each category, or the same across all > Type categories? E.g. I know of no customization of EntityType as it > exists in 5.x, and tbh I am not even sure what that would mean. BasicType > obviously has some parts that we want to allow users to override, but is > that really best achieved through a custom BasicType? Or is it better > served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or > SqlSelectionReader? What about EmbeddedType? CollectionType? This would > affect @TypeDef and Type registration methods specific to customizations. > > Persisters for the most part continue to serve the same role they have in > the past with a few additions and some changes... > > One addition was the creation of an EmbeddedPersister. *Embedded*. This, > like CollectionPersister, models a "role" e.g. "Person.name" as opposed to > the Embeddable Name.class. Note however that JPA calls it an > EmbeddableType and expects info about the Embeddable (the Class). > EmbeddedPersister is role-based (Embedded) instead, which is a mismatch. > In the case there are more than 1 usage of the Embeddable in different > Embedded roles then we have to decide which EmbeddedPersister to return. > It affects the sub-Attributes information. We could just return "one of > them" and deal with it for Alpha1, but we should answer what we want to do > there long term. > > Collectively, these persisters now implement the JPA ManagedType model > directly. Another addition was the creation of ManagedTypeImplementor, > IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the > persister hierarchy. Which means we can now directly return them in our > JPA Metamodel impl. > > That also means implementing JPA's notion of Attributes. I also needed > something similar for SQM's Navigable contract. Plus I have been working > towards changing how Hibernate understands Attributes internally > (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed > well. > > There are some things we should discuss too in terms of user impact. We > know up front that we need to move to reading values from JDBC ResultSets > positionally, as opposed to nominally which is how it was exposed in > Hibernate prior to 6.0. So we know already we will be asking implementors > and consumers of those contracts to make changes. Given that, we have > *some* liberty in changing these contracts some more. We just want to be > cognizant of (a) how much we change, (b) who it affects (use cases) and (c) > whether there are alternatives. For any use cases we determine to be > "valid" use cases, I think we need to make certain that there is some way > to handle that in the new alternatives. > > One use case, e.g., is setting Query parameters and being able to specify > its Type. To a degree we want to be able to continue to support that. But > I think we limit it to just references to org.hibernate.type.Type (though > "gutted") specifically and remove all others; and temporarily have the new > org.hibernate.type.spi.Type interface extend the old. This would allow > them to continue to get these org.hibernate.type.Type references in some > fashion and use them as Query parameter type hints. But I think we should > look at implementing some other parameter type "hints" like accepting > PersistentAttribute/Navigable references, JPA (static) metamodel > references, etc. These are better, as they would include things like > AttributeConverter whereas the Type reference would not. > > Sorry this got so long. I've had a lot floating around in my head the last > few days as I have worked on 6.0 and I wanted to bring them up for > discussion. The main thing I wonder about is what we mean by "custom > types" in terms of what exactly is being customized? And how does that > relate specifically to BasicType versus EmbeddedType versus ...? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > From steve at hibernate.org Mon Jan 23 09:11:00 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 23 Jan 2017 14:11:00 +0000 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: References: Message-ID: Nice! So if we keep UserType, we have to be clear that it has to change. I also do not want to continue to support the other "user type extensions", like: 1. org.hibernate.usertype.EnhancedUserType 2. org.hibernate.usertype.DynamicParameterizedType 3. org.hibernate.usertype.LoggableUserType 4. etc So we should come up with a plan for that. On Mon, Jan 23, 2017, 1:48 PM Vlad Mihalcea wrote: Hi, I like the SqlTypeDescriptor and JavaTypeDescriptor much better than UserType, which we should probably deprecate in 6.0. I wrote an article on my blog in which I demonstrate how to create a JSON type using JavaTypeDescriptor and SqlTypeDescriptor: https://vladmihalcea.com/2016/06/20/how-to-map-json-objects-using-generic-hibernate-types/ I like this example because it shows how you can reuse the same JavaTypeDescriptor for two different JSON SQL types: String or Binary, for which we have two distinct SqlTypeDescriptor objects. The new User Guide shows ho to implement Custom Types using the Java and SQL descriptors as well: http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#basic-custom-type Vlad On Mon, Jan 23, 2017 at 3:37 PM, Steve Ebersole wrote: Right, and that exactly lines up with what I am proposing. If the intent of "customize" is to describe new Java types (e.g. Java 8 temporals prior to our explicit support) the tht is the role of a JavaTypeDescriptor, specifically a BasicJavaDescriptor. They would register a BasicJavaDescriptor describing the type. If the intent is to model a non-supported SQL type then that would mean adding a new SqlTypeDescriptor describing that type, although that will often also mean adding a new BasicJavaDescriptor describing the Java mapping of that SQL type. On Mon, Jan 23, 2017 at 7:00 AM Vlad Mihalcea wrote: Hi, Related to your questions: he main thing I wonder about is what we mean by "custom types" in terms of what exactly is being customized? And how does that relate specifically to BasicType versus EmbeddedType versus ...? Most of the time, the users want to take advantage of various database types that are not universally supported by all RDBMS: JSON, Money (SQL Server). On the Java side, I don't see what we can customize because we already provide all the basic types, and for everything else, users can compose those into Embeddables. The Java 1.8 Date/Time are an example of what users would like to customize in case we didn't support this already. But even if Java 1.9 adds other basic types, chances are that we are going to support them natively, meaning that users will still not need to add a custom Type. So, I don't see how a Hibernate user will customize the way Embeddables, Enums, Entities or Collections are being stored or loaded from the database. The exception to the rule is a recent Pull Request from someone who wants to support PostgreSQL arrays. But this falls back into the same category as before: database types that are not universally supported by all RDBMS. Vlad On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea wrote: There's a lot to dig in here. I'll have to get the branch and study the changes, to come back with some opinions. Vlad On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole wrote: We are getting pretty far along on the 6.0 changes and I wanted to start a(nother) discussion about Types in 6.0 to get feedback and thoughts on a few topics. First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types and "persisters"... (a lot of this is the same from pre-6.0, just making things more explicit) JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so let's start there. A JavaTypeDescriptor is a descriptor of a given Java type. That is, it provides Hibernate with information about the Java type. Is it a numeric type? How do we compare 2 values of this type? How do we make a deep copy of a value of this type? Etc. SqlTypeDescriptor is the same, but for a database type (VARCHAR, BLOB, etc). These 2 work together to perform reading and writing at the JDBC-level. We decided to broadly categorize JavaTypeDescriptors based on the JPA type categorizations: 1. BASIC - BasicJavaDescriptor 1. TemporalJavaDescriptor 2. NumericJavaDescriptor 2. MANAGED - ManagedJavaDescriptor 1. EMBEDDABLE - EmbeddableJavaDescriptor 2. IDENTIFIABLE - IdentifiableJavaDescriptor 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor 2. ENTITY - EntityJavaDescriptor Type (org.hibernate.type.spi.Type) represents a combination of a JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a specific "non-root Navigable domain value". Navigable is a query-focused contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a high-level t is similar to JPA's Bindable except that it applies to Collection indices (or map-keys) and elements (or map-values) as well. Navigable essentially represents an named navigation one can perform in a query. The root Navigable is always an entity (EntityPersister). EntityPersister is the only Navigable that does not expose a Type. (There is an EntityType, but it represents entity-valued non-root Navigables such as a ManyToOne). All other navigables expose a Type. That is all a long-winded way to say that Types represents that Java/SqlTypeDescriptors for a role-based Navigable. Like the categorization discussed above for JavaTypeDescriptor, Type has a similar categorization: 1. Type 1. BasicType 1. TemporalType 2. AnyType 3. ManagedType 1. EmbeddedType 2. IdentifiableType 1. MappedSuperclassType 2. EntityType It is important to keep in mind that these represents a specific reference to thse things in regards to a Navigable. E.g. an EntityType is the "type" of a SingularPersistentAttribute that is a ManyToOne - it points to the corresponding EntityPersister but it also represents the FK columns to refer to the entity. It is a role-based Navigable. Historically reads and writes have all routed through the Type (with certain Types delegating much of that to persisters). That will no longer be the case in 6.0 as one of the main design goals for 6.0 is to re-write how Hibernate reads and writes (mainly reads) values from JDBC. The major shift here is to read all values from JDBC using a "SqlSelectionReader" equivalent to a BasicType. These values are read and held in an array that "readers" then know how to access (positionally) and use. Most of that design is beyond the discussion here, but it useful to understand. It is discussed in the design.adoc in my orm-sqm poc repo for those curious. Long story, short... Types no longer directly implement JDBC read/write which we will come back to later. PersistentAttribute and the other Navigables now take a role in JDBC reads/writes. AttributeConverters and other read/write-related concerns have been moved to these contracts. Again, most of this is covered in the mentioned design doc. Since Type no longer directly implements JDBC read/write operations I think it is important to ask ourselves what exactly we see as "customizable" wrt each Type. Is that different for each category, or the same across all Type categories? E.g. I know of no customization of EntityType as it exists in 5.x, and tbh I am not even sure what that would mean. BasicType obviously has some parts that we want to allow users to override, but is that really best achieved through a custom BasicType? Or is it better served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or SqlSelectionReader? What about EmbeddedType? CollectionType? This would affect @TypeDef and Type registration methods specific to customizations. Persisters for the most part continue to serve the same role they have in the past with a few additions and some changes... One addition was the creation of an EmbeddedPersister. *Embedded*. This, like CollectionPersister, models a "role" e.g. "Person.name" as opposed to the Embeddable Name.class. Note however that JPA calls it an EmbeddableType and expects info about the Embeddable (the Class). EmbeddedPersister is role-based (Embedded) instead, which is a mismatch. In the case there are more than 1 usage of the Embeddable in different Embedded roles then we have to decide which EmbeddedPersister to return. It affects the sub-Attributes information. We could just return "one of them" and deal with it for Alpha1, but we should answer what we want to do there long term. Collectively, these persisters now implement the JPA ManagedType model directly. Another addition was the creation of ManagedTypeImplementor, IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the persister hierarchy. Which means we can now directly return them in our JPA Metamodel impl. That also means implementing JPA's notion of Attributes. I also needed something similar for SQM's Navigable contract. Plus I have been working towards changing how Hibernate understands Attributes internally (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed well. There are some things we should discuss too in terms of user impact. We know up front that we need to move to reading values from JDBC ResultSets positionally, as opposed to nominally which is how it was exposed in Hibernate prior to 6.0. So we know already we will be asking implementors and consumers of those contracts to make changes. Given that, we have *some* liberty in changing these contracts some more. We just want to be cognizant of (a) how much we change, (b) who it affects (use cases) and (c) whether there are alternatives. For any use cases we determine to be "valid" use cases, I think we need to make certain that there is some way to handle that in the new alternatives. One use case, e.g., is setting Query parameters and being able to specify its Type. To a degree we want to be able to continue to support that. But I think we limit it to just references to org.hibernate.type.Type (though "gutted") specifically and remove all others; and temporarily have the new org.hibernate.type.spi.Type interface extend the old. This would allow them to continue to get these org.hibernate.type.Type references in some fashion and use them as Query parameter type hints. But I think we should look at implementing some other parameter type "hints" like accepting PersistentAttribute/Navigable references, JPA (static) metamodel references, etc. These are better, as they would include things like AttributeConverter whereas the Type reference would not. Sorry this got so long. I've had a lot floating around in my head the last few days as I have worked on 6.0 and I wanted to bring them up for discussion. The main thing I wonder about is what we mean by "custom types" in terms of what exactly is being customized? And how does that relate specifically to BasicType versus EmbeddedType versus ...? _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From mihalcea.vlad at gmail.com Mon Jan 23 09:36:19 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 23 Jan 2017 16:36:19 +0200 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: References: Message-ID: Hi, I see no reason why we should keep it indefinitely. I'd say we deprecate it in 5.x, and remove it later (6.0 or 6.1). Migrating a custom UserType to using Java and SQL descriptor is not difficult, and we could just write a blog post for a step-by-step guide. Anyone in favor of keeping UserType? Vlad On Mon, Jan 23, 2017 at 4:11 PM, Steve Ebersole wrote: > Nice! > > So if we keep UserType, we have to be clear that it has to change. I also > do not want to continue to support the other "user type extensions", like: > > > 1. org.hibernate.usertype.EnhancedUserType > 2. org.hibernate.usertype.DynamicParameterizedType > 3. org.hibernate.usertype.LoggableUserType > 4. etc > > So we should come up with a plan for that. > > > On Mon, Jan 23, 2017, 1:48 PM Vlad Mihalcea > wrote: > > Hi, > > I like the SqlTypeDescriptor and JavaTypeDescriptor much better than > UserType, which we should probably deprecate in 6.0. > > I wrote an article on my blog in which I demonstrate how to create a JSON > type using JavaTypeDescriptor and SqlTypeDescriptor: > > https://vladmihalcea.com/2016/06/20/how-to-map-json-objects- > using-generic-hibernate-types/ > > I like this example because it shows how you can reuse the same > JavaTypeDescriptor for two different JSON SQL types: String or Binary, > for which we have two distinct SqlTypeDescriptor objects. > > The new User Guide shows ho to implement Custom Types using the Java and > SQL descriptors as well: > > http://docs.jboss.org/hibernate/orm/5.2/userguide/ > html_single/Hibernate_User_Guide.html#basic-custom-type > > Vlad > > On Mon, Jan 23, 2017 at 3:37 PM, Steve Ebersole > wrote: > > Right, and that exactly lines up with what I am proposing. > > If the intent of "customize" is to describe new Java types (e.g. Java 8 > temporals prior to our explicit support) the tht is the role of a > JavaTypeDescriptor, specifically a BasicJavaDescriptor. They would > register a BasicJavaDescriptor describing the type. > > If the intent is to model a non-supported SQL type then that would mean > adding a new SqlTypeDescriptor describing that type, although that will > often also mean adding a new BasicJavaDescriptor describing the Java > mapping of that SQL type. > > > On Mon, Jan 23, 2017 at 7:00 AM Vlad Mihalcea > wrote: > > Hi, > > Related to your questions: > > he main thing I wonder about is what we mean by "custom > types" in terms of what exactly is being customized? And how does that > relate specifically to BasicType versus EmbeddedType versus ...? > > > Most of the time, the users want to take advantage of various database > types that are not universally supported by all RDBMS: JSON, Money (SQL > Server). > > On the Java side, I don't see what we can customize because we already > provide all the basic types, and for everything else, users can compose > those into Embeddables. The Java 1.8 Date/Time are an example of what users > would like to customize in case we didn't support this already. But even if > Java 1.9 adds other basic types, chances are that we are going to support > them natively, meaning that users will still not need to add a custom Type. > > So, I don't see how a Hibernate user will customize the way Embeddables, > Enums, Entities or Collections are being stored or loaded from the > database. The exception to the rule is a recent Pull Request from someone > who wants to support PostgreSQL arrays. But this falls back into the same > category as before: database types that are not universally supported by > all RDBMS. > > Vlad > > On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea > wrote: > > There's a lot to dig in here. I'll have to get the branch and study the > changes, to come back with some opinions. > > Vlad > > On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole > wrote: > > We are getting pretty far along on the 6.0 changes and I wanted to start > a(nother) discussion about Types in 6.0 to get feedback and thoughts on a > few topics. > > First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types > and "persisters"... > > (a lot of this is the same from pre-6.0, just making things more explicit) > > JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so let's > start there. A JavaTypeDescriptor is a descriptor of a given Java type. > That is, it provides Hibernate with information about the Java type. Is it > a numeric type? How do we compare 2 values of this type? How do we make a > deep copy of a value of this type? Etc. SqlTypeDescriptor is the same, > but for a database type (VARCHAR, BLOB, etc). These 2 work together to > perform reading and writing at the JDBC-level. > > We decided to broadly categorize JavaTypeDescriptors based on the JPA type > categorizations: > > 1. BASIC - BasicJavaDescriptor > 1. TemporalJavaDescriptor > 2. NumericJavaDescriptor > 2. MANAGED - ManagedJavaDescriptor > 1. EMBEDDABLE - EmbeddableJavaDescriptor > 2. IDENTIFIABLE - IdentifiableJavaDescriptor > 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor > 2. ENTITY - EntityJavaDescriptor > > > Type (org.hibernate.type.spi.Type) represents a combination of a > JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a > specific "non-root Navigable domain value". Navigable is a query-focused > contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a > high-level t is similar to JPA's Bindable except that it applies to > Collection indices (or map-keys) and elements (or map-values) as well. > Navigable essentially represents an named navigation one can perform in a > query. The root Navigable is always an entity (EntityPersister). > EntityPersister is the only Navigable that does not expose a Type. (There > is an EntityType, but it represents entity-valued non-root Navigables such > as a ManyToOne). All other navigables expose a Type. That is all a > long-winded way to say that Types represents that Java/SqlTypeDescriptors > for a role-based Navigable. > > Like the categorization discussed above for JavaTypeDescriptor, Type has a > similar categorization: > > 1. Type > 1. BasicType > 1. TemporalType > 2. AnyType > 3. ManagedType > 1. EmbeddedType > 2. IdentifiableType > 1. MappedSuperclassType > 2. EntityType > > It is important to keep in mind that these represents a specific reference > to thse things in regards to a Navigable. E.g. an EntityType is the "type" > of a SingularPersistentAttribute that is a ManyToOne - it points to the > corresponding EntityPersister but it also represents the FK columns to > refer to the entity. It is a role-based Navigable. > > Historically reads and writes have all routed through the Type (with > certain Types delegating much of that to persisters). That will no longer > be the case in 6.0 as one of the main design goals for 6.0 is to re-write > how Hibernate reads and writes (mainly reads) values from JDBC. The major > shift here is to read all values from JDBC using a "SqlSelectionReader" > equivalent to a BasicType. These values are read and held in an array that > "readers" then know how to access (positionally) and use. Most of that > design is beyond the discussion here, but it useful to understand. It is > discussed in the design.adoc in my orm-sqm poc repo for those curious. > Long story, short... Types no longer directly implement JDBC read/write > which we will come back to later. > > PersistentAttribute and the other Navigables now take a role in JDBC > reads/writes. AttributeConverters and other read/write-related concerns > have been moved to these contracts. Again, most of this is covered in the > mentioned design doc. > > Since Type no longer directly implements JDBC read/write operations I think > it is important to ask ourselves what exactly we see as "customizable" wrt > each Type. Is that different for each category, or the same across all > Type categories? E.g. I know of no customization of EntityType as it > exists in 5.x, and tbh I am not even sure what that would mean. BasicType > obviously has some parts that we want to allow users to override, but is > that really best achieved through a custom BasicType? Or is it better > served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or > SqlSelectionReader? What about EmbeddedType? CollectionType? This would > affect @TypeDef and Type registration methods specific to customizations. > > Persisters for the most part continue to serve the same role they have in > the past with a few additions and some changes... > > One addition was the creation of an EmbeddedPersister. *Embedded*. This, > like CollectionPersister, models a "role" e.g. "Person.name" as opposed to > the Embeddable Name.class. Note however that JPA calls it an > EmbeddableType and expects info about the Embeddable (the Class). > EmbeddedPersister is role-based (Embedded) instead, which is a mismatch. > In the case there are more than 1 usage of the Embeddable in different > Embedded roles then we have to decide which EmbeddedPersister to return. > It affects the sub-Attributes information. We could just return "one of > them" and deal with it for Alpha1, but we should answer what we want to do > there long term. > > Collectively, these persisters now implement the JPA ManagedType model > directly. Another addition was the creation of ManagedTypeImplementor, > IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the > persister hierarchy. Which means we can now directly return them in our > JPA Metamodel impl. > > That also means implementing JPA's notion of Attributes. I also needed > something similar for SQM's Navigable contract. Plus I have been working > towards changing how Hibernate understands Attributes internally > (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed > well. > > There are some things we should discuss too in terms of user impact. We > know up front that we need to move to reading values from JDBC ResultSets > positionally, as opposed to nominally which is how it was exposed in > Hibernate prior to 6.0. So we know already we will be asking implementors > and consumers of those contracts to make changes. Given that, we have > *some* liberty in changing these contracts some more. We just want to be > cognizant of (a) how much we change, (b) who it affects (use cases) and (c) > whether there are alternatives. For any use cases we determine to be > "valid" use cases, I think we need to make certain that there is some way > to handle that in the new alternatives. > > One use case, e.g., is setting Query parameters and being able to specify > its Type. To a degree we want to be able to continue to support that. But > I think we limit it to just references to org.hibernate.type.Type (though > "gutted") specifically and remove all others; and temporarily have the new > org.hibernate.type.spi.Type interface extend the old. This would allow > them to continue to get these org.hibernate.type.Type references in some > fashion and use them as Query parameter type hints. But I think we should > look at implementing some other parameter type "hints" like accepting > PersistentAttribute/Navigable references, JPA (static) metamodel > references, etc. These are better, as they would include things like > AttributeConverter whereas the Type reference would not. > > Sorry this got so long. I've had a lot floating around in my head the last > few days as I have worked on 6.0 and I wanted to bring them up for > discussion. The main thing I wonder about is what we mean by "custom > types" in terms of what exactly is being customized? And how does that > relate specifically to BasicType versus EmbeddedType versus ...? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > From andrea at hibernate.org Mon Jan 23 09:45:57 2017 From: andrea at hibernate.org (andrea boriero) Date: Mon, 23 Jan 2017 14:45:57 +0000 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: References: Message-ID: trying to find a valid reason to keep UserType but not able, so I'm for removing it. On 23 January 2017 at 14:36, Vlad Mihalcea wrote: > Hi, > > I see no reason why we should keep it indefinitely. I'd say we deprecate it > in 5.x, and remove it later (6.0 or 6.1). > Migrating a custom UserType to using Java and SQL descriptor is not > difficult, and we could just write a blog post for a step-by-step guide. > > Anyone in favor of keeping UserType? > > Vlad > > On Mon, Jan 23, 2017 at 4:11 PM, Steve Ebersole > wrote: > > > Nice! > > > > So if we keep UserType, we have to be clear that it has to change. I > also > > do not want to continue to support the other "user type extensions", > like: > > > > > > 1. org.hibernate.usertype.EnhancedUserType > > 2. org.hibernate.usertype.DynamicParameterizedType > > 3. org.hibernate.usertype.LoggableUserType > > 4. etc > > > > So we should come up with a plan for that. > > > > > > On Mon, Jan 23, 2017, 1:48 PM Vlad Mihalcea > > wrote: > > > > Hi, > > > > I like the SqlTypeDescriptor and JavaTypeDescriptor much better than > > UserType, which we should probably deprecate in 6.0. > > > > I wrote an article on my blog in which I demonstrate how to create a JSON > > type using JavaTypeDescriptor and SqlTypeDescriptor: > > > > https://vladmihalcea.com/2016/06/20/how-to-map-json-objects- > > using-generic-hibernate-types/ > > > > I like this example because it shows how you can reuse the same > > JavaTypeDescriptor for two different JSON SQL types: String or Binary, > > for which we have two distinct SqlTypeDescriptor objects. > > > > The new User Guide shows ho to implement Custom Types using the Java and > > SQL descriptors as well: > > > > http://docs.jboss.org/hibernate/orm/5.2/userguide/ > > html_single/Hibernate_User_Guide.html#basic-custom-type > > > > Vlad > > > > On Mon, Jan 23, 2017 at 3:37 PM, Steve Ebersole > > wrote: > > > > Right, and that exactly lines up with what I am proposing. > > > > If the intent of "customize" is to describe new Java types (e.g. Java 8 > > temporals prior to our explicit support) the tht is the role of a > > JavaTypeDescriptor, specifically a BasicJavaDescriptor. They would > > register a BasicJavaDescriptor describing the type. > > > > If the intent is to model a non-supported SQL type then that would mean > > adding a new SqlTypeDescriptor describing that type, although that will > > often also mean adding a new BasicJavaDescriptor describing the Java > > mapping of that SQL type. > > > > > > On Mon, Jan 23, 2017 at 7:00 AM Vlad Mihalcea > > wrote: > > > > Hi, > > > > Related to your questions: > > > > he main thing I wonder about is what we mean by "custom > > types" in terms of what exactly is being customized? And how does that > > relate specifically to BasicType versus EmbeddedType versus ...? > > > > > > Most of the time, the users want to take advantage of various database > > types that are not universally supported by all RDBMS: JSON, Money (SQL > > Server). > > > > On the Java side, I don't see what we can customize because we already > > provide all the basic types, and for everything else, users can compose > > those into Embeddables. The Java 1.8 Date/Time are an example of what > users > > would like to customize in case we didn't support this already. But even > if > > Java 1.9 adds other basic types, chances are that we are going to support > > them natively, meaning that users will still not need to add a custom > Type. > > > > So, I don't see how a Hibernate user will customize the way Embeddables, > > Enums, Entities or Collections are being stored or loaded from the > > database. The exception to the rule is a recent Pull Request from someone > > who wants to support PostgreSQL arrays. But this falls back into the same > > category as before: database types that are not universally supported by > > all RDBMS. > > > > Vlad > > > > On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea > > wrote: > > > > There's a lot to dig in here. I'll have to get the branch and study the > > changes, to come back with some opinions. > > > > Vlad > > > > On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole > > wrote: > > > > We are getting pretty far along on the 6.0 changes and I wanted to start > > a(nother) discussion about Types in 6.0 to get feedback and thoughts on a > > few topics. > > > > First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, > Types > > and "persisters"... > > > > (a lot of this is the same from pre-6.0, just making things more > explicit) > > > > JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so > let's > > start there. A JavaTypeDescriptor is a descriptor of a given Java type. > > That is, it provides Hibernate with information about the Java type. Is > it > > a numeric type? How do we compare 2 values of this type? How do we > make a > > deep copy of a value of this type? Etc. SqlTypeDescriptor is the same, > > but for a database type (VARCHAR, BLOB, etc). These 2 work together to > > perform reading and writing at the JDBC-level. > > > > We decided to broadly categorize JavaTypeDescriptors based on the JPA > type > > categorizations: > > > > 1. BASIC - BasicJavaDescriptor > > 1. TemporalJavaDescriptor > > 2. NumericJavaDescriptor > > 2. MANAGED - ManagedJavaDescriptor > > 1. EMBEDDABLE - EmbeddableJavaDescriptor > > 2. IDENTIFIABLE - IdentifiableJavaDescriptor > > 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor > > 2. ENTITY - EntityJavaDescriptor > > > > > > Type (org.hibernate.type.spi.Type) represents a combination of a > > JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a > > specific "non-root Navigable domain value". Navigable is a query-focused > > contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a > > high-level t is similar to JPA's Bindable except that it applies to > > Collection indices (or map-keys) and elements (or map-values) as well. > > Navigable essentially represents an named navigation one can perform in a > > query. The root Navigable is always an entity (EntityPersister). > > EntityPersister is the only Navigable that does not expose a Type. > (There > > is an EntityType, but it represents entity-valued non-root Navigables > such > > as a ManyToOne). All other navigables expose a Type. That is all a > > long-winded way to say that Types represents that Java/SqlTypeDescriptors > > for a role-based Navigable. > > > > Like the categorization discussed above for JavaTypeDescriptor, Type has > a > > similar categorization: > > > > 1. Type > > 1. BasicType > > 1. TemporalType > > 2. AnyType > > 3. ManagedType > > 1. EmbeddedType > > 2. IdentifiableType > > 1. MappedSuperclassType > > 2. EntityType > > > > It is important to keep in mind that these represents a specific > reference > > to thse things in regards to a Navigable. E.g. an EntityType is the > "type" > > of a SingularPersistentAttribute that is a ManyToOne - it points to the > > corresponding EntityPersister but it also represents the FK columns to > > refer to the entity. It is a role-based Navigable. > > > > Historically reads and writes have all routed through the Type (with > > certain Types delegating much of that to persisters). That will no > longer > > be the case in 6.0 as one of the main design goals for 6.0 is to re-write > > how Hibernate reads and writes (mainly reads) values from JDBC. The > major > > shift here is to read all values from JDBC using a "SqlSelectionReader" > > equivalent to a BasicType. These values are read and held in an array > that > > "readers" then know how to access (positionally) and use. Most of that > > design is beyond the discussion here, but it useful to understand. It is > > discussed in the design.adoc in my orm-sqm poc repo for those curious. > > Long story, short... Types no longer directly implement JDBC read/write > > which we will come back to later. > > > > PersistentAttribute and the other Navigables now take a role in JDBC > > reads/writes. AttributeConverters and other read/write-related concerns > > have been moved to these contracts. Again, most of this is covered in > the > > mentioned design doc. > > > > Since Type no longer directly implements JDBC read/write operations I > think > > it is important to ask ourselves what exactly we see as "customizable" > wrt > > each Type. Is that different for each category, or the same across all > > Type categories? E.g. I know of no customization of EntityType as it > > exists in 5.x, and tbh I am not even sure what that would mean. > BasicType > > obviously has some parts that we want to allow users to override, but is > > that really best achieved through a custom BasicType? Or is it better > > served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or > > SqlSelectionReader? What about EmbeddedType? CollectionType? This > would > > affect @TypeDef and Type registration methods specific to customizations. > > > > Persisters for the most part continue to serve the same role they have in > > the past with a few additions and some changes... > > > > One addition was the creation of an EmbeddedPersister. *Embedded*. > This, > > like CollectionPersister, models a "role" e.g. "Person.name" as opposed > to > > the Embeddable Name.class. Note however that JPA calls it an > > EmbeddableType and expects info about the Embeddable (the Class). > > EmbeddedPersister is role-based (Embedded) instead, which is a mismatch. > > In the case there are more than 1 usage of the Embeddable in different > > Embedded roles then we have to decide which EmbeddedPersister to return. > > It affects the sub-Attributes information. We could just return "one of > > them" and deal with it for Alpha1, but we should answer what we want to > do > > there long term. > > > > Collectively, these persisters now implement the JPA ManagedType model > > directly. Another addition was the creation of ManagedTypeImplementor, > > IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the > > persister hierarchy. Which means we can now directly return them in our > > JPA Metamodel impl. > > > > That also means implementing JPA's notion of Attributes. I also needed > > something similar for SQM's Navigable contract. Plus I have been working > > towards changing how Hibernate understands Attributes internally > > (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed > > well. > > > > There are some things we should discuss too in terms of user impact. We > > know up front that we need to move to reading values from JDBC ResultSets > > positionally, as opposed to nominally which is how it was exposed in > > Hibernate prior to 6.0. So we know already we will be asking > implementors > > and consumers of those contracts to make changes. Given that, we have > > *some* liberty in changing these contracts some more. We just want to be > > cognizant of (a) how much we change, (b) who it affects (use cases) and > (c) > > whether there are alternatives. For any use cases we determine to be > > "valid" use cases, I think we need to make certain that there is some way > > to handle that in the new alternatives. > > > > One use case, e.g., is setting Query parameters and being able to specify > > its Type. To a degree we want to be able to continue to support that. > But > > I think we limit it to just references to org.hibernate.type.Type (though > > "gutted") specifically and remove all others; and temporarily have the > new > > org.hibernate.type.spi.Type interface extend the old. This would allow > > them to continue to get these org.hibernate.type.Type references in some > > fashion and use them as Query parameter type hints. But I think we > should > > look at implementing some other parameter type "hints" like accepting > > PersistentAttribute/Navigable references, JPA (static) metamodel > > references, etc. These are better, as they would include things like > > AttributeConverter whereas the Type reference would not. > > > > Sorry this got so long. I've had a lot floating around in my head the > last > > few days as I have worked on 6.0 and I wanted to bring them up for > > discussion. The main thing I wonder about is what we mean by "custom > > types" in terms of what exactly is being customized? And how does that > > relate specifically to BasicType versus EmbeddedType versus ...? > > _______________________________________________ > > 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 christian.beikov at gmail.com Mon Jan 23 12:10:48 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Mon, 23 Jan 2017 18:10:48 +0100 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: References: Message-ID: <2253a424-8b3b-f7e5-48b6-4be1694a54e5@gmail.com> Since custom JavaTypeDescriptors and SqlTypeDescriptors can be used instead, I'm also for removing it. Am 23.01.2017 um 15:45 schrieb andrea boriero: > trying to find a valid reason to keep UserType but not able, so I'm for > removing it. > > On 23 January 2017 at 14:36, Vlad Mihalcea wrote: > >> Hi, >> >> I see no reason why we should keep it indefinitely. I'd say we deprecate it >> in 5.x, and remove it later (6.0 or 6.1). >> Migrating a custom UserType to using Java and SQL descriptor is not >> difficult, and we could just write a blog post for a step-by-step guide. >> >> Anyone in favor of keeping UserType? >> >> Vlad >> >> On Mon, Jan 23, 2017 at 4:11 PM, Steve Ebersole >> wrote: >> >>> Nice! >>> >>> So if we keep UserType, we have to be clear that it has to change. I >> also >>> do not want to continue to support the other "user type extensions", >> like: >>> >>> 1. org.hibernate.usertype.EnhancedUserType >>> 2. org.hibernate.usertype.DynamicParameterizedType >>> 3. org.hibernate.usertype.LoggableUserType >>> 4. etc >>> >>> So we should come up with a plan for that. >>> >>> >>> On Mon, Jan 23, 2017, 1:48 PM Vlad Mihalcea >>> wrote: >>> >>> Hi, >>> >>> I like the SqlTypeDescriptor and JavaTypeDescriptor much better than >>> UserType, which we should probably deprecate in 6.0. >>> >>> I wrote an article on my blog in which I demonstrate how to create a JSON >>> type using JavaTypeDescriptor and SqlTypeDescriptor: >>> >>> https://vladmihalcea.com/2016/06/20/how-to-map-json-objects- >>> using-generic-hibernate-types/ >>> >>> I like this example because it shows how you can reuse the same >>> JavaTypeDescriptor for two different JSON SQL types: String or Binary, >>> for which we have two distinct SqlTypeDescriptor objects. >>> >>> The new User Guide shows ho to implement Custom Types using the Java and >>> SQL descriptors as well: >>> >>> http://docs.jboss.org/hibernate/orm/5.2/userguide/ >>> html_single/Hibernate_User_Guide.html#basic-custom-type >>> >>> Vlad >>> >>> On Mon, Jan 23, 2017 at 3:37 PM, Steve Ebersole >>> wrote: >>> >>> Right, and that exactly lines up with what I am proposing. >>> >>> If the intent of "customize" is to describe new Java types (e.g. Java 8 >>> temporals prior to our explicit support) the tht is the role of a >>> JavaTypeDescriptor, specifically a BasicJavaDescriptor. They would >>> register a BasicJavaDescriptor describing the type. >>> >>> If the intent is to model a non-supported SQL type then that would mean >>> adding a new SqlTypeDescriptor describing that type, although that will >>> often also mean adding a new BasicJavaDescriptor describing the Java >>> mapping of that SQL type. >>> >>> >>> On Mon, Jan 23, 2017 at 7:00 AM Vlad Mihalcea >>> wrote: >>> >>> Hi, >>> >>> Related to your questions: >>> >>> he main thing I wonder about is what we mean by "custom >>> types" in terms of what exactly is being customized? And how does that >>> relate specifically to BasicType versus EmbeddedType versus ...? >>> >>> >>> Most of the time, the users want to take advantage of various database >>> types that are not universally supported by all RDBMS: JSON, Money (SQL >>> Server). >>> >>> On the Java side, I don't see what we can customize because we already >>> provide all the basic types, and for everything else, users can compose >>> those into Embeddables. The Java 1.8 Date/Time are an example of what >> users >>> would like to customize in case we didn't support this already. But even >> if >>> Java 1.9 adds other basic types, chances are that we are going to support >>> them natively, meaning that users will still not need to add a custom >> Type. >>> So, I don't see how a Hibernate user will customize the way Embeddables, >>> Enums, Entities or Collections are being stored or loaded from the >>> database. The exception to the rule is a recent Pull Request from someone >>> who wants to support PostgreSQL arrays. But this falls back into the same >>> category as before: database types that are not universally supported by >>> all RDBMS. >>> >>> Vlad >>> >>> On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea >>> wrote: >>> >>> There's a lot to dig in here. I'll have to get the branch and study the >>> changes, to come back with some opinions. >>> >>> Vlad >>> >>> On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole >>> wrote: >>> >>> We are getting pretty far along on the 6.0 changes and I wanted to start >>> a(nother) discussion about Types in 6.0 to get feedback and thoughts on a >>> few topics. >>> >>> First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, >> Types >>> and "persisters"... >>> >>> (a lot of this is the same from pre-6.0, just making things more >> explicit) >>> JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so >> let's >>> start there. A JavaTypeDescriptor is a descriptor of a given Java type. >>> That is, it provides Hibernate with information about the Java type. Is >> it >>> a numeric type? How do we compare 2 values of this type? How do we >> make a >>> deep copy of a value of this type? Etc. SqlTypeDescriptor is the same, >>> but for a database type (VARCHAR, BLOB, etc). These 2 work together to >>> perform reading and writing at the JDBC-level. >>> >>> We decided to broadly categorize JavaTypeDescriptors based on the JPA >> type >>> categorizations: >>> >>> 1. BASIC - BasicJavaDescriptor >>> 1. TemporalJavaDescriptor >>> 2. NumericJavaDescriptor >>> 2. MANAGED - ManagedJavaDescriptor >>> 1. EMBEDDABLE - EmbeddableJavaDescriptor >>> 2. IDENTIFIABLE - IdentifiableJavaDescriptor >>> 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor >>> 2. ENTITY - EntityJavaDescriptor >>> >>> >>> Type (org.hibernate.type.spi.Type) represents a combination of a >>> JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a >>> specific "non-root Navigable domain value". Navigable is a query-focused >>> contract (SQM/HQL/Criteria) so I wont get too deep into that here. At a >>> high-level t is similar to JPA's Bindable except that it applies to >>> Collection indices (or map-keys) and elements (or map-values) as well. >>> Navigable essentially represents an named navigation one can perform in a >>> query. The root Navigable is always an entity (EntityPersister). >>> EntityPersister is the only Navigable that does not expose a Type. >> (There >>> is an EntityType, but it represents entity-valued non-root Navigables >> such >>> as a ManyToOne). All other navigables expose a Type. That is all a >>> long-winded way to say that Types represents that Java/SqlTypeDescriptors >>> for a role-based Navigable. >>> >>> Like the categorization discussed above for JavaTypeDescriptor, Type has >> a >>> similar categorization: >>> >>> 1. Type >>> 1. BasicType >>> 1. TemporalType >>> 2. AnyType >>> 3. ManagedType >>> 1. EmbeddedType >>> 2. IdentifiableType >>> 1. MappedSuperclassType >>> 2. EntityType >>> >>> It is important to keep in mind that these represents a specific >> reference >>> to thse things in regards to a Navigable. E.g. an EntityType is the >> "type" >>> of a SingularPersistentAttribute that is a ManyToOne - it points to the >>> corresponding EntityPersister but it also represents the FK columns to >>> refer to the entity. It is a role-based Navigable. >>> >>> Historically reads and writes have all routed through the Type (with >>> certain Types delegating much of that to persisters). That will no >> longer >>> be the case in 6.0 as one of the main design goals for 6.0 is to re-write >>> how Hibernate reads and writes (mainly reads) values from JDBC. The >> major >>> shift here is to read all values from JDBC using a "SqlSelectionReader" >>> equivalent to a BasicType. These values are read and held in an array >> that >>> "readers" then know how to access (positionally) and use. Most of that >>> design is beyond the discussion here, but it useful to understand. It is >>> discussed in the design.adoc in my orm-sqm poc repo for those curious. >>> Long story, short... Types no longer directly implement JDBC read/write >>> which we will come back to later. >>> >>> PersistentAttribute and the other Navigables now take a role in JDBC >>> reads/writes. AttributeConverters and other read/write-related concerns >>> have been moved to these contracts. Again, most of this is covered in >> the >>> mentioned design doc. >>> >>> Since Type no longer directly implements JDBC read/write operations I >> think >>> it is important to ask ourselves what exactly we see as "customizable" >> wrt >>> each Type. Is that different for each category, or the same across all >>> Type categories? E.g. I know of no customization of EntityType as it >>> exists in 5.x, and tbh I am not even sure what that would mean. >> BasicType >>> obviously has some parts that we want to allow users to override, but is >>> that really best achieved through a custom BasicType? Or is it better >>> served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or >>> SqlSelectionReader? What about EmbeddedType? CollectionType? This >> would >>> affect @TypeDef and Type registration methods specific to customizations. >>> >>> Persisters for the most part continue to serve the same role they have in >>> the past with a few additions and some changes... >>> >>> One addition was the creation of an EmbeddedPersister. *Embedded*. >> This, >>> like CollectionPersister, models a "role" e.g. "Person.name" as opposed >> to >>> the Embeddable Name.class. Note however that JPA calls it an >>> EmbeddableType and expects info about the Embeddable (the Class). >>> EmbeddedPersister is role-based (Embedded) instead, which is a mismatch. >>> In the case there are more than 1 usage of the Embeddable in different >>> Embedded roles then we have to decide which EmbeddedPersister to return. >>> It affects the sub-Attributes information. We could just return "one of >>> them" and deal with it for Alpha1, but we should answer what we want to >> do >>> there long term. >>> >>> Collectively, these persisters now implement the JPA ManagedType model >>> directly. Another addition was the creation of ManagedTypeImplementor, >>> IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the >>> persister hierarchy. Which means we can now directly return them in our >>> JPA Metamodel impl. >>> >>> That also means implementing JPA's notion of Attributes. I also needed >>> something similar for SQM's Navigable contract. Plus I have been working >>> towards changing how Hibernate understands Attributes internally >>> (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed >>> well. >>> >>> There are some things we should discuss too in terms of user impact. We >>> know up front that we need to move to reading values from JDBC ResultSets >>> positionally, as opposed to nominally which is how it was exposed in >>> Hibernate prior to 6.0. So we know already we will be asking >> implementors >>> and consumers of those contracts to make changes. Given that, we have >>> *some* liberty in changing these contracts some more. We just want to be >>> cognizant of (a) how much we change, (b) who it affects (use cases) and >> (c) >>> whether there are alternatives. For any use cases we determine to be >>> "valid" use cases, I think we need to make certain that there is some way >>> to handle that in the new alternatives. >>> >>> One use case, e.g., is setting Query parameters and being able to specify >>> its Type. To a degree we want to be able to continue to support that. >> But >>> I think we limit it to just references to org.hibernate.type.Type (though >>> "gutted") specifically and remove all others; and temporarily have the >> new >>> org.hibernate.type.spi.Type interface extend the old. This would allow >>> them to continue to get these org.hibernate.type.Type references in some >>> fashion and use them as Query parameter type hints. But I think we >> should >>> look at implementing some other parameter type "hints" like accepting >>> PersistentAttribute/Navigable references, JPA (static) metamodel >>> references, etc. These are better, as they would include things like >>> AttributeConverter whereas the Type reference would not. >>> >>> Sorry this got so long. I've had a lot floating around in my head the >> last >>> few days as I have worked on 6.0 and I wanted to bring them up for >>> discussion. The main thing I wonder about is what we mean by "custom >>> types" in terms of what exactly is being customized? And how does that >>> relate specifically to BasicType versus EmbeddedType versus ...? >>> _______________________________________________ >>> 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 Mon Jan 23 12:37:27 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 23 Jan 2017 17:37:27 +0000 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: <2253a424-8b3b-f7e5-48b6-4be1694a54e5@gmail.com> References: <2253a424-8b3b-f7e5-48b6-4be1694a54e5@gmail.com> Message-ID: What is everyone's opinion of the following sections? There are some things we should discuss too in terms of user impact. We know up front that we need to move to reading values from JDBC ResultSets positionally, as opposed to nominally which is how it was exposed in Hibernate prior to 6.0. So we know already we will be asking implementors and consumers of those contracts to make changes. Given that, we have *some* liberty in changing these contracts some more. We just want to be cognizant of (a) how much we change, (b) who it affects (use cases) and (c) whether there are alternatives. For any use cases we determine to be "valid" use cases, I think we need to make certain that there is some way to handle that in the new alternatives. One use case, e.g., is setting Query parameters and being able to specify its Type. To a degree we want to be able to continue to support that. But I think we limit it to just references to org.hibernate.type.Type (though "gutted") specifically and remove all others; and temporarily have the new org.hibernate.type.spi.Type interface extend the old. This would allow them to continue to get these org.hibernate.type.Type references in some fashion and use them as Query parameter type hints. But I think we should look at implementing some other parameter type "hints" like accepting PersistentAttribute/Navigable references, JPA (static) metamodel references, etc. These are better, as they would include things like AttributeConverter whereas the Type reference would not. On Mon, Jan 23, 2017 at 11:13 AM Christian Beikov < christian.beikov at gmail.com> wrote: > Since custom JavaTypeDescriptors and SqlTypeDescriptors can be used > instead, I'm also for removing it. > > Am 23.01.2017 um 15:45 schrieb andrea boriero: > > trying to find a valid reason to keep UserType but not able, so I'm for > > removing it. > > > > On 23 January 2017 at 14:36, Vlad Mihalcea > wrote: > > > >> Hi, > >> > >> I see no reason why we should keep it indefinitely. I'd say we > deprecate it > >> in 5.x, and remove it later (6.0 or 6.1). > >> Migrating a custom UserType to using Java and SQL descriptor is not > >> difficult, and we could just write a blog post for a step-by-step guide. > >> > >> Anyone in favor of keeping UserType? > >> > >> Vlad > >> > >> On Mon, Jan 23, 2017 at 4:11 PM, Steve Ebersole > >> wrote: > >> > >>> Nice! > >>> > >>> So if we keep UserType, we have to be clear that it has to change. I > >> also > >>> do not want to continue to support the other "user type extensions", > >> like: > >>> > >>> 1. org.hibernate.usertype.EnhancedUserType > >>> 2. org.hibernate.usertype.DynamicParameterizedType > >>> 3. org.hibernate.usertype.LoggableUserType > >>> 4. etc > >>> > >>> So we should come up with a plan for that. > >>> > >>> > >>> On Mon, Jan 23, 2017, 1:48 PM Vlad Mihalcea > >>> wrote: > >>> > >>> Hi, > >>> > >>> I like the SqlTypeDescriptor and JavaTypeDescriptor much better than > >>> UserType, which we should probably deprecate in 6.0. > >>> > >>> I wrote an article on my blog in which I demonstrate how to create a > JSON > >>> type using JavaTypeDescriptor and SqlTypeDescriptor: > >>> > >>> https://vladmihalcea.com/2016/06/20/how-to-map-json-objects- > >>> using-generic-hibernate-types/ > >>> > >>> I like this example because it shows how you can reuse the same > >>> JavaTypeDescriptor for two different JSON SQL types: String or Binary, > >>> for which we have two distinct SqlTypeDescriptor objects. > >>> > >>> The new User Guide shows ho to implement Custom Types using the Java > and > >>> SQL descriptors as well: > >>> > >>> http://docs.jboss.org/hibernate/orm/5.2/userguide/ > >>> html_single/Hibernate_User_Guide.html#basic-custom-type > >>> > >>> Vlad > >>> > >>> On Mon, Jan 23, 2017 at 3:37 PM, Steve Ebersole > >>> wrote: > >>> > >>> Right, and that exactly lines up with what I am proposing. > >>> > >>> If the intent of "customize" is to describe new Java types (e.g. Java 8 > >>> temporals prior to our explicit support) the tht is the role of a > >>> JavaTypeDescriptor, specifically a BasicJavaDescriptor. They would > >>> register a BasicJavaDescriptor describing the type. > >>> > >>> If the intent is to model a non-supported SQL type then that would mean > >>> adding a new SqlTypeDescriptor describing that type, although that will > >>> often also mean adding a new BasicJavaDescriptor describing the Java > >>> mapping of that SQL type. > >>> > >>> > >>> On Mon, Jan 23, 2017 at 7:00 AM Vlad Mihalcea > > >>> wrote: > >>> > >>> Hi, > >>> > >>> Related to your questions: > >>> > >>> he main thing I wonder about is what we mean by "custom > >>> types" in terms of what exactly is being customized? And how does that > >>> relate specifically to BasicType versus EmbeddedType versus ...? > >>> > >>> > >>> Most of the time, the users want to take advantage of various database > >>> types that are not universally supported by all RDBMS: JSON, Money (SQL > >>> Server). > >>> > >>> On the Java side, I don't see what we can customize because we already > >>> provide all the basic types, and for everything else, users can compose > >>> those into Embeddables. The Java 1.8 Date/Time are an example of what > >> users > >>> would like to customize in case we didn't support this already. But > even > >> if > >>> Java 1.9 adds other basic types, chances are that we are going to > support > >>> them natively, meaning that users will still not need to add a custom > >> Type. > >>> So, I don't see how a Hibernate user will customize the way > Embeddables, > >>> Enums, Entities or Collections are being stored or loaded from the > >>> database. The exception to the rule is a recent Pull Request from > someone > >>> who wants to support PostgreSQL arrays. But this falls back into the > same > >>> category as before: database types that are not universally supported > by > >>> all RDBMS. > >>> > >>> Vlad > >>> > >>> On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea < > mihalcea.vlad at gmail.com> > >>> wrote: > >>> > >>> There's a lot to dig in here. I'll have to get the branch and study the > >>> changes, to come back with some opinions. > >>> > >>> Vlad > >>> > >>> On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole > >>> wrote: > >>> > >>> We are getting pretty far along on the 6.0 changes and I wanted to > start > >>> a(nother) discussion about Types in 6.0 to get feedback and thoughts > on a > >>> few topics. > >>> > >>> First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, > >> Types > >>> and "persisters"... > >>> > >>> (a lot of this is the same from pre-6.0, just making things more > >> explicit) > >>> JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so > >> let's > >>> start there. A JavaTypeDescriptor is a descriptor of a given Java > type. > >>> That is, it provides Hibernate with information about the Java type. > Is > >> it > >>> a numeric type? How do we compare 2 values of this type? How do we > >> make a > >>> deep copy of a value of this type? Etc. SqlTypeDescriptor is the > same, > >>> but for a database type (VARCHAR, BLOB, etc). These 2 work together to > >>> perform reading and writing at the JDBC-level. > >>> > >>> We decided to broadly categorize JavaTypeDescriptors based on the JPA > >> type > >>> categorizations: > >>> > >>> 1. BASIC - BasicJavaDescriptor > >>> 1. TemporalJavaDescriptor > >>> 2. NumericJavaDescriptor > >>> 2. MANAGED - ManagedJavaDescriptor > >>> 1. EMBEDDABLE - EmbeddableJavaDescriptor > >>> 2. IDENTIFIABLE - IdentifiableJavaDescriptor > >>> 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor > >>> 2. ENTITY - EntityJavaDescriptor > >>> > >>> > >>> Type (org.hibernate.type.spi.Type) represents a combination of a > >>> JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a > >>> specific "non-root Navigable domain value". Navigable is a > query-focused > >>> contract (SQM/HQL/Criteria) so I wont get too deep into that here. At > a > >>> high-level t is similar to JPA's Bindable except that it applies to > >>> Collection indices (or map-keys) and elements (or map-values) as well. > >>> Navigable essentially represents an named navigation one can perform > in a > >>> query. The root Navigable is always an entity (EntityPersister). > >>> EntityPersister is the only Navigable that does not expose a Type. > >> (There > >>> is an EntityType, but it represents entity-valued non-root Navigables > >> such > >>> as a ManyToOne). All other navigables expose a Type. That is all a > >>> long-winded way to say that Types represents that > Java/SqlTypeDescriptors > >>> for a role-based Navigable. > >>> > >>> Like the categorization discussed above for JavaTypeDescriptor, Type > has > >> a > >>> similar categorization: > >>> > >>> 1. Type > >>> 1. BasicType > >>> 1. TemporalType > >>> 2. AnyType > >>> 3. ManagedType > >>> 1. EmbeddedType > >>> 2. IdentifiableType > >>> 1. MappedSuperclassType > >>> 2. EntityType > >>> > >>> It is important to keep in mind that these represents a specific > >> reference > >>> to thse things in regards to a Navigable. E.g. an EntityType is the > >> "type" > >>> of a SingularPersistentAttribute that is a ManyToOne - it points to the > >>> corresponding EntityPersister but it also represents the FK columns to > >>> refer to the entity. It is a role-based Navigable. > >>> > >>> Historically reads and writes have all routed through the Type (with > >>> certain Types delegating much of that to persisters). That will no > >> longer > >>> be the case in 6.0 as one of the main design goals for 6.0 is to > re-write > >>> how Hibernate reads and writes (mainly reads) values from JDBC. The > >> major > >>> shift here is to read all values from JDBC using a "SqlSelectionReader" > >>> equivalent to a BasicType. These values are read and held in an array > >> that > >>> "readers" then know how to access (positionally) and use. Most of that > >>> design is beyond the discussion here, but it useful to understand. It > is > >>> discussed in the design.adoc in my orm-sqm poc repo for those curious. > >>> Long story, short... Types no longer directly implement JDBC read/write > >>> which we will come back to later. > >>> > >>> PersistentAttribute and the other Navigables now take a role in JDBC > >>> reads/writes. AttributeConverters and other read/write-related > concerns > >>> have been moved to these contracts. Again, most of this is covered in > >> the > >>> mentioned design doc. > >>> > >>> Since Type no longer directly implements JDBC read/write operations I > >> think > >>> it is important to ask ourselves what exactly we see as "customizable" > >> wrt > >>> each Type. Is that different for each category, or the same across all > >>> Type categories? E.g. I know of no customization of EntityType as it > >>> exists in 5.x, and tbh I am not even sure what that would mean. > >> BasicType > >>> obviously has some parts that we want to allow users to override, but > is > >>> that really best achieved through a custom BasicType? Or is it better > >>> served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or > >>> SqlSelectionReader? What about EmbeddedType? CollectionType? This > >> would > >>> affect @TypeDef and Type registration methods specific to > customizations. > >>> > >>> Persisters for the most part continue to serve the same role they have > in > >>> the past with a few additions and some changes... > >>> > >>> One addition was the creation of an EmbeddedPersister. *Embedded*. > >> This, > >>> like CollectionPersister, models a "role" e.g. "Person.name" as opposed > >> to > >>> the Embeddable Name.class. Note however that JPA calls it an > >>> EmbeddableType and expects info about the Embeddable (the Class). > >>> EmbeddedPersister is role-based (Embedded) instead, which is a > mismatch. > >>> In the case there are more than 1 usage of the Embeddable in different > >>> Embedded roles then we have to decide which EmbeddedPersister to > return. > >>> It affects the sub-Attributes information. We could just return "one > of > >>> them" and deal with it for Alpha1, but we should answer what we want to > >> do > >>> there long term. > >>> > >>> Collectively, these persisters now implement the JPA ManagedType model > >>> directly. Another addition was the creation of ManagedTypeImplementor, > >>> IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the > >>> persister hierarchy. Which means we can now directly return them in > our > >>> JPA Metamodel impl. > >>> > >>> That also means implementing JPA's notion of Attributes. I also needed > >>> something similar for SQM's Navigable contract. Plus I have been > working > >>> towards changing how Hibernate understands Attributes internally > >>> (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed > >>> well. > >>> > >>> There are some things we should discuss too in terms of user impact. > We > >>> know up front that we need to move to reading values from JDBC > ResultSets > >>> positionally, as opposed to nominally which is how it was exposed in > >>> Hibernate prior to 6.0. So we know already we will be asking > >> implementors > >>> and consumers of those contracts to make changes. Given that, we have > >>> *some* liberty in changing these contracts some more. We just want to > be > >>> cognizant of (a) how much we change, (b) who it affects (use cases) and > >> (c) > >>> whether there are alternatives. For any use cases we determine to be > >>> "valid" use cases, I think we need to make certain that there is some > way > >>> to handle that in the new alternatives. > >>> > >>> One use case, e.g., is setting Query parameters and being able to > specify > >>> its Type. To a degree we want to be able to continue to support that. > >> But > >>> I think we limit it to just references to org.hibernate.type.Type > (though > >>> "gutted") specifically and remove all others; and temporarily have the > >> new > >>> org.hibernate.type.spi.Type interface extend the old. This would allow > >>> them to continue to get these org.hibernate.type.Type references in > some > >>> fashion and use them as Query parameter type hints. But I think we > >> should > >>> look at implementing some other parameter type "hints" like accepting > >>> PersistentAttribute/Navigable references, JPA (static) metamodel > >>> references, etc. These are better, as they would include things like > >>> AttributeConverter whereas the Type reference would not. > >>> > >>> Sorry this got so long. I've had a lot floating around in my head the > >> last > >>> few days as I have worked on 6.0 and I wanted to bring them up for > >>> discussion. The main thing I wonder about is what we mean by "custom > >>> types" in terms of what exactly is being customized? And how does that > >>> relate specifically to BasicType versus EmbeddedType versus ...? > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From candrews at integralblue.com Mon Jan 23 14:16:01 2017 From: candrews at integralblue.com (Craig Andrews) Date: Mon, 23 Jan 2017 14:16:01 -0500 Subject: [hibernate-dev] Spring Cache integration Message-ID: <8dc92140ea1ea10f52f97d8b141f96dd@integralblue.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Following up on the thread from November [1], I'd really like to have a decision made on this topic. To recap, I'm requesting that my PR [2] be reviewed and, with any suggested changes made, merged. to add an adapter to Hibernate allowing it to use the Spring Cache Abstraction as a Hibernate second level cache. This integration would allow Hibernate to use a variety of caching systems supported by Spring in a simple, and if used with Spring Boot, virtually automatic way. I think it would be useful for a number of variety of projects and Hibernate seems like the right place for it. The change builds upon the work already done for Ehcache. Thank you, ~Craig [1] https://lists.jboss.org/pipermail/hibernate-dev/2016-November/015596.html [2] https://github.com/hibernate/hibernate-orm/pull/1639 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyTC1jmTRjNyKWaNhRYmxbEYasJIFAliGVnIACgkQRYmxbEYa sJLodxAA4GG1+/vkHiVv6nbXUCClEpFmaDOtl5sUcU6Pa2oOYKXH+spd3h/Yjl3b hNjTH/iCQ9U3gMy3xLT0R2RDrE7ZyO9TQwE62K7ypqXF9k4i7twRI9a7qV26yP3x DbZ3AlJ0SZKl3Fsl3f3mZPPrgX7Q11J5/lZTAHHAqk1d8GmGR41SzjdZa/Jx/ggk SJGb5+IQV1UNh5sQkQ5mF7aCFnkEf/0XYaywOQH+nx9rqh+FO7HgEIO47o0Up8Cj ly6Rqem/7Up7fWNlrbooly8ePR13Zt/hYX6qkr+JHd6VDkUyN+qUmV8pPqOhe11J sEfxSYJPV09PAcSALgt6Kjk9kTIlHZbn0cKA6ES5SRHQR2iPUTxT2B/4JVfFmfgC nCFtFGI9kVYJeMaYDlLQtLnGa7vQmD8uC/OXx7j75a0RdVIJjQHlnSujeGkYYdbC f24G/ZbMr7/plxsw1kRM/3R0e5nVIdjiWlQ5uceUVgccernjrIlJ/cFGg9WwCZb0 AX9pN7ZuoGXsXyD8D4LN3/FiZRZ1j7CTI8FJNeYQ4aOwM0aAVRTmvaURiz4rD329 HLZVXZuF4dj8vJITN2Epi9Q4Ez079Spc7lL+xgZ6o19M83540SufHDBlDA4qUEYs 9WzQEq49devAZbQEb0h6rMFvWF6V2vDmWD85e40g1i621FddkBU= =adUY -----END PGP SIGNATURE----- From christian.beikov at gmail.com Tue Jan 24 18:52:42 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Wed, 25 Jan 2017 00:52:42 +0100 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: References: <2253a424-8b3b-f7e5-48b6-4be1694a54e5@gmail.com> Message-ID: Sounds like what we have discussed today and as far as I can remember, nobody complained about removing the type spi stuff. I think we might want to prepare a blog post or topical/migration guide that helps people to migrate their custom types to the new way of doing it. Am 23.01.2017 um 18:37 schrieb Steve Ebersole: > What is everyone's opinion of the following sections? > > > There are some things we should discuss too in terms of user impact. > We know up front that we need to move to reading values from JDBC > ResultSets positionally, as opposed to nominally which is how it was > exposed in Hibernate prior to 6.0. So we know already we will be > asking implementors and consumers of those contracts to make changes. > Given that, we have *some* liberty in changing these contracts some > more. We just want to be cognizant of (a) how much we change, (b) who > it affects (use cases) and (c) whether there are alternatives. For any > use cases we determine to be "valid" use cases, I think we need to > make certain that there is some way to handle that in the new > alternatives. > > One use case, e.g., is setting Query parameters and being able to > specify its Type. To a degree we want to be able to continue to > support that. But I think we limit it to just references to > org.hibernate.type.Type (though "gutted") specifically and remove all > others; and temporarily have the new org.hibernate.type.spi.Type > interface extend the old. This would allow them to continue to get > these org.hibernate.type.Type references in some fashion and use them > as Query parameter type hints. But I think we should look at > implementing some other parameter type "hints" like accepting > PersistentAttribute/Navigable references, JPA (static) metamodel > references, etc. These are better, as they would include things like > AttributeConverter whereas the Type reference would not. > > > > On Mon, Jan 23, 2017 at 11:13 AM Christian Beikov > > wrote: > > Since custom JavaTypeDescriptors and SqlTypeDescriptors can be used > instead, I'm also for removing it. > > Am 23.01.2017 um 15:45 schrieb andrea boriero: > > trying to find a valid reason to keep UserType but not able, so > I'm for > > removing it. > > > > On 23 January 2017 at 14:36, Vlad Mihalcea > > wrote: > > > >> Hi, > >> > >> I see no reason why we should keep it indefinitely. I'd say we > deprecate it > >> in 5.x, and remove it later (6.0 or 6.1). > >> Migrating a custom UserType to using Java and SQL descriptor is not > >> difficult, and we could just write a blog post for a > step-by-step guide. > >> > >> Anyone in favor of keeping UserType? > >> > >> Vlad > >> > >> On Mon, Jan 23, 2017 at 4:11 PM, Steve Ebersole > > > >> wrote: > >> > >>> Nice! > >>> > >>> So if we keep UserType, we have to be clear that it has to > change. I > >> also > >>> do not want to continue to support the other "user type > extensions", > >> like: > >>> > >>> 1. org.hibernate.usertype.EnhancedUserType > >>> 2. org.hibernate.usertype.DynamicParameterizedType > >>> 3. org.hibernate.usertype.LoggableUserType > >>> 4. etc > >>> > >>> So we should come up with a plan for that. > >>> > >>> > >>> On Mon, Jan 23, 2017, 1:48 PM Vlad Mihalcea > > > >>> wrote: > >>> > >>> Hi, > >>> > >>> I like the SqlTypeDescriptor and JavaTypeDescriptor much > better than > >>> UserType, which we should probably deprecate in 6.0. > >>> > >>> I wrote an article on my blog in which I demonstrate how to > create a JSON > >>> type using JavaTypeDescriptor and SqlTypeDescriptor: > >>> > >>> https://vladmihalcea.com/2016/06/20/how-to-map-json-objects- > >>> using-generic-hibernate-types/ > >>> > >>> I like this example because it shows how you can reuse the same > >>> JavaTypeDescriptor for two different JSON SQL types: String or > Binary, > >>> for which we have two distinct SqlTypeDescriptor objects. > >>> > >>> The new User Guide shows ho to implement Custom Types using > the Java and > >>> SQL descriptors as well: > >>> > >>> http://docs.jboss.org/hibernate/orm/5.2/userguide/ > >>> html_single/Hibernate_User_Guide.html#basic-custom-type > >>> > >>> Vlad > >>> > >>> On Mon, Jan 23, 2017 at 3:37 PM, Steve Ebersole > > > >>> wrote: > >>> > >>> Right, and that exactly lines up with what I am proposing. > >>> > >>> If the intent of "customize" is to describe new Java types > (e.g. Java 8 > >>> temporals prior to our explicit support) the tht is the role of a > >>> JavaTypeDescriptor, specifically a BasicJavaDescriptor. They > would > >>> register a BasicJavaDescriptor describing the type. > >>> > >>> If the intent is to model a non-supported SQL type then that > would mean > >>> adding a new SqlTypeDescriptor describing that type, although > that will > >>> often also mean adding a new BasicJavaDescriptor describing > the Java > >>> mapping of that SQL type. > >>> > >>> > >>> On Mon, Jan 23, 2017 at 7:00 AM Vlad Mihalcea > > > >>> wrote: > >>> > >>> Hi, > >>> > >>> Related to your questions: > >>> > >>> he main thing I wonder about is what we mean by "custom > >>> types" in terms of what exactly is being customized? And how > does that > >>> relate specifically to BasicType versus EmbeddedType versus ...? > >>> > >>> > >>> Most of the time, the users want to take advantage of various > database > >>> types that are not universally supported by all RDBMS: JSON, > Money (SQL > >>> Server). > >>> > >>> On the Java side, I don't see what we can customize because we > already > >>> provide all the basic types, and for everything else, users > can compose > >>> those into Embeddables. The Java 1.8 Date/Time are an example > of what > >> users > >>> would like to customize in case we didn't support this > already. But even > >> if > >>> Java 1.9 adds other basic types, chances are that we are going > to support > >>> them natively, meaning that users will still not need to add a > custom > >> Type. > >>> So, I don't see how a Hibernate user will customize the way > Embeddables, > >>> Enums, Entities or Collections are being stored or loaded from the > >>> database. The exception to the rule is a recent Pull Request > from someone > >>> who wants to support PostgreSQL arrays. But this falls back > into the same > >>> category as before: database types that are not universally > supported by > >>> all RDBMS. > >>> > >>> Vlad > >>> > >>> On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea > > > >>> wrote: > >>> > >>> There's a lot to dig in here. I'll have to get the branch and > study the > >>> changes, to come back with some opinions. > >>> > >>> Vlad > >>> > >>> On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole > > > >>> wrote: > >>> > >>> We are getting pretty far along on the 6.0 changes and I > wanted to start > >>> a(nother) discussion about Types in 6.0 to get feedback and > thoughts on a > >>> few topics. > >>> > >>> First a quick break down of JavaTypeDescriptors, > SqlTypeDescriptors, > >> Types > >>> and "persisters"... > >>> > >>> (a lot of this is the same from pre-6.0, just making things more > >> explicit) > >>> JavaTypeDescriptors and SqlTypeDescriptors are the "lowest > level", so > >> let's > >>> start there. A JavaTypeDescriptor is a descriptor of a given > Java type. > >>> That is, it provides Hibernate with information about the Java > type. Is > >> it > >>> a numeric type? How do we compare 2 values of this type? How > do we > >> make a > >>> deep copy of a value of this type? Etc. SqlTypeDescriptor is > the same, > >>> but for a database type (VARCHAR, BLOB, etc). These 2 work > together to > >>> perform reading and writing at the JDBC-level. > >>> > >>> We decided to broadly categorize JavaTypeDescriptors based on > the JPA > >> type > >>> categorizations: > >>> > >>> 1. BASIC - BasicJavaDescriptor > >>> 1. TemporalJavaDescriptor > >>> 2. NumericJavaDescriptor > >>> 2. MANAGED - ManagedJavaDescriptor > >>> 1. EMBEDDABLE - EmbeddableJavaDescriptor > >>> 2. IDENTIFIABLE - IdentifiableJavaDescriptor > >>> 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor > >>> 2. ENTITY - EntityJavaDescriptor > >>> > >>> > >>> Type (org.hibernate.type.spi.Type) represents a combination of a > >>> JavaTypeDescriptor and one or more SqlTypeDescriptors in > relation to a > >>> specific "non-root Navigable domain value". Navigable is a > query-focused > >>> contract (SQM/HQL/Criteria) so I wont get too deep into that > here. At a > >>> high-level t is similar to JPA's Bindable except that it > applies to > >>> Collection indices (or map-keys) and elements (or map-values) > as well. > >>> Navigable essentially represents an named navigation one can > perform in a > >>> query. The root Navigable is always an entity (EntityPersister). > >>> EntityPersister is the only Navigable that does not expose a Type. > >> (There > >>> is an EntityType, but it represents entity-valued non-root > Navigables > >> such > >>> as a ManyToOne). All other navigables expose a Type. That is > all a > >>> long-winded way to say that Types represents that > Java/SqlTypeDescriptors > >>> for a role-based Navigable. > >>> > >>> Like the categorization discussed above for > JavaTypeDescriptor, Type has > >> a > >>> similar categorization: > >>> > >>> 1. Type > >>> 1. BasicType > >>> 1. TemporalType > >>> 2. AnyType > >>> 3. ManagedType > >>> 1. EmbeddedType > >>> 2. IdentifiableType > >>> 1. MappedSuperclassType > >>> 2. EntityType > >>> > >>> It is important to keep in mind that these represents a specific > >> reference > >>> to thse things in regards to a Navigable. E.g. an EntityType > is the > >> "type" > >>> of a SingularPersistentAttribute that is a ManyToOne - it > points to the > >>> corresponding EntityPersister but it also represents the FK > columns to > >>> refer to the entity. It is a role-based Navigable. > >>> > >>> Historically reads and writes have all routed through the Type > (with > >>> certain Types delegating much of that to persisters). That > will no > >> longer > >>> be the case in 6.0 as one of the main design goals for 6.0 is > to re-write > >>> how Hibernate reads and writes (mainly reads) values from > JDBC. The > >> major > >>> shift here is to read all values from JDBC using a > "SqlSelectionReader" > >>> equivalent to a BasicType. These values are read and held in > an array > >> that > >>> "readers" then know how to access (positionally) and use. > Most of that > >>> design is beyond the discussion here, but it useful to > understand. It is > >>> discussed in the design.adoc in my orm-sqm poc repo for those > curious. > >>> Long story, short... Types no longer directly implement JDBC > read/write > >>> which we will come back to later. > >>> > >>> PersistentAttribute and the other Navigables now take a role > in JDBC > >>> reads/writes. AttributeConverters and other > read/write-related concerns > >>> have been moved to these contracts. Again, most of this is > covered in > >> the > >>> mentioned design doc. > >>> > >>> Since Type no longer directly implements JDBC read/write > operations I > >> think > >>> it is important to ask ourselves what exactly we see as > "customizable" > >> wrt > >>> each Type. Is that different for each category, or the same > across all > >>> Type categories? E.g. I know of no customization of > EntityType as it > >>> exists in 5.x, and tbh I am not even sure what that would mean. > >> BasicType > >>> obviously has some parts that we want to allow users to > override, but is > >>> that really best achieved through a custom BasicType? Or is > it better > >>> served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor > and/or > >>> SqlSelectionReader? What about EmbeddedType? CollectionType? > This > >> would > >>> affect @TypeDef and Type registration methods specific to > customizations. > >>> > >>> Persisters for the most part continue to serve the same role > they have in > >>> the past with a few additions and some changes... > >>> > >>> One addition was the creation of an EmbeddedPersister. > *Embedded*. > >> This, > >>> like CollectionPersister, models a "role" e.g. "Person.name" > as opposed > >> to > >>> the Embeddable Name.class. Note however that JPA calls it an > >>> EmbeddableType and expects info about the Embeddable (the Class). > >>> EmbeddedPersister is role-based (Embedded) instead, which is a > mismatch. > >>> In the case there are more than 1 usage of the Embeddable in > different > >>> Embedded roles then we have to decide which EmbeddedPersister > to return. > >>> It affects the sub-Attributes information. We could just > return "one of > >>> them" and deal with it for Alpha1, but we should answer what > we want to > >> do > >>> there long term. > >>> > >>> Collectively, these persisters now implement the JPA > ManagedType model > >>> directly. Another addition was the creation of > ManagedTypeImplementor, > >>> IdentifiableTypeImplementor and > MappedSuperclassTypeImplementor in the > >>> persister hierarchy. Which means we can now directly return > them in our > >>> JPA Metamodel impl. > >>> > >>> That also means implementing JPA's notion of Attributes. I > also needed > >>> something similar for SQM's Navigable contract. Plus I have > been working > >>> towards changing how Hibernate understands Attributes internally > >>> (encapsulation - OO ftw!) for some time anyway, so this all > dove-tailed > >>> well. > >>> > >>> There are some things we should discuss too in terms of user > impact. We > >>> know up front that we need to move to reading values from JDBC > ResultSets > >>> positionally, as opposed to nominally which is how it was > exposed in > >>> Hibernate prior to 6.0. So we know already we will be asking > >> implementors > >>> and consumers of those contracts to make changes. Given that, > we have > >>> *some* liberty in changing these contracts some more. We just > want to be > >>> cognizant of (a) how much we change, (b) who it affects (use > cases) and > >> (c) > >>> whether there are alternatives. For any use cases we > determine to be > >>> "valid" use cases, I think we need to make certain that there > is some way > >>> to handle that in the new alternatives. > >>> > >>> One use case, e.g., is setting Query parameters and being able > to specify > >>> its Type. To a degree we want to be able to continue to > support that. > >> But > >>> I think we limit it to just references to > org.hibernate.type.Type (though > >>> "gutted") specifically and remove all others; and temporarily > have the > >> new > >>> org.hibernate.type.spi.Type interface extend the old. This > would allow > >>> them to continue to get these org.hibernate.type.Type > references in some > >>> fashion and use them as Query parameter type hints. But I > think we > >> should > >>> look at implementing some other parameter type "hints" like > accepting > >>> PersistentAttribute/Navigable references, JPA (static) metamodel > >>> references, etc. These are better, as they would include > things like > >>> AttributeConverter whereas the Type reference would not. > >>> > >>> Sorry this got so long. I've had a lot floating around in my > head the > >> last > >>> few days as I have worked on 6.0 and I wanted to bring them up for > >>> discussion. The main thing I wonder about is what we mean by > "custom > >>> types" in terms of what exactly is being customized? And how > does that > >>> relate specifically to BasicType versus EmbeddedType versus ...? > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Jan 24 18:57:31 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 24 Jan 2017 23:57:31 +0000 Subject: [hibernate-dev] 6.0 - Type system In-Reply-To: References: <2253a424-8b3b-f7e5-48b6-4be1694a54e5@gmail.com> Message-ID: Ofc. Vlad was saying the same. More what we discussed today though was what to do with the API Type stuff (o.h.type versus o.h.type.spi). On Tue, Jan 24, 2017 at 5:52 PM Christian Beikov wrote: > Sounds like what we have discussed today and as far as I can remember, > nobody complained about removing the type spi stuff. I think we might want > to prepare a blog post or topical/migration guide that helps people to > migrate their custom types to the new way of doing it. > > > Am 23.01.2017 um 18:37 schrieb Steve Ebersole: > > What is everyone's opinion of the following sections? > > > There are some things we should discuss too in terms of user impact. We > know up front that we need to move to reading values from JDBC ResultSets > positionally, as opposed to nominally which is how it was exposed in > Hibernate prior to 6.0. So we know already we will be asking implementors > and consumers of those contracts to make changes. Given that, we have > *some* liberty in changing these contracts some more. We just want to be > cognizant of (a) how much we change, (b) who it affects (use cases) and (c) > whether there are alternatives. For any use cases we determine to be > "valid" use cases, I think we need to make certain that there is some way > to handle that in the new alternatives. > > One use case, e.g., is setting Query parameters and being able to specify > its Type. To a degree we want to be able to continue to support that. But > I think we limit it to just references to org.hibernate.type.Type (though > "gutted") specifically and remove all others; and temporarily have the new > org.hibernate.type.spi.Type interface extend the old. This would allow > them to continue to get these org.hibernate.type.Type references in some > fashion and use them as Query parameter type hints. But I think we should > look at implementing some other parameter type "hints" like accepting > PersistentAttribute/Navigable references, JPA (static) metamodel > references, etc. These are better, as they would include things like > AttributeConverter whereas the Type reference would not. > > > > On Mon, Jan 23, 2017 at 11:13 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > > Since custom JavaTypeDescriptors and SqlTypeDescriptors can be used > instead, I'm also for removing it. > > Am 23.01.2017 um 15:45 schrieb andrea boriero: > > trying to find a valid reason to keep UserType but not able, so I'm for > > removing it. > > > > On 23 January 2017 at 14:36, Vlad Mihalcea > wrote: > > > >> Hi, > >> > >> I see no reason why we should keep it indefinitely. I'd say we > deprecate it > >> in 5.x, and remove it later (6.0 or 6.1). > >> Migrating a custom UserType to using Java and SQL descriptor is not > >> difficult, and we could just write a blog post for a step-by-step guide. > >> > >> Anyone in favor of keeping UserType? > >> > >> Vlad > >> > >> On Mon, Jan 23, 2017 at 4:11 PM, Steve Ebersole > >> wrote: > >> > >>> Nice! > >>> > >>> So if we keep UserType, we have to be clear that it has to change. I > >> also > >>> do not want to continue to support the other "user type extensions", > >> like: > >>> > >>> 1. org.hibernate.usertype.EnhancedUserType > >>> 2. org.hibernate.usertype.DynamicParameterizedType > >>> 3. org.hibernate.usertype.LoggableUserType > >>> 4. etc > >>> > >>> So we should come up with a plan for that. > >>> > >>> > >>> On Mon, Jan 23, 2017, 1:48 PM Vlad Mihalcea > >>> wrote: > >>> > >>> Hi, > >>> > >>> I like the SqlTypeDescriptor and JavaTypeDescriptor much better than > >>> UserType, which we should probably deprecate in 6.0. > >>> > >>> I wrote an article on my blog in which I demonstrate how to create a > JSON > >>> type using JavaTypeDescriptor and SqlTypeDescriptor: > >>> > >>> https://vladmihalcea.com/2016/06/20/how-to-map-json-objects- > >>> using-generic-hibernate-types/ > >>> > >>> I like this example because it shows how you can reuse the same > >>> JavaTypeDescriptor for two different JSON SQL types: String or Binary, > >>> for which we have two distinct SqlTypeDescriptor objects. > >>> > >>> The new User Guide shows ho to implement Custom Types using the Java > and > >>> SQL descriptors as well: > >>> > >>> http://docs.jboss.org/hibernate/orm/5.2/userguide/ > >>> html_single/Hibernate_User_Guide.html#basic-custom-type > >>> > >>> Vlad > >>> > >>> On Mon, Jan 23, 2017 at 3:37 PM, Steve Ebersole > >>> wrote: > >>> > >>> Right, and that exactly lines up with what I am proposing. > >>> > >>> If the intent of "customize" is to describe new Java types (e.g. Java 8 > >>> temporals prior to our explicit support) the tht is the role of a > >>> JavaTypeDescriptor, specifically a BasicJavaDescriptor. They would > >>> register a BasicJavaDescriptor describing the type. > >>> > >>> If the intent is to model a non-supported SQL type then that would mean > >>> adding a new SqlTypeDescriptor describing that type, although that will > >>> often also mean adding a new BasicJavaDescriptor describing the Java > >>> mapping of that SQL type. > >>> > >>> > >>> On Mon, Jan 23, 2017 at 7:00 AM Vlad Mihalcea > > >>> wrote: > >>> > >>> Hi, > >>> > >>> Related to your questions: > >>> > >>> he main thing I wonder about is what we mean by "custom > >>> types" in terms of what exactly is being customized? And how does that > >>> relate specifically to BasicType versus EmbeddedType versus ...? > >>> > >>> > >>> Most of the time, the users want to take advantage of various database > >>> types that are not universally supported by all RDBMS: JSON, Money (SQL > >>> Server). > >>> > >>> On the Java side, I don't see what we can customize because we already > >>> provide all the basic types, and for everything else, users can compose > >>> those into Embeddables. The Java 1.8 Date/Time are an example of what > >> users > >>> would like to customize in case we didn't support this already. But > even > >> if > >>> Java 1.9 adds other basic types, chances are that we are going to > support > >>> them natively, meaning that users will still not need to add a custom > >> Type. > >>> So, I don't see how a Hibernate user will customize the way > Embeddables, > >>> Enums, Entities or Collections are being stored or loaded from the > >>> database. The exception to the rule is a recent Pull Request from > someone > >>> who wants to support PostgreSQL arrays. But this falls back into the > same > >>> category as before: database types that are not universally supported > by > >>> all RDBMS. > >>> > >>> Vlad > >>> > >>> On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea < > mihalcea.vlad at gmail.com> > >>> wrote: > >>> > >>> There's a lot to dig in here. I'll have to get the branch and study the > >>> changes, to come back with some opinions. > >>> > >>> Vlad > >>> > >>> On Thu, Jan 19, 2017 at 7:34 PM, Steve Ebersole > >>> wrote: > >>> > >>> We are getting pretty far along on the 6.0 changes and I wanted to > start > >>> a(nother) discussion about Types in 6.0 to get feedback and thoughts > on a > >>> few topics. > >>> > >>> First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, > >> Types > >>> and "persisters"... > >>> > >>> (a lot of this is the same from pre-6.0, just making things more > >> explicit) > >>> JavaTypeDescriptors and SqlTypeDescriptors are the "lowest level", so > >> let's > >>> start there. A JavaTypeDescriptor is a descriptor of a given Java > type. > >>> That is, it provides Hibernate with information about the Java type. > Is > >> it > >>> a numeric type? How do we compare 2 values of this type? How do we > >> make a > >>> deep copy of a value of this type? Etc. SqlTypeDescriptor is the > same, > >>> but for a database type (VARCHAR, BLOB, etc). These 2 work together to > >>> perform reading and writing at the JDBC-level. > >>> > >>> We decided to broadly categorize JavaTypeDescriptors based on the JPA > >> type > >>> categorizations: > >>> > >>> 1. BASIC - BasicJavaDescriptor > >>> 1. TemporalJavaDescriptor > >>> 2. NumericJavaDescriptor > >>> 2. MANAGED - ManagedJavaDescriptor > >>> 1. EMBEDDABLE - EmbeddableJavaDescriptor > >>> 2. IDENTIFIABLE - IdentifiableJavaDescriptor > >>> 1. MAPPED_SUPERCLASS - MappedSupercassJavaDescriptor > >>> 2. ENTITY - EntityJavaDescriptor > >>> > >>> > >>> Type (org.hibernate.type.spi.Type) represents a combination of a > >>> JavaTypeDescriptor and one or more SqlTypeDescriptors in relation to a > >>> specific "non-root Navigable domain value". Navigable is a > query-focused > >>> contract (SQM/HQL/Criteria) so I wont get too deep into that here. At > a > >>> high-level t is similar to JPA's Bindable except that it applies to > >>> Collection indices (or map-keys) and elements (or map-values) as well. > >>> Navigable essentially represents an named navigation one can perform > in a > >>> query. The root Navigable is always an entity (EntityPersister). > >>> EntityPersister is the only Navigable that does not expose a Type. > >> (There > >>> is an EntityType, but it represents entity-valued non-root Navigables > >> such > >>> as a ManyToOne). All other navigables expose a Type. That is all a > >>> long-winded way to say that Types represents that > Java/SqlTypeDescriptors > >>> for a role-based Navigable. > >>> > >>> Like the categorization discussed above for JavaTypeDescriptor, Type > has > >> a > >>> similar categorization: > >>> > >>> 1. Type > >>> 1. BasicType > >>> 1. TemporalType > >>> 2. AnyType > >>> 3. ManagedType > >>> 1. EmbeddedType > >>> 2. IdentifiableType > >>> 1. MappedSuperclassType > >>> 2. EntityType > >>> > >>> It is important to keep in mind that these represents a specific > >> reference > >>> to thse things in regards to a Navigable. E.g. an EntityType is the > >> "type" > >>> of a SingularPersistentAttribute that is a ManyToOne - it points to the > >>> corresponding EntityPersister but it also represents the FK columns to > >>> refer to the entity. It is a role-based Navigable. > >>> > >>> Historically reads and writes have all routed through the Type (with > >>> certain Types delegating much of that to persisters). That will no > >> longer > >>> be the case in 6.0 as one of the main design goals for 6.0 is to > re-write > >>> how Hibernate reads and writes (mainly reads) values from JDBC. The > >> major > >>> shift here is to read all values from JDBC using a "SqlSelectionReader" > >>> equivalent to a BasicType. These values are read and held in an array > >> that > >>> "readers" then know how to access (positionally) and use. Most of that > >>> design is beyond the discussion here, but it useful to understand. It > is > >>> discussed in the design.adoc in my orm-sqm poc repo for those curious. > >>> Long story, short... Types no longer directly implement JDBC read/write > >>> which we will come back to later. > >>> > >>> PersistentAttribute and the other Navigables now take a role in JDBC > >>> reads/writes. AttributeConverters and other read/write-related > concerns > >>> have been moved to these contracts. Again, most of this is covered in > >> the > >>> mentioned design doc. > >>> > >>> Since Type no longer directly implements JDBC read/write operations I > >> think > >>> it is important to ask ourselves what exactly we see as "customizable" > >> wrt > >>> each Type. Is that different for each category, or the same across all > >>> Type categories? E.g. I know of no customization of EntityType as it > >>> exists in 5.x, and tbh I am not even sure what that would mean. > >> BasicType > >>> obviously has some parts that we want to allow users to override, but > is > >>> that really best achieved through a custom BasicType? Or is it better > >>> served by allowing custom JavaTypeDescriptor/SqlTypeDescriptor and/or > >>> SqlSelectionReader? What about EmbeddedType? CollectionType? This > >> would > >>> affect @TypeDef and Type registration methods specific to > customizations. > >>> > >>> Persisters for the most part continue to serve the same role they have > in > >>> the past with a few additions and some changes... > >>> > >>> One addition was the creation of an EmbeddedPersister. *Embedded*. > >> This, > >>> like CollectionPersister, models a "role" e.g. "Person.name" as opposed > >> to > >>> the Embeddable Name.class. Note however that JPA calls it an > >>> EmbeddableType and expects info about the Embeddable (the Class). > >>> EmbeddedPersister is role-based (Embedded) instead, which is a > mismatch. > >>> In the case there are more than 1 usage of the Embeddable in different > >>> Embedded roles then we have to decide which EmbeddedPersister to > return. > >>> It affects the sub-Attributes information. We could just return "one > of > >>> them" and deal with it for Alpha1, but we should answer what we want to > >> do > >>> there long term. > >>> > >>> Collectively, these persisters now implement the JPA ManagedType model > >>> directly. Another addition was the creation of ManagedTypeImplementor, > >>> IdentifiableTypeImplementor and MappedSuperclassTypeImplementor in the > >>> persister hierarchy. Which means we can now directly return them in > our > >>> JPA Metamodel impl. > >>> > >>> That also means implementing JPA's notion of Attributes. I also needed > >>> something similar for SQM's Navigable contract. Plus I have been > working > >>> towards changing how Hibernate understands Attributes internally > >>> (encapsulation - OO ftw!) for some time anyway, so this all dove-tailed > >>> well. > >>> > >>> There are some things we should discuss too in terms of user impact. > We > >>> know up front that we need to move to reading values from JDBC > ResultSets > >>> positionally, as opposed to nominally which is how it was exposed in > >>> Hibernate prior to 6.0. So we know already we will be asking > >> implementors > >>> and consumers of those contracts to make changes. Given that, we have > >>> *some* liberty in changing these contracts some more. We just want to > be > >>> cognizant of (a) how much we change, (b) who it affects (use cases) and > >> (c) > >>> whether there are alternatives. For any use cases we determine to be > >>> "valid" use cases, I think we need to make certain that there is some > way > >>> to handle that in the new alternatives. > >>> > >>> One use case, e.g., is setting Query parameters and being able to > specify > >>> its Type. To a degree we want to be able to continue to support that. > >> But > >>> I think we limit it to just references to org.hibernate.type.Type > (though > >>> "gutted") specifically and remove all others; and temporarily have the > >> new > >>> org.hibernate.type.spi.Type interface extend the old. This would allow > >>> them to continue to get these org.hibernate.type.Type references in > some > >>> fashion and use them as Query parameter type hints. But I think we > >> should > >>> look at implementing some other parameter type "hints" like accepting > >>> PersistentAttribute/Navigable references, JPA (static) metamodel > >>> references, etc. These are better, as they would include things like > >>> AttributeConverter whereas the Type reference would not. > >>> > >>> Sorry this got so long. I've had a lot floating around in my head the > >> last > >>> few days as I have worked on 6.0 and I wanted to bring them up for > >>> discussion. The main thing I wonder about is what we mean by "custom > >>> types" in terms of what exactly is being customized? And how does that > >>> relate specifically to BasicType versus EmbeddedType versus ...? > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From smarlow at redhat.com Thu Jan 26 04:28:56 2017 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 26 Jan 2017 09:28:56 +0000 Subject: [hibernate-dev] Example of WildFly JPA container safely closing the EntityManager after the application calls transaction.rollback, which also handles background tx reaper thread time outs Message-ID: Hi, [1] is an example of how the WildFly JPA container is ensuring that the background (transaction manager) reaper (transaction timeout) thread does not cause EntityManager.close() to be called, while the application is actively executing calls to EntityManager.*(). The idea, as suggested by Tom Jenkinson, is to track when the application (container) calls transaction.commit/rollback. We also register a Synchronization. When we detect that transaction.commit/rollback and the Synchronization.afterCompletion have both been called, it is safe to perform the EntityManager clean up action, as we know that only one thread will then be invoking the EntityManager.close(). >From a state point of view, please look at how [2] is checking for the EventType.DISASSOCIATING event, which means that transaction.rollback/commit was called by the application. If the Synchronization.afterCompletion has already run as well, then we clean up the EntityManager, otherwise, we defer the cleanup action until the call to Synchronization.afterCompletion occurs. Also see [3] which contains the recommendation of using the above solution. Scott [1] https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java#L146 [2] https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java#L197 [3] https://developer.jboss.org/message/919807 From smarlow at redhat.com Thu Jan 26 04:32:45 2017 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 26 Jan 2017 09:32:45 +0000 Subject: [hibernate-dev] Example of WildFly JPA container safely closing the EntityManager after the application calls transaction.rollback, which also handles background tx reaper thread time outs In-Reply-To: References: Message-ID: Artifact that contains the org.jboss:jboss-transaction-spi (WildFly is currently using version 7.5.0.Final of this artifact). On Thu, Jan 26, 2017 at 9:28 AM, Scott Marlow wrote: > Hi, > > [1] is an example of how the WildFly JPA container is ensuring that > the background (transaction manager) reaper (transaction timeout) > thread does not cause EntityManager.close() to be called, while the > application is actively executing calls to EntityManager.*(). > > The idea, as suggested by Tom Jenkinson, is to track when the > application (container) calls transaction.commit/rollback. We also > register a Synchronization. When we detect that > transaction.commit/rollback and the Synchronization.afterCompletion > have both been called, it is safe to perform the EntityManager clean > up action, as we know that only one thread will then be invoking the > EntityManager.close(). > > From a state point of view, please look at how [2] is checking for the > EventType.DISASSOCIATING event, which means that > transaction.rollback/commit was called by the application. If the > Synchronization.afterCompletion has already run as well, then we clean > up the EntityManager, otherwise, we defer the cleanup action until the > call to Synchronization.afterCompletion occurs. > > Also see [3] which contains the recommendation of using the above solution. > > Scott > > [1] https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java#L146 > > [2] https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java#L197 > > [3] https://developer.jboss.org/message/919807 From steve at hibernate.org Fri Jan 27 07:54:43 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Jan 2017 12:54:43 +0000 Subject: [hibernate-dev] 6.0 - ResultTransformer In-Reply-To: References: <42848f6f-fa00-4d36-5a7f-fce4d4283f1c@gmail.com> Message-ID: On Tue, Sep 13, 2016 at 9:55 PM Gail Badner wrote: > Sorry for the late response. I've been looking through the fix for > HHH-5163 [1] to jog my memory. > > Here are some reasons why CacheableResultTransformer is important when > caching query results: > > 1) The same SQL can be generated when associations are joined as when > associations are fetched, but what gets cached is different. The cached > results exclude fetched associations. QueryKey needs to contain the proper > CacheableResultTransformer to indicate which tuple elements are cached to > distinguish the differing results. > Just to be clear... Those 2 cases *do not* generate the same SQL. In fetch case the SELECT clause includes the association columns, in the non-fetch-join case it doe not. But I understand what you mean. And with 6.0 this is no longer a concern since all of the selections (the SQL selections) are cached. Along with the fact that we know the "fetch graph" now in 6.0 wrt that cached data we can easily (well "easily" is relative) rebuild the full graph. > 2) IIRC, the tuple elements that got cached by the legacy Criteria and HQL > were inconsistent, and I believe that in some cases the ResultTransformer > was applied before caching the value, which added to problems assembling > the query results (HHH--2463). CacheableResultTransformer ensured that what > got cached was consistent (excluding fetched values), and ensured that rows > were untransformed (padded with nulls where fetches were) and > re-transformed (if necessary) by a specified transformer as necessary. > Right. This is it. And with 6.0 because we now cache the actual JDBC values (meaning transformations are applied "on top of" the cached values) this is no longer a concern. > I added lots of tests for this change, so I think we will find out quickly > if something gets broken. > Sweet! Although hopefully the tests do not assert that fetched associations are no longer present. That was not the case pre-6.x but is no longer true as discussed above. Steve, I'm not completely following your discussion. Some pseudocode would > help. > I gave psuedo code above and in the Jira I linked. From steve at hibernate.org Fri Jan 27 09:42:25 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Jan 2017 14:42:25 +0000 Subject: [hibernate-dev] Query#iterate Message-ID: I know I started a discussion of this somewhere with some of you, but I cannot find it anymore. I had suggested we consider getting rid of this Query#iterate method. I just wanted to get everyone's opinions of this. Specifically, getting of it in 6.0. If anyone has dug much into the current Antlr 2 based parser you will be familiar with this idea of shallow versus non-shallow queries. That is where this comes into play. Query#iterate is a shallow query (shallow=true). All other queries are non-shallow. There are quite a few internal reasons to simply drop that method and get rid of the idea of this shallow flag. I am happy to discuss these reasons for those interested and that do not know. But obviously we should not be getting rid of things just because of "internal complications" if they are used by many users. I cannot speak to whether any users use this, let alone how many. Thoughts? From christian.beikov at gmail.com Fri Jan 27 10:50:27 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Fri, 27 Jan 2017 16:50:27 +0100 Subject: [hibernate-dev] Query#iterate In-Reply-To: References: Message-ID: I just know of people that are using iterate() now for efficient incremental processing, but I guess any other approach(streams maybe?) to do incremental processing would be good enough for these users. Unfortunately I don't know what a shallow query is or what the implication on the query or the processing of being shallow are. I guess this has to do with how row processing is done? I can imagine that this complicates the implementation, but really, there are users out there which rely on the performance model of that. Am 27.01.2017 um 15:42 schrieb Steve Ebersole: > I know I started a discussion of this somewhere with some of you, but I > cannot find it anymore. > > I had suggested we consider getting rid of this Query#iterate method. I > just wanted to get everyone's opinions of this. Specifically, getting of > it in 6.0. > > If anyone has dug much into the current Antlr 2 based parser you will be > familiar with this idea of shallow versus non-shallow queries. That is > where this comes into play. Query#iterate is a shallow query > (shallow=true). All other queries are non-shallow. > > There are quite a few internal reasons to simply drop that method and get > rid of the idea of this shallow flag. I am happy to discuss these reasons > for those interested and that do not know. > > But obviously we should not be getting rid of things just because of > "internal complications" if they are used by many users. I cannot speak to > whether any users use this, let alone how many. > > Thoughts? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Jan 27 11:31:05 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Jan 2017 16:31:05 +0000 Subject: [hibernate-dev] boolean type support Message-ID: Another thing we run into in 6.0 dev is handling booleans, specifically in regards to dealing with the database representation (0 or 1, versus 'T' of 'F', versus ...). The way we handle this today (pre-6.0) is to "fake it" by registering a JavaTypeDescriptor for each representation combo[1]. We can obviously continue to do it this way. But in moving forward we wanted to take a step back and look at this again. And really this is the kind of scenario that AttributeConverters are designed to handle. So we are considering to instead actually handle this via an AttributeConverter. To fully understand this remember that we have also moved AttributeConverter tracking on to the attribute[2] itself as opposed to "baking it" into a Type. In that way it would just be handled by the "type system" to automatically add an AttributeConverter to the attribute. Obviously that only works if there is not already an AttributeConverter applied to to the attribute. I cannot imagine that ever happens in a supported way, or a way that we want to support. Essentially that would mean a condition where we convert the value twice in each direction. But in case we miss some ase, I wanted to ask the list. [1] Yes, it seems odd that this is handled in the JavaTypeDescriptor. The reason it happens that way is that it is incorporated into the wrap/unwrap code. [2] I say "attribute" just a a means of simplification. It is really a Navigable which is new concept and probably not well known to everyone.. From christian.beikov at gmail.com Fri Jan 27 11:43:02 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Fri, 27 Jan 2017 17:43:02 +0100 Subject: [hibernate-dev] boolean type support In-Reply-To: References: Message-ID: <75e20435-6829-d556-d7a8-9b305e5c5030@gmail.com> Am 27.01.2017 um 17:31 schrieb Steve Ebersole: > Obviously that only works if there is not already an AttributeConverter > applied to to the attribute. I cannot imagine that ever happens in a > supported way, or a way that we want to support. Essentially that would > mean a condition where we convert the value twice in each direction. But > in case we miss some ase, I wanted to ask the list. So if a user defines a converter for Boolean=>Enum for example, that would not work on e.g. Oracle since on such a DB the column type is integer? I am not sure if a converter for Boolean as source type would make sense, but if allowing it adds a lot of complexity I'd say don't support it for now and wait for a user to complain. Seems like a pretty edgy edge case to me :D From emmanuel at hibernate.org Fri Jan 27 12:23:13 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 27 Jan 2017 18:23:13 +0100 Subject: [hibernate-dev] [HV/HSEARCH] Free form Message-ID: <452FAF91-6C62-44E9-86E5-4CB1B7726460@hibernate.org> I took the flight home to play with free form and specifically how we would retrieve data from the free form structure. By free-form I mean non POJO but they will have schema (not expressed here). https://github.com/emmanuelbernard/hibernate-search/commit/0bd3fbab137bdad81bfa5b9934063792a050f537 And in particular https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freeform/src/main/java/org/hibernate/freeform/StructureTraverser.java https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freeform/src/main/java/org/hibernate/freeform/pojo/impl/PojoStructureTraverser.java It probably does not compile, I could not make the build work. I figured it was important to dump this raw thinking because it will influence and will be influenced by the redesign of the DocumentBuilder of Hibernate Search. There are several options for traversing a free form structure - expose the traversing API as a holder to navigate all properties per structure and sub structure. This is what the prototype shows. Caching needs to be accessed via a hashmap get or other lookup. Metadata and the traversing structure will be navigated in parallel - expose a structure that is specialized to a single property or container unwrapping aspect. The structures will be spread across and embedded in the Metadata Another angle: - create a traversable object per payload to carry it (sharing metadata info per type) - have a stateless traversable object that is provided the payload for each access The former seems better as it does not create a traversable object per object navigated. The latter is better for payloads that need parsing or are better at sequential access since state could be cached. We need to discuss that and know where DocumentBuilder is going to properly design this API. Emmanuel From mihalcea.vlad at gmail.com Fri Jan 27 12:39:01 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 27 Jan 2017 19:39:01 +0200 Subject: [hibernate-dev] Query#iterate In-Reply-To: References: Message-ID: I would not bother too much about iterate since it can be easily emulated with an entity query. If I recall correctly, Query#iterate does something like this: select e.id from Entity e where condition and for every identifier we can load the entity from the 2nd-level cache instead of loading it from the DB. Now, if the entities are not already cached, it will be a disaster if N is fairly large. For this reason, I think we should deprecate it and remove it anyway. Vlad On Fri, Jan 27, 2017 at 5:50 PM, Christian Beikov < christian.beikov at gmail.com> wrote: > I just know of people that are using iterate() now for efficient > incremental processing, but I guess any other approach(streams maybe?) > to do incremental processing would be good enough for these users. > > Unfortunately I don't know what a shallow query is or what the > implication on the query or the processing of being shallow are. > I guess this has to do with how row processing is done? I can imagine > that this complicates the implementation, but really, there are users > out there which rely on the performance model of that. > > Am 27.01.2017 um 15:42 schrieb Steve Ebersole: > > I know I started a discussion of this somewhere with some of you, but I > > cannot find it anymore. > > > > I had suggested we consider getting rid of this Query#iterate method. I > > just wanted to get everyone's opinions of this. Specifically, getting of > > it in 6.0. > > > > If anyone has dug much into the current Antlr 2 based parser you will be > > familiar with this idea of shallow versus non-shallow queries. That is > > where this comes into play. Query#iterate is a shallow query > > (shallow=true). All other queries are non-shallow. > > > > There are quite a few internal reasons to simply drop that method and get > > rid of the idea of this shallow flag. I am happy to discuss these > reasons > > for those interested and that do not know. > > > > But obviously we should not be getting rid of things just because of > > "internal complications" if they are used by many users. I cannot speak > to > > whether any users use this, let alone how many. > > > > Thoughts? > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Fri Jan 27 13:01:16 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Jan 2017 18:01:16 +0000 Subject: [hibernate-dev] Query#iterate In-Reply-To: References: Message-ID: On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov wrote: > I just know of people that are using iterate() now for efficient > incremental processing, but I guess any other approach(streams maybe?) > to do incremental processing would be good enough for these users. > > ScrollableResults do not meet that need? > Unfortunately I don't know what a shallow query is or what the > implication on the query or the processing of being shallow are. > Just what I said before. "shallow" is simply a boolean flag that is part of the translator. It is set to true when the translation is triggered from Query#iterate. When the translation is triggered from Query#list or Query#scroll it is set to false. > I guess this has to do with how row processing is done? The main thing is effects is the SQL we render. For "entity returns" it simply selects the ids and we expect to then load them (immediately!) by that id (N+1). Its usefulness is actually VERY limited in scope as it actually performs horrendously in, what, 95-99% of use cases? Interestingly it really does not have much effect on "row processing". From christian.beikov at gmail.com Fri Jan 27 13:17:27 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Fri, 27 Jan 2017 19:17:27 +0100 Subject: [hibernate-dev] Query#iterate In-Reply-To: References: Message-ID: <836985ff-3d69-e726-4f93-555b4de216b5@gmail.com> I'm sorry, I apparently confused iterate() with scroll() then, so forget what I wrote before ^^ In face of that new info, I actually don't know of any actual users. After thinking a bit about it, why not make that behavior configurable via setProperty and drop that method? Am 27.01.2017 um 19:01 schrieb Steve Ebersole: > On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov > > wrote: > > I just know of people that are using iterate() now for efficient > incremental processing, but I guess any other approach(streams maybe?) > to do incremental processing would be good enough for these users. > > > ScrollableResults do not meet that need? > > Unfortunately I don't know what a shallow query is or what the > implication on the query or the processing of being shallow are. > > > Just what I said before. "shallow" is simply a boolean flag that is > part of the translator. It is set to true when the translation is > triggered from Query#iterate. When the translation is triggered from > Query#list or Query#scroll it is set to false. > > I guess this has to do with how row processing is done? > > > The main thing is effects is the SQL we render. For "entity returns" > it simply selects the ids and we expect to then load them > (immediately!) by that id (N+1). Its usefulness is actually VERY > limited in scope as it actually performs horrendously in, what, 95-99% > of use cases? > > Interestingly it really does not have much effect on "row processing". > From steve at hibernate.org Fri Jan 27 13:24:18 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Jan 2017 18:24:18 +0000 Subject: [hibernate-dev] boolean type support In-Reply-To: <75e20435-6829-d556-d7a8-9b305e5c5030@gmail.com> References: <75e20435-6829-d556-d7a8-9b305e5c5030@gmail.com> Message-ID: On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov < christian.beikov at gmail.com> wrote: > Am 27.01.2017 um 17:31 schrieb Steve Ebersole: > > Obviously that only works if there is not already an AttributeConverter > > applied to to the attribute. I cannot imagine that ever happens in a > > supported way, or a way that we want to support. Essentially that would > > mean a condition where we convert the value twice in each direction. But > > in case we miss some ase, I wanted to ask the list. > So if a user defines a converter for Boolean=>Enum for example, that > would not work on e.g. Oracle since on such a DB the column type is > integer? > I am not following what you mean. Why would an enum be a boolean? You mean something like: enum Sex { MALE, FEMALE ) and then storing into the DB as `IS_MALE`? I mean I guess someone *could* write an app that way. I'd laugh at them, but I guess they could ;) Anyway, they can already do that... it called an AttributeConverter :P More I am asking about the legacy BooleanType, YesNoType and TrueFalseType. These each used different JavaTypeDescriptor instances encoding the specific true/false DB ('Y'/'N', 'T'/'F', 1/0, ..) representations. So in stepping back and thinking about how this "should" be designed, I am thinking that the most logical design is to have just a single JavaTypeDesriptor for boolean and to somehow keep the specific DB storage representations as part of the attribute[1]. But then we start thinking how that should affect the wrap/unwrap process. Well, we already have a way for attribute-level "config" to alter the wrap/unwrap process - again, AttributeConverter. So at the minimum we will handle this in the same manner as we hande AttributeConverter. But then we asked whether we might just *use* AttributeConverter for this; this design works well, so long as these attributes do not also have an AttributeConverter associated with them. I think I'd propose this... We'd essentially say that we do not natively understand how to store booleans (just bear with me...). Specifically how to convert them into a DB storable format. Which means we'd need something to help us perform that conversion. If the user has attached an AttributeConverter to the attribute we'd simply use that. If they have not, then we'd look to this config option to see if they have specified how to do that globally. If they have not done that either, we'd simply as the Dialect. [1] I'd never do this, but it is entirely possible that a user would want a boolean value from one attribute stored in the DB as 0/1 and another attribute store as Y/N. So attribute is the highest granularity we need to resolve this at. But they might instead very well want to store all boolean values in their app to the DB as a single representation - we'd support that via config, as well as fallback to Dialect From steve at hibernate.org Fri Jan 27 13:26:17 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Jan 2017 18:26:17 +0000 Subject: [hibernate-dev] Query#iterate In-Reply-To: <836985ff-3d69-e726-4f93-555b4de216b5@gmail.com> References: <836985ff-3d69-e726-4f93-555b4de216b5@gmail.com> Message-ID: Because the behavior is also fundamentally questionable. On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov < christian.beikov at gmail.com> wrote: > I'm sorry, I apparently confused iterate() with scroll() then, so forget > what I wrote before ^^ > > In face of that new info, I actually don't know of any actual users. After > thinking a bit about it, why not make that behavior configurable via > setProperty and drop that method? > > > Am 27.01.2017 um 19:01 schrieb Steve Ebersole: > > On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > > I just know of people that are using iterate() now for efficient > incremental processing, but I guess any other approach(streams maybe?) > to do incremental processing would be good enough for these users. > > > ScrollableResults do not meet that need? > > > > Unfortunately I don't know what a shallow query is or what the > implication on the query or the processing of being shallow are. > > > Just what I said before. "shallow" is simply a boolean flag that is part > of the translator. It is set to true when the translation is triggered > from Query#iterate. When the translation is triggered from Query#list or > Query#scroll it is set to false. > > > > I guess this has to do with how row processing is done? > > > The main thing is effects is the SQL we render. For "entity returns" it > simply selects the ids and we expect to then load them (immediately!) by > that id (N+1). Its usefulness is actually VERY limited in scope as it > actually performs horrendously in, what, 95-99% of use cases? > > Interestingly it really does not have much effect on "row processing". > > > From steve at hibernate.org Fri Jan 27 13:28:59 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Jan 2017 18:28:59 +0000 Subject: [hibernate-dev] boolean type support In-Reply-To: References: <75e20435-6829-d556-d7a8-9b305e5c5030@gmail.com> Message-ID: Correction : If they have not done that either, we'd simply *ask* the Dialect. On Fri, Jan 27, 2017 at 12:24 PM Steve Ebersole wrote: > On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > > Am 27.01.2017 um 17:31 schrieb Steve Ebersole: > > Obviously that only works if there is not already an AttributeConverter > > applied to to the attribute. I cannot imagine that ever happens in a > > supported way, or a way that we want to support. Essentially that would > > mean a condition where we convert the value twice in each direction. But > > in case we miss some ase, I wanted to ask the list. > So if a user defines a converter for Boolean=>Enum for example, that > would not work on e.g. Oracle since on such a DB the column type is > integer? > > > I am not following what you mean. Why would an enum be a boolean? You > mean something like: > > enum Sex { MALE, FEMALE ) > > and then storing into the DB as `IS_MALE`? > > I mean I guess someone *could* write an app that way. I'd laugh at them, > but I guess they could ;) > > Anyway, they can already do that... it called an AttributeConverter :P > > More I am asking about the legacy BooleanType, YesNoType and > TrueFalseType. These each used different JavaTypeDescriptor instances > encoding the specific true/false DB ('Y'/'N', 'T'/'F', 1/0, ..) > representations. > > So in stepping back and thinking about how this "should" be designed, I am > thinking that the most logical design is to have just a single > JavaTypeDesriptor for boolean and to somehow keep the specific DB storage > representations as part of the attribute[1]. > > But then we start thinking how that should affect the wrap/unwrap > process. Well, we already have a way for attribute-level "config" to alter > the wrap/unwrap process - again, AttributeConverter. So at the minimum we > will handle this in the same manner as we hande AttributeConverter. But > then we asked whether we might just *use* AttributeConverter for this; this > design works well, so long as these attributes do not also have an > AttributeConverter associated with them. > > I think I'd propose this... > > We'd essentially say that we do not natively understand how to store > booleans (just bear with me...). Specifically how to convert them into a > DB storable format. Which means we'd need something to help us perform > that conversion. If the user has attached an AttributeConverter to the > attribute we'd simply use that. If they have not, then we'd look to this > config option to see if they have specified how to do that globally. If > they have not done that either, we'd simply as the Dialect. > > > [1] I'd never do this, but it is entirely possible that a user would want > a boolean value from one attribute stored in the DB as 0/1 and another > attribute store as Y/N. So attribute is the highest granularity we need to > resolve this at. But they might instead very well want to store all > boolean values in their app to the DB as a single representation - we'd > support that via config, as well as fallback to Dialect > > From mihalcea.vlad at gmail.com Fri Jan 27 13:34:02 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 27 Jan 2017 20:34:02 +0200 Subject: [hibernate-dev] Query#iterate In-Reply-To: References: <836985ff-3d69-e726-4f93-555b4de216b5@gmail.com> Message-ID: I'm for removing it even if it didn't complicate the query parser. Vlad On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole wrote: > Because the behavior is also fundamentally questionable. > > On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov < > christian.beikov at gmail.com> wrote: > > > I'm sorry, I apparently confused iterate() with scroll() then, so forget > > what I wrote before ^^ > > > > In face of that new info, I actually don't know of any actual users. > After > > thinking a bit about it, why not make that behavior configurable via > > setProperty and drop that method? > > > > > > Am 27.01.2017 um 19:01 schrieb Steve Ebersole: > > > > On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov < > > christian.beikov at gmail.com> wrote: > > > > I just know of people that are using iterate() now for efficient > > incremental processing, but I guess any other approach(streams maybe?) > > to do incremental processing would be good enough for these users. > > > > > > ScrollableResults do not meet that need? > > > > > > > > Unfortunately I don't know what a shallow query is or what the > > implication on the query or the processing of being shallow are. > > > > > > Just what I said before. "shallow" is simply a boolean flag that is part > > of the translator. It is set to true when the translation is triggered > > from Query#iterate. When the translation is triggered from Query#list or > > Query#scroll it is set to false. > > > > > > > > I guess this has to do with how row processing is done? > > > > > > The main thing is effects is the SQL we render. For "entity returns" it > > simply selects the ids and we expect to then load them (immediately!) by > > that id (N+1). Its usefulness is actually VERY limited in scope as it > > actually performs horrendously in, what, 95-99% of use cases? > > > > Interestingly it really does not have much effect on "row processing". > > > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Fri Jan 27 13:42:41 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 27 Jan 2017 20:42:41 +0200 Subject: [hibernate-dev] boolean type support In-Reply-To: References: <75e20435-6829-d556-d7a8-9b305e5c5030@gmail.com> Message-ID: If you think we can handle this better using Attributes, then we can give it a try. Nevertheless, the current implementation is nice as well. We have a single Java descriptor and multiple Sql descriptors to cover various DB column types or column values. Vlad On Fri, Jan 27, 2017 at 8:28 PM, Steve Ebersole wrote: > Correction : If they have not done that either, we'd simply *ask* the > Dialect. > > On Fri, Jan 27, 2017 at 12:24 PM Steve Ebersole > wrote: > > > On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov < > > christian.beikov at gmail.com> wrote: > > > > Am 27.01.2017 um 17:31 schrieb Steve Ebersole: > > > Obviously that only works if there is not already an AttributeConverter > > > applied to to the attribute. I cannot imagine that ever happens in a > > > supported way, or a way that we want to support. Essentially that > would > > > mean a condition where we convert the value twice in each direction. > But > > > in case we miss some ase, I wanted to ask the list. > > So if a user defines a converter for Boolean=>Enum for example, that > > would not work on e.g. Oracle since on such a DB the column type is > > integer? > > > > > > I am not following what you mean. Why would an enum be a boolean? You > > mean something like: > > > > enum Sex { MALE, FEMALE ) > > > > and then storing into the DB as `IS_MALE`? > > > > I mean I guess someone *could* write an app that way. I'd laugh at them, > > but I guess they could ;) > > > > Anyway, they can already do that... it called an AttributeConverter :P > > > > More I am asking about the legacy BooleanType, YesNoType and > > TrueFalseType. These each used different JavaTypeDescriptor instances > > encoding the specific true/false DB ('Y'/'N', 'T'/'F', 1/0, ..) > > representations. > > > > So in stepping back and thinking about how this "should" be designed, I > am > > thinking that the most logical design is to have just a single > > JavaTypeDesriptor for boolean and to somehow keep the specific DB storage > > representations as part of the attribute[1]. > > > > But then we start thinking how that should affect the wrap/unwrap > > process. Well, we already have a way for attribute-level "config" to > alter > > the wrap/unwrap process - again, AttributeConverter. So at the minimum > we > > will handle this in the same manner as we hande AttributeConverter. But > > then we asked whether we might just *use* AttributeConverter for this; > this > > design works well, so long as these attributes do not also have an > > AttributeConverter associated with them. > > > > I think I'd propose this... > > > > We'd essentially say that we do not natively understand how to store > > booleans (just bear with me...). Specifically how to convert them into a > > DB storable format. Which means we'd need something to help us perform > > that conversion. If the user has attached an AttributeConverter to the > > attribute we'd simply use that. If they have not, then we'd look to this > > config option to see if they have specified how to do that globally. If > > they have not done that either, we'd simply as the Dialect. > > > > > > [1] I'd never do this, but it is entirely possible that a user would want > > a boolean value from one attribute stored in the DB as 0/1 and another > > attribute store as Y/N. So attribute is the highest granularity we need > to > > resolve this at. But they might instead very well want to store all > > boolean values in their app to the DB as a single representation - we'd > > support that via config, as well as fallback to Dialect > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Fri Jan 27 13:50:22 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Jan 2017 18:50:22 +0000 Subject: [hibernate-dev] boolean type support In-Reply-To: References: <75e20435-6829-d556-d7a8-9b305e5c5030@gmail.com> Message-ID: But see that's my point. That's *not* what we have. We have 3 JavaTypeDescriptors (instances) and 3 SqlTypeDescriptors (instances) to handle this. Sure we have 1 JavaTypeDescriptor *class*, but it takes 3 distinct configurations. But the problem with this is... when I see a Boolean/boolean type in the domain model which JavaTypeDescriptor does that resolve to? Anyway, I will try it and see how it goes. On Fri, Jan 27, 2017 at 12:42 PM Vlad Mihalcea wrote: > If you think we can handle this better using Attributes, then we can give > it a try. > > Nevertheless, the current implementation is nice as well. We have a single > Java descriptor and multiple Sql descriptors to cover various DB column > types or column values. > > Vlad > On Fri, Jan 27, 2017 at 8:28 PM, Steve Ebersole > wrote: > > Correction : If they have not done that either, we'd simply *ask* the > Dialect. > > > On Fri, Jan 27, 2017 at 12:24 PM Steve Ebersole > wrote: > > > On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov < > > christian.beikov at gmail.com> wrote: > > > > Am 27.01.2017 um 17:31 schrieb Steve Ebersole: > > > Obviously that only works if there is not already an AttributeConverter > > > applied to to the attribute. I cannot imagine that ever happens in a > > > supported way, or a way that we want to support. Essentially that > would > > > mean a condition where we convert the value twice in each direction. > But > > > in case we miss some ase, I wanted to ask the list. > > So if a user defines a converter for Boolean=>Enum for example, that > > would not work on e.g. Oracle since on such a DB the column type is > > integer? > > > > > > I am not following what you mean. Why would an enum be a boolean? You > > mean something like: > > > > enum Sex { MALE, FEMALE ) > > > > and then storing into the DB as `IS_MALE`? > > > > I mean I guess someone *could* write an app that way. I'd laugh at them, > > but I guess they could ;) > > > > Anyway, they can already do that... it called an AttributeConverter :P > > > > More I am asking about the legacy BooleanType, YesNoType and > > TrueFalseType. These each used different JavaTypeDescriptor instances > > encoding the specific true/false DB ('Y'/'N', 'T'/'F', 1/0, ..) > > representations. > > > > So in stepping back and thinking about how this "should" be designed, I > am > > thinking that the most logical design is to have just a single > > JavaTypeDesriptor for boolean and to somehow keep the specific DB storage > > representations as part of the attribute[1]. > > > > But then we start thinking how that should affect the wrap/unwrap > > process. Well, we already have a way for attribute-level "config" to > alter > > the wrap/unwrap process - again, AttributeConverter. So at the minimum > we > > will handle this in the same manner as we hande AttributeConverter. But > > then we asked whether we might just *use* AttributeConverter for this; > this > > design works well, so long as these attributes do not also have an > > AttributeConverter associated with them. > > > > I think I'd propose this... > > > > We'd essentially say that we do not natively understand how to store > > booleans (just bear with me...). Specifically how to convert them into a > > DB storable format. Which means we'd need something to help us perform > > that conversion. If the user has attached an AttributeConverter to the > > attribute we'd simply use that. If they have not, then we'd look to this > > config option to see if they have specified how to do that globally. If > > they have not done that either, we'd simply as the Dialect. > > > > > > [1] I'd never do this, but it is entirely possible that a user would want > > a boolean value from one attribute stored in the DB as 0/1 and another > > attribute store as Y/N. So attribute is the highest granularity we need > to > > resolve this at. But they might instead very well want to store all > > boolean values in their app to the DB as a single representation - we'd > > support that via config, as well as fallback to Dialect > > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From sanne at hibernate.org Fri Jan 27 13:50:59 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 27 Jan 2017 18:50:59 +0000 Subject: [hibernate-dev] Query#iterate In-Reply-To: References: <836985ff-3d69-e726-4f93-555b4de216b5@gmail.com> Message-ID: +1 to remove On 27 January 2017 at 18:34, Vlad Mihalcea wrote: > I'm for removing it even if it didn't complicate the query parser. > > Vlad > > On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole wrote: > >> Because the behavior is also fundamentally questionable. >> >> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov < >> christian.beikov at gmail.com> wrote: >> >> > I'm sorry, I apparently confused iterate() with scroll() then, so forget >> > what I wrote before ^^ >> > >> > In face of that new info, I actually don't know of any actual users. >> After >> > thinking a bit about it, why not make that behavior configurable via >> > setProperty and drop that method? >> > >> > >> > Am 27.01.2017 um 19:01 schrieb Steve Ebersole: >> > >> > On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov < >> > christian.beikov at gmail.com> wrote: >> > >> > I just know of people that are using iterate() now for efficient >> > incremental processing, but I guess any other approach(streams maybe?) >> > to do incremental processing would be good enough for these users. >> > >> > >> > ScrollableResults do not meet that need? >> > >> > >> > >> > Unfortunately I don't know what a shallow query is or what the >> > implication on the query or the processing of being shallow are. >> > >> > >> > Just what I said before. "shallow" is simply a boolean flag that is part >> > of the translator. It is set to true when the translation is triggered >> > from Query#iterate. When the translation is triggered from Query#list or >> > Query#scroll it is set to false. >> > >> > >> > >> > I guess this has to do with how row processing is done? >> > >> > >> > The main thing is effects is the SQL we render. For "entity returns" it >> > simply selects the ids and we expect to then load them (immediately!) by >> > that id (N+1). Its usefulness is actually VERY limited in scope as it >> > actually performs horrendously in, what, 95-99% of use cases? >> > >> > Interestingly it really does not have much effect on "row processing". >> > >> > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From christian.beikov at gmail.com Fri Jan 27 14:16:11 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Fri, 27 Jan 2017 20:16:11 +0100 Subject: [hibernate-dev] Query#iterate In-Reply-To: References: <836985ff-3d69-e726-4f93-555b4de216b5@gmail.com> Message-ID: <76b4a78a-efed-53cd-61cb-008e6ab4c800@gmail.com> +1 for remove then too. We can still add it later via a configuration property if someone complains. Am 27.01.2017 um 19:50 schrieb Sanne Grinovero: > +1 to remove > > On 27 January 2017 at 18:34, Vlad Mihalcea wrote: >> I'm for removing it even if it didn't complicate the query parser. >> >> Vlad >> >> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole wrote: >> >>> Because the behavior is also fundamentally questionable. >>> >>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov < >>> christian.beikov at gmail.com> wrote: >>> >>>> I'm sorry, I apparently confused iterate() with scroll() then, so forget >>>> what I wrote before ^^ >>>> >>>> In face of that new info, I actually don't know of any actual users. >>> After >>>> thinking a bit about it, why not make that behavior configurable via >>>> setProperty and drop that method? >>>> >>>> >>>> Am 27.01.2017 um 19:01 schrieb Steve Ebersole: >>>> >>>> On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov < >>>> christian.beikov at gmail.com> wrote: >>>> >>>> I just know of people that are using iterate() now for efficient >>>> incremental processing, but I guess any other approach(streams maybe?) >>>> to do incremental processing would be good enough for these users. >>>> >>>> >>>> ScrollableResults do not meet that need? >>>> >>>> >>>> >>>> Unfortunately I don't know what a shallow query is or what the >>>> implication on the query or the processing of being shallow are. >>>> >>>> >>>> Just what I said before. "shallow" is simply a boolean flag that is part >>>> of the translator. It is set to true when the translation is triggered >>>> from Query#iterate. When the translation is triggered from Query#list or >>>> Query#scroll it is set to false. >>>> >>>> >>>> >>>> I guess this has to do with how row processing is done? >>>> >>>> >>>> The main thing is effects is the SQL we render. For "entity returns" it >>>> simply selects the ids and we expect to then load them (immediately!) by >>>> that id (N+1). Its usefulness is actually VERY limited in scope as it >>>> actually performs horrendously in, what, 95-99% of use cases? >>>> >>>> Interestingly it really does not have much effect on "row processing". >>>> >>>> >>>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From mihalcea.vlad at gmail.com Fri Jan 27 14:18:26 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 27 Jan 2017 21:18:26 +0200 Subject: [hibernate-dev] Query#iterate In-Reply-To: <76b4a78a-efed-53cd-61cb-008e6ab4c800@gmail.com> References: <836985ff-3d69-e726-4f93-555b4de216b5@gmail.com> <76b4a78a-efed-53cd-61cb-008e6ab4c800@gmail.com> Message-ID: They can always emulate it with a query that returns the ids and then just call entityManager.find for each id so I don't think we'll ever need to add it back. Vlad On Fri, Jan 27, 2017 at 9:16 PM, Christian Beikov < christian.beikov at gmail.com> wrote: > +1 for remove then too. We can still add it later via a configuration > property if someone complains. > > Am 27.01.2017 um 19:50 schrieb Sanne Grinovero: > > +1 to remove > > > > On 27 January 2017 at 18:34, Vlad Mihalcea > wrote: > >> I'm for removing it even if it didn't complicate the query parser. > >> > >> Vlad > >> > >> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole > wrote: > >> > >>> Because the behavior is also fundamentally questionable. > >>> > >>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov < > >>> christian.beikov at gmail.com> wrote: > >>> > >>>> I'm sorry, I apparently confused iterate() with scroll() then, so > forget > >>>> what I wrote before ^^ > >>>> > >>>> In face of that new info, I actually don't know of any actual users. > >>> After > >>>> thinking a bit about it, why not make that behavior configurable via > >>>> setProperty and drop that method? > >>>> > >>>> > >>>> Am 27.01.2017 um 19:01 schrieb Steve Ebersole: > >>>> > >>>> On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov < > >>>> christian.beikov at gmail.com> wrote: > >>>> > >>>> I just know of people that are using iterate() now for efficient > >>>> incremental processing, but I guess any other approach(streams maybe?) > >>>> to do incremental processing would be good enough for these users. > >>>> > >>>> > >>>> ScrollableResults do not meet that need? > >>>> > >>>> > >>>> > >>>> Unfortunately I don't know what a shallow query is or what the > >>>> implication on the query or the processing of being shallow are. > >>>> > >>>> > >>>> Just what I said before. "shallow" is simply a boolean flag that is > part > >>>> of the translator. It is set to true when the translation is > triggered > >>>> from Query#iterate. When the translation is triggered from > Query#list or > >>>> Query#scroll it is set to false. > >>>> > >>>> > >>>> > >>>> I guess this has to do with how row processing is done? > >>>> > >>>> > >>>> The main thing is effects is the SQL we render. For "entity returns" > it > >>>> simply selects the ids and we expect to then load them (immediately!) > by > >>>> that id (N+1). Its usefulness is actually VERY limited in scope as it > >>>> actually performs horrendously in, what, 95-99% of use cases? > >>>> > >>>> Interestingly it really does not have much effect on "row processing". > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From christian.beikov at gmail.com Fri Jan 27 14:25:12 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Fri, 27 Jan 2017 20:25:12 +0100 Subject: [hibernate-dev] Extended KEY expression support Message-ID: <1aeaf4a4-ad8f-e05a-671e-0f58ea67337d@gmail.com> I have a little proposal for supporting the use of a KEY expression in the FROM clause and I'd like to hear your opinions on that. Unfortunately the JPA spec does not support that, but since a key of a java.util.Map mapping may be an entity type, we need to specify how one can "join" that key explicitly. Right now(pre HHH-10537), when joining a java.util.Map mapping, an inner join is generated for the map key entity type. In my fix for HHH-10537 I changed the behavior to respect/inherit the join type of the collection join. The problem is, that one can't further join any attributes on that key, because there is no syntax in the HQL or the JPA spec that allows to do that. We need to decide (1) whether we always want to join the entity key or require the user to do that specifically via e.g. something like "JOIN alias.map m JOIN KEY(m) k" and also (2) how the syntax for joining further attributes should look like. If we decide to not allow the "JOIN KEY(m)" syntax for (1) we have to support something like "JOIN KEY(m).association", otherwise we can just use the alias like for normal joins "JOIN k.association". Either way, we have to change the grammar but I'd rather like to support/implement the map key joining syntax like "JOIN KEY(m) k" for (1). A further change to that would be to not generate the implicit key table join anymore but require the user to do the join explicitly. Since that would break backwards compatibility, I'd like to make that behavior configurable and of course, by default it will generate the implicit key join to maintain backwards compatibility. I also propose to switch the default in 6.0 so that the join is not generate anymore. The usage in the JPA Criteria API will unfortunately require a cast since the return type of javax.persistence.metamodel.MapAttribute#key() is javax.persistence.metamodel.Path instead of javax.persistence.metamodel.SingularAttribute but essentially the same functionality is available to a user out of the box. Specifying a custom join for a key would look like this in the Criteria API MapAttribute mapAttribute = ... Join keyEntity = mapAttribute.join((SingularAttribute) mapAttribute.key(), JoinType.LEFT); keyEntity.join(...) So the questions again. 1. Do you all agree that this is important and should be done? 2. Agree to not generate implicit joins for keys in future versions? 3. Allow joining the key in a separate join? 4. Allow further joins on a key? 5. Happy with how it can be done in JPA Criteria? In addition to that, it would be nice if anyone could make someone from the JPA EG aware of this. From a JPQL BNF point of view, I'd propose the following changes from join_single_valued_path_expression::= identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field to join_single_valued_path_expression::= identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field | map_field_identification_variable Regards, Christian From christian.beikov at gmail.com Fri Jan 27 15:28:47 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Fri, 27 Jan 2017 21:28:47 +0100 Subject: [hibernate-dev] Extended KEY expression support In-Reply-To: <1aeaf4a4-ad8f-e05a-671e-0f58ea67337d@gmail.com> References: <1aeaf4a4-ad8f-e05a-671e-0f58ea67337d@gmail.com> Message-ID: <7660d854-b7b1-2394-9f47-e6054f25b79e@gmail.com> Fwiw EclipseLink supports both syntaxes "JOIN KEY(m) k" and also "JOIN KEY(m).association". Am 27.01.2017 um 20:25 schrieb Christian Beikov: > I have a little proposal for supporting the use of a KEY expression in > the FROM clause and I'd like to hear your opinions on that. > Unfortunately the JPA spec does not support that, but since a key of a > java.util.Map mapping may be an entity type, we need to specify how > one can "join" that key explicitly. > > Right now(pre HHH-10537), when joining a java.util.Map mapping, an > inner join is generated for the map key entity type. In my fix for > HHH-10537 I changed the behavior to respect/inherit the join type of > the collection join. > The problem is, that one can't further join any attributes on that > key, because there is no syntax in the HQL or the JPA spec that allows > to do that. > > We need to decide (1) whether we always want to join the entity key or > require the user to do that specifically via e.g. something like "JOIN > alias.map m JOIN KEY(m) k" > and also (2) how the syntax for joining further attributes should look > like. If we decide to not allow the "JOIN KEY(m)" syntax for (1) we > have to support something like "JOIN KEY(m).association", otherwise we > can just use the alias like for normal joins "JOIN k.association". > Either way, we have to change the grammar but I'd rather like to > support/implement the map key joining syntax like "JOIN KEY(m) k" for > (1). A further change to that would be to not generate the implicit > key table join anymore but require the user to do the join explicitly. > Since that would break backwards compatibility, I'd like to make that > behavior configurable and of course, by default it will generate the > implicit key join to maintain backwards compatibility. I also propose > to switch the default in 6.0 so that the join is not generate anymore. > The usage in the JPA Criteria API will unfortunately require a cast > since the return type of > javax.persistence.metamodel.MapAttribute#key() is > javax.persistence.metamodel.Path instead of > javax.persistence.metamodel.SingularAttribute but essentially the same > functionality is available to a user out of the box. > Specifying a custom join for a key would look like this in the > Criteria API > > MapAttribute mapAttribute = ... > Join keyEntity = > mapAttribute.join((SingularAttribute MapKeyEntity>) mapAttribute.key(), JoinType.LEFT); > keyEntity.join(...) > > So the questions again. > 1. Do you all agree that this is important and should be done? > 2. Agree to not generate implicit joins for keys in future versions? > 3. Allow joining the key in a separate join? > 4. Allow further joins on a key? > 5. Happy with how it can be done in JPA Criteria? > > In addition to that, it would be nice if anyone could make someone > from the JPA EG aware of this. > From a JPQL BNF point of view, I'd propose the following changes > > from > > join_single_valued_path_expression::= > identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field > > > to > > join_single_valued_path_expression::= > identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field > | > map_field_identification_variable > > Regards, > Christian From steve at hibernate.org Fri Jan 27 17:58:41 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Jan 2017 22:58:41 +0000 Subject: [hibernate-dev] Extended KEY expression support In-Reply-To: <1aeaf4a4-ad8f-e05a-671e-0f58ea67337d@gmail.com> References: <1aeaf4a4-ad8f-e05a-671e-0f58ea67337d@gmail.com> Message-ID: My initial thoughts... On Fri, Jan 27, 2017 at 1:29 PM Christian Beikov wrote: > I have a little proposal for supporting the use of a KEY expression in > the FROM clause and I'd like to hear your opinions on that. > Unfortunately the JPA spec does not support that, but since a key of a > java.util.Map mapping may be an entity type, we need to specify how one > can "join" that key explicitly. > > Right now(pre HHH-10537), when joining a java.util.Map mapping, an inner > join is generated for the map key entity type. In my fix for HHH-10537 I > changed the behavior to respect/inherit the join type of the collection > join. > The problem is, that one can't further join any attributes on that key, > because there is no syntax in the HQL or the JPA spec that allows to do > that. > > We need to decide (1) whether we always want to join the entity key or > require the user to do that specifically via e.g. something like "JOIN > alias.map m JOIN KEY(m) k" > and also (2) how the syntax for joining further attributes should look > like. If we decide to not allow the "JOIN KEY(m)" syntax for (1) we have > to support something like "JOIN KEY(m).association", otherwise we can > just use the alias like for normal joins "JOIN k.association". > I definitely like the syntax to join the key if it happens to be an entity (or an embedded!). That makes the syntax for further referencing or joining it's attributes very natural. Either way, we have to change the grammar but I'd rather like to > support/implement the map key joining syntax like "JOIN KEY(m) k" for > (1). By "change the grammar" I assume you mean the JPA query BNF? Because the SQM grammar already supports this. Or perhaps you mean the pre-6.0 Hibernate grammar? If so, see below. A further change to that would be to not generate the implicit key > table join anymore but require the user to do the join explicitly. Since > that would break backwards compatibility, I'd like to make that behavior > configurable and of course, by default it will generate the implicit key > join to maintain backwards compatibility. I also propose to switch the > default in 6.0 so that the join is not generate anymore. > I personally would vote to *not* make this change in 5.x even in terms of making it configurable. The grammar there is fugly enough already and this is the kind of thing (especially making branches of it configurable) that takes that fugliness to a new level. But I think it is a useful change and would certainly consider it for 6.0 > The usage in the JPA Criteria API will unfortunately require a cast > since the return type of javax.persistence.metamodel.MapAttribute#key() > is javax.persistence.metamodel.Path instead of > javax.persistence.metamodel.SingularAttribute but essentially the same > functionality is available to a user out of the box. > Right. In terms of SQM and 6.0 this perfectly illustrates the importance of the Navigable/NavigableSource contracts and defining references and joins based on them as opposed to strictly attribute-based. I *hate* the idea of making the map key "pose" as a SingularAttribute just for the sake of doing things we should be able to do with it. We have to cast anyway, so I'd much prefer to cast to Hibernate-specific (this is Hibernate specific anyway) contracts that expose this more properly probably based on Navigable/NavigableSource above. In those terms, a map key is always a Navigable. If the key happens to be an entity (or an embedded!) then the key is also a NavigableSource and can therefore be further dereferenced. I'd rather base such an extension on this concept rather than making map key be something it is not just to make it work. We can make it work and model it correctly! Specifying a custom join for a key would look like this in the Criteria API > > MapAttribute mapAttribute = ... > Join keyEntity = > mapAttribute.join((SingularAttribute MapKeyEntity>) mapAttribute.key(), JoinType.LEFT); > keyEntity.join(...) > > So the questions again. > 1. Do you all agree that this is important and should be done? 2. Agree to not generate implicit joins for keys in future versions? 3. Allow joining the key in a separate join? > I am missing how 1, 2 and 3 are any different. Anyway... I think it is useful. I think we should plan to do it... for 6.0 > 4. Allow further joins on a key? > And this is a natural consequence of 1, 2 and 3 ;) > 5. Happy with how it can be done in JPA Criteria? > Meh. JPA is a spec. We can make proposals, but we are not the only ones on the EG. What is more important to me is that we make it possible from *our* implementation of the spec. Especially moving forward considering we dropped the legacy criteria API and plan to develop criteria extensions on top of the JPA criteria API. It is overall better designed - we just need to add in our extras that JPA does not support. What that looks like exactly (to get around JPA not defining it) is not very as relevant to me. We'll make the proposal which is the most we can do. > In addition to that, it would be nice if anyone could make someone from > the JPA EG aware of this. > From a JPQL BNF point of view, I'd propose the following changes > > from > > join_single_valued_path_expression::= > > identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field > > to > > join_single_valued_path_expression::= > > identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field > | > map_field_identification_variable > > Well considering myself, Scott and Emmanuel are all part of the JPA EG... done ;) That said, in my experience, the JPA EG (or certain members of it) tend to be extremely resistent to changes. I'm not certain this is something they would go for, specificaly because of the Criteria implication you mention. While I'm not sure it says this specifically, the assumption is that the BNF applies to both JPQL and Criteria. We can certainly bring it up for discussion if/when we have serious discussions about the "next steps" for the spec. From steve at hibernate.org Fri Jan 27 17:59:56 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Jan 2017 22:59:56 +0000 Subject: [hibernate-dev] Extended KEY expression support In-Reply-To: <7660d854-b7b1-2394-9f47-e6054f25b79e@gmail.com> References: <1aeaf4a4-ad8f-e05a-671e-0f58ea67337d@gmail.com> <7660d854-b7b1-2394-9f47-e6054f25b79e@gmail.com> Message-ID: FWIW = for what it is worth. TBH, to me it is not worth much ;) I don't do things "just because EclipseLink does it". On Fri, Jan 27, 2017 at 2:33 PM Christian Beikov wrote: > Fwiw EclipseLink supports both syntaxes "JOIN KEY(m) k" and also "JOIN > KEY(m).association". > > Am 27.01.2017 um 20:25 schrieb Christian Beikov: > > I have a little proposal for supporting the use of a KEY expression in > > the FROM clause and I'd like to hear your opinions on that. > > Unfortunately the JPA spec does not support that, but since a key of a > > java.util.Map mapping may be an entity type, we need to specify how > > one can "join" that key explicitly. > > > > Right now(pre HHH-10537), when joining a java.util.Map mapping, an > > inner join is generated for the map key entity type. In my fix for > > HHH-10537 I changed the behavior to respect/inherit the join type of > > the collection join. > > The problem is, that one can't further join any attributes on that > > key, because there is no syntax in the HQL or the JPA spec that allows > > to do that. > > > > We need to decide (1) whether we always want to join the entity key or > > require the user to do that specifically via e.g. something like "JOIN > > alias.map m JOIN KEY(m) k" > > and also (2) how the syntax for joining further attributes should look > > like. If we decide to not allow the "JOIN KEY(m)" syntax for (1) we > > have to support something like "JOIN KEY(m).association", otherwise we > > can just use the alias like for normal joins "JOIN k.association". > > Either way, we have to change the grammar but I'd rather like to > > support/implement the map key joining syntax like "JOIN KEY(m) k" for > > (1). A further change to that would be to not generate the implicit > > key table join anymore but require the user to do the join explicitly. > > Since that would break backwards compatibility, I'd like to make that > > behavior configurable and of course, by default it will generate the > > implicit key join to maintain backwards compatibility. I also propose > > to switch the default in 6.0 so that the join is not generate anymore. > > The usage in the JPA Criteria API will unfortunately require a cast > > since the return type of > > javax.persistence.metamodel.MapAttribute#key() is > > javax.persistence.metamodel.Path instead of > > javax.persistence.metamodel.SingularAttribute but essentially the same > > functionality is available to a user out of the box. > > Specifying a custom join for a key would look like this in the > > Criteria API > > > > MapAttribute mapAttribute = ... > > Join keyEntity = > > mapAttribute.join((SingularAttribute > MapKeyEntity>) mapAttribute.key(), JoinType.LEFT); > > keyEntity.join(...) > > > > So the questions again. > > 1. Do you all agree that this is important and should be done? > > 2. Agree to not generate implicit joins for keys in future versions? > > 3. Allow joining the key in a separate join? > > 4. Allow further joins on a key? > > 5. Happy with how it can be done in JPA Criteria? > > > > In addition to that, it would be nice if anyone could make someone > > from the JPA EG aware of this. > > From a JPQL BNF point of view, I'd propose the following changes > > > > from > > > > join_single_valued_path_expression::= > > > identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field > > > > > > to > > > > join_single_valued_path_expression::= > > > identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field > > | > > map_field_identification_variable > > > > Regards, > > Christian > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From christian.beikov at gmail.com Sat Jan 28 06:00:27 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Sat, 28 Jan 2017 12:00:27 +0100 Subject: [hibernate-dev] Extended KEY expression support In-Reply-To: References: <1aeaf4a4-ad8f-e05a-671e-0f58ea67337d@gmail.com> Message-ID: <68fa381f-e532-0d20-f527-82039169969e@gmail.com> I created an issue for this feature: https://hibernate.atlassian.net/browse/HHH-11433 If we agree to render "domain joins" that involve multiple tables with the ANSI SQL parenthesis join syntax, we can actually even "ignore" the join types for key and value tables. That would make things like referring to subtype properties in an ON clause also a lot easier. Here a quick example: @Entity class Entity{ Map map; } @Entity @Inheritance(JOINED) class A{ ... } @Entity class B extends A { String propertyB; } @Entity class C extends A { String propertyC; } @Entity @Inheritance(JOINED) class X { String propertyX; } @Entity class Y { String propertyY; } @Entity class Z { String propertyZ; } SELECT e.id, KEY(m), VALUE(m) FROM Entity e LEFT JOIN e.map m ON KEY(m).propertyX > 0 AND TREAT(KEY(m) AS Y).propertyY = TREAT(m AS B).propertyB OR KEY(m).propertyX <= 0 AND TREAT(KEY(m) AS Z).propertyZ = TREAT(m AS C).propertyC That would render roughly like SELECT ... FROM table_entity e LEFT JOIN ( table_map m JOIN ( table_x x LEFT JOIN table_y y ON x.id = y.id LEFT JOIN table_z z ON x.id = z.id ) ON m.key = x.id JOIN ( table_a a LEFT JOIN table_b b ON a.id = b.id LEFT JOIN table_c c ON a.id = c.id ) ON m.value = a.id ) m ON m.e_id = e.id AND ( x.property_x > 0 AND y.property_y = b.property_b OR x.property_x <= 0 AND z.property_z = c.property_c ) I guess the concept of the parenthesis join fits the table group idea? Am 27.01.2017 um 23:58 schrieb Steve Ebersole > > A further change to that would be to not generate the implicit key > table join anymore but require the user to do the join explicitly. > Since > that would break backwards compatibility, I'd like to make that > behavior > configurable and of course, by default it will generate the > implicit key > join to maintain backwards compatibility. I also propose to switch the > default in 6.0 so that the join is not generate anymore. > > > I personally would vote to *not* make this change in 5.x even in terms > of making it configurable. The grammar there is fugly enough already > and this is the kind of thing (especially making branches of it > configurable) that takes that fugliness to a new level. I gave that another thought and don't think that requiring the user to do a separate join is a good idea anymore. We can actually infer if a join is required and when using the ANSI parenthesis join syntax the join type does not really matter. If we stick to the join rendering style we have, we should just use the collection tables join type. Do you think it makes sense to implement support for "JOIN KEY(m).association" in 5.2 or just leave it as it is? I would implement that if you give your ok. What do you think about all that so far? From chris at hibernate.org Sat Jan 28 15:37:44 2017 From: chris at hibernate.org (Chris Cranford) Date: Sat, 28 Jan 2017 15:37:44 -0500 Subject: [hibernate-dev] Query#iterate In-Reply-To: References: <836985ff-3d69-e726-4f93-555b4de216b5@gmail.com> Message-ID: <17f7d7ab-fae1-0ef1-28df-bc8f3ca359e6@hibernate.org> +1 to remove as well On 01/27/2017 01:50 PM, Sanne Grinovero wrote: > +1 to remove > > On 27 January 2017 at 18:34, Vlad Mihalcea wrote: >> I'm for removing it even if it didn't complicate the query parser. >> >> Vlad >> >> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole wrote: >> >>> Because the behavior is also fundamentally questionable. >>> >>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov < >>> christian.beikov at gmail.com> wrote: >>> >>>> I'm sorry, I apparently confused iterate() with scroll() then, so forget >>>> what I wrote before ^^ >>>> >>>> In face of that new info, I actually don't know of any actual users. >>> After >>>> thinking a bit about it, why not make that behavior configurable via >>>> setProperty and drop that method? >>>> >>>> >>>> Am 27.01.2017 um 19:01 schrieb Steve Ebersole: >>>> >>>> On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov < >>>> christian.beikov at gmail.com> wrote: >>>> >>>> I just know of people that are using iterate() now for efficient >>>> incremental processing, but I guess any other approach(streams maybe?) >>>> to do incremental processing would be good enough for these users. >>>> >>>> >>>> ScrollableResults do not meet that need? >>>> >>>> >>>> >>>> Unfortunately I don't know what a shallow query is or what the >>>> implication on the query or the processing of being shallow are. >>>> >>>> >>>> Just what I said before. "shallow" is simply a boolean flag that is part >>>> of the translator. It is set to true when the translation is triggered >>>> from Query#iterate. When the translation is triggered from Query#list or >>>> Query#scroll it is set to false. >>>> >>>> >>>> >>>> I guess this has to do with how row processing is done? >>>> >>>> >>>> The main thing is effects is the SQL we render. For "entity returns" it >>>> simply selects the ids and we expect to then load them (immediately!) by >>>> that id (N+1). Its usefulness is actually VERY limited in scope as it >>>> actually performs horrendously in, what, 95-99% of use cases? >>>> >>>> Interestingly it really does not have much effect on "row processing". >>>> >>>> >>>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From crancran at gmail.com Sat Jan 28 15:55:27 2017 From: crancran at gmail.com (Chris Cranford) Date: Sat, 28 Jan 2017 15:55:27 -0500 Subject: [hibernate-dev] Extended KEY expression support In-Reply-To: <68fa381f-e532-0d20-f527-82039169969e@gmail.com> References: <1aeaf4a4-ad8f-e05a-671e-0f58ea67337d@gmail.com> <68fa381f-e532-0d20-f527-82039169969e@gmail.com> Message-ID: <88395246-a288-7294-031c-0a47567a4dbb@gmail.com> My thoughts.... On 01/28/2017 06:00 AM, Christian Beikov wrote: > I created an issue for this feature: > https://hibernate.atlassian.net/browse/HHH-11433 > > > Am 27.01.2017 um 23:58 schrieb Steve Ebersole >> I personally would vote to *not* make this change in 5.x even in terms >> of making it configurable. The grammar there is fugly enough already >> and this is the kind of thing (especially making branches of it >> configurable) that takes that fugliness to a new level. > I gave that another thought and don't think that requiring the user to > do a separate join is a good idea anymore. We can actually infer if a > join is required and when using the ANSI parenthesis join syntax the > join type does not really matter. If we stick to the join rendering > style we have, we should just use the collection tables join type. > > Do you think it makes sense to implement support for "JOIN > KEY(m).association" in 5.2 or just leave it as it is? I would implement > that if you give your ok. > > What do you think about all that so far? > I'd say we likely shouldn't be putting significant effort into adding **new features*** *into 5.2. I'd recommend adding it into the 6.0 branch and if/when we decide to consider a 5.3 branch release as a further stepping stone to 6.0, perhaps we back-port this feature to that branch if the team feels its relevant to do so. But that's just my perspective :). Chris From andrea at hibernate.org Sat Jan 28 19:36:28 2017 From: andrea at hibernate.org (andrea boriero) Date: Sun, 29 Jan 2017 00:36:28 +0000 Subject: [hibernate-dev] Query#iterate In-Reply-To: <17f7d7ab-fae1-0ef1-28df-bc8f3ca359e6@hibernate.org> References: <836985ff-3d69-e726-4f93-555b4de216b5@gmail.com> <17f7d7ab-fae1-0ef1-28df-bc8f3ca359e6@hibernate.org> Message-ID: +1 to remove On 28 Jan 2017 20:44, "Chris Cranford" wrote: > +1 to remove as well > > > On 01/27/2017 01:50 PM, Sanne Grinovero wrote: > > +1 to remove > > > > On 27 January 2017 at 18:34, Vlad Mihalcea > wrote: > >> I'm for removing it even if it didn't complicate the query parser. > >> > >> Vlad > >> > >> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole > wrote: > >> > >>> Because the behavior is also fundamentally questionable. > >>> > >>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov < > >>> christian.beikov at gmail.com> wrote: > >>> > >>>> I'm sorry, I apparently confused iterate() with scroll() then, so > forget > >>>> what I wrote before ^^ > >>>> > >>>> In face of that new info, I actually don't know of any actual users. > >>> After > >>>> thinking a bit about it, why not make that behavior configurable via > >>>> setProperty and drop that method? > >>>> > >>>> > >>>> Am 27.01.2017 um 19:01 schrieb Steve Ebersole: > >>>> > >>>> On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov < > >>>> christian.beikov at gmail.com> wrote: > >>>> > >>>> I just know of people that are using iterate() now for efficient > >>>> incremental processing, but I guess any other approach(streams maybe?) > >>>> to do incremental processing would be good enough for these users. > >>>> > >>>> > >>>> ScrollableResults do not meet that need? > >>>> > >>>> > >>>> > >>>> Unfortunately I don't know what a shallow query is or what the > >>>> implication on the query or the processing of being shallow are. > >>>> > >>>> > >>>> Just what I said before. "shallow" is simply a boolean flag that is > part > >>>> of the translator. It is set to true when the translation is > triggered > >>>> from Query#iterate. When the translation is triggered from > Query#list or > >>>> Query#scroll it is set to false. > >>>> > >>>> > >>>> > >>>> I guess this has to do with how row processing is done? > >>>> > >>>> > >>>> The main thing is effects is the SQL we render. For "entity returns" > it > >>>> simply selects the ids and we expect to then load them (immediately!) > by > >>>> that id (N+1). Its usefulness is actually VERY limited in scope as it > >>>> actually performs horrendously in, what, 95-99% of use cases? > >>>> > >>>> Interestingly it really does not have much effect on "row processing". > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Mon Jan 30 04:55:32 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jan 2017 10:55:32 +0100 Subject: [hibernate-dev] NoORM - New groupId and relocation artifacts Message-ID: Hi, So, with Gunnar, we did the work to rename the groupId and relocate the artifacts of Validator. It would be nice if we could be consistent on the way we do it. So what we did: - we created a relocation/ directory/parent artifact containing all the relocation artifacts - we only enable the build of the relocation artifacts if the relocation profile is enabled (the release scripts are already updated to take this new profile into account) See these commits for the details: - https://github.com/hibernate/hibernate-validator/commit/744b4c525c527e510648da8fed6c7e0fce8dd95c - https://github.com/hibernate/hibernate-noorm-release-scripts/commit/0fd44ecb06fd8269d8498affdd8e9c2a0c5836d4 If you have any question, feel free to ask. HTH -- Guillaume From yoann at hibernate.org Mon Jan 30 05:23:16 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 30 Jan 2017 11:23:16 +0100 Subject: [hibernate-dev] [HV/HSEARCH] Free form In-Reply-To: <452FAF91-6C62-44E9-86E5-4CB1B7726460@hibernate.org> References: <452FAF91-6C62-44E9-86E5-4CB1B7726460@hibernate.org> Message-ID: Hi, Did the same this week-end, and adapted your work to match the bigger picture of what we discussed on Friday. Basically the "StructureTraverser" is now called "ValueProcessor", because it's not responsible for exposing the internals of a structure anymore, but only to process a structure according to previously defined metadata, passing the output to the "DocumentContext". I think it's the second option you suggested. It makes sense in my opinion, since metadata will be defined differently for different source types (POJO, JSON, ...). This design allows in particular what Sanne suggested: when bootstrapping, we can build some kind of "walker" (a composition of "ValueProcessors") from the metadata, and avoid metadata lookup at runtime. The snippet is there: https://gist.github.com/yrodiere/ 9ff8fe8a8c7f59c1a051b36db20fbd4d I'm sure it'll have to be refined to address additional constraints, but in its current state it seems to address all of our requirements. Yoann Rodi?re Hibernate NoORM Team On 27 January 2017 at 18:23, Emmanuel Bernard wrote: > I took the flight home to play with free form and specifically how we > would retrieve data from the free form structure. > By free-form I mean non POJO but they will have schema (not expressed > here). > > https://github.com/emmanuelbernard/hibernate-search/commit/ > 0bd3fbab137bdad81bfa5b9934063792a050f537 > > And in particular > https://github.com/emmanuelbernard/hibernate- > search/blob/freeform/freeform/src/main/java/org/hibernate/ > freeform/StructureTraverser.java > https://github.com/emmanuelbernard/hibernate- > search/blob/freeform/freeform/src/main/java/org/hibernate/ > freeform/pojo/impl/PojoStructureTraverser.java > > It probably does not compile, I could not make the build work. > > I figured it was important to dump this raw thinking because it will > influence and will be influenced by the redesign of the DocumentBuilder of > Hibernate Search. > > There are several options for traversing a free form structure > - expose the traversing API as a holder to navigate all properties per > structure and sub structure. This is what the prototype shows. Caching > needs to be accessed via a hashmap get or other lookup. Metadata and the > traversing structure will be navigated in parallel > - expose a structure that is specialized to a single property or container > unwrapping aspect. The structures will be spread across and embedded in the > Metadata > > > Another angle: > - create a traversable object per payload to carry it (sharing metadata > info per type) > - have a stateless traversable object that is provided the payload for > each access > > The former seems better as it does not create a traversable object per > object navigated. > The latter is better for payloads that need parsing or are better at > sequential access since state could be cached. > > We need to discuss that and know where DocumentBuilder is going to > properly design this API. > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Mon Jan 30 05:23:53 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jan 2017 11:23:53 +0100 Subject: [hibernate-dev] Hibernate Commons project Message-ID: Hi, So, as discussed at the F2F, I set up an hibernate-commons project. Currently, it's here https://github.com/gsmet/hibernate-commons, waiting for everyone to agree on the name, the license, the purpose and so on. We would like to make quick progress on it as it's blocking for the migration of Search and OGM to the new AsciiDoctor output (we are still using Docbook as the final output for these projects). It would be nice if we could move them to this output for Search 5.7 and OGM 5.1 which are planned for the coming weeks. Basically the idea behind this repo is to centralize things useful to all (or several) Hibernate projects: - an AsciiDoctor theme - testing utilities we would like to share for all the Hibernate projects - (still to be decided as not that obvious) utilities we would like to share for the NoORM projects Things that should be discussed: == The groupId I used hibernate-commons as it seemed like an obvious groupId. The fact is that we already have hibernate-commons-annotations here. Thoughts? == The license Most of our projects are LGPL licensed except for HV which is Apache 2 licensed. Which license should we choose? == The AsciiDoctor theme So the theme I put in is slightly different from the one from ORM: - the top banner is white instead of black. The black banner was a bit too aggressive to my taste; - I was very light on customizing the HTML output as I would really like us to not spend time on maintaining it. So it's basically the default output whereas ORM has customized the color of the titles of the links and several other things. I think the default output is really nice and we can keep it as is; - I customized the PDF output a bit more as there were problems with the default output. I think it's pretty good now. Here is the current output for Search: - HTML: http://docs.jboss.org/hibernate/beta/html_single/ - PDF: http://docs.jboss.org/hibernate/beta/pdf/hibernate_search_reference.pdf -> note that if you want to use a specific theme for specific purposes, it would still be possible. It's a base you can configure with your own CSS and such. Thoughts? -- Guillaume From yoann at hibernate.org Mon Jan 30 06:03:33 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 30 Jan 2017 12:03:33 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: Message-ID: Everything you said seems to make sense to me, so +1. We can see later whether we agree on the other common projects we could add (checkstyle rules, test utils, ...), but I think there won't be many arguments *against* them as long as there is no transitive dependency to these projects for end users. It's mostly about how we work internally, after all. About the specifics: == The groupId To me it seems to make perfect sense to move hibernate-commons-annotations to the same repo, but I can understand it'll cause some trouble to developers. At the very least we could just rename org.hibernate:hibernate-commons-annotations to org.hibernate.commons:hibernate-commons-annotations, so that we'll be consistent with the other 6.x groupId renamings. As for moving code between repos, we can always see about that later: it won't impact end users. == The license On the license side, I think we can only license our common projects under Apache License 2, because one cannot include LGPL work within an ASL2 work. So using LGPL would prevent us from using the projects in HV... probably. Source: http://www.apache.org/legal/resolved.html#category-x > The LGPL is ineligible primarily due to the restrictions it places on larger works, violating the third license criterion. Yoann Rodi?re Hibernate NoORM Team On 30 January 2017 at 11:23, Guillaume Smet wrote: > Hi, > > So, as discussed at the F2F, I set up an hibernate-commons project. > > Currently, it's here https://github.com/gsmet/hibernate-commons, waiting > for everyone to agree on the name, the license, the purpose and so on. > > We would like to make quick progress on it as it's blocking for the > migration of Search and OGM to the new AsciiDoctor output (we are still > using Docbook as the final output for these projects). It would be nice if > we could move them to this output for Search 5.7 and OGM 5.1 which are > planned for the coming weeks. > > Basically the idea behind this repo is to centralize things useful to all > (or several) Hibernate projects: > - an AsciiDoctor theme > - testing utilities we would like to share for all the Hibernate projects > - (still to be decided as not that obvious) utilities we would like to > share for the NoORM projects > > Things that should be discussed: > > == The groupId > > I used hibernate-commons as it seemed like an obvious groupId. The fact is > that we already have hibernate-commons-annotations here. > > Thoughts? > > == The license > > Most of our projects are LGPL licensed except for HV which is Apache 2 > licensed. Which license should we choose? > > == The AsciiDoctor theme > > So the theme I put in is slightly different from the one from ORM: > - the top banner is white instead of black. The black banner was a bit too > aggressive to my taste; > - I was very light on customizing the HTML output as I would really like us > to not spend time on maintaining it. So it's basically the default output > whereas ORM has customized the color of the titles of the links and several > other things. I think the default output is really nice and we can keep it > as is; > - I customized the PDF output a bit more as there were problems with the > default output. I think it's pretty good now. > > Here is the current output for Search: > - HTML: http://docs.jboss.org/hibernate/beta/html_single/ > - PDF: > http://docs.jboss.org/hibernate/beta/pdf/hibernate_search_reference.pdf > > -> note that if you want to use a specific theme for specific purposes, it > would still be possible. It's a base you can configure with your own CSS > and such. > > Thoughts? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Jan 30 06:44:35 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 30 Jan 2017 11:44:35 +0000 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: Message-ID: # groupId +1 for the name "hibernate-commons". I wouldn't want to move the hibernate-commons-annotations project though. This project is stable, not evolving much yet several branches will need to be maintained for very long time still. Moving repositories would make maintenance trickier for no other reason than satisfying some weird form of OCD.. incidentally, I totally relate with the urge to move it but I think we'll have to deal with that ;) # License It's not technically true that an ASL2 project can not depend on LGPL work; I suspect you might get confused with requirements of the Apache Foundation on projects hosted on the foundation: "Apache Products" those requirements are stricter than their license, and Hibernate Validator just uses the ASL2 license but is not an Apache Product. I'm not against using ASL2 for this project, especially since such confusion is common that could help avoiding debates.. but since it contains branding elements (I assume that e.g. the asciidoc style contains logos?) we might actually need to check with legal which licenses are fine with some help from Red Hat legal. # Style +1 I also like the white top banner better. I hope the ORM team will prefer it too, so that we can 1) keep consistency 2) share these. Thanks! Sanne On 30 January 2017 at 11:03, Yoann Rodiere wrote: > Everything you said seems to make sense to me, so +1. > We can see later whether we agree on the other common projects we could add > (checkstyle rules, test utils, ...), but I think there won't be many > arguments *against* them as long as there is no transitive dependency to > these projects for end users. It's mostly about how we work internally, > after all. > > About the specifics: > > == The groupId > > To me it seems to make perfect sense to move hibernate-commons-annotations > to the same repo, but I can understand it'll cause some trouble to > developers. At the very least we could just rename > org.hibernate:hibernate-commons-annotations to > org.hibernate.commons:hibernate-commons-annotations, so that we'll be > consistent with the other 6.x groupId renamings. As for moving code between > repos, we can always see about that later: it won't impact end users. > > == The license > > On the license side, I think we can only license our common projects under > Apache License 2, because one cannot include LGPL work within an ASL2 work. > So using LGPL would prevent us from using the projects in HV... probably. > Source: http://www.apache.org/legal/resolved.html#category-x >> The LGPL is ineligible primarily due to the restrictions it places on > larger works, violating the third license criterion. > > > Yoann Rodi?re > Hibernate NoORM Team > > On 30 January 2017 at 11:23, Guillaume Smet > wrote: > >> Hi, >> >> So, as discussed at the F2F, I set up an hibernate-commons project. >> >> Currently, it's here https://github.com/gsmet/hibernate-commons, waiting >> for everyone to agree on the name, the license, the purpose and so on. >> >> We would like to make quick progress on it as it's blocking for the >> migration of Search and OGM to the new AsciiDoctor output (we are still >> using Docbook as the final output for these projects). It would be nice if >> we could move them to this output for Search 5.7 and OGM 5.1 which are >> planned for the coming weeks. >> >> Basically the idea behind this repo is to centralize things useful to all >> (or several) Hibernate projects: >> - an AsciiDoctor theme >> - testing utilities we would like to share for all the Hibernate projects >> - (still to be decided as not that obvious) utilities we would like to >> share for the NoORM projects >> >> Things that should be discussed: >> >> == The groupId >> >> I used hibernate-commons as it seemed like an obvious groupId. The fact is >> that we already have hibernate-commons-annotations here. >> >> Thoughts? >> >> == The license >> >> Most of our projects are LGPL licensed except for HV which is Apache 2 >> licensed. Which license should we choose? >> >> == The AsciiDoctor theme >> >> So the theme I put in is slightly different from the one from ORM: >> - the top banner is white instead of black. The black banner was a bit too >> aggressive to my taste; >> - I was very light on customizing the HTML output as I would really like us >> to not spend time on maintaining it. So it's basically the default output >> whereas ORM has customized the color of the titles of the links and several >> other things. I think the default output is really nice and we can keep it >> as is; >> - I customized the PDF output a bit more as there were problems with the >> default output. I think it's pretty good now. >> >> Here is the current output for Search: >> - HTML: http://docs.jboss.org/hibernate/beta/html_single/ >> - PDF: >> http://docs.jboss.org/hibernate/beta/pdf/hibernate_search_reference.pdf >> >> -> note that if you want to use a specific theme for specific purposes, it >> would still be possible. It's a base you can configure with your own CSS >> and such. >> >> Thoughts? >> >> -- >> 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 sanne at hibernate.org Mon Jan 30 07:01:34 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 30 Jan 2017 12:01:34 +0000 Subject: [hibernate-dev] NoORM - New groupId and relocation artifacts In-Reply-To: References: Message-ID: Nothing major, but still this got me wondering: - why the parent pom "hibernate-validator-relocation" ? - why the profile switch? do you plan to omit these artifacts for - say - nightly builds and local testing of other projects depending on it? - what's the benefit you're hoping to achieve by being consistent with this approach? Thanks, Sanne On 30 January 2017 at 09:55, Guillaume Smet wrote: > Hi, > > So, with Gunnar, we did the work to rename the groupId and relocate the > artifacts of Validator. > > It would be nice if we could be consistent on the way we do it. > > So what we did: > - we created a relocation/ directory/parent artifact containing all the > relocation artifacts > - we only enable the build of the relocation artifacts if the relocation > profile is enabled (the release scripts are already updated to take this > new profile into account) > > See these commits for the details: > - > https://github.com/hibernate/hibernate-validator/commit/744b4c525c527e510648da8fed6c7e0fce8dd95c > - > https://github.com/hibernate/hibernate-noorm-release-scripts/commit/0fd44ecb06fd8269d8498affdd8e9c2a0c5836d4 > > If you have any question, feel free to ask. > > HTH > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Mon Jan 30 07:08:11 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 30 Jan 2017 13:08:11 +0100 Subject: [hibernate-dev] NoORM - New groupId and relocation artifacts In-Reply-To: References: Message-ID: One benefit we always get by being consistent is that it's easier for a newcomer to switch from project to project... If it doesn't require more work, we may as well be consistent. Anyway, thanks Guillaume, I added this piece of information to the HSearch ticket: https://hibernate.atlassian.net/browse/HSEARCH-2557 Yoann Rodi?re Hibernate NoORM Team On 30 January 2017 at 13:01, Sanne Grinovero wrote: > Nothing major, but still this got me wondering: > - why the parent pom "hibernate-validator-relocation" ? > - why the profile switch? do you plan to omit these artifacts for - > say - nightly builds and local testing of other projects depending on > it? > - what's the benefit you're hoping to achieve by being consistent > with this approach? > > Thanks, > Sanne > > > On 30 January 2017 at 09:55, Guillaume Smet > wrote: > > Hi, > > > > So, with Gunnar, we did the work to rename the groupId and relocate the > > artifacts of Validator. > > > > It would be nice if we could be consistent on the way we do it. > > > > So what we did: > > - we created a relocation/ directory/parent artifact containing all the > > relocation artifacts > > - we only enable the build of the relocation artifacts if the relocation > > profile is enabled (the release scripts are already updated to take this > > new profile into account) > > > > See these commits for the details: > > - > > https://github.com/hibernate/hibernate-validator/commit/ > 744b4c525c527e510648da8fed6c7e0fce8dd95c > > - > > https://github.com/hibernate/hibernate-noorm-release-scripts/commit/ > 0fd44ecb06fd8269d8498affdd8e9c2a0c5836d4 > > > > If you have any question, feel free to ask. > > > > HTH > > > > -- > > Guillaume > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Mon Jan 30 07:49:42 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jan 2017 13:49:42 +0100 Subject: [hibernate-dev] NoORM - New groupId and relocation artifacts In-Reply-To: References: Message-ID: On Mon, Jan 30, 2017 at 1:01 PM, Sanne Grinovero wrote: > Nothing major, but still this got me wondering: > - why the parent pom "hibernate-validator-relocation" ? > To avoid having too many useless directories in the parent directory. > - why the profile switch? do you plan to omit these artifacts for - > say - nightly builds and local testing of other projects depending on > it? > Because it's less noisy when we do a normal build. It's already noisy enough. > - what's the benefit you're hoping to achieve by being consistent > with this approach? > Well, is being consistent not a big enough benefit? -- Guillaume From guillaume.smet at gmail.com Mon Jan 30 07:58:21 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jan 2017 13:58:21 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: Message-ID: On Mon, Jan 30, 2017 at 12:44 PM, Sanne Grinovero wrote: > # groupId > +1 for the name "hibernate-commons". > > I wouldn't want to move the hibernate-commons-annotations project > though. This project is stable, not evolving much yet several branches > will need to be maintained for very long time still. > Moving repositories would make maintenance trickier for no other > reason than satisfying some weird form of OCD.. incidentally, I > totally relate with the urge to move it but I think we'll have to deal > with that ;) > Note that the current version of hibernate-commons-annotations is org.hibernate.common (without the s at the end, not org.hibernate as Yoann stated it). Moving hibernate-commons-annotations is not such a good idea IMHO: - it's licensed under the LGPL so it would force us to use this license (or relicense it or having different licenses for the submodules but they are all bad ideas) - we would release a new version of this module each time we want to upgrade the theme and I don't think it would be readable for consumers of this preexisting artifact. The latter point is what worries me about centralizing all the utils in the same repo with the same lifecycle. > # License > It's not technically true that an ASL2 project can not depend on LGPL > work; I suspect you might get confused with requirements of the Apache > Foundation on projects hosted on the foundation: "Apache Products" > those requirements are stricter than their license, and Hibernate > Validator just uses the ASL2 license but is not an Apache Product. > I'm not against using ASL2 for this project, especially since such > confusion is common that could help avoiding debates.. but since it > contains branding elements (I assume that e.g. the asciidoc style > contains logos?) we might actually need to check with legal which > licenses are fine with some help from Red Hat legal. > Yes, the AsciiDoctor theme contains the Hibernate logo. But so does the HV repository. I don't think it's an issue. > # Style > +1 I also like the white top banner better. I hope the ORM team will > prefer it too, so that we can 1) keep consistency 2) share these. > You see that you like consistency ;). -- Guillaume From sanne at hibernate.org Mon Jan 30 08:01:46 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 30 Jan 2017 13:01:46 +0000 Subject: [hibernate-dev] NoORM - New groupId and relocation artifacts In-Reply-To: References: Message-ID: On 30 January 2017 at 12:49, Guillaume Smet wrote: > On Mon, Jan 30, 2017 at 1:01 PM, Sanne Grinovero > wrote: >> >> Nothing major, but still this got me wondering: >> - why the parent pom "hibernate-validator-relocation" ? > > > To avoid having too many useless directories in the parent directory. > >> >> - why the profile switch? do you plan to omit these artifacts for - >> say - nightly builds and local testing of other projects depending on >> it? > > > Because it's less noisy when we do a normal build. It's already noisy > enough. > >> >> - what's the benefit you're hoping to achieve by being consistent >> with this approach? > > > Well, is being consistent not a big enough benefit? Different projects have different needs. Consistency is nice, and certainly makes it easier to find oneself comfortably "at home" when jumping from one project to another, but it also is inconvenient to do things "for consistency" when one has different requirements. So when it comes to trivial changes, IMO practicality trumps need for consistency. But ok, +1 for consistency then. My question was merely to explore if I had missed something non-trivial. Thanks, Sanne > > -- > Guillaume > From guillaume.smet at gmail.com Mon Jan 30 08:09:34 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jan 2017 14:09:34 +0100 Subject: [hibernate-dev] NoORM - New groupId and relocation artifacts In-Reply-To: References: Message-ID: On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero wrote: > Different projects have different needs. Consistency is nice, and > certainly makes it easier to find oneself comfortably "at home" when > jumping from one project to another, but it also is inconvenient to do > things "for consistency" when one has different requirements. > I don't think we would have different requirements regarding the relocation artifacts. But if you see any issue with the approach we chose for HV, interesting in hearing them so that we can have the same approach for the different NoORM project. -- Guillaume From davide at hibernate.org Mon Jan 30 08:14:15 2017 From: davide at hibernate.org (Davide D'Alto) Date: Mon, 30 Jan 2017 13:14:15 +0000 Subject: [hibernate-dev] Update Jenkins plugins In-Reply-To: References: Message-ID: I didn't have time to do it. I'll postponed the updates to next week: the 9th of February Thanks, Davide On Tue, Jan 17, 2017 at 4:56 PM, Davide D'Alto wrote: > Hi, > there are some plugins to upgrade on Jenkins and it seems they have > some non trivial changes. > > I'll do that on Thursday and hopefully it won't cause too many issues. > > Thanks, > Davideb From yoann at hibernate.org Mon Jan 30 09:29:11 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 30 Jan 2017 15:29:11 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: Message-ID: On 30 January 2017 at 13:58, Guillaume Smet wrote: > Note that the current version of hibernate-commons-annotations is > org.hibernate.common (without the s at the end, not org.hibernate as Yoann > stated it). > You're right. Wouldn't the simplest solution be to use the same groupId (without a "s") in our new repo? > Moving hibernate-commons-annotations is not such a good idea IMHO: > - it's licensed under the LGPL so it would force us to use this license (or > relicense it or having different licenses for the submodules but they are > all bad ideas) > It sure seems complicated. But relicensing from LGPL to ASL2 may not be such a big deal, since LGPL seems stricter than ASL2. Couldn't we simply dual-license the whole repository under ASL2/LGPL? That way, previous users wouldn't need to be aware of the change, and new users could choose to comply with whichever suits them best. Or does it require to release two packages for each submodule (one for each license)? Anyway... there are other reasons for not wanting to move the code to another repo, so maybe we could just focus on having consistent group IDs and let the code live in different places and have different maven parents. > - we would release a new version of this module each time we want to > upgrade the theme and I don't think it would be readable for consumers of > this preexisting artifact. > > The latter point is what worries me about centralizing all the utils in the > same repo with the same lifecycle. > We already got through this discussion, but let's sum it up: - With a common versioning, consuming projects will only have to take care to use the latest version available and use it for every common project they depend on. - With a common versioning, consuming projects will retain the ability to punctually use an older version for some subproject. Sure, on the day we decide to break something, we'll have to bump the minor or major for every "common" project, and it will give the false impression that every such project has breaking changes. But we don't wan't to do that often, and we'll probably won't have so many common projects anyway. Having separate lifecycles/repos is probably cleaner, but it has its own downsides: - Consuming poms will be less readable and less easily updated (one version per consumed common project). - Releasing the common projects will be more work. - Maintenance will be a bit harder (having multiple scattered repos to work on). - We'll run the risk of some common projects not being updated, in particular the version of their dependencies. Which could be avoided, or at least be less likely, if we centralize the dependency management in the parent pom of the common projects. We can leave hibernate-common-annotations where it is, since it's pre-existing and already critical in several of our projects, so its maintenance is pretty much guaranteed. But that kind of splitting seems dangerous for the new common projects, because it makes it harder to maintain them, and there will be no full-time maintainers. So we'd better not split these common projects any further, and give these projects a chance to get regular maintenance... Yoann Rodi?re Hibernate NoORM Team From guillaume.smet at gmail.com Mon Jan 30 10:37:39 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jan 2017 16:37:39 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: Message-ID: On Mon, Jan 30, 2017 at 3:26 PM, Yoann Rodiere wrote: > > On 30 January 2017 at 13:58, Guillaume Smet > wrote: > >> Note that the current version of hibernate-commons-annotations is >> org.hibernate.common (without the s at the end, not org.hibernate as Yoann >> stated it). >> > You're right. Wouldn't the simplest solution be to use the same groupId > (without a "s") in our new repo? > I'm not so sure it's a good idea to share the groupId while it being a completely different project. I'm starting to think that maybe the good groupId for these common internal projects could be org.hibernate.*internal*. We plan them to be purely internal artifacts and we might as well state it. What do you all think about it? > Moving hibernate-commons-annotations is not such a good idea IMHO: >> - it's licensed under the LGPL so it would force us to use this license >> (or >> relicense it or having different licenses for the submodules but they are >> all bad ideas) >> > > It sure seems complicated. But relicensing from LGPL to ASL2 may not be > such a big deal, since LGPL seems stricter than ASL2. > Couldn't we simply dual-license the whole repository under ASL2/LGPL? That > way, previous users wouldn't need to be aware of the change, and new users > could choose to comply with whichever suits them best. > Yeah, dual licensing might be the better solution. But I think it would be OK with ASL2. Anyway, let's wait for Emmanuel to decide on this subject. > - we would release a new version of this module each time we want to >> upgrade the theme and I don't think it would be readable for consumers of >> this preexisting artifact. >> >> The latter point is what worries me about centralizing all the utils in >> the >> same repo with the same lifecycle. >> > > We already got through this discussion, but let's sum it up: > Not exactly. I was specifically talking about hibernate-commons-annotations as it's a different beast: it's already released and people might use it in their projects. Thus I don't think it's a good idea to think of it as a purely internal project. IMHO, it makes a difference. -- Guillaume From steve at hibernate.org Mon Jan 30 11:26:40 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 30 Jan 2017 16:26:40 +0000 Subject: [hibernate-dev] NoORM - New groupId and relocation artifacts In-Reply-To: References: Message-ID: Well let's investigate what this consistency means across projects first. As Sanne mentions, if it makes it building ORM more difficult then I'd be -1 it too. But I promise to take a peek when I get back from PTO in a few days. Or maybe Andrea can in the next few days as he already has worked on the changes to release relocation artifacts for ORM; I just do not know when he is coming back from PTO. Either way we will have looked at it for ORM by the end of week. On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet wrote: On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero wrote: > Different projects have different needs. Consistency is nice, and > certainly makes it easier to find oneself comfortably "at home" when > jumping from one project to another, but it also is inconvenient to do > things "for consistency" when one has different requirements. > I don't think we would have different requirements regarding the relocation artifacts. But if you see any issue with the approach we chose for HV, interesting in hearing them so that we can have the same approach for the different NoORM project. -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Jan 30 11:31:51 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 30 Jan 2017 16:31:51 +0000 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts) In-Reply-To: References: Message-ID: Relatedly, I have been thinking whether we want to rename the ORM artifacts as well since this is the best time if we wanted to do that. So we know we will change the groupId to `org.hibernate.orm`. I was thinking we might want to also either: 1. rename `hibernate-core` as `hibernate-orm` 2. rename all the artifacts following the pattern `hibernate-orm-${1}`, e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole wrote: > Well let's investigate what this consistency means across projects first. > As Sanne mentions, if it makes it building ORM more difficult then I'd be > -1 it too. But I promise to take a peek when I get back from PTO in a few > days. Or maybe Andrea can in the next few days as he already has worked on > the changes to release relocation artifacts for ORM; I just do not know > when he is coming back from PTO. Either way we will have looked at it for > ORM by the end of week. > > On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet > wrote: > > On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero > wrote: > > > Different projects have different needs. Consistency is nice, and > > certainly makes it easier to find oneself comfortably "at home" when > > jumping from one project to another, but it also is inconvenient to do > > things "for consistency" when one has different requirements. > > > > I don't think we would have different requirements regarding the relocation > artifacts. > > But if you see any issue with the approach we chose for HV, interesting in > hearing them so that we can have the same approach for the different NoORM > project. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From guillaume.smet at gmail.com Mon Jan 30 11:34:12 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jan 2017 17:34:12 +0100 Subject: [hibernate-dev] NoORM - New groupId and relocation artifacts In-Reply-To: References: Message-ID: Hi Steve, Thus the NoORM prefix in the subject :). I just wanted us to be consistent across the NoORM projects. -- Guillaume From steve at hibernate.org Mon Jan 30 11:36:29 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 30 Jan 2017 16:36:29 +0000 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: Message-ID: Disclaimer : I have not yet looked at the Asciidoc style. Again I promise to look at it when I come back from PTO. That said I want to make certain that the developed style matches the new ORM documentation style. The design team at Red Hat spent a lot of time helping us develop that. Specifically I mean the banners and general color scheme. On Mon, Jan 30, 2017 at 9:43 AM Guillaume Smet wrote: > On Mon, Jan 30, 2017 at 3:26 PM, Yoann Rodiere > wrote: > > > > > On 30 January 2017 at 13:58, Guillaume Smet > > wrote: > > > >> Note that the current version of hibernate-commons-annotations is > >> org.hibernate.common (without the s at the end, not org.hibernate as > Yoann > >> stated it). > >> > > You're right. Wouldn't the simplest solution be to use the same groupId > > (without a "s") in our new repo? > > > > I'm not so sure it's a good idea to share the groupId while it being a > completely different project. > > I'm starting to think that maybe the good groupId for these common internal > projects could be org.hibernate.*internal*. We plan them to be purely > internal artifacts and we might as well state it. > > What do you all think about it? > > > > Moving hibernate-commons-annotations is not such a good idea IMHO: > >> - it's licensed under the LGPL so it would force us to use this license > >> (or > >> relicense it or having different licenses for the submodules but they > are > >> all bad ideas) > >> > > > > It sure seems complicated. But relicensing from LGPL to ASL2 may not be > > such a big deal, since LGPL seems stricter than ASL2. > > Couldn't we simply dual-license the whole repository under ASL2/LGPL? > That > > way, previous users wouldn't need to be aware of the change, and new > users > > could choose to comply with whichever suits them best. > > > > Yeah, dual licensing might be the better solution. But I think it would be > OK with ASL2. Anyway, let's wait for Emmanuel to decide on this subject. > > > > - we would release a new version of this module each time we want to > >> upgrade the theme and I don't think it would be readable for consumers > of > >> this preexisting artifact. > >> > >> The latter point is what worries me about centralizing all the utils in > >> the > >> same repo with the same lifecycle. > >> > > > > We already got through this discussion, but let's sum it up: > > > > Not exactly. I was specifically talking about hibernate-commons-annotations > as it's a different beast: it's already released and people might use it in > their projects. Thus I don't think it's a good idea to think of it as a > purely internal project. > > IMHO, it makes a difference. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Jan 30 11:37:34 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 30 Jan 2017 16:37:34 +0000 Subject: [hibernate-dev] NoORM - New groupId and relocation artifacts In-Reply-To: References: Message-ID: Umm, we could also be consistent across all of the projects since they are all Hibernate projects. On Mon, Jan 30, 2017 at 10:34 AM Guillaume Smet wrote: > Hi Steve, > > Thus the NoORM prefix in the subject :). > > I just wanted us to be consistent across the NoORM projects. > > -- > Guillaume > From mark at lawinegevaar.nl Mon Jan 30 12:00:57 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Mon, 30 Jan 2017 18:00:57 +0100 Subject: [hibernate-dev] When is Dialect.requiresCastingOfParametersInSelectClause applied? Message-ID: After a hiatus of 6 months, I have gone back to my PR for improving/replacing the Firebird dialect. I am running into a number of test failures which I am working through to see if they are relevant or not. One of the test failures I am looking at is org.hibernate.jpa.test.criteria.basic.ConcatTest.testSelectCaseWithConcat Firebird is rather picky about parameters occurring in the select-clause, and they will almost always need to be cast to the necessary type (and lengths). This tests seems to generate the following query: select case when concattest0_.id is not null then (?||?) else 'Empty' end as col_0_0_, trim(both ' ' from (?||?)) as col_1_0_ from TEST_ENTITY concattest0_ I have implemented Dialect#requiresCastingOfParametersInSelectClause() to return true, but unfortunately for this specific test it has no effect. The absolute minimum SQL necessary for this to work (with some caveats) is: select case when 1 = 1 then (?||?) else 'Empty' end as col_0_0_, trim(both ' ' from (cast(? as varchar(256))|| cast(? as varchar(256)))) as col_1_0_ from TEST_ENTITY concattest0_ And preferably the (?||?) in the case should have an explicit cast for each parameter as well, as otherwise each parameter is limited to 5 characters each (setting longer values will lead to a truncation exception). Is this something that is fixable, and if so how? Or is this one of those things where you just have to say 'aw, too bad, let it go' (or, maybe: do it later if it is really necessary)? With this specific failure out of the way: what is the general rule of thumb of handling test failures in hibernate_core for a lesser-known dialect? I currently have 257 test failures (and 512 ignored) with Firebird and my new dialect. I might add that some failures seem to be generic (eg DriverManagerRegistrationTest, StandardRefCursorSupportTest, NoCdiAvailableTest, XmlAccessTest, FetchProfileTest, IndexTest and some others). -- Mark Rotteveel From yoann at hibernate.org Mon Jan 30 13:07:25 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 30 Jan 2017 19:07:25 +0100 Subject: [hibernate-dev] Hibernate Search 5.6.0.Final and 5.7.0.CR1 released Message-ID: Hello, We just released Hibernate Search 5.6.0.Final, the first stable release featuring experimental support for Elasticsearch (2.x). We also started the candidate release phase for Hibernate Search 5.7 by releasing version 5.7.0.CR1, with support for ORM 5.2.7 and newer (but not older, see the blog post). This is the last step before 5.7 is released, so be sure to check it out so you can share your thoughts with us before the release! For more information, please see our blog: http://in.relation.to/2017/01/30/hibernate-search-5-6-0-Final-and-5-7-0-CR1/ Cheers, Yoann Rodi?re Hibernate NoORM Team From sanne at hibernate.org Mon Jan 30 13:19:13 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 30 Jan 2017 18:19:13 +0000 Subject: [hibernate-dev] [hibernate-announce] Hibernate Search 5.6.0.Final and 5.7.0.CR1 released In-Reply-To: References: Message-ID: Great! Fantastic work everyone! On 30 January 2017 at 18:07, Yoann Rodiere wrote: > Hello, > > We just released Hibernate Search 5.6.0.Final, the first stable release > featuring experimental support for Elasticsearch (2.x). > > We also started the candidate release phase for Hibernate Search 5.7 by > releasing version 5.7.0.CR1, with support for ORM 5.2.7 and newer (but not > older, see the blog post). > This is the last step before 5.7 is released, so be sure to check it out so > you can share your thoughts with us before the release! > > For more information, please see our blog: > > http://in.relation.to/2017/01/30/hibernate-search-5-6-0-Final-and-5-7-0-CR1/ > > Cheers, > > Yoann Rodi?re > Hibernate NoORM Team > _______________________________________________ > hibernate-announce mailing list > hibernate-announce at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-announce From andrea at hibernate.org Mon Jan 30 14:05:24 2017 From: andrea at hibernate.org (andrea boriero) Date: Mon, 30 Jan 2017 19:05:24 +0000 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts) In-Reply-To: References: Message-ID: I worked on the ORM relocation script probably a year ago, I'll have to go back and refresh my memory. Tomorrow I'll give a look at it. On 30 Jan 2017 16:44, "Steve Ebersole" wrote: > Relatedly, I have been thinking whether we want to rename the ORM artifacts > as well since this is the best time if we wanted to do that. > > So we know we will change the groupId to `org.hibernate.orm`. > > I was thinking we might want to also either: > > 1. rename `hibernate-core` as `hibernate-orm` > 2. rename all the artifacts following the pattern `hibernate-orm-${1}`, > e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. > > > On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole > wrote: > > > Well let's investigate what this consistency means across projects first. > > As Sanne mentions, if it makes it building ORM more difficult then I'd be > > -1 it too. But I promise to take a peek when I get back from PTO in a > few > > days. Or maybe Andrea can in the next few days as he already has worked > on > > the changes to release relocation artifacts for ORM; I just do not know > > when he is coming back from PTO. Either way we will have looked at it > for > > ORM by the end of week. > > > > On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet > > > wrote: > > > > On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero > > wrote: > > > > > Different projects have different needs. Consistency is nice, and > > > certainly makes it easier to find oneself comfortably "at home" when > > > jumping from one project to another, but it also is inconvenient to do > > > things "for consistency" when one has different requirements. > > > > > > > I don't think we would have different requirements regarding the > relocation > > artifacts. > > > > But if you see any issue with the approach we chose for HV, interesting > in > > hearing them so that we can have the same approach for the different > NoORM > > project. > > > > -- > > Guillaume > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From andrea at hibernate.org Mon Jan 30 14:19:13 2017 From: andrea at hibernate.org (andrea boriero) Date: Mon, 30 Jan 2017 19:19:13 +0000 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts) In-Reply-To: References: Message-ID: Not have a strong opinion on the renaming. On 30 Jan 2017 19:05, "andrea boriero" wrote: I worked on the ORM relocation script probably a year ago, I'll have to go back and refresh my memory. Tomorrow I'll give a look at it. On 30 Jan 2017 16:44, "Steve Ebersole" wrote: > Relatedly, I have been thinking whether we want to rename the ORM artifacts > as well since this is the best time if we wanted to do that. > > So we know we will change the groupId to `org.hibernate.orm`. > > I was thinking we might want to also either: > > 1. rename `hibernate-core` as `hibernate-orm` > 2. rename all the artifacts following the pattern `hibernate-orm-${1}`, > e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. > > > On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole > wrote: > > > Well let's investigate what this consistency means across projects first. > > As Sanne mentions, if it makes it building ORM more difficult then I'd be > > -1 it too. But I promise to take a peek when I get back from PTO in a > few > > days. Or maybe Andrea can in the next few days as he already has worked > on > > the changes to release relocation artifacts for ORM; I just do not know > > when he is coming back from PTO. Either way we will have looked at it > for > > ORM by the end of week. > > > > On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet > > > wrote: > > > > On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero > > wrote: > > > > > Different projects have different needs. Consistency is nice, and > > > certainly makes it easier to find oneself comfortably "at home" when > > > jumping from one project to another, but it also is inconvenient to do > > > things "for consistency" when one has different requirements. > > > > > > > I don't think we would have different requirements regarding the > relocation > > artifacts. > > > > But if you see any issue with the approach we chose for HV, interesting > in > > hearing them so that we can have the same approach for the different > NoORM > > project. > > > > -- > > Guillaume > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Mon Jan 30 14:49:48 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jan 2017 20:49:48 +0100 Subject: [hibernate-dev] NoORM - New groupId and relocation artifacts In-Reply-To: References: Message-ID: On Mon, Jan 30, 2017 at 5:37 PM, Steve Ebersole wrote: > Umm, we could also be consistent across all of the projects since they are > all Hibernate projects. > Sure. But as the build system is different, there might be different requirements/prerequisites. So, for the NoORM projects, I'd like us to be consistent as the projects have a lot of things in common. For the ORM project, it's your call. -- Guillaume From guillaume.smet at gmail.com Mon Jan 30 14:57:54 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Jan 2017 20:57:54 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: Message-ID: On Mon, Jan 30, 2017 at 5:36 PM, Steve Ebersole wrote: > Disclaimer : I have not yet looked at the Asciidoc style. Again I promise > to look at it when I come back from PTO. That said I want to make certain > that the developed style matches the new ORM documentation style. The > design team at Red Hat spent a lot of time helping us develop that. > Specifically I mean the banners and general color scheme > So that you don't waste your time looking for the differences: they are not similar. There were a lot of things disturbing me in the current ORM theme (the black banner too aggressive, the lots of fonts loaded, the old icons for warning/note, some overriding that I don't find strictly necessary and don't think are worth maintaining...). The one I put there is simpler and doesn't override that many things (apart from adding the logo with the banner). That being said, it's possible to use part of what I pushed and have specific parts for what you want to keep. It was designed that way. Typically, I think you might be interested by the PDF theme anyway. If others think the ORM theme should be the one we enforce, I'll push it but I won't maintain the theme if it breaks in the future (and I'm really not convinced by the output). All in all, not a subject to work on while you're on PTO :). -- Guillaume From christian.beikov at gmail.com Tue Jan 31 01:51:29 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Tue, 31 Jan 2017 07:51:29 +0100 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId In-Reply-To: References: Message-ID: <8ac62a27-3990-198a-241a-e5404ad3e853@gmail.com> Sounds good to me. +1 Am 30.01.2017 um 17:31 schrieb Steve Ebersole: > Relatedly, I have been thinking whether we want to rename the ORM artifacts > as well since this is the best time if we wanted to do that. > > So we know we will change the groupId to `org.hibernate.orm`. > > I was thinking we might want to also either: > > 1. rename `hibernate-core` as `hibernate-orm` > 2. rename all the artifacts following the pattern `hibernate-orm-${1}`, > e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. > > > On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole wrote: > >> Well let's investigate what this consistency means across projects first. >> As Sanne mentions, if it makes it building ORM more difficult then I'd be >> -1 it too. But I promise to take a peek when I get back from PTO in a few >> days. Or maybe Andrea can in the next few days as he already has worked on >> the changes to release relocation artifacts for ORM; I just do not know >> when he is coming back from PTO. Either way we will have looked at it for >> ORM by the end of week. >> >> On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet >> wrote: >> >> On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero >> wrote: >> >>> Different projects have different needs. Consistency is nice, and >>> certainly makes it easier to find oneself comfortably "at home" when >>> jumping from one project to another, but it also is inconvenient to do >>> things "for consistency" when one has different requirements. >>> >> I don't think we would have different requirements regarding the relocation >> artifacts. >> >> But if you see any issue with the approach we chose for HV, interesting in >> hearing them so that we can have the same approach for the different NoORM >> project. >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Tue Jan 31 03:09:20 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 31 Jan 2017 09:09:20 +0100 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts) In-Reply-To: References: Message-ID: Agreed, it'd be the right time if we wanted to change this. I vote for 1 in case we do it. In ORM it's enough for many use cases to just add that core module, hence I like the more concise "hibernate-orm" id (similar to "hibernate-validator"). It's a bit different for OGM and HSEARCH where one needs core and typically another module with the NoSQL/indexing backend (hence I like "hibernate-ogm-core" there). 2017-01-30 17:31 GMT+01:00 Steve Ebersole : > Relatedly, I have been thinking whether we want to rename the ORM artifacts > as well since this is the best time if we wanted to do that. > > So we know we will change the groupId to `org.hibernate.orm`. > > I was thinking we might want to also either: > > 1. rename `hibernate-core` as `hibernate-orm` > 2. rename all the artifacts following the pattern `hibernate-orm-${1}`, > e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. > > > On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole wrote: > >> Well let's investigate what this consistency means across projects first. >> As Sanne mentions, if it makes it building ORM more difficult then I'd be >> -1 it too. But I promise to take a peek when I get back from PTO in a few >> days. Or maybe Andrea can in the next few days as he already has worked on >> the changes to release relocation artifacts for ORM; I just do not know >> when he is coming back from PTO. Either way we will have looked at it for >> ORM by the end of week. >> >> On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet >> wrote: >> >> On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero >> wrote: >> >> > Different projects have different needs. Consistency is nice, and >> > certainly makes it easier to find oneself comfortably "at home" when >> > jumping from one project to another, but it also is inconvenient to do >> > things "for consistency" when one has different requirements. >> > >> >> I don't think we would have different requirements regarding the relocation >> artifacts. >> >> But if you see any issue with the approach we chose for HV, interesting in >> hearing them so that we can have the same approach for the different NoORM >> project. >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From andrea at hibernate.org Tue Jan 31 04:57:00 2017 From: andrea at hibernate.org (andrea boriero) Date: Tue, 31 Jan 2017 09:57:00 +0000 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts) In-Reply-To: References: Message-ID: after thinking a bit on +1 for Steve proposal On 31 January 2017 at 08:09, Gunnar Morling wrote: > Agreed, it'd be the right time if we wanted to change this. > > I vote for 1 in case we do it. > > In ORM it's enough for many use cases to just add that core module, > hence I like the more concise "hibernate-orm" id (similar to > "hibernate-validator"). It's a bit different for OGM and HSEARCH where > one needs core and typically another module with the NoSQL/indexing > backend (hence I like "hibernate-ogm-core" there). > > > > 2017-01-30 17:31 GMT+01:00 Steve Ebersole : > > Relatedly, I have been thinking whether we want to rename the ORM > artifacts > > as well since this is the best time if we wanted to do that. > > > > So we know we will change the groupId to `org.hibernate.orm`. > > > > I was thinking we might want to also either: > > > > 1. rename `hibernate-core` as `hibernate-orm` > > 2. rename all the artifacts following the pattern > `hibernate-orm-${1}`, > > e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. > > > > > > On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole > wrote: > > > >> Well let's investigate what this consistency means across projects > first. > >> As Sanne mentions, if it makes it building ORM more difficult then I'd > be > >> -1 it too. But I promise to take a peek when I get back from PTO in a > few > >> days. Or maybe Andrea can in the next few days as he already has > worked on > >> the changes to release relocation artifacts for ORM; I just do not know > >> when he is coming back from PTO. Either way we will have looked at it > for > >> ORM by the end of week. > >> > >> On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet < > guillaume.smet at gmail.com> > >> wrote: > >> > >> On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero > >> wrote: > >> > >> > Different projects have different needs. Consistency is nice, and > >> > certainly makes it easier to find oneself comfortably "at home" when > >> > jumping from one project to another, but it also is inconvenient to do > >> > things "for consistency" when one has different requirements. > >> > > >> > >> I don't think we would have different requirements regarding the > relocation > >> artifacts. > >> > >> But if you see any issue with the approach we chose for HV, interesting > in > >> hearing them so that we can have the same approach for the different > NoORM > >> project. > >> > >> -- > >> Guillaume > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Tue Jan 31 05:34:52 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 31 Jan 2017 11:34:52 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: Message-ID: Hi, Some thoughts: == Group Id == Should be something like "org.hibernate.common" as per our discussions from last week. == Repo organization == I would prefer to have the AsciiDoc style, shared testing utilities and other utilities in separate repos, not a shared one. To me, a repo represents a coherent unit of "things" with its own lifecycle. Updates to the style should not mandate an update of the version of the testing and other utilities, so they should be in their own repo. This should also make it easier in terms of licenses (no need for relicensing). == Unified Appearance == Now that's one field where we really should strive for consistency: the different projects of the Hibernate umbrella should have one shared doc style for the sake of unified and professional experience. That's much more important than aligning on build profile names and the like. I don't have a strong opinion on which style it should be; the only thing I really dislike about the current ORM one is that there is no TOC on the side as we have it for HV. That makes it very impractical to navigate. --Gunnar 2017-01-30 20:57 GMT+01:00 Guillaume Smet : > On Mon, Jan 30, 2017 at 5:36 PM, Steve Ebersole wrote: > >> Disclaimer : I have not yet looked at the Asciidoc style. Again I promise >> to look at it when I come back from PTO. That said I want to make certain >> that the developed style matches the new ORM documentation style. The >> design team at Red Hat spent a lot of time helping us develop that. >> Specifically I mean the banners and general color scheme >> > > So that you don't waste your time looking for the differences: they are not > similar. > > There were a lot of things disturbing me in the current ORM theme (the > black banner too aggressive, the lots of fonts loaded, the old icons for > warning/note, some overriding that I don't find strictly necessary and > don't think are worth maintaining...). The one I put there is simpler and > doesn't override that many things (apart from adding the logo with the > banner). > > That being said, it's possible to use part of what I pushed and have > specific parts for what you want to keep. It was designed that way. > Typically, I think you might be interested by the PDF theme anyway. > > If others think the ORM theme should be the one we enforce, I'll push it > but I won't maintain the theme if it breaks in the future (and I'm really > not convinced by the output). > > All in all, not a subject to work on while you're on PTO :). > > -- > Guillaume > _______________________________________________ > 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 Jan 31 05:49:57 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 31 Jan 2017 12:49:57 +0200 Subject: [hibernate-dev] When is Dialect.requiresCastingOfParametersInSelectClause applied? In-Reply-To: References: Message-ID: Hi, If there is just one test case that doesn't work for a specific Dialect because the Dialect does not support such feature, you can just skip it for that Dialect either directly or through a DialectChecks. One example: when a test uses sequences, you need to use a DialectCheck because otherwise it will fail on MySQL. Vlad On Mon, Jan 30, 2017 at 7:00 PM, Mark Rotteveel wrote: > After a hiatus of 6 months, I have gone back to my PR for > improving/replacing the Firebird dialect. I am running into a number of > test failures which I am working through to see if they are relevant or > not. > > One of the test failures I am looking at is > org.hibernate.jpa.test.criteria.basic.ConcatTest.testSelectCaseWithConcat > > Firebird is rather picky about parameters occurring in the > select-clause, and they will almost always need to be cast to the > necessary type (and lengths). This tests seems to generate the following > query: > > select > case > when concattest0_.id is not null then (?||?) > else 'Empty' > end as col_0_0_, > trim(both ' ' > from > (?||?)) as col_1_0_ > from > TEST_ENTITY concattest0_ > > I have implemented Dialect#requiresCastingOfParametersInSelectClause() > to return true, but unfortunately for this specific test it has no effect. > > The absolute minimum SQL necessary for this to work (with some caveats) is: > > select > case > when 1 = 1 then (?||?) > else 'Empty' > end as col_0_0_, > trim(both ' ' > from > (cast(? as varchar(256))|| cast(? as varchar(256)))) as col_1_0_ > from > TEST_ENTITY concattest0_ > > And preferably the (?||?) in the case should have an explicit cast for > each parameter as well, as otherwise each parameter is limited to 5 > characters each (setting longer values will lead to a truncation > exception). > > Is this something that is fixable, and if so how? Or is this one of > those things where you just have to say 'aw, too bad, let it go' (or, > maybe: do it later if it is really necessary)? > > With this specific failure out of the way: what is the general rule of > thumb of handling test failures in hibernate_core for a lesser-known > dialect? > > I currently have 257 test failures (and 512 ignored) with Firebird and > my new dialect. I might add that some failures seem to be generic (eg > DriverManagerRegistrationTest, StandardRefCursorSupportTest, > NoCdiAvailableTest, XmlAccessTest, FetchProfileTest, IndexTest and some > others). > -- > Mark Rotteveel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Tue Jan 31 06:27:13 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 31 Jan 2017 12:27:13 +0100 Subject: [hibernate-dev] Hibernate Commons project In-Reply-To: References: Message-ID: On Tue, Jan 31, 2017 at 11:34 AM, Gunnar Morling wrote: > == Repo organization == > > I would prefer to have the AsciiDoc style, shared testing utilities > and other utilities in separate repos, not a shared one. To me, a repo > represents a coherent unit of "things" with its own lifecycle. Updates > to the style should not mandate an update of the version of the > testing and other utilities, so they should be in their own repo. This > should also make it easier in terms of licenses (no need for > relicensing). > Yeah, that was my first intention but I got outnumbered and to be honest I don't really care as long as they are purely internal projects. I'll let Yoann and Sanne explain their point of view as they will do that better than me (IIRC, it was mostly about the maintenance cost but I'm not sure it makes a difference if the lifecycles are completely different). Anyway, it does not solve the license issue. As per our discussion last week, if we have some general utilities to share between the NoORM projects for instance, we would probably like to copy the sources of the utilities to avoid conflicting dependencies when depending on 2 of the projects (probably using https://maven.apache.org/plugins/maven-dependency-plugin/examples/using-dependencies-sources.html). In this case, I think we would need to dual license (ASL 2 + LGPL) the utilities as the sources will be distributed with the rest of the projects. So, if I try to sum it up: == GroupId == 2 proposals: - org.hibernate.common (the same as hibernate-commons-annotations) - org.hibernate.internal (let's drop my initial org.hibernate.commons proposal, it's too confusing with org.hibernate.common) == The license == The license: probably better to dual license everything under the ASL2 and the LGPL - especially if we start to share utilities. Will check with Emmanuel when he's back. == The AsciiDoctor theme == We mostly agree that it's probably better to converge on a similar layout. Steve seems to be strongly attached to the Hibernate theme. I personally don't like it and think it would be more painful to maintain in the long term as it overrides more things. Sanne was also more convinced by the white banner. If I sum up the differences between the 2 themes ( http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html vs http://docs.jboss.org/hibernate/beta/html_single/): - black banner vs white banner - original Docbook icons vs font based icons (Font Awesome) - dark blue titles vs standard red ones - admonitions are totally different (compare http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#naming and the end of this paragraph http://docs.jboss.org/hibernate/beta/html_single/#search-batchindexing-threadsandconnections ) - a lots of fonts loaded in the ORM doc but I must admit that I think most are useless: http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibernate-fonts.css so we could probably clean this up - more overrides (compare http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibernate-layout.css vs http://docs.jboss.org/hibernate/beta/html_single/css/hibernate.css) so more maintenance if the HTML output of AsciiDoctor is changed - note that I'm new to AsciiDoctor so I don't know how stable the HTML output is The ORM output might have been better than the default AsciiDoctor output at the time it was made, but as of now I really think the current AsciiDoctor output is more pleasant to read and more modern. And we would benefit from future improvements for free. -- Guillaume From mark at lawinegevaar.nl Tue Jan 31 11:15:40 2017 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Tue, 31 Jan 2017 17:15:40 +0100 Subject: [hibernate-dev] When is Dialect.requiresCastingOfParametersInSelectClause applied? In-Reply-To: References: Message-ID: <4a747e3b-d7fe-d2a3-0595-d03138425a96@lawinegevaar.nl> On 31-1-2017 11:49, Vlad Mihalcea wrote: > Hi, > > If there is just one test case that doesn't work for a specific Dialect > because the Dialect does not support such feature, > you can just skip it for that Dialect either directly or through a > DialectChecks. > > One example: when a test uses sequences, you need to use a DialectCheck > because otherwise it will fail on MySQL. Thanks, I will work through the failures one by one then and see if they can work for Firebird or not. Mark -- Mark Rotteveel From sanne at hibernate.org Tue Jan 31 13:22:41 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 31 Jan 2017 18:22:41 +0000 Subject: [hibernate-dev] [HSEARCH] heads up git users! In-Reply-To: References: Message-ID: The rename was applied now. "master" is now referring to the branch which was previously called "5.7". The maintenance branch for 5.6.x is now named "5.6". I will not delete the branch "5.7" branch, for convenience of the open pull requests and any work in progress you might have. Let's make sure any such change is merged to master first though, then "backported" as usual.. eventually when we release it 5.7 will just be the maintenance branch of 5.7. Thanks, Sanne On 23 January 2017 at 11:39, Sanne Grinovero wrote: > Hi all, > > I'm soon going to rename branches on the reference repository > [https://github.com/hibernate/hibernate-search] > > "master" branch is going to be renamed "5.6" > > "5.7" branch is going to be renamed "master" > > If you keep this in mind, you should be able to avoid any trouble: > rebase as usual before sending PRs, just make sure you updated your > local references to match the reference and then use the new names > during the rebase. > If you get in trouble.. I'm open to help out. > > Reminder: with git what matters is the commit signature: "renaming" > just means we're moving the labels from one branch to the other; the > branch itself is not being affected. > > Thanks, > Sanne From andrea at hibernate.org Tue Jan 31 15:34:00 2017 From: andrea at hibernate.org (andrea boriero) Date: Tue, 31 Jan 2017 20:34:00 +0000 Subject: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts) In-Reply-To: References: Message-ID: rebased my old PR and it stops working, the "publishing is not yet able to resolve a dependency on a project with multiple different publications" exception is back :( I'm investigating to understand what change reintroduced this issue. On 31 January 2017 at 09:57, andrea boriero wrote: > after thinking a bit on +1 for Steve proposal > > On 31 January 2017 at 08:09, Gunnar Morling wrote: > >> Agreed, it'd be the right time if we wanted to change this. >> >> I vote for 1 in case we do it. >> >> In ORM it's enough for many use cases to just add that core module, >> hence I like the more concise "hibernate-orm" id (similar to >> "hibernate-validator"). It's a bit different for OGM and HSEARCH where >> one needs core and typically another module with the NoSQL/indexing >> backend (hence I like "hibernate-ogm-core" there). >> >> >> >> 2017-01-30 17:31 GMT+01:00 Steve Ebersole : >> > Relatedly, I have been thinking whether we want to rename the ORM >> artifacts >> > as well since this is the best time if we wanted to do that. >> > >> > So we know we will change the groupId to `org.hibernate.orm`. >> > >> > I was thinking we might want to also either: >> > >> > 1. rename `hibernate-core` as `hibernate-orm` >> > 2. rename all the artifacts following the pattern >> `hibernate-orm-${1}`, >> > e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. >> > >> > >> > On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole >> wrote: >> > >> >> Well let's investigate what this consistency means across projects >> first. >> >> As Sanne mentions, if it makes it building ORM more difficult then I'd >> be >> >> -1 it too. But I promise to take a peek when I get back from PTO in a >> few >> >> days. Or maybe Andrea can in the next few days as he already has >> worked on >> >> the changes to release relocation artifacts for ORM; I just do not know >> >> when he is coming back from PTO. Either way we will have looked at it >> for >> >> ORM by the end of week. >> >> >> >> On Mon, Jan 30, 2017 at 7:11 AM Guillaume Smet < >> guillaume.smet at gmail.com> >> >> wrote: >> >> >> >> On Mon, Jan 30, 2017 at 2:01 PM, Sanne Grinovero >> >> wrote: >> >> >> >> > Different projects have different needs. Consistency is nice, and >> >> > certainly makes it easier to find oneself comfortably "at home" when >> >> > jumping from one project to another, but it also is inconvenient to >> do >> >> > things "for consistency" when one has different requirements. >> >> > >> >> >> >> I don't think we would have different requirements regarding the >> relocation >> >> artifacts. >> >> >> >> But if you see any issue with the approach we chose for HV, >> interesting in >> >> hearing them so that we can have the same approach for the different >> NoORM >> >> project. >> >> >> >> -- >> >> Guillaume >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >