From yoann at hibernate.org  Thu May  2 07:31:44 2019
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 2 May 2019 13:31:44 +0200
Subject: [hibernate-dev] Hibernate Search 6.0.0.Alpha5 released
Message-ID: <CAEqagprCbjcgpgE-zDfYDBrFifAOKkjjOrrHFVHZZ7T8k+5QKQ@mail.gmail.com>

Hello,

We just published Hibernate Search 6.0.0.Alpha5, the fourth release for the
still-in-development 6.0 branch.

This release mainly restores the "indexNullAs" feature, adds a brand new
API to declare dependencies in bridges, and adds compatibility with
Elasticsearch 6.7 and 7.0.

As an Alpha, this version is an early technology preview. Be sure to read
about it on our blog before you try it out:

http://in.relation.to/2019/05/02/hibernate-search-6-0-0-Alpha5/

Cheers,
Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

From emmanuel at hibernate.org  Fri May  3 02:54:09 2019
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 03 May 2019 08:54:09 +0200
Subject: [hibernate-dev] Programmatic API for constraint definitions
Message-ID: <3F7C9F08-15A2-44BE-9E0A-B5575A4B8F53@hibernate.org>

Here is a roughly similar but with some twist approach to Hibernate 
Validator programmatic definition.
https://github.com/making/yavi/blob/develop/README.md

From yoann at hibernate.org  Thu May  9 09:51:29 2019
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 9 May 2019 15:51:29 +0200
Subject: [hibernate-dev] Jenkins upgrade
In-Reply-To: <CAFdSV9uS3kj=r0_aDdyQF9AJusuaJ_ZkjV0TYcsTF+1oAUwGQw@mail.gmail.com>
References: <CAEqagppk8MS4b=ja+6n+0yCpO+Q=czS7TPCrqsWtJuQFR=_M0g@mail.gmail.com>
	<CANoTJYNji+nnKQNFZCHYGFS3MVR8VV32aMSMbsRJcsUrOpcCqA@mail.gmail.com>
	<CAFdSV9uS3kj=r0_aDdyQF9AJusuaJ_ZkjV0TYcsTF+1oAUwGQw@mail.gmail.com>
Message-ID: <CAEqagpon_MqYzRFLwP+joc5WFEGT4Qt-8pFwpyWhNYpoJCSn-w@mail.gmail.com>

Marko brought to my attention that a few jobs, including Hibernate
Validator's, were failing. The failures were caused by a regression in
Jenkins 2.175 [1].

I just upgraded again, which should work around the problem. You may get
warnings in your build logs related to FilePaths being serialized: please
ignore them, it's a non-critical problem in some plugins that should get
solved in future updates.

[1] https://issues.jenkins-ci.org/browse/JENKINS-57244

Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org


On Tue, 30 Apr 2019 at 15:11, Steve Ebersole <steve at hibernate.org> wrote:

> Thanks guys!
>
> On Tue, Apr 30, 2019 at 8:07 AM Davide D'Alto <davide at hibernate.org>
> wrote:
>
>> On a related note, I've created a new AMI to use as slave and
>> configure Jenkins to use it.
>> If there are issues, it is still possible to use the old one  by
>> updating the Jenkins configuration (http://ci.hibernate.org/configure)
>> to the AMI ID we used before (custom fedora v23).
>>
>> Cheers,
>> Davide
>>
>> On Tue, Apr 30, 2019 at 11:46 AM Yoann Rodiere <yoann at hibernate.org>
>> wrote:
>> >
>> > Hello,
>> >
>> > TL;DR: I just updated Jenkins and its plugins. If things stop working
>> > correctly, please let me know.
>> >
>> > Some details below, in case I'm not here when things start to break
>> down...
>> >
>> > I updated Jenkins and its plugins to the latest versions, hoping to fix
>> the
>> > problem we've been having lately where we would only ever get a single
>> EC2
>> > slave.
>> >
>> > The result was an AWS EC2 plugin that started many, many EC2 slaves,
>> but on
>> > the Jenkins side mapped all slaves to the same URL, which resulted in
>> > multiple builds running concurrently on the same EC2 instance, which
>> > obviously resulted in many failures.
>> >
>> > I rolled back the AWS EC2 plugin from 1.42 to 1.39 (like I had to do a
>> few
>> > weeks ago), and things to be back to normal. It even works better than
>> > before I attempted the upgrade: the plugin correctly spawns multiple
>> slaves
>> > as required.
>> >
>> > Frankly I don't understand what is going on, but it works again so I'll
>> > stop touching it. I suppose I should take the time to investigate,
>> attempt
>> > to reproduce the problem and report it to the plugin maintainers. I
>> > currently do not have a few days to spare for that, so it'll wait...
>> >
>> > For the record, I also had to do the following during the upgrade:
>> >
>> >    - I had to update the AWS permissions for the EC2 plugin:
>> >
>> https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin#AmazonEC2Plugin-Version1.41(Oct24th,2018)
>> >    - I had to install a plugin to ensure running builds are no longer
>> >    allowed to do whatever they want (~root permissions):
>> >
>> https://jenkins.io/doc/book/system-administration/security/build-authorization/
>> >
>> > Cheers,
>> >
>> >
>> > Yoann Rodi?re
>> > Hibernate NoORM Team
>> > yoann at hibernate.org
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From rory.odonnell at oracle.com  Fri May 10 04:00:15 2019
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 10 May 2019 09:00:15 +0100
Subject: [hibernate-dev] JDK 13 - Early Access build 20 is available
Message-ID: <f254ef80-3283-7e67-12e6-7e500383601e@oracle.com>


Hi Sanne,


      *OpenJDK builds *- JDK 13 - Early Access build 20 is available at
      http://jdk.java.net/13/

  * These early-access , open-source builds are provided under the
      o GNU General Public License, version?2, with the Classpath
        Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
  * Changes in this build
    <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B19%22%3A%3A%22jdk-13%2B20%22-%22jdk-13%2B19%22%29&revcount=1000>
  * Release notes [1]


      *Significant changes since the last availability email*

  * build 20
      o Removal of T-Systems Deutsche Telekom Root CA 2 certificate
        (JDK-8222137)
      o Add new FileSystems.newFileSystem methods (JDK-8218875)
      o Enhance auto vectorization for x86 (JDK-8222074)
      o Remove CollectorPolicy and its subclasses (JDK-8198505)
      o Drop support for pre JDK 1.4 SocketImpl implementations
        (JDK-8216978)
  * build 19
      o add support for generating method handles from a variable symbol
        (JDK-8222744)
      o mark new VM option AllowRedefinitionToAddOrDeleteMethods as
        deprecated (JDK-8222934)
  * build 18
      o Improve String::equals warmup characteristics (JDK-8215017)
      o [Containers] Improve systemd slice memory limit support
        (JDK-8217338)


        Bug fixes for issues reported by Open Source Projects

  * build 20
      o assert(Compile::current()->live_nodes() <
        Compile::current()->max_node_limit()) failed: Live Node limit
        exceeded limit (JDK-8219520)
      o C2: MemNode::can_see_stored_value() ignores casts which carry
        control dependency (JDK-8219902)
      o New fix of the deadlock in sun.security.ssl.SSLSocketImpl
        (JDK-8219991)


      JEP updates since last email

  * JEP 350: Dynamic CDS Archives <http://openjdk.java.net/jeps/350>?
    istargeted for JDK 13.
  * JEP 351: ZGC: Uncommit Unused Memory
    <http://openjdk.java.net/jeps/351> istargeted for JDK 13
  * JEP 353: Reimplement the Legacy Socket API
    <http://openjdk.java.net/jeps/353>?moved to Candidate
  * JEP 354: Switch Expressions <http://openjdk.java.net/jeps/354> moved
    to Candidate.


      OpenJDK Committers? Workshop, 1?2 August 2019 [2]

Rgds,Rory

[1] http://jdk.java.net/13/release-notes
[2] https://mail.openjdk.java.net/pipermail/announce/2019-April/000269.html

-- 
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland


From yoann at hibernate.org  Fri May 10 04:48:42 2019
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 10 May 2019 10:48:42 +0200
Subject: [hibernate-dev] JDK 13 - Early Access build 20 is available
In-Reply-To: <f254ef80-3283-7e67-12e6-7e500383601e@oracle.com>
References: <f254ef80-3283-7e67-12e6-7e500383601e@oracle.com>
Message-ID: <CAEqagpqrST_DTmyCcPK7Xjj0Ytzg+qUde6j3cuPcrPp7Mwd8Ng@mail.gmail.com>

I upgraded CI: "OpenJDK 13 latest" now points to ea20.

Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org


On Fri, 10 May 2019 at 10:01, Rory O'Donnell <rory.odonnell at oracle.com>
wrote:

>
> Hi Sanne,
>
>
>       *OpenJDK builds *- JDK 13 - Early Access build 20 is available at
>       http://jdk.java.net/13/
>
>   * These early-access , open-source builds are provided under the
>       o GNU General Public License, version 2, with the Classpath
>         Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
>   * Changes in this build
>     <
> http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B19%22%3A%3A%22jdk-13%2B20%22-%22jdk-13%2B19%22%29&revcount=1000
> >
>   * Release notes [1]
>
>
>       *Significant changes since the last availability email*
>
>   * build 20
>       o Removal of T-Systems Deutsche Telekom Root CA 2 certificate
>         (JDK-8222137)
>       o Add new FileSystems.newFileSystem methods (JDK-8218875)
>       o Enhance auto vectorization for x86 (JDK-8222074)
>       o Remove CollectorPolicy and its subclasses (JDK-8198505)
>       o Drop support for pre JDK 1.4 SocketImpl implementations
>         (JDK-8216978)
>   * build 19
>       o add support for generating method handles from a variable symbol
>         (JDK-8222744)
>       o mark new VM option AllowRedefinitionToAddOrDeleteMethods as
>         deprecated (JDK-8222934)
>   * build 18
>       o Improve String::equals warmup characteristics (JDK-8215017)
>       o [Containers] Improve systemd slice memory limit support
>         (JDK-8217338)
>
>
>         Bug fixes for issues reported by Open Source Projects
>
>   * build 20
>       o assert(Compile::current()->live_nodes() <
>         Compile::current()->max_node_limit()) failed: Live Node limit
>         exceeded limit (JDK-8219520)
>       o C2: MemNode::can_see_stored_value() ignores casts which carry
>         control dependency (JDK-8219902)
>       o New fix of the deadlock in sun.security.ssl.SSLSocketImpl
>         (JDK-8219991)
>
>
>       JEP updates since last email
>
>   * JEP 350: Dynamic CDS Archives <http://openjdk.java.net/jeps/350>
>     istargeted for JDK 13.
>   * JEP 351: ZGC: Uncommit Unused Memory
>     <http://openjdk.java.net/jeps/351> istargeted for JDK 13
>   * JEP 353: Reimplement the Legacy Socket API
>     <http://openjdk.java.net/jeps/353> moved to Candidate
>   * JEP 354: Switch Expressions <http://openjdk.java.net/jeps/354> moved
>     to Candidate.
>
>
>       OpenJDK Committers? Workshop, 1?2 August 2019 [2]
>
> Rgds,Rory
>
> [1] http://jdk.java.net/13/release-notes
> [2]
> https://mail.openjdk.java.net/pipermail/announce/2019-April/000269.html
>
> --
> 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 coladict at gmail.com  Mon May 13 08:38:24 2019
From: coladict at gmail.com (Jordan Gigov)
Date: Mon, 13 May 2019 15:38:24 +0300
Subject: [hibernate-dev] Post-connect queries for 6.1?
Message-ID: <CA+nBocDb-jCz11jWhxSugKuM18rXmim_T8oZRifkzOuuvmGjYQ@mail.gmail.com>

I thought it would be good to have an API that will call any registered
queries upon connecting to the database, and maybe ones before returning it
to the connection pool.
I'm thinking it should be called in the implementations of ConnectionProvider
and MultiTenantConnectionProvider.

The basic purpose would be so you can set certain parameters. For example
in setting the timezone in PostgreSQL:

SET SESSION TIME ZONE 'UTC';

Or in MySQL:

SET SESSION time_zone = 'Europe/Berlin';

This would of course require dialect handling, and access to some of the
configuration settings given to the SessionFactory.
There should also be a way for users to customize these with a
per-persistence-unit configuration of some sort. They might want to pass
other such runtime tweaks.
Someone may want to send something like this to their MySQL:

SET SESSION sql_mode = 'TRADITIONAL,ANSI';

I realize it's too late to think about this for 6.0, but it's something to
consider for later on.

From steve at hibernate.org  Mon May 13 09:25:36 2019
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 13 May 2019 08:25:36 -0500
Subject: [hibernate-dev] HHH-11147 - bytecode based "proxies"
Message-ID: <CAFdSV9sEPi3ewK5C6YA3QoLtQKZwqarycuxVsiGj-M4o0JjE-A@mail.gmail.com>

Over the last 3 weeks or so, we have put a lot of work into HHH-11147 which
essentially allows bytecode enhancement to behave like the more traditional
proxy feature (create a reference based solely on the entity id).

We are wrapping up development of that improvement, enhancement, change,
whatever-you-want-to-call-it...  One remaining question however is how to
make this change available in terms of releases.  It seems to big of a deal
to simply drop in a new bug-fix release.

Should we consider a 5.5 release?  Push it to 6?  Thoughts?

From christian.beikov at gmail.com  Mon May 13 10:57:29 2019
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 13 May 2019 16:57:29 +0200
Subject: [hibernate-dev] HHH-11147 - bytecode based "proxies"
In-Reply-To: <CAFdSV9sEPi3ewK5C6YA3QoLtQKZwqarycuxVsiGj-M4o0JjE-A@mail.gmail.com>
References: <CAFdSV9sEPi3ewK5C6YA3QoLtQKZwqarycuxVsiGj-M4o0JjE-A@mail.gmail.com>
Message-ID: <49683cc5-7930-da09-61dd-da6003bbdab1@gmail.com>

+1 for 6

Am 13.05.2019 um 15:25 schrieb Steve Ebersole:
> Over the last 3 weeks or so, we have put a lot of work into HHH-11147 which
> essentially allows bytecode enhancement to behave like the more traditional
> proxy feature (create a reference based solely on the entity id).
>
> We are wrapping up development of that improvement, enhancement, change,
> whatever-you-want-to-call-it...  One remaining question however is how to
> make this change available in terms of releases.  It seems to big of a deal
> to simply drop in a new bug-fix release.
>
> Should we consider a 5.5 release?  Push it to 6?  Thoughts?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Mon May 13 12:42:01 2019
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 13 May 2019 17:42:01 +0100
Subject: [hibernate-dev] HHH-11147 - bytecode based "proxies"
In-Reply-To: <49683cc5-7930-da09-61dd-da6003bbdab1@gmail.com>
References: <CAFdSV9sEPi3ewK5C6YA3QoLtQKZwqarycuxVsiGj-M4o0JjE-A@mail.gmail.com>
	<49683cc5-7930-da09-61dd-da6003bbdab1@gmail.com>
Message-ID: <CAFm4XO2u8canQ5fG5w1x2+oFY+4XYkhyLU2GaUcUdLEQRQsRww@mail.gmail.com>

Hi Steve,

like Christian, I would probably target ORM 6, but it's up to you.

If you would rather recommend a 5.5 to get these improvements out
earlier, I have no objections and can help with that.

Thanks,
Sanne

On Mon, 13 May 2019 at 16:20, Christian Beikov
<christian.beikov at gmail.com> wrote:
>
> +1 for 6
>
> Am 13.05.2019 um 15:25 schrieb Steve Ebersole:
> > Over the last 3 weeks or so, we have put a lot of work into HHH-11147 which
> > essentially allows bytecode enhancement to behave like the more traditional
> > proxy feature (create a reference based solely on the entity id).
> >
> > We are wrapping up development of that improvement, enhancement, change,
> > whatever-you-want-to-call-it...  One remaining question however is how to
> > make this change available in terms of releases.  It seems to big of a deal
> > to simply drop in a new bug-fix release.
> >
> > Should we consider a 5.5 release?  Push it to 6?  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 gbadner at redhat.com  Mon May 13 16:26:59 2019
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 13 May 2019 13:26:59 -0700
Subject: [hibernate-dev] HHH-11147 - bytecode based "proxies"
In-Reply-To: <CAFm4XO2u8canQ5fG5w1x2+oFY+4XYkhyLU2GaUcUdLEQRQsRww@mail.gmail.com>
References: <CAFdSV9sEPi3ewK5C6YA3QoLtQKZwqarycuxVsiGj-M4o0JjE-A@mail.gmail.com>
	<49683cc5-7930-da09-61dd-da6003bbdab1@gmail.com>
	<CAFm4XO2u8canQ5fG5w1x2+oFY+4XYkhyLU2GaUcUdLEQRQsRww@mail.gmail.com>
Message-ID: <CAFDzhiT7MYJ5MBgcY2Yr1dqj2nwphLAyzat-VrfifeVddzFyCQ@mail.gmail.com>

Hi Steve,

We had discussed releasing in 5.4, and possibly 5.3, with the default
for hibernate.bytecode.allow_enhancement_as_proxy=false. I am in favor of
this.

Are you suggesting that the default behavior would effectively be to set
hibernate.bytecode.allow_enhancement_as_proxy=true in 5.5?

Do you think there would be any need to be able to restore the earlier
behavior in 5.5? IOW, would we even need the property in 5.5?

Regards,
Gail

On Mon, May 13, 2019 at 10:11 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi Steve,
>
> like Christian, I would probably target ORM 6, but it's up to you.
>
> If you would rather recommend a 5.5 to get these improvements out
> earlier, I have no objections and can help with that.
>
> Thanks,
> Sanne
>
> On Mon, 13 May 2019 at 16:20, Christian Beikov
> <christian.beikov at gmail.com> wrote:
> >
> > +1 for 6
> >
> > Am 13.05.2019 um 15:25 schrieb Steve Ebersole:
> > > Over the last 3 weeks or so, we have put a lot of work into HHH-11147
> which
> > > essentially allows bytecode enhancement to behave like the more
> traditional
> > > proxy feature (create a reference based solely on the entity id).
> > >
> > > We are wrapping up development of that improvement, enhancement,
> change,
> > > whatever-you-want-to-call-it...  One remaining question however is how
> to
> > > make this change available in terms of releases.  It seems to big of a
> deal
> > > to simply drop in a new bug-fix release.
> > >
> > > Should we consider a 5.5 release?  Push it to 6?  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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue May 14 12:14:43 2019
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 14 May 2019 11:14:43 -0500
Subject: [hibernate-dev] Post-connect queries for 6.1?
In-Reply-To: <CA+nBocDb-jCz11jWhxSugKuM18rXmim_T8oZRifkzOuuvmGjYQ@mail.gmail.com>
References: <CA+nBocDb-jCz11jWhxSugKuM18rXmim_T8oZRifkzOuuvmGjYQ@mail.gmail.com>
Message-ID: <CAFdSV9uJ4fOG8MO6pLscV=_heqjr=T2qR5e3ftberNWP9quPaA@mail.gmail.com>

Add a feature request to Jira I guess.  Of course you can already achieve
this using a custom ConnectionProvider and most connection pools allow such
things.  For me personally this is not a critical feature.

On Mon, May 13, 2019 at 7:57 AM Jordan Gigov <coladict at gmail.com> wrote:

> I thought it would be good to have an API that will call any registered
> queries upon connecting to the database, and maybe ones before returning it
> to the connection pool.
> I'm thinking it should be called in the implementations of
> ConnectionProvider
> and MultiTenantConnectionProvider.
>
> The basic purpose would be so you can set certain parameters. For example
> in setting the timezone in PostgreSQL:
>
> SET SESSION TIME ZONE 'UTC';
>
> Or in MySQL:
>
> SET SESSION time_zone = 'Europe/Berlin';
>
> This would of course require dialect handling, and access to some of the
> configuration settings given to the SessionFactory.
> There should also be a way for users to customize these with a
> per-persistence-unit configuration of some sort. They might want to pass
> other such runtime tweaks.
> Someone may want to send something like this to their MySQL:
>
> SET SESSION sql_mode = 'TRADITIONAL,ANSI';
>
> I realize it's too late to think about this for 6.0, but it's something to
> consider for later on.
> _______________________________________________
> 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 May 21 09:42:29 2019
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 21 May 2019 15:42:29 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o-kxQ1aA=2HJAPv2RBiwzRF0Lxofvoe_HycObGxLR0Jpw@mail.gmail.com>

Hi,

Here are the minutes of this week's meeting (no bot for me so copy/paste
FTW):

15:04 < gsmet> #startmeeting
15:04 < gsmet> not having the bot there really starts to be an issue
15:04 < fax4ever> :/
15:04 < gsmet> anyway, let's start
15:04 < gsmet> #topic Progress Davide
15:04 < ddalto> The most interesting thing that happened is that I went to
London and talk with Mark Paluch (Spring Data Project Lead
15:04 < ddalto> ) and showed him the Hibernate Rx API.
15:05 < ddalto> Mark pointed out a couple of things that are a bit
inconsistent and might be worth to have a look.
15:05 < ddalto> I also saw his presentation on r2dbc (Reactive Relational
Database Connectivity) where he focused on the differences between
async/reactive
15:06 < ddalto> Other than that I continue to work on the reactive API
15:06 < fax4ever> nice!
15:07 -!- chammer [~
chatzilla at p200300C4BF0C4E00E9728938CEEE8926.dip0.t-ipconnect.de] has joined
#hibernate-dev
15:07 < chammer> eclipse-dev
15:07 < ddalto> That's mostly my sprint
15:07 < gsmet> ok, thanks
15:08 < gsmet> #topic Next 2 weeks Davide
15:09 < ddalto> I'm going to spend some time studying the r2dbc project
15:09 < ddalto> and see if I can adapt the API to be more consistent
15:09 < ddalto> I also have a PR on OGM that I need to look
15:10 < ddalto> That's all
15:10 < gsmet> ok, thanks
15:10 < gsmet> #topic Progress Fabio
15:10 < fax4ever> We skiped the meeting last time.
15:10 < fax4ever> So the progess this time will be about the last 4 weeks
of activity.
15:10 < fax4ever> Firstly, we fixed some pending pull requests,
15:10 < fax4ever> such as the one to check the analyzer compatibility
15:11 < fax4ever> for multi-index-full-text fields.
15:11 < fax4ever> Secondly, we did the issue about ElasticSearch schema
validation.
15:11 < fax4ever> In our tests we cover now all supported attributes.
15:11 < fax4ever> In the process we removed some attributes, like boost and
fieldData,
15:11 < fax4ever> and we discovered that the default of 'doc_values' from
15:11 < fax4ever> Elasticsearch 5 is really 'true' as declared in
Elasticsearch doc.
15:11 < fax4ever> Thirdly, we applied the new the built-in normalize method
15:11 < fax4ever> provided by Lucene whenever we need a normalization.
15:12 < fax4ever> The trick here was to override some methods in
TokenizerChain class.
15:12 < fax4ever> It was necessary because we don't use the Lucene-provided
CustomAnalyzer builder.
15:12 < fax4ever> Fourtly, we made thread safe
LuceneDistanceToFieldProjection class.
15:12 < fax4ever> The query builder cannot change the instance anymore,
15:12 < fax4ever> it only can change its own context.
15:12 < fax4ever> Fifthly, we avoided for any case the use of the Hibernate
Search session,
15:12 < fax4ever> if the underlying Hibernate ORM session is closed.
15:13 < fax4ever> if the underlying Hibernate ORM session is closed.
15:13 < fax4ever> Sixthly, I reviewed several pull requests, most of them
were quite extensive.
15:13 < fax4ever> Finally, the last two weeks were most about supporting
15:13 < fax4ever> the new annotation @DecimalScale and BigDecimal and
BigInteger backend field type.
15:13 < fax4ever> The rest of the time I reviewed further PRs.
15:13 < fax4ever> That's alla about the progress thanks
15:14 < gsmet> #topic Next 2 weeks Fabio
15:14 < fax4ever> I'm finishing the big pull request to support BigInteger
BigDecimal and scaling factor in general
15:14 < fax4ever> I'm almost to finish
15:15 < fax4ever> after I'll follow the lineup for the new sprint
15:15 < fax4ever> as usual
15:15 < fax4ever> so you can see our progress on the sprint page of jira
15:15 < fax4ever> that's all from me thanks
15:15 < gsmet> thanks
15:15 < gsmet> #topic Progress Guillaume
15:16 < gsmet> not much progress from my side
15:16 < gsmet> I reviewed and included a couple of Validator PRs
15:16 < gsmet> we had quite a few reports lately
15:16 < gsmet> Marko is fixing most of the bugs
15:16 < gsmet> we also had a significant external contributions which is
nice
15:17 < gsmet> other than that, I'm bugging Yoann about various things,
while I'm working on a Hibernate Search quickstart for Quarkus
15:17 < gsmet> hopefully, it's for the best but I admit I'm whining a lot :)
15:17 < fax4ever> cool!
15:17 < yrodiere> :)
15:17 < gsmet> #topic Next 2 weeks Guillaume
15:18 < gsmet> so I want to finish the guide + quickstart for Quarkus' next
release
15:18 < gsmet> I also have to update to the latest snapshots - next alpha
15:19 < gsmet> I also would like to release a new 6.0.x and a new
6.1.0.alpha for HV
15:19 < gsmet> that's it for me
15:19 < gsmet> #topic Progress Koen
15:19 < koentsje> i have been improving the create project wizard for the
quarkus tools
15:20 < koentsje> also continue the work on the cheat sheet
15:20 < koentsje> and i have tried to get continuous integration working
without much success, so i will definitely have to talk to yrodiere for this
15:21 < yrodiere> sure
15:21 < koentsje> but i did manage to set up a reddeer integration test
plugin
15:21 < koentsje> additionally i have released hibernate tools 5.3.10
15:22 < koentsje> and i have integrated the new release in the eclipse
tooling
15:22 < koentsje> and finally i have been working on integrating quarkus
0.15.0 into the eclipse tools
15:22 < koentsje> this is almost done, but still one or two loose ends
15:23 -!- sfikes [~sfikes at c-69-246-28-50.hsd1.ms.comcast.net] has joined
#hibernate-dev
15:23 < koentsje> that?s it
15:23 < gsmet> #topic Next 2 weeks Koen
15:23 < koentsje> first thing is finish the 0.15.0 integration
15:24 < koentsje> i also want to create a quarkus configuration for
running/debugging quarkus applications in eclipse
15:24 < koentsje> and improve the quarkus extensions view
15:25 < koentsje> and then, as said, investigate/implement continuous
integration
15:25 < koentsje> plus elaborate the reddeer automatic integration tests
15:25 < koentsje> if any time left, i want to investigate gradle for the
hibernate tools build
15:25 < koentsje> that will be it
15:26 < gsmet> ok, thanks
15:26 < gsmet> #topic Progress Yoann
15:26 < yrodiere> It's been a month for me too, so bear with me...
15:26 < yrodiere> First I sent a PR to add new APIs to declare dependencies
in bridges
15:26 < yrodiere> It was quite complicated to write, and probably even
worse to review (sorry Fabio!), but there are tests and in the end it got
merged
15:26 < yrodiere> I also upgraded Search 6 to ES 6.7.1 and 7
15:27 < yrodiere> Not a lot of changes there, just a bit of work to get rid
of some warnings
15:27 < yrodiere> That, and Fabio's work, got into the Search 6.0.0.Alpha5
release
15:27 < yrodiere> which was supposed to go into Quarkus 0.15, and maybe it
did, but we'll do another release before the Hibernate Search extension is
really advertised in Quarkus 0.16
15:27 < yrodiere> Then I worked on allowing users to configure the
"synchronization strategy" for automatic indexing in the Hibernate Search
ORM mapper
15:27 -!- sfikes [~sfikes at c-69-246-28-50.hsd1.ms.comcast.net] has quit
[Client Quit]
15:27 < yrodiere> This strategy basically describes how much to wait for
the indexing upon transaction commits
15:28 < yrodiere> There are three built-in strategies: "queued" (~ do not
wait), "committed" (~ wait until changes are persisted to disk, but don't
wait for them to be searchable) and "searchable" (you get the
                  idea)
15:28 < yrodiere> And there's also a way to plug in a custom strategy.
15:28 < yrodiere> The past two weeks, I fixed a bunch of tickets that were
really just waiting to be closed and were already fixed.
15:28 < yrodiere> I also submitted a PR to restore orchestration in the
Lucene backend
15:28 < yrodiere> Previously it was trivial, just serializing everything,
but that was supposed to be temporary
15:28 < yrodiere> As a result of this works the Lucene ITs went down from 2
minutes to 30s, which is nice
15:29 < fax4ever> ;)
15:29 < yrodiere> I suspect there is room for improvement, but at least
it's better than it used to be
15:29 < yrodiere> Beside that, I did some work on the Search DSL (again),
to make sure backends can fully extend it, down to the type of query and of
SearchResult.
15:29 < yrodiere> That's mainly to lay the groundwork for the introduction
of major backend-specific features, such as aggregations, which will
require a whole part of the DSL and probably a specific result
                  type too.
15:29 -!- sfikes [~sfikes at c-69-246-28-50.hsd1.ms.comcast.net] has joined
#hibernate-dev
15:29 < yrodiere> For good measure I introduced APIs for explaining query
score computation, which are different in Lucene and Elasticsearch: it
worked fine.
15:30 < yrodiere> I also changed the index schema declaration API a little
bit to force users to declare multi-valued fields, because we'll probably
need that information in the future.
15:30 < yrodiere> Finally..
15:30 < yrodiere> Yesterday and today, I worked on making the Search DSL
even less verbose by making some method calls optional
15:30 < yrodiere> It looks like this now:
15:30 < yrodiere> return Search.getSearchSession(em).search(Book.class)
15:30 < yrodiere>         .predicate(f ->
f.simpleQueryString().onFields("title").matching(pattern))
15:30 < yrodiere>         .sort(f -> f.byField("title_sort"))
15:30 < yrodiere>         .fetchHits();
15:30 < yrodiere> Well it's not merged yet, but close.
15:30 < yrodiere> Next two weeks!
15:30 < gsmet> #topic Next 2 weeks Yoann
15:31 < yrodiere> There's a big PRs still pending, so I expect to have to
do some work to do based on the reviews
15:31 < yrodiere> I will also have to release Search 6.0.0.Alpha6 for
Quarkus 0.16
15:31 < yrodiere> And ideally I'd like to release some of the maintenance
branches, too... but I've been postponing these for so long... who knows?
15:31 < yrodiere> After that, I will try to make Hibernate Search work in
the modulepath.
15:31 < yrodiere> I started to look into it, and it looks possible, but
there are a few problems with service loading that I suspect are related to
the aggregatedClassLoader in ORM. I still have to investigate.
15:32 < yrodiere> The problem is mainly that we already advertised this as
something that "just works", and I discovered some time ago that no, it
definitely did not
15:32 < yrodiere> so I'd like to fix that
15:32 < yrodiere> There are a few other tickets, but the main one will be
about restoring APIs for per-class works (purge, flush, ...) in the ORM
mapper. For now they are not exposed to end-users in Search 6,
                  they are just SPIs.
15:32 < yrodiere> That's all from me!
15:33 < gsmet> #topic Additional topics
15:33 < gsmet> I will be attending Mix-IT on Thursday-Friday so probably
not very active
15:34 < gsmet> RH is the main sponsor of the conference so we need people
there
15:34 < yrodiere> When is the Quarkus release again?
15:34 < gsmet> I won't be able to organize the hangout so Yoann, you're
hereby nominated chair :)
15:34 < gsmet> Wed 29th
15:34 < yrodiere> sure
15:35 < yrodiere> ok, so you'll be able to try out the Search release on
monday/tuesday
15:35 < fax4ever> :)
15:35 < yrodiere> well, have fun :)
15:35 < gsmet> well, we won't have people on the stand all day as there are
a lot of talks
15:35 < gsmet> so I'll be working as time permits
15:36 < gsmet> I really want to test this lazy thing before you release
15:36 < gsmet> anyone has anything to add?
15:36 < yrodiere> nope
15:36 < fax4ever> not from me thanks
15:36 < gsmet> OK, so let's close the meeting and have some fun
copy/pasting to an email...
15:37 < gsmet> #endmeeting

Cheers,

-- 
Guillaume

From gunnar at hibernate.org  Thu May 23 04:04:13 2019
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 23 May 2019 10:04:13 +0200
Subject: [hibernate-dev] in.relation.to -- HTTPS
Message-ID: <CADGJaX-rGQqK4U7LhTvsAZLF2j1uJy5K0-wi7nW5roAe6_g2FA@mail.gmail.com>

Hi all,

Just tried to reach in.relation.to via HTTPS, but it doesn't connect. Has
it not been moved to HTTPS yet, or is something broken there?

--Gunnar

From sanne at hibernate.org  Thu May 23 05:48:43 2019
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 23 May 2019 10:48:43 +0100
Subject: [hibernate-dev] in.relation.to -- HTTPS
In-Reply-To: <CADGJaX-rGQqK4U7LhTvsAZLF2j1uJy5K0-wi7nW5roAe6_g2FA@mail.gmail.com>
References: <CADGJaX-rGQqK4U7LhTvsAZLF2j1uJy5K0-wi7nW5roAe6_g2FA@mail.gmail.com>
Message-ID: <CAFm4XO3pYs5DskAPh2Lc=xPqFJNzbWB5tcFnDZZfo9pvw16kSQ@mail.gmail.com>

It wasn't moved yet.

On Thu, 23 May 2019 at 10:20, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> Hi all,
>
> Just tried to reach in.relation.to via HTTPS, but it doesn't connect. Has
> it not been moved to HTTPS yet, or is something broken there?
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Fri May 24 21:07:26 2019
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 24 May 2019 18:07:26 -0700
Subject: [hibernate-dev] hibernate.jpa.compliance.caching and nullable
	secondary tables
Message-ID: <CAFDzhiQwS8Cn1+QGhSFZB45h3y+adyay-G_yBS4RWJnYD6BZiQ@mail.gmail.com>

The Javadoc for JpaCompliance#isJpaCacheComplianceEnabled says:

* @implNote Effects include marking all secondary tables as non-optional.
The reason

* being that optional secondary tables can lead to entity cache being
invalidated rather
* than updated.

But, the way it's used is the opposite (marks all secondary tables as
optional): [1]
isNullableTable[j] = join.isOptional()
                         || creationContext.getSessionFactory()

 .getSessionFactoryOptions()
                                                   .getJpaCompliance()

 .isJpaCacheComplianceEnabled();

Even if a secondary table is explicitly mapped as non-optional using
@org.hibernate.annotations.Table(appliesTo=...,optional=false),
when hibernate.jpa.compliance.caching=true, Hibernate assumes that
secondary tables are nullable. This causes an outer join to be used in
queries, when an inner join could be used instead.

The property was added by HHH-12282 [2], which also mentions that the
intention is to mark all tables as non-optional. HHH-12282 also has a
comment [3] that says:

"I think its safe enough here to simply say that compliance means we omit
the table-span check at all."

Should the determination of whether a table is nullable depends only
on org.hibernate.mapping.Join#isOptional, like the following?

isNullableTable[j] = join.isOptional();

JpaCompliance().isJpaCacheComplianceEnabled() == true would still skip
invalidation.

WDYT?

Regards,
Gail

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/persister/entity/SingleTableEntityPersister.java#L181-L185
[2] https://hibernate.atlassian.net/browse/HHH-12282
[3]
https://hibernate.atlassian.net/browse/HHH-12282?focusedCommentId=101168&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-101168

From yoann at hibernate.org  Mon May 27 04:12:52 2019
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 27 May 2019 10:12:52 +0200
Subject: [hibernate-dev] Hibernate Search 6.0.0.Alpha6 released
Message-ID: <CAEqagppX=yPOdXat7CVOyUzJoDJuo86LP5Ypckv9dgZgGcoq9g@mail.gmail.com>

Hello,

We just published Hibernate Search 6.0.0.Alpha6, a new release of the
still-in-development 6.0 branch.

This release mainly restores decent performance for Lucene index reads and
writes, adds support for indexing BigDecimal and BigInteger, reduces the
verbosity of the search DSL, and adds support for configuring on-commit
synchronization for automatic indexing.

As an Alpha, this version is an early technology preview. Be sure to read
about it on our blog before you try it out:

http://in.relation.to/2019/05/27/hibernate-search-6-0-0-Alpha6/
Cheers,

Yoann Rodi?re
Hibernate NoORM Team
yoann at hibernate.org

From guillaume.smet at hibernate.org  Thu May 30 12:18:42 2019
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Thu, 30 May 2019 18:18:42 +0200
Subject: [hibernate-dev] Hibernate ORM 5.4.3.Final released
Message-ID: <CALt0+o_iKqZ6ddbGD_E3kBmB6-E5rePg+mgJdd8dSd-qq=2ZhA@mail.gmail.com>

Hi,

We just released Hibernate ORM 5.4.3.Final.

It just fixes a few issues, nothing big.

More information here:
http://in.relation.to/2019/05/30/hibernate-orm-543-final-out/ .

Have a nice day.

-- 
Guillaume

From rory.odonnell at oracle.com  Fri May 31 03:08:07 2019
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 31 May 2019 08:08:07 +0100
Subject: [hibernate-dev] JDK 13 - Early Access build 23 is available
Message-ID: <86653b5f-4ac5-947f-5b43-24d186c07c3e@oracle.com>

Hi Sanne,


      *OpenJDK builds *- JDK 13 - Early Access build 23 is available at
      http://jdk.java.net/13/

  * These early-access , open-source builds are provided under the
      o GNU General Public License, version?2, with the Classpath
        Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
  * Changes in this build
    <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B22%22%3A%3A%22jdk-13%2B23%22-%22jdk-13%2B22%22%29&revcount=1000>

  * Release notes [1]


        *Significant changes since the last availability email*

  * build 23
      o Support for Unicode 12.1 (JDK-8221431
        <https://bugs.openjdk.java.net/browse/JDK-8221431>)
      o Add new keytool -showinfo -tls command for displaying TLS
        configuration information (JDK-8219861
        <https://bugs.openjdk.java.net/browse/JDK-8219861>)
  * build 22
      o New methods for creating DOM and SAX factories with Namespace
        support (JDK-8219692
        <https://bugs.openjdk.java.net/browse/JDK-8219692>)
      o Removal of two DocuSign root CA certificates (JDK-8223499
        <https://bugs.openjdk.java.net/browse/JDK-8223499>)
  * build 21
      o JDWP support for IPv6 (JDK-8184770
        <https://bugs.openjdk.java.net/browse/JDK-8184770>)
      o Change the mechanism by which JDK loads the platform-specific
        AWT Toolkit (JDK-8212700
        <https://bugs.openjdk.java.net/browse/JDK-8212700>)
      o Upgrade CLDR to Version 35.1 (JDK-8221432
        <https://bugs.openjdk.java.net/browse/JDK-8221432>)
      o xConfigurable Read Timeout for CRLs (JDK-8191808
        <https://bugs.openjdk.java.net/browse/JDK-8191808>)
      o Removal of two Comodo root CA certificates (JDK-8222136
        <https://bugs.openjdk.java.net/browse/JDK-8222136>)


        Bug fixes for issues reported by Open Source Projects

  * build 22
      o OutOfMemory on compiling with darcula.jar in classpath
        (JDK-8222807 <https://bugs.openjdk.java.net/browse/JDK-8222807>)
  * build 21
      o java -version output and certain system properties contain
        "null" text in their values (JDK-8223695
        <https://bugs.openjdk.java.net/browse/JDK-8223695>)
  * build 20
      o assert(Compile::current()->live_nodes() <
        Compile::current()->max_node_limit()) failed: Live Node limit
        exceeded limit (JDK-8219520
        <https://bugs.openjdk.java.net/browse/JDK-8219520>)
      o C2: MemNode::can_see_stored_value() ignores casts which carry
        control dependency (JDK-8219902
        <https://bugs.openjdk.java.net/browse/JDK-8219902>)
      o New fix of the deadlock in sun.security.ssl.SSLSocketImpl
        (JDK-8219991 <https://bugs.openjdk.java.net/browse/JDK-8219991>)


        JEP updates since last email

  * JEP 350: Dynamic CDS Archives <http://openjdk.java.net/jeps/350>?was
    *Integrated*.
  * JEP 351: ZGC: Uncommit Unused Memory
    <http://openjdk.java.net/jeps/351>?was *Integrated*.
  * JEP 353: Reimplement the Legacy Socket API
    <http://openjdk.java.net/jeps/353>?was*Targetted* JDK 13.
  * JEP 355: Text Blocks (Preview)
    <http://openjdk.java.net/jeps/355>?was *Proposed to target*?JDK 13.


Rgds,Rory

[1] http://jdk.java.net/13/release-notes

-- 
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland