From sanne at hibernate.org Mon Jun 3 07:34:36 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 3 Jun 2019 12:34:36 +0100 Subject: [hibernate-dev] Doing some maintenance on ci.hibernate.org Message-ID: Hey all, today I'll be restarting the server running ci.hibernate.org, and installing some updates. You can login as usual, but it might ask your permission again to allow github to share your profile with the ci server. I will need to repeat such operation multiple times this week, please be patient. Thanks, Sanne From guillaume.smet at gmail.com Tue Jun 4 11:12:01 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 4 Jun 2019 17:12:01 +0200 Subject: [hibernate-dev] Hibernate NoORM meeting minutes Message-ID: Hi, As usual, here are the minutes of this week's NoORM meeting. Once again carefully crafted by hand. 15:01 < gsmet> #topic Progress Fabio 15:01 < fax4ever> First of all, we merged the contribution to support 15:02 < fax4ever> @DecimalScale within BigDecimal and BigInteger field types. 15:03 -!- rvansa [rvansa at nat/redhat/x-xhodhuijvfvkddtt] has joined #hibernate-dev 15:03 < fax4ever> Most of the effort of the last two weeks were about adding field type options, 15:03 < fax4ever> that are present on Hibernate Search 5, 15:03 < fax4ever> but that weren't present on Hibernate Search 6. 15:03 < fax4ever> Now we supports the options: 15:03 < fax4ever> 1. norms 15:03 < fax4ever> 2. searchable 15:04 < fax4ever> 3. termVector 15:04 < fax4ever> I think that was a significant milestone to release a beta. 15:04 < fax4ever> The rest of time... 15:04 < fax4ever> On one hand, I reviewed some pull requests. 15:04 < fax4ever> On the other hand, I completed all the issues 15:04 < fax4ever> that were supposed to be done in the current sprint. 15:04 < fax4ever> Actually, it has been the first time I do it. :/ 15:05 < fax4ever> They were about: 15:05 < fax4ever> 1. Handle .onMissingValue().use() properly for date fields in Elasticsearch 15:05 < fax4ever> 2. Return a CompletableFuture instead of a Future from MassIndexer.start(). 15:05 < fax4ever> 3. Add a test for indexEmbedded depth parameter shared across class. 15:05 < fax4ever> (for Search 6 and 5) 15:05 < fax4ever> 4. Support correctly `.withPrefixLength` in Elasticsearch. 15:05 < fax4ever> (Search 5) 15:06 < fax4ever> That has been the first time that I contributed to Search 5 too. 15:06 < fax4ever> Next two weeks, please. 15:06 < gsmet> #topic Next 2 weeks Fabio 15:06 < fax4ever> Thanks 15:06 < fax4ever> I started today a new issue to allow to provide a missing value 15:06 < fax4ever> replacement for sorting, 15:06 < fax4ever> even if the field has a String type and the backend is Lucene. 15:07 < fax4ever> That's not supported by Lucene, you know. 15:07 < fax4ever> But Elasticsearch does it. 15:07 < fax4ever> So I've studied the code of Elasticsearch 15:07 < fax4ever> and now I'm trying to do something `similar` for the issue. 15:07 < fax4ever> About the rest, as usual a new sprint has been created, 15:07 < fax4ever> so you can see the forecast of the next two weeks on Jira. 15:07 < fax4ever> See `HSEARCH - 2019-10`. 15:08 < fax4ever> That's all from me. Thanks for your attention. 15:08 < gsmet> thanks! 15:08 < gsmet> #topic Progress Guillaume 15:08 < gsmet> so I haven't done much on the Hibernate front 15:08 < gsmet> I released ORM 5.4.3.Final 15:09 < gsmet> not totally Hibernate related but still, I wrote a guide + a quickstart for using Hibernate Search on Quarkus 15:09 < gsmet> it was long overdue but Search is now a first class citizen in the Quarkus world 15:09 < gsmet> now, we just need a Final, guys :) 15:10 < gsmet> I also spent some time on HV, merging a few things in and preparing new releases 15:10 < yrodiere> when it's ready ;) 15:10 < gsmet> #topic Next 2 weeks Guillaume 15:10 < gsmet> so I need to fix an issue with HV + Quarkus then release new versions of HV 15:11 < gsmet> that's my number one priority for now 15:11 < gsmet> I have to prepare for a couple of talks so I will probably code less than usual 15:12 < gsmet> please ping me when you release new Search version so that I can upgrade the one used by Quarkus 15:12 < yrodiere> ok I'll try to remember 15:12 < gsmet> that's pretty much it for me 15:12 < yrodiere> worst case you'll get an email on hibernate-dev :) 15:12 < gsmet> usually, you ping me to review the blog post :) 15:12 < yrodiere> right :) 15:12 < gsmet> #topic Progress Koen 15:13 < koentsje> i have finished the integration of quarkus 0.15.0 in the eclipse tools 15:13 -!- sfikes [~sfikes at c-69-246-28-50.hsd1.ms.comcast.net] has joined #hibernate-dev 15:13 < koentsje> i worked on an implementation for a quarkus run/debug configuration for running quarkus inside eclipse 15:14 < gsmet> good thing I released 0.16.0 yesterday then :] 15:14 < koentsje> this is not working yet, so i need to continue to work on this 15:14 < koentsje> @gsmet, yes this is for next sprint ;) 15:15 < koentsje> i had to do some maintenance on the hibernate tooling 15:15 < koentsje> i released hibernate tools 5.4.3.Final in lockstep with orm 5.4.3.Final 15:15 < koentsje> did the integration of 5.4.3.Final in JBoss tools 15:16 < koentsje> and this is about it so i miserably failed to work on the continuous integration 15:16 < gsmet> #topic Next 2 weeks Koen 15:17 < koentsje> integration of the 0.16.0 release in quarkus eclipse tools 15:17 < koentsje> look at some bug reports for hibernate tools that came in recently 15:18 < koentsje> continue the quarkus run/debug configuration 15:18 < koentsje> elaborate on the reddeer automatic integration tests 15:19 < koentsje> and finally, the continuous integration of the quarkus eclipse tooling 15:19 < koentsje> thanks 15:19 < gsmet> thanks! 15:19 < gsmet> #topic Progress Yoann 15:20 < yrodiere> First, I worked on making Search work properly in Quarkus 15:20 < yrodiere> I had to make Hibernate Search 6 work with ORM bytecode enhancement enabled, 15:20 < yrodiere> since Quarkus enables that by default 15:20 < yrodiere> It looks like it works now... I don't know how well, but at least it's better than it used to be :) 15:20 < yrodiere> Guillaume reported a few issues with Search in Eclipse, so I had to fix the code so that ECJ (the Eclipse compiler) was happy 15:20 < yrodiere> I also added a step to our Jenkins CI job to build with ECJ in headless mode 15:20 < yrodiere> so that next time we don't have to wait for Guillaume to know something is wrong :) 15:21 < yrodiere> And since *someone* insisted, I also reported several ECJ bugs. 15:21 < yrodiere> Not sure they will fix them anytime soon, but I guess it was worth a shot. 15:21 < gsmet> I'm becoming more useless every day :/ 15:21 < yrodiere> And yeah, it's in our best interest, I know :) 15:21 < fax4ever> :) 15:21 < yrodiere> After that, we released Search 6.0.0.Alpha6, which is the version used in Quarkus at the moment 15:22 < yrodiere> (yay!) 15:22 < yrodiere> Next, I tried to make Hibernate Search work in JDK11 in the modulepath 15:22 < yrodiere> Turns out it didn't work because of a classloading issue that is present both in ORM and in Search 15:22 < yrodiere> I submitted a PR to fix that in ORM as a first step, it's pending review 15:22 < yrodiere> I have everything ready to make Search work in the modulepath, but I need this ORM fix to be merged and released firsst 15:22 < yrodiere> well, except the lucene backend of course 15:23 < yrodiere> Lucene is lightyears away from working in the modulepath 15:23 < yrodiere> While I was on ORM, I also submitted a PR to add support for JPA criteria on stateless sessions 15:23 < yrodiere> which will be necessary sooner or later, since we use Hibernate criteria in Search on stateless sessions, 15:23 < yrodiere> and Hibernate Criteria will be removed in ORM 6 in favor of JPA criteria 15:23 < yrodiere> I also upgraded Search to Hibernate ORM 5.4.3.Final 15:23 < yrodiere> There was an incompatibility, which was easily worked around but still annoying 15:23 < yrodiere> So I set up CI jobs that build search against the latest ORM snapshot every day. 15:23 < yrodiere> Next time I may be able to catch the problem sooner. 15:24 < yrodiere> I also upgraded Search to Elasticsearch 7.1. 15:24 < yrodiere> Everything went just fine, for once. 15:24 < yrodiere> Apart from that, I worked on a few clean-up PRs 15:24 < yrodiere> And most importantly, on exposing index write APIs in the Hibernate Search ORM integration 15:24 < yrodiere> It's almost done, I'm writing the documentation and will submit a PR soon 15:24 < yrodiere> Next two weeks... 15:24 < gsmet> #topic Next 2 weeks Yoann 15:24 < yrodiere> After I'm finished with the write APIs, I intend to submit a fix for a problem we noticed with Fabio in Elasticsearch 15:25 < yrodiere> Essentially they store some numbers with 64-bit precision, but they parse them as a double (~53-bit precision) when we send values through the rest API 15:25 < yrodiere> That's a problem for our support for indexing BigDecimal, in particular. 15:25 < yrodiere> because what good is a BigDecimal if you only get the precision of a double? 15:25 < fax4ever> good question 15:26 < yrodiere> Then I intend to write a bit of documentation 15:26 < yrodiere> Most likely referencing the various predicates, sorts and projections 15:26 < gsmet> \o/ 15:26 < yrodiere> that'll be fascinating, I'm sure :) 15:26 < yrodiere> And when I'm done I'll try to fix some of the remaining problems of the ORM mapper 15:26 < yrodiere> such as support for document IDs that are not the entity ID 15:26 < yrodiere> or initialization of lazy collection/map/array properties when indexing (if necessary) 15:26 < yrodiere> That's all from me! 15:27 < gsmet> ok, thanks 15:27 < gsmet> #topic Other topics 15:27 < gsmet> Monday is a holiday in France 15:28 < koentsje> also in belgium \o/ 15:29 < fax4ever> not in Italy :) From rory.odonnell at oracle.com Sun Jun 16 01:50:46 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Sun, 16 Jun 2019 11:20:46 +0530 Subject: [hibernate-dev] JDK 13 enters Rampdown Phase One Message-ID: Hi Sanne, *JDK 13 Early Access build **25 is now available **at : - jdk.java.net/13/* * Per the JDK 13 schedule [1], we are now in Rampdown Phase One. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. * Changes in this build 25 [4] *Request for feedback on JEP 353 integrated in b24 * JEP 353: Reimplement the Legacy Socket API" has been integrated into jdk-13+24. It would be very useful if applications or libraries using java.net.Socket or java.net.ServerSocket APIs could test with this build and report any issues found. The JEP provides information on the system property that can be used to switch back to the old implementation and that may be useful to check for behavior differences between the old and new implementation. It would be very useful to get feedback via the OpenJDK net-dev mailing list, bugs via the usual channel. *Updates to Release Notes since last email* * b25 - Support Kerberos cross-realm referrals (RFC 6806)(JDK-8215032 ) * b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145 ) * b24 - Reimplement the Legacy Socket API(JDK-8221481 ) o see above request for feedback * b24? - Deprecated rmic tool For Removal(JDK-8217412 ) * b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767 ) * b23 - Support for Unicode 12.1 (JDK-8221431 ) * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432 ) *OpenJDK 14 **Early Access build 1 **is now available **at : - jdk.java.net/14/* * These early-access, open-source builds are provided under the GNU General Public License, version?2, with the Classpath Exception . * Changes in this build [5] ** Rgds, Rory [1] http://openjdk.java.net/projects/jdk/13/#Schedule [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html [3] http://jdk.java.net/13/release-notes [4] JDK 13 - Changes in b25 here [5] JDK 14 - Changes in b1 here -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland From mark at lawinegevaar.nl Sun Jun 16 10:28:01 2019 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sun, 16 Jun 2019 16:28:01 +0200 Subject: [hibernate-dev] Which branch to target? Message-ID: <94a74235-d53a-a1fd-f017-37b2d75677d8@lawinegevaar.nl> After a significant hiatus, I have restarted my work on adding improved support for Firebird 2.5 and 3.0 (and more importantly struggling through some test failures). I am wondering what I should target for my changes: the current master branch or the upstream/wip/6.0 branch. What would be the preferred or 'better' option? Mark -- Mark Rotteveel From yoann at hibernate.org Mon Jun 17 03:06:18 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 17 Jun 2019 09:06:18 +0200 Subject: [hibernate-dev] JDK 13 enters Rampdown Phase One In-Reply-To: References: Message-ID: Hello team, Following the notification above, I updated CI to use the latest JDK13. I also configured JDK14 so you can use in your builds. It's named, unsurprisingly, "OpenJDK 14 Latest". Please set up Jenkins jobs as appropriate for your projects. Please be aware that JDK14 will be an LTS release, and as such will be a very good target to focus on to solve compatibility problems that haven't been solved in JDK12/JDK13. Just a reminder that ORM bytecode enhancement doesn't work with JDK13 and we need some component updates on that front before we can fix it. I expect we'll need those updates for JDK14 too. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Sun, 16 Jun 2019 at 07:51, Rory O'Donnell wrote: > Hi Sanne, > > *JDK 13 Early Access build **25 is now available **at : - > jdk.java.net/13/* > > * Per the JDK 13 schedule [1], we are now in Rampdown Phase One. > o For more details , see Mark Reinhold's email to jdk-dev mailing > list [2] > o The overall feature set is frozen, no further JEPs will be > targeted to this release. > * Changes in this build 25 [4] > > *Request for feedback on JEP 353 integrated in b24 > * > > JEP 353: Reimplement the Legacy Socket API" has been integrated into > jdk-13+24. It would be very useful if applications or libraries using > java.net.Socket or java.net.ServerSocket APIs could test with this build > and report any issues found. The JEP provides information on the system > property that can be used to switch back to the old implementation and > that may be useful to check for behavior differences between the old and > new implementation. It would be very useful to get feedback via the > OpenJDK net-dev mailing list, bugs via the usual channel. > > *Updates to Release Notes since last email* > > * b25 - Support Kerberos cross-realm referrals (RFC 6806)(JDK-8215032 > ) > * b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145 > ) > * b24 - Reimplement the Legacy Socket API(JDK-8221481 > ) > o see above request for feedback > * b24 - Deprecated rmic tool For Removal(JDK-8217412 > ) > * b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767 > ) > * b23 - Support for Unicode 12.1 (JDK-8221431 > ) > * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432 > ) > > *OpenJDK 14 **Early Access build 1 **is now available **at : - > jdk.java.net/14/* > > * These early-access, open-source builds are provided under the GNU > General Public License, version 2, with the Classpath Exception > . > * Changes in this build [5] > > ** > > Rgds, Rory > > [1] http://openjdk.java.net/projects/jdk/13/#Schedule > > [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html > [3] http://jdk.java.net/13/release-notes > [4] JDK 13 - Changes in b25 here > < > http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B24%22%3A%3A%22jdk-13%2B25%22-%22jdk-13%2B24%22%29&revcount=1000 > > > [5] JDK 14 - Changes in b1 here > < > http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B0%22%3A%3A%22jdk-14%2B1%22-%22jdk-14%2B0%22%29&revcount=1000 > > > > -- > 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 sanne at hibernate.org Mon Jun 17 04:43:44 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 17 Jun 2019 09:43:44 +0100 Subject: [hibernate-dev] JDK 13 enters Rampdown Phase One In-Reply-To: References: Message-ID: On Mon, 17 Jun 2019 at 08:17, Yoann Rodiere wrote: > > Hello team, > > Following the notification above, I updated CI to use the latest JDK13. > > I also configured JDK14 so you can use in your builds. It's named, > unsurprisingly, "OpenJDK 14 Latest". Please set up Jenkins jobs as > appropriate for your projects. > > Please be aware that JDK14 will be an LTS release, and as such will be a > very good target to focus on to solve compatibility problems that haven't > been solved in JDK12/JDK13. > > Just a reminder that ORM bytecode enhancement doesn't work with JDK13 and > we need some component updates on that front before we can fix it. > I expect we'll need those updates for JDK14 too. I thought that the next LTS was going to be JDK 17. Did the plans change? Thanks, Sanne > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Sun, 16 Jun 2019 at 07:51, Rory O'Donnell > wrote: > > > Hi Sanne, > > > > *JDK 13 Early Access build **25 is now available **at : - > > jdk.java.net/13/* > > > > * Per the JDK 13 schedule [1], we are now in Rampdown Phase One. > > o For more details , see Mark Reinhold's email to jdk-dev mailing > > list [2] > > o The overall feature set is frozen, no further JEPs will be > > targeted to this release. > > * Changes in this build 25 [4] > > > > *Request for feedback on JEP 353 integrated in b24 > > * > > > > JEP 353: Reimplement the Legacy Socket API" has been integrated into > > jdk-13+24. It would be very useful if applications or libraries using > > java.net.Socket or java.net.ServerSocket APIs could test with this build > > and report any issues found. The JEP provides information on the system > > property that can be used to switch back to the old implementation and > > that may be useful to check for behavior differences between the old and > > new implementation. It would be very useful to get feedback via the > > OpenJDK net-dev mailing list, bugs via the usual channel. > > > > *Updates to Release Notes since last email* > > > > * b25 - Support Kerberos cross-realm referrals (RFC 6806)(JDK-8215032 > > ) > > * b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145 > > ) > > * b24 - Reimplement the Legacy Socket API(JDK-8221481 > > ) > > o see above request for feedback > > * b24 - Deprecated rmic tool For Removal(JDK-8217412 > > ) > > * b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767 > > ) > > * b23 - Support for Unicode 12.1 (JDK-8221431 > > ) > > * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432 > > ) > > > > *OpenJDK 14 **Early Access build 1 **is now available **at : - > > jdk.java.net/14/* > > > > * These early-access, open-source builds are provided under the GNU > > General Public License, version 2, with the Classpath Exception > > . > > * Changes in this build [5] > > > > ** > > > > Rgds, Rory > > > > [1] http://openjdk.java.net/projects/jdk/13/#Schedule > > > > [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html > > [3] http://jdk.java.net/13/release-notes > > [4] JDK 13 - Changes in b25 here > > < > > http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B24%22%3A%3A%22jdk-13%2B25%22-%22jdk-13%2B24%22%29&revcount=1000 > > > > > [5] JDK 14 - Changes in b1 here > > < > > http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B0%22%3A%3A%22jdk-14%2B1%22-%22jdk-14%2B0%22%29&revcount=1000 > > > > > > > -- > > 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 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Mon Jun 17 04:57:06 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 17 Jun 2019 10:57:06 +0200 Subject: [hibernate-dev] JDK 13 enters Rampdown Phase One In-Reply-To: References: Message-ID: > I thought that the next LTS was going to be JDK 17. Did the plans change? It could be both actually. LTS is not a notion of OpenJDK itself; instead, individual build providers can support LTS for any release they want. The three years cadence (i.e. 11, 17 etc.) is what Oracle indicated they'd plan for their build and its seems other build providers will stick to that rhythm. But it doesn't mean that nobody could offer an LTS release based on OpenJDK 14. Also what exactly "LTS" means (time of support etc.) may differ between build providers. --Gunnar Am Mo., 17. Juni 2019 um 10:44 Uhr schrieb Sanne Grinovero < sanne at hibernate.org>: > On Mon, 17 Jun 2019 at 08:17, Yoann Rodiere wrote: > > > > Hello team, > > > > Following the notification above, I updated CI to use the latest JDK13. > > > > I also configured JDK14 so you can use in your builds. It's named, > > unsurprisingly, "OpenJDK 14 Latest". Please set up Jenkins jobs as > > appropriate for your projects. > > > > Please be aware that JDK14 will be an LTS release, and as such will be a > > very good target to focus on to solve compatibility problems that haven't > > been solved in JDK12/JDK13. > > > > Just a reminder that ORM bytecode enhancement doesn't work with JDK13 and > > we need some component updates on that front before we can fix it. > > I expect we'll need those updates for JDK14 too. > > I thought that the next LTS was going to be JDK 17. Did the plans change? > > Thanks, > Sanne > > > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > > > > > On Sun, 16 Jun 2019 at 07:51, Rory O'Donnell > > wrote: > > > > > Hi Sanne, > > > > > > *JDK 13 Early Access build **25 is now available **at : - > > > jdk.java.net/13/* > > > > > > * Per the JDK 13 schedule [1], we are now in Rampdown Phase One. > > > o For more details , see Mark Reinhold's email to jdk-dev mailing > > > list [2] > > > o The overall feature set is frozen, no further JEPs will be > > > targeted to this release. > > > * Changes in this build 25 [4] > > > > > > *Request for feedback on JEP 353 integrated in b24 > > > * > > > > > > JEP 353: Reimplement the Legacy Socket API" has been integrated into > > > jdk-13+24. It would be very useful if applications or libraries using > > > java.net.Socket or java.net.ServerSocket APIs could test with this > build > > > and report any issues found. The JEP provides information on the system > > > property that can be used to switch back to the old implementation and > > > that may be useful to check for behavior differences between the old > and > > > new implementation. It would be very useful to get feedback via the > > > OpenJDK net-dev mailing list, bugs via the usual channel. > > > > > > *Updates to Release Notes since last email* > > > > > > * b25 - Support Kerberos cross-realm referrals (RFC 6806)(JDK-8215032 > > > ) > > > * b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145 > > > ) > > > * b24 - Reimplement the Legacy Socket API(JDK-8221481 > > > ) > > > o see above request for feedback > > > * b24 - Deprecated rmic tool For Removal(JDK-8217412 > > > ) > > > * b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767 > > > ) > > > * b23 - Support for Unicode 12.1 (JDK-8221431 > > > ) > > > * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432 > > > ) > > > > > > *OpenJDK 14 **Early Access build 1 **is now available **at : - > > > jdk.java.net/14/* > > > > > > * These early-access, open-source builds are provided under the GNU > > > General Public License, version 2, with the Classpath Exception > > > . > > > * Changes in this build [5] > > > > > > ** > > > > > > Rgds, Rory > > > > > > [1] http://openjdk.java.net/projects/jdk/13/#Schedule > > > > > > [2] > https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html > > > [3] http://jdk.java.net/13/release-notes > > > [4] JDK 13 - Changes in b25 here > > > < > > > > http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B24%22%3A%3A%22jdk-13%2B25%22-%22jdk-13%2B24%22%29&revcount=1000 > > > > > > > [5] JDK 14 - Changes in b1 here > > > < > > > > http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B0%22%3A%3A%22jdk-14%2B1%22-%22jdk-14%2B0%22%29&revcount=1000 > > > > > > > > > > -- > > > 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 > > _______________________________________________ > > 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 Jun 17 05:06:51 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 17 Jun 2019 11:06:51 +0200 Subject: [hibernate-dev] JDK 13 enters Rampdown Phase One In-Reply-To: References: Message-ID: > I thought that the next LTS was going to be JDK 17. Did the plans change? No, you're probably right. It looks like my information was outdated. Sorry for the confusion. It wouldn't hurt to try and stay compatible, though... :) Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Mon, 17 Jun 2019 at 10:57, Gunnar Morling wrote: > > I thought that the next LTS was going to be JDK 17. Did the plans change? > > It could be both actually. > > LTS is not a notion of OpenJDK itself; instead, individual build providers > can support LTS for any release they want. The three years cadence (i.e. > 11, 17 etc.) is what Oracle indicated they'd plan for their build and its > seems other build providers will stick to that rhythm. But it doesn't mean > that nobody could offer an LTS release based on OpenJDK 14. Also what > exactly "LTS" means (time of support etc.) may differ between build > providers. > > --Gunnar > > > > Am Mo., 17. Juni 2019 um 10:44 Uhr schrieb Sanne Grinovero < > sanne at hibernate.org>: > >> On Mon, 17 Jun 2019 at 08:17, Yoann Rodiere wrote: >> > >> > Hello team, >> > >> > Following the notification above, I updated CI to use the latest JDK13. >> > >> > I also configured JDK14 so you can use in your builds. It's named, >> > unsurprisingly, "OpenJDK 14 Latest". Please set up Jenkins jobs as >> > appropriate for your projects. >> > >> > Please be aware that JDK14 will be an LTS release, and as such will be a >> > very good target to focus on to solve compatibility problems that >> haven't >> > been solved in JDK12/JDK13. >> > >> > Just a reminder that ORM bytecode enhancement doesn't work with JDK13 >> and >> > we need some component updates on that front before we can fix it. >> > I expect we'll need those updates for JDK14 too. >> >> I thought that the next LTS was going to be JDK 17. Did the plans change? >> >> Thanks, >> Sanne >> >> >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > >> > On Sun, 16 Jun 2019 at 07:51, Rory O'Donnell >> > wrote: >> > >> > > Hi Sanne, >> > > >> > > *JDK 13 Early Access build **25 is now available **at : - >> > > jdk.java.net/13/* >> > > >> > > * Per the JDK 13 schedule [1], we are now in Rampdown Phase One. >> > > o For more details , see Mark Reinhold's email to jdk-dev >> mailing >> > > list [2] >> > > o The overall feature set is frozen, no further JEPs will be >> > > targeted to this release. >> > > * Changes in this build 25 [4] >> > > >> > > *Request for feedback on JEP 353 integrated in b24 >> > > * >> > > >> > > JEP 353: Reimplement the Legacy Socket API" has been integrated into >> > > jdk-13+24. It would be very useful if applications or libraries using >> > > java.net.Socket or java.net.ServerSocket APIs could test with this >> build >> > > and report any issues found. The JEP provides information on the >> system >> > > property that can be used to switch back to the old implementation and >> > > that may be useful to check for behavior differences between the old >> and >> > > new implementation. It would be very useful to get feedback via the >> > > OpenJDK net-dev mailing list, bugs via the usual channel. >> > > >> > > *Updates to Release Notes since last email* >> > > >> > > * b25 - Support Kerberos cross-realm referrals (RFC >> 6806)(JDK-8215032 >> > > ) >> > > * b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145 >> > > ) >> > > * b24 - Reimplement the Legacy Socket API(JDK-8221481 >> > > ) >> > > o see above request for feedback >> > > * b24 - Deprecated rmic tool For Removal(JDK-8217412 >> > > ) >> > > * b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767 >> > > ) >> > > * b23 - Support for Unicode 12.1 (JDK-8221431 >> > > ) >> > > * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432 >> > > ) >> > > >> > > *OpenJDK 14 **Early Access build 1 **is now available **at : - >> > > jdk.java.net/14/* >> > > >> > > * These early-access, open-source builds are provided under the GNU >> > > General Public License, version 2, with the Classpath Exception >> > > . >> > > * Changes in this build [5] >> > > >> > > ** >> > > >> > > Rgds, Rory >> > > >> > > [1] http://openjdk.java.net/projects/jdk/13/#Schedule >> > > >> > > [2] >> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html >> > > [3] http://jdk.java.net/13/release-notes >> > > [4] JDK 13 - Changes in b25 here >> > > < >> > > >> http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B24%22%3A%3A%22jdk-13%2B25%22-%22jdk-13%2B24%22%29&revcount=1000 >> > > > >> > > [5] JDK 14 - Changes in b1 here >> > > < >> > > >> http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B0%22%3A%3A%22jdk-14%2B1%22-%22jdk-14%2B0%22%29&revcount=1000 >> > > > >> > > >> > > -- >> > > 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 >> > _______________________________________________ >> > 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 Jun 17 05:31:27 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 17 Jun 2019 10:31:27 +0100 Subject: [hibernate-dev] JDK 13 enters Rampdown Phase One In-Reply-To: References: Message-ID: On Mon, 17 Jun 2019, 09:57 Gunnar Morling, wrote: > > I thought that the next LTS was going to be JDK 17. Did the plans change? > > It could be both actually. > > LTS is not a notion of OpenJDK itself; instead, individual build providers > can support LTS for any release they want. The three years cadence (i.e. > 11, 17 etc.) is what Oracle indicated they'd plan for their build and its > seems other build providers will stick to that rhythm. But it doesn't mean > that nobody could offer an LTS release based on OpenJDK 14. Also what > exactly "LTS" means (time of support etc.) may differ between build > providers. > Fun fact: I originally wrote a similar blurb of explanation in my reply, then removed it opting for a simpler reply. Indeed some vendors might choose different support timelines, but nobody announced such a move ATM, I suppose divergence is possible but for a while it seems likely that the Oracle LTS cadence will be highly influential on version choice decisions. so what matters for us is that we need great quality with any JVM release as soon as they are released. LTS are of notable interest not because of us spending more QA love on them, but because they implicitly mark a time in which we can finally drop compatibility with older stuff, and benefit from cool new stuff. > --Gunnar > > > > Am Mo., 17. Juni 2019 um 10:44 Uhr schrieb Sanne Grinovero < > sanne at hibernate.org>: > >> On Mon, 17 Jun 2019 at 08:17, Yoann Rodiere wrote: >> > >> > Hello team, >> > >> > Following the notification above, I updated CI to use the latest JDK13. >> > >> > I also configured JDK14 so you can use in your builds. It's named, >> > unsurprisingly, "OpenJDK 14 Latest". Please set up Jenkins jobs as >> > appropriate for your projects. >> > >> > Please be aware that JDK14 will be an LTS release, and as such will be a >> > very good target to focus on to solve compatibility problems that >> haven't >> > been solved in JDK12/JDK13. >> > >> > Just a reminder that ORM bytecode enhancement doesn't work with JDK13 >> and >> > we need some component updates on that front before we can fix it. >> > I expect we'll need those updates for JDK14 too. >> >> I thought that the next LTS was going to be JDK 17. Did the plans change? >> >> Thanks, >> Sanne >> >> >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > >> > >> > On Sun, 16 Jun 2019 at 07:51, Rory O'Donnell >> > wrote: >> > >> > > Hi Sanne, >> > > >> > > *JDK 13 Early Access build **25 is now available **at : - >> > > jdk.java.net/13/* >> > > >> > > * Per the JDK 13 schedule [1], we are now in Rampdown Phase One. >> > > o For more details , see Mark Reinhold's email to jdk-dev >> mailing >> > > list [2] >> > > o The overall feature set is frozen, no further JEPs will be >> > > targeted to this release. >> > > * Changes in this build 25 [4] >> > > >> > > *Request for feedback on JEP 353 integrated in b24 >> > > * >> > > >> > > JEP 353: Reimplement the Legacy Socket API" has been integrated into >> > > jdk-13+24. It would be very useful if applications or libraries using >> > > java.net.Socket or java.net.ServerSocket APIs could test with this >> build >> > > and report any issues found. The JEP provides information on the >> system >> > > property that can be used to switch back to the old implementation and >> > > that may be useful to check for behavior differences between the old >> and >> > > new implementation. It would be very useful to get feedback via the >> > > OpenJDK net-dev mailing list, bugs via the usual channel. >> > > >> > > *Updates to Release Notes since last email* >> > > >> > > * b25 - Support Kerberos cross-realm referrals (RFC >> 6806)(JDK-8215032 >> > > ) >> > > * b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145 >> > > ) >> > > * b24 - Reimplement the Legacy Socket API(JDK-8221481 >> > > ) >> > > o see above request for feedback >> > > * b24 - Deprecated rmic tool For Removal(JDK-8217412 >> > > ) >> > > * b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767 >> > > ) >> > > * b23 - Support for Unicode 12.1 (JDK-8221431 >> > > ) >> > > * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432 >> > > ) >> > > >> > > *OpenJDK 14 **Early Access build 1 **is now available **at : - >> > > jdk.java.net/14/* >> > > >> > > * These early-access, open-source builds are provided under the GNU >> > > General Public License, version 2, with the Classpath Exception >> > > . >> > > * Changes in this build [5] >> > > >> > > ** >> > > >> > > Rgds, Rory >> > > >> > > [1] http://openjdk.java.net/projects/jdk/13/#Schedule >> > > >> > > [2] >> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html >> > > [3] http://jdk.java.net/13/release-notes >> > > [4] JDK 13 - Changes in b25 here >> > > < >> > > >> http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B24%22%3A%3A%22jdk-13%2B25%22-%22jdk-13%2B24%22%29&revcount=1000 >> > > > >> > > [5] JDK 14 - Changes in b1 here >> > > < >> > > >> http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B0%22%3A%3A%22jdk-14%2B1%22-%22jdk-14%2B0%22%29&revcount=1000 >> > > > >> > > >> > > -- >> > > 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 >> > _______________________________________________ >> > 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 Tue Jun 18 02:31:07 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 18 Jun 2019 08:31:07 +0200 Subject: [hibernate-dev] Hibernate Search 5.11.2.Final and 5.10.6.Final released Message-ID: Hello, We just published two maintenance releases for the Hibernate Search: 5.11.2.Final and 5.10.6.Final. These releases mainly upgrade Hibernate Search to the latest compatible Hibernate ORM versions and fix several issues with the Elasticsearch integration. Find more detailed information on our blog: http://in.relation.to/2019/06/18/hibernate-search-5-11-2-Final-and-5-10-6-Final/ Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From mark at lawinegevaar.nl Tue Jun 18 09:19:06 2019 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Tue, 18 Jun 2019 15:19:06 +0200 Subject: [hibernate-dev] Which branch to target? In-Reply-To: <94a74235-d53a-a1fd-f017-37b2d75677d8@lawinegevaar.nl> References: <94a74235-d53a-a1fd-f017-37b2d75677d8@lawinegevaar.nl> Message-ID: On 16-6-2019 16:28, Mark Rotteveel wrote: > After a significant hiatus, I have restarted my work on adding improved > support for Firebird 2.5 and 3.0 (and more importantly struggling > through some test failures). > > I am wondering what I should target for my changes: the current master > branch or the upstream/wip/6.0 branch. What would be the preferred or > 'better' option? On a related note, I have touched a lot of tests to either skip them or make some changes to make them pass. What is the best approach: commit together with the dialect changes, or offer the dialect change in a separate pull request from all those test changes? Mark -- Mark Rotteveel From guillaume.smet at gmail.com Tue Jun 18 09:34:05 2019 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 18 Jun 2019 15:34:05 +0200 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, As usual, here are the minutes of the NoORM IRC meeting. 15:01 < gsmet> #topic Progress Davide 15:01 < DavideD> On the OGM side, there have been a couple of PRs and several questions. Always on the MongoDB side. In theory, there is a guy looking at the support for transaction on MongoDB but I haven't received any news about it yet. 15:01 < DavideD> On the Hibernate Async side, I'm still working on it but progressing very slowly. 15:02 < DavideD> That's pretty much it 15:02 < gsmet> OK 15:02 < gsmet> #topic Next 2 weeks Davide 15:02 < DavideD> There are going to be some OGM prs to review and I will continue the work on the async side 15:03 < gsmet> is there anything that should be done to help you make more progress on the async side? 15:03 < DavideD> That's all 15:04 < DavideD> I don't know, I talked about it with Sanne last week 15:04 < gsmet> OK 15:04 < DavideD> I think the main issue is that I'm working on it on my own 15:04 < gsmet> yeah, that sure doesn't help 15:04 < DavideD> But he is aware of it, so I guess at some point we will have some reorganization 15:05 < gsmet> OK! 15:05 < gsmet> thanks! 15:05 < gsmet> #topic Progress Fabio 15:05 < fax4ever> Starting from where we stayed last time... 15:05 < fax4ever> We have made it possible to provide a missing-value-replacement for sorting 15:05 < fax4ever> on a String field using the Lucene backend. 15:06 < fax4ever> Furthermore, it seems that Elasticsearch does not apply some normalizer 15:06 < fax4ever> defined on a field on the sort missing value provied at query time. 15:06 < fax4ever> We do it in the Lucene backend and it would be nice having the same behavior 15:06 < fax4ever> on Elasticsearch too. 15:06 < fax4ever> For that reason I wrote this post: 15:06 < fax4ever> https://discuss.elastic.co/t/should-sort-missing-values-be-normalized/184222 . 15:06 < jbossbot> Title: Should sort missing values be normalized? - Elasticsearch - Discuss the Elastic Stack 15:06 < yrodiere> From what I can see nobody answered, you should probably try a bug report instead 15:07 < fax4ever> OK let's do that 15:07 < fax4ever> thanks 15:07 < fax4ever> using github? 15:07 < yrodiere> yes 15:07 < fax4ever> they don't have Jira... OK 15:07 < fax4ever> So I'll 15:07 < fax4ever> it's time to do that :) 15:07 < yrodiere> let's have a look together, maybe? Wouldn't want it to be dismissed just because something is not clear 15:07 < fax4ever> Moreover, we removed any dependence on java.beans.Introspector. 15:08 < fax4ever> Since it won?t be included in future versions of the JDK. 15:08 < fax4ever> Using Hibernate commons annotations 15:08 < fax4ever> that provide excellent support for annotations 15:08 < fax4ever> but not for generics 15:09 < fax4ever> so for the generics part we kept the Hibernate Search implementation 15:09 < fax4ever> Furthermore, we handled what happens when a client reuses a query component, 15:09 < fax4ever> such as an instance of predicate, sort or projection. 15:09 < fax4ever> We rely on the addressed index set to check whether a component can be used on a given scope. 15:10 < fax4ever> If they don't match, we throw an exception log 15:10 < fax4ever> Finally, I revied some large pull requests. 15:10 < gsmet> fax4ever: keep in mind that we don't need all the details of each issue :) 15:10 < fax4ever> But I'm still to slow in reviewing :/ 15:10 < fax4ever> OK :P 15:11 < fax4ever> That's all about Progess... 15:11 < fax4ever> too slow 15:11 < gsmet> #topic Next 2 weeks Fabio 15:11 < fax4ever> I'll be staying on PTO from June 22 to July 15. 15:11 < yrodiere> fax4ever: I still think you're fast enough, just a bit too meticulous ;) 15:11 < fax4ever> too good :) 15:11 < fax4ever> So in the next three days, the ones up to June 21, 15:12 < fax4ever> I would like to spend much time as possible reviewing further pull requests. 15:12 < fax4ever> Finally, maybe I'll have the time to solve some issues too. 15:12 < fax4ever> Like the one to handle the case where a GeoPoint field is declared sortable. 15:12 < fax4ever> That's all from me. 15:12 < gsmet> ok, thanks! 15:12 < fax4ever> Thank you! 15:12 < gsmet> #topic Progress Guillaume 15:13 -!- sfikes [~sfikes at c-69-246-28-50.hsd1.tn.comcast.net] has joined #hibernate-dev 15:13 < gsmet> so I worked a bit on ORM to fix an enhancement issue 15:13 < gsmet> and a bit on HV to push new releases for the 6.0 branch and the 6.1 branch 15:14 < gsmet> nothing much but it was high time we release them as they contained a few minor but annoying fixes 15:14 < gsmet> #topic Next 2 weeks Guillaume 15:14 < gsmet> I won't work on Hibernate stuff that much 15:14 < gsmet> I want to make progress on the ORM integration in Quarkus 15:15 < gsmet> I made some progress this week but there is still some work to do 15:15 < gsmet> I also have a talk next week and I will demo Quarkus + Hibernate Search as a live demo 15:15 < yrodiere> \o/ 15:15 < gsmet> so I have to practice a lot until then :) 15:16 < gsmet> that's pretty much it for me 15:16 < gsmet> #topic Progress Koen 15:16 < koentsje> i have integrated quarkus 0.16.0 in the eclipse tools 15:16 < fax4ever> nice! 15:16 < koentsje> also continued to work (a tiny bit) on the quarkus run/debug configuration in eclips 15:17 < koentsje> yrodiere helped me setting up a continuous integration job for the quarkus-eclipse project 15:17 < koentsje> (basically he did all the work ;) ) 15:18 < koentsje> i did a bit of maintenance on the core hibernate tools, updating dependencies 15:18 < yrodiere> I didn't debug the build :P 15:19 < koentsje> and i investigated a jboss tools problem that i lost track of, it concerns failure of creation of hibernate consoles for hibernate 5.3 and 5.4 15:19 < koentsje> but so far, i haven?t been able to reproduce it? even though our qe guys are adamant 15:19 < koentsje> that?s it for me for the past sprint 15:20 < gsmet> #topic Next 2 weeks Koen 15:20 < koentsje> i will first try continue with this jboss tools problem 15:20 < koentsje> reproduce it and (hopefully) fix it 15:21 < koentsje> then continue the quarkus run/debug configuration 15:21 < koentsje> and finally if time, tackle the issues carried over from last period: 15:21 < koentsje> - improve the quarkus extension view 15:22 < koentsje> - elaborate the reddeer automatic integration test 15:22 < koentsje> also, i plan to take off next week thursday and friday? 15:22 < koentsje> that?s it 15:23 < gsmet> thanks! 15:23 < gsmet> #topic Progress Yoann 15:23 < yrodiere> First, I finished the work I started during the previous sprint about adding write APIs that go beyond just automatic indexing. 15:23 < yrodiere> It allows more fine-grained control over indexing when executing batch processes, in particular. 15:23 < yrodiere> After that I tried to make a case for giving more precision to the `scaled_float` type in Elasticsearch, which would be useful to us when indexing BigDecimal or BigInteger. 15:24 < yrodiere> Long story short, there was an easy fix but would not improve the precision of all features (aggregations in particular), so they were adamant about it: it's a no 15:24 < yrodiere> So we'll have better precision in the Lucene backend than in the Elasticsearch backend, there's not much we can do about it. 15:24 < yrodiere> Next, I fixed several minor issues with the Search DSL, mainly the fact that we used to require a Function for lambdas in the predicate and projection DSL, and a Consumer for lambdas in the Sort DSL 15:24 < yrodiere> Now we'll expect a Function everywhere. 15:24 < yrodiere> I also worked on the ORM mapper, restoring support for indexed entities whose document ID is extracted from a property that is not the entity ID 15:25 < yrodiere> Apart from that, most of my time was spent on the documentation 15:25 < yrodiere> both the javadoc and the reference documentation 15:25 < yrodiere> It took way longer than I initially imagined, but now we have something 15:25 < yrodiere> Next two weeks... 15:25 < gsmet> #topic Next 2 weeks Yoann 15:25 < yrodiere> I already started a code cleanup in the POJO mapper, which I expect to submit soon 15:26 < yrodiere> It's mostly related to what I did regarding entities whose document ID is not the entity ID: 15:26 < yrodiere> I had to implement a quick and dirty fix, a clean one requires more extensive changes 15:26 < yrodiere> In parallel I've also started investigating a bug related to distance projections; I will finish that 15:26 < yrodiere> I also want to test and implement support for ES 6.8 15:26 < yrodiere> Then I intend to release a new Alpha, probably by the end of the week 15:27 < yrodiere> I will also work on some API changes that should happen before the beta, but they probably won't make it into master before the release 15:27 < yrodiere> Some changes are not very impacting to users, such as renaming some DSL interfaces (users don't reference these types directly anyway), 15:27 < yrodiere> but others are more extensive, such as moving the mapping annotations to a common package (it's a bit of a mess right now) 15:27 < yrodiere> I think that's all 15:27 < yrodiere> gsmet: Fabio will be on PTO starting next week, so I may need your help for reviews... ? :) 15:27 < gsmet> ping me when you have some stuff to review 15:28 < gsmet> ah wait 15:28 < gsmet> I'm on PTO starting next Wednesday (had 5 days that I *have* to take in June) 15:28 -!- rvansa [rvansa at nat/redhat/x-lsbsmokpiytmhfpj] has quit [Ping timeout: 245 seconds] 15:28 < gsmet> and polishing my talk until then but I should hopefully have some time here and there 15:28 < yrodiere> ok 15:29 < gsmet> and I'm on semi-PTO on Friday 15:29 < gsmet> (meaning, I took a PTO but I will probably work a bit) 15:29 < yrodiere> don't hesitate to ask if I can help with something, that will leave your more time to review and will reduce the amount of stuff to review ;) 15:29 < gsmet> yeah, well, it's mostly about practicing and practicing 15:29 < gsmet> so nobody can really help 15:30 < gsmet> well, you can practice if you want but it won't help me ;) 15:30 < yrodiere> developers, developers, developers 15:30 < fax4ever> :) From sanne at hibernate.org Wed Jun 19 06:12:20 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 19 Jun 2019 11:12:20 +0100 Subject: [hibernate-dev] Which branch to target? In-Reply-To: References: <94a74235-d53a-a1fd-f017-37b2d75677d8@lawinegevaar.nl> Message-ID: On Tue, 18 Jun 2019 at 14:19, Mark Rotteveel wrote: > > On 16-6-2019 16:28, Mark Rotteveel wrote: > > After a significant hiatus, I have restarted my work on adding improved > > support for Firebird 2.5 and 3.0 (and more importantly struggling > > through some test failures). > > > > I am wondering what I should target for my changes: the current master > > branch or the upstream/wip/6.0 branch. What would be the preferred or > > 'better' option? Hi Mark, sorry for the late reply, I think we'll need Steve to give you a definitive answer. Just wondering, would your patches be significantly different? As far as I know branch wip/6.0 is a bit in flux ATM, so it might be safer to just target master. Or send them to both if that's easy for you? > On a related note, I have touched a lot of tests to either skip them or > make some changes to make them pass. What is the best approach: commit > together with the dialect changes, or offer the dialect change in a > separate pull request from all those test changes? Either works for us. Maybe it's easier for you to first send a PR with all testsuite improvements? Thanks, Sanne > > Mark > -- > Mark Rotteveel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From mark at lawinegevaar.nl Fri Jun 21 11:09:15 2019 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Fri, 21 Jun 2019 17:09:15 +0200 Subject: [hibernate-dev] Which branch to target? In-Reply-To: References: <94a74235-d53a-a1fd-f017-37b2d75677d8@lawinegevaar.nl> Message-ID: <977ffcd0-cfb8-b3d2-9a88-756374557563@lawinegevaar.nl> On 2019-06-19 12:12, Sanne Grinovero wrote: > On Tue, 18 Jun 2019 at 14:19, Mark Rotteveel > wrote: >> >> On 16-6-2019 16:28, Mark Rotteveel wrote: >> > After a significant hiatus, I have restarted my work on adding improved >> > support for Firebird 2.5 and 3.0 (and more importantly struggling >> > through some test failures). >> > >> > I am wondering what I should target for my changes: the current master >> > branch or the upstream/wip/6.0 branch. What would be the preferred or >> > 'better' option? > > Hi Mark, > > sorry for the late reply, I think we'll need Steve to give you a > definitive answer. > Just wondering, would your patches be significantly different? At this point I have only looked at master, so I don't yet know if there would be significant differences or not. > As far as I know branch wip/6.0 is a bit in flux ATM, so it might be > safer to just target master. > Or send them to both if that's easy for you? I can probably do that as well. >> On a related note, I have touched a lot of tests to either skip them >> or >> make some changes to make them pass. What is the best approach: commit >> together with the dialect changes, or offer the dialect change in a >> separate pull request from all those test changes? > > Either works for us. Maybe it's easier for you to first send a PR with > all testsuite improvements? Most of the test changes rely on the presence of the new dialects I created for Firebird 2.5 and 3.0 (for dialect-specific checks, or to skip the test for a dialect). A single PR seems like a logical choice, but the new dialects could be the first PR and the test changes as a follow up. Mark From mark at lawinegevaar.nl Sat Jun 22 04:19:13 2019 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sat, 22 Jun 2019 10:19:13 +0200 Subject: [hibernate-dev] Test FormulaWithPartitionByTest seems to rely on implementation specific ordering Message-ID: <052e1135-fbe1-c8e6-f5ca-6b33b34689b6@lawinegevaar.nl> The test FormulaWithPartitionByTest against Firebird 3 fails because the returned result has a different order than the one expected by the test. As far as I can tell, the order expected by the test is arbitrary or at least, as far as I can tell, the order expected is not necessarily required by the SQL standard (although it might as well be a bug in Firebird, I'm just not sure). The testdata is (ID, DISCOUNT_CODE, DISCOUNT_VALUE) (1, "20", 12.34) (2, "20", 15.89) (3, "100", 12.5) With generated query: select formulawit0_.id as id1_0_, formulawit0_.DISCOUNT_CODE as DISCOUNT_CODE2_0_, formulawit0_.DISCOUNT_VALUE as DISCOUNT_VALUE3_0_, ROW_NUMBER() OVER( PARTITION BY formulawit0_.DISCOUNT_CODE ORDER BY SIGN(formulawit0_.DISCOUNT_VALUE) DESC ) as formula0_ from DisplayItem formulawit0_ order by formulawit0_.id The expected order of the row_number() is 1, 2, 1 but due to the evaluation order in Firebird of order by in window functions and the top level order by, the resulting order is 2, 1, 1. I can see four solutions for this: 1. Just ignore the test for Firebird 3 2. Add a Firebird specific expectation of order (although that would be testing what is likely an implementation artifact) 3. Enforce a more specific order in the window function by changing the order by to ORDER BY SIGN(DISCOUNT_VALUE) DESC, ID 4. Enforce an order by that is consistent with the data: ORDER BY DISCOUNT_VALUE (the use of SIGN with the shown data can lead to an arbitrary order as the result is always 1). What would have your preference? Mark -- Mark Rotteveel From yoann at hibernate.org Mon Jun 24 03:07:48 2019 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 24 Jun 2019 09:07:48 +0200 Subject: [hibernate-dev] Hibernate Search 6.0.0.Alpha7 released Message-ID: Hello, We just published Hibernate Search 6.0.0.Alpha7, a new release of the still-in-development 6.0 branch. This release mainly restores missing parameters for index field types, restores explicit indexing APIs, and upgrades to Elasticsearch 6.8 and 7.1. As an Alpha, this version is an early technology preview. Be sure to read about it on our blog before you try it out: https://in.relation.to/2019/06/24/hibernate-search-6-0-0-Alpha7/ Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From steve at hibernate.org Mon Jun 24 11:53:22 2019 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 24 Jun 2019 10:53:22 -0500 Subject: [hibernate-dev] Test FormulaWithPartitionByTest seems to rely on implementation specific ordering In-Reply-To: <052e1135-fbe1-c8e6-f5ca-6b33b34689b6@lawinegevaar.nl> References: <052e1135-fbe1-c8e6-f5ca-6b33b34689b6@lawinegevaar.nl> Message-ID: The query is selecting ids, so I assume you mean `1,2,3` as the expectation. Clearly Firebird cannot support what the query is attempting to do - so the best option is to skip this test for Firebird. However, the order-by is really not serving any purpose to the test aside from making the assertions easier; so another option would be to remove the order-by and assert the results via iterating them. On Sat, Jun 22, 2019 at 3:19 AM Mark Rotteveel wrote: > The test FormulaWithPartitionByTest against Firebird 3 fails because the > returned result has a different order than the one expected by the test. > > As far as I can tell, the order expected by the test is arbitrary or at > least, as far as I can tell, the order expected is not necessarily > required by the SQL standard (although it might as well be a bug in > Firebird, I'm just not sure). > > The testdata is > (ID, DISCOUNT_CODE, DISCOUNT_VALUE) > (1, "20", 12.34) > (2, "20", 15.89) > (3, "100", 12.5) > > With generated query: > select > formulawit0_.id as id1_0_, > formulawit0_.DISCOUNT_CODE as DISCOUNT_CODE2_0_, > formulawit0_.DISCOUNT_VALUE as DISCOUNT_VALUE3_0_, > ROW_NUMBER() OVER( PARTITION > BY > formulawit0_.DISCOUNT_CODE > ORDER BY > SIGN(formulawit0_.DISCOUNT_VALUE) DESC ) as formula0_ > from > DisplayItem formulawit0_ > order by > formulawit0_.id > > The expected order of the row_number() is 1, 2, 1 but due to the > evaluation order in Firebird of order by in window functions and the top > level order by, the resulting order is 2, 1, 1. > > I can see four solutions for this: > > 1. Just ignore the test for Firebird 3 > 2. Add a Firebird specific expectation of order (although that would be > testing what is likely an implementation artifact) > 3. Enforce a more specific order in the window function by changing the > order by to ORDER BY SIGN(DISCOUNT_VALUE) DESC, ID > 4. Enforce an order by that is consistent with the data: ORDER BY > DISCOUNT_VALUE (the use of SIGN with the shown data can lead to an > arbitrary order as the result is always 1). > > What would have your preference? > > Mark > -- > Mark Rotteveel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From graham_hibernate at collo.me.uk Mon Jun 24 21:58:14 2019 From: graham_hibernate at collo.me.uk (Graham Collinson) Date: Tue, 25 Jun 2019 02:58:14 +0100 Subject: [hibernate-dev] Fwd: Test FormulaWithPartitionByTest seems to rely on implementation specific ordering In-Reply-To: References: <052e1135-fbe1-c8e6-f5ca-6b33b34689b6@lawinegevaar.nl> Message-ID: Didn't include the list on my original email, sorry. ---------- Forwarded message --------- From: Graham Collinson Date: Tue, 25 Jun 2019 at 02:56 Subject: Re: [hibernate-dev] Test FormulaWithPartitionByTest seems to rely on implementation specific ordering To: Steve Ebersole Hi, I get similar results when trying this as a manual test in mariadb (10.3.8-MariaDB). The full results returned are: +--------+-------------------+--------------------+-----------+ | id1_0_ | DISCOUNT_CODE2_0_ | DISCOUNT_VALUE3_0_ | formula0_ | +--------+-------------------+--------------------+-----------+ | 1 | 20 | 12.34 | 2 | | 2 | 20 | 15.89 | 1 | | 3 | 100 | 12.5 | 1 | +--------+-------------------+--------------------+-----------+ If the test is against the row_number (or formula0_) column then expecting 1,2,1 appears to be incorrect. The row_number is over a partition on discount code with rows ordered by sign(discount_value) descending. As Mark says sign(discount_value) is always 1. So should this query lead to the list of row_numbers expected by the test? I tested in oracle (11.2.0.3) and got the order the test expects. ID1_0_ DISCOUNT_CODE2_0_ DISCOUNT_VALUE3_0_ FORMULA0_ 1 20 12.34 1 2 20 15.89 2 3 100 12.5 1 It looks like it may be a bit random to me. Regards, Graham On Mon, 24 Jun 2019 at 16:56, Steve Ebersole wrote: > The query is selecting ids, so I assume you mean `1,2,3` as the > expectation. > > Clearly Firebird cannot support what the query is attempting to do - so the > best option is to skip this test for Firebird. However, the order-by is > really not serving any purpose to the test aside from making the assertions > easier; so another option would be to remove the order-by and assert the > results via iterating them. > > On Sat, Jun 22, 2019 at 3:19 AM Mark Rotteveel > wrote: > > > The test FormulaWithPartitionByTest against Firebird 3 fails because the > > returned result has a different order than the one expected by the test. > > > > As far as I can tell, the order expected by the test is arbitrary or at > > least, as far as I can tell, the order expected is not necessarily > > required by the SQL standard (although it might as well be a bug in > > Firebird, I'm just not sure). > > > > The testdata is > > (ID, DISCOUNT_CODE, DISCOUNT_VALUE) > > (1, "20", 12.34) > > (2, "20", 15.89) > > (3, "100", 12.5) > > > > With generated query: > > select > > formulawit0_.id as id1_0_, > > formulawit0_.DISCOUNT_CODE as DISCOUNT_CODE2_0_, > > formulawit0_.DISCOUNT_VALUE as DISCOUNT_VALUE3_0_, > > ROW_NUMBER() OVER( PARTITION > > BY > > formulawit0_.DISCOUNT_CODE > > ORDER BY > > SIGN(formulawit0_.DISCOUNT_VALUE) DESC ) as formula0_ > > from > > DisplayItem formulawit0_ > > order by > > formulawit0_.id > > > > The expected order of the row_number() is 1, 2, 1 but due to the > > evaluation order in Firebird of order by in window functions and the top > > level order by, the resulting order is 2, 1, 1. > > > > I can see four solutions for this: > > > > 1. Just ignore the test for Firebird 3 > > 2. Add a Firebird specific expectation of order (although that would be > > testing what is likely an implementation artifact) > > 3. Enforce a more specific order in the window function by changing the > > order by to ORDER BY SIGN(DISCOUNT_VALUE) DESC, ID > > 4. Enforce an order by that is consistent with the data: ORDER BY > > DISCOUNT_VALUE (the use of SIGN with the shown data can lead to an > > arbitrary order as the result is always 1). > > > > What would have your preference? > > > > Mark > > -- > > Mark Rotteveel > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mark at lawinegevaar.nl Wed Jun 26 03:43:37 2019 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Wed, 26 Jun 2019 09:43:37 +0200 Subject: [hibernate-dev] Test FormulaWithPartitionByTest seems to rely on implementation specific ordering In-Reply-To: References: <052e1135-fbe1-c8e6-f5ca-6b33b34689b6@lawinegevaar.nl> Message-ID: <9f57373461311658afa6bec9ef5b5222@lawinegevaar.nl> On 2019-06-24 17:53, Steve Ebersole wrote: > The query is selecting ids, so I assume you mean `1,2,3` as the > expectation. The test is asserting the result of `ROW_NUMBER() OVER( PARTITION BY DISCOUNT_CODE ORDER BY SIGN(DISCOUNT_VALUE) DESC )`, and given the `ORDER BY SIGN(DISCOUNT_VALUE) DESC` and the values of `DISCOUNT_VALUE` all being positive, this means it orders by (literal) 1. This results in an implementation specific order (possibly with optimizer or storage related effects on ordering). The result expected by the test is: (ID, DISCOUNT_CODE, DISCOUNT_VALUE, formula) (1, "20", 12.34, 1) (2, "20", 15.89, 2) (3, "100", 12.5, 1) The result produced by Firebird (and, going by another reply, MariaDB) is: (ID, DISCOUNT_CODE, DISCOUNT_VALUE, formula) (1, "20", 12.34, 2) (2, "20", 15.89, 1) (3, "100", 12.5, 1) Both seem to fulfill the requirement of the test. Changing the test to `ORDER BY DISCOUNT_VALUE DESC` or `ORDER BY DISCOUNT_VALUE DESC, ID` would make the order of the result deterministic and possible to assert. > Clearly Firebird cannot support what the query is attempting to do - > so the best option is to skip this test for Firebird. Firebird can support what the query is attempting to do, but I guess that the current test is asserting an implementation-specific order. > However, the > order-by is really not serving any purpose to the test aside from > making the assertions easier; so another option would be to remove the > order-by and assert the results via iterating them. A deterministic order would make asserting easier, so having an order by on top-level and in the window function would be better than having none. Mark From mark at lawinegevaar.nl Sat Jun 29 08:49:04 2019 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sat, 29 Jun 2019 14:49:04 +0200 Subject: [hibernate-dev] Which branch to target? In-Reply-To: <977ffcd0-cfb8-b3d2-9a88-756374557563@lawinegevaar.nl> References: <94a74235-d53a-a1fd-f017-37b2d75677d8@lawinegevaar.nl> <977ffcd0-cfb8-b3d2-9a88-756374557563@lawinegevaar.nl> Message-ID: On 21-6-2019 17:09, Mark Rotteveel wrote: > On 2019-06-19 12:12, Sanne Grinovero wrote: >> As far as I know branch wip/6.0 is a bit in flux ATM, so it might be >> safer to just target master. >> Or send them to both if that's easy for you? > > I can probably do that as well. I have my dialect changes for master ready and will open the pull request shortly. I also started on a branch with the dialects for wip/6.0 but I'm running into all kinds of issues with query generation. Some examples: - deletes are generated as `delete ` instead of `delete from ` (SQL standard syntax requires `from`, as does Firebird). This happens in SqlDeleteToJdbcDeleteConverter.processDeleteStatement - joins add parentheses around table + alias elements (eg `inner join ( as in SQL:2016 correctly, parentheses around table + alias are not in the standard grammar, nor is it allowed by Firebird). This seems to happen in AbstractSqlAstWalker.visitTableGroupJoin. I could create a pull request for my current state on wip/6.0 and update it later, but I wonder if it would be better to wait until wip/6.0 is in a better state. What do you think? Mark -- Mark Rotteveel From mark at lawinegevaar.nl Sat Jun 29 09:07:10 2019 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Sat, 29 Jun 2019 15:07:10 +0200 Subject: [hibernate-dev] Which branch to target? In-Reply-To: References: <94a74235-d53a-a1fd-f017-37b2d75677d8@lawinegevaar.nl> <977ffcd0-cfb8-b3d2-9a88-756374557563@lawinegevaar.nl> Message-ID: <773aab89-ce5f-0bad-7648-2b749724b9d6@lawinegevaar.nl> On 29-6-2019 14:49, Mark Rotteveel wrote: > On 21-6-2019 17:09, Mark Rotteveel wrote: >> On 2019-06-19 12:12, Sanne Grinovero wrote: >>> As far as I know branch wip/6.0 is a bit in flux ATM, so it might be >>> safer to just target master. >>> Or send them to both if that's easy for you? >> >> I can probably do that as well. > > I have my dialect changes for master ready and will open the pull > request shortly. PR: https://github.com/hibernate/hibernate-orm/pull/2934 -- Mark Rotteveel