From fercoli at redhat.com  Mon Oct  1 05:49:29 2018
From: fercoli at redhat.com (Fabio Massimo Ercoli)
Date: Mon, 1 Oct 2018 11:49:29 +0200
Subject: [hibernate-dev] Hibernate OGM 5.4.0.CR1 is out
Message-ID: <CAFiQRE98sqr7Xm7WHtggdDoGviqo3DfCyVcJXf5yoxSBHn5DTA@mail.gmail.com>

Hibernate OGM 5.4.0.CR1 is ready!

Some improvement was the support of Infinispan remote transactions over
HotRod client,
java.time field types and MongoDB ReadConcern strategy.

All the details in the blog post:
http://in.relation.to/2018/10/01/hibernate-ogm-5-4-CR1-released/

Thanks, Fabio

From gbadner at redhat.com  Tue Oct  2 21:16:20 2018
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 2 Oct 2018 18:16:20 -0700
Subject: [hibernate-dev] What should happen to queued operations when a
	collection is detached?
In-Reply-To: <CAFDzhiTShF65304wy5=0NThSUwA6u8kp8os99Exq1eCJVV_MtQ@mail.gmail.com>
References: <CAFDzhiTShF65304wy5=0NThSUwA6u8kp8os99Exq1eCJVV_MtQ@mail.gmail.com>
Message-ID: <CAFDzhiQEmgqUNsCrzfd07_kYVV-==KYvLwWWqS76atvEHUEFkg@mail.gmail.com>

Since I haven't heard anything back, I've gone ahead and updated my PR [1]
to ignore queued operations when merging a detached collection. This restores
the functionality that was in place prior to HHH-5855 (which caused
HHH-11209).

In addition I've added warnings for the following situations:
* a detached collection is being merged that has queued operations;
* a collection with queued operations is attached to a session;
* a collection with queued operations is detached from a session.

I've also added a test case that shows that Session#merge and
Session#saveOrUpdate have different results when called on an entity with a
collection with queued operations. When Session#merge is called, the queued
operations are ignored. When Session#saveOrUpdate is called, the queued
operations are executed on flush.

I don't like this inconsistency, but I'm not sure what to do about it. I
don't think it's a good idea to have collections floating around with
queued operations. As far as the application knows, it is just an
uninitialized collection. I can see that the entity could find its way into
a new session, with surprising results.

IIUC, an application probably shouldn't detach an entity with a collection
in this state (having queued operations), so I think it makes sense that a
warning be logged when this happens. On the other hand, the warning will
also be logged if a transaction involving updates to a collection with
queued operations fails.

I would really appreciate some feedback on this, since HHH-11209 is a bad
regression that really should be fixed.

Thanks,
Gail

[1] https://github.com/hibernate/hibernate-orm/pull/2460

On Fri, Sep 28, 2018 at 6:27 PM Gail Badner <gbadner at redhat.com> wrote:

> HHH-11209 involves a bug merging a detached entity with an uninitialized
> collection that has queued operations.
>
> After looking into this issue I found a bug
> where AbstractPersistentCollection#operationQueue was not being cleared
> after a commit, if there was no cascade mapped for the collection.
>
> I've fixed that in a PR. [1]
>
> After that fix, the detached entity in the test case attached to HHH-11209
> has an uninitialized entity without any queued operations after commit,
> which can be merged successfully in a new session/transaction.
>
> There is still a problem when Hibernate tries to merge a detached entity
> has an uninitialized collection with queued operations though. My PR throws
> UnsupportedOperationException in this case, and there is a test case that
> reproduces it.
>
> I've been working on a fix to add support for this, but I have my doubts
> that it really should be supported. I see that prior to fixing HHH-5855
> (which caused HHH-11209), Hibernate simply ignored the queued operations in
> the detached collection. [2].
>
> The fix for HHH-5855 properly dealt with merging a managed collection that
> was uninitialized with queued operations. It introduced the bug where a
> NullPointerException would get thrown if that collection  was detached.
>
> If we want to support merging the queued operations, then I would consider
> that an improvement. Would this be a worthwhile improvement? I'm guessing
> not, but I wanted to get some opinions.
>
> For now, I see a couple of ways to deal with this so that HHH-11209 can be
> wrapped up:
> 1) ignore queued operations in a detached collection when merging, as was
> done before HHH-5855 was fixed.
> 2) clear the queued operations when the collection is detached.
>
> Comments?
>
> Thanks,
> Gail
>
> [1] https://github.com/hibernate/hibernate-orm/pull/2460
> [2]
> https://github.com/hibernate/hibernate-orm/commit/c1934b72edb4f781520937618b3b750bebb84576#diff-2c7912a47063b9ea81323bf9c6628895L651
>

From gbadner at redhat.com  Thu Oct  4 18:10:12 2018
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 4 Oct 2018 15:10:12 -0700
Subject: [hibernate-dev] What should happen to queued operations when a
	collection is detached?
In-Reply-To: <CAFDzhiQEmgqUNsCrzfd07_kYVV-==KYvLwWWqS76atvEHUEFkg@mail.gmail.com>
References: <CAFDzhiTShF65304wy5=0NThSUwA6u8kp8os99Exq1eCJVV_MtQ@mail.gmail.com>
	<CAFDzhiQEmgqUNsCrzfd07_kYVV-==KYvLwWWqS76atvEHUEFkg@mail.gmail.com>
Message-ID: <CAFDzhiSgkEYV4ka9v584=tPcPJSbw45co53aunqDoELF4uEhXg@mail.gmail.com>

 Guillaume has reviewed my PR and I've pushed the fix to master.

I still think the inconsistency should be resolved. I have no plans to do
any more on this without any feedback.

Regards,
Gail

On Tue, Oct 2, 2018 at 6:16 PM Gail Badner <gbadner at redhat.com> wrote:

> Since I haven't heard anything back, I've gone ahead and updated my PR [1]
> to ignore queued operations when merging a detached collection. This restores
> the functionality that was in place prior to HHH-5855 (which caused
> HHH-11209).
>
> In addition I've added warnings for the following situations:
> * a detached collection is being merged that has queued operations;
> * a collection with queued operations is attached to a session;
> * a collection with queued operations is detached from a session.
>
> I've also added a test case that shows that Session#merge and
> Session#saveOrUpdate have different results when called on an entity with a
> collection with queued operations. When Session#merge is called, the queued
> operations are ignored. When Session#saveOrUpdate is called, the queued
> operations are executed on flush.
>
> I don't like this inconsistency, but I'm not sure what to do about it. I
> don't think it's a good idea to have collections floating around with
> queued operations. As far as the application knows, it is just an
> uninitialized collection. I can see that the entity could find its way into
> a new session, with surprising results.
>
> IIUC, an application probably shouldn't detach an entity with a collection
> in this state (having queued operations), so I think it makes sense that a
> warning be logged when this happens. On the other hand, the warning will
> also be logged if a transaction involving updates to a collection with
> queued operations fails.
>
> I would really appreciate some feedback on this, since HHH-11209 is a bad
> regression that really should be fixed.
>
> Thanks,
> Gail
>
> [1] https://github.com/hibernate/hibernate-orm/pull/2460
>
> On Fri, Sep 28, 2018 at 6:27 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> HHH-11209 involves a bug merging a detached entity with an uninitialized
>> collection that has queued operations.
>>
>> After looking into this issue I found a bug
>> where AbstractPersistentCollection#operationQueue was not being cleared
>> after a commit, if there was no cascade mapped for the collection.
>>
>> I've fixed that in a PR. [1]
>>
>> After that fix, the detached entity in the test case attached to
>> HHH-11209 has an uninitialized entity without any queued operations after
>> commit, which can be merged successfully in a new session/transaction.
>>
>> There is still a problem when Hibernate tries to merge a detached entity
>> has an uninitialized collection with queued operations though. My PR throws
>> UnsupportedOperationException in this case, and there is a test case that
>> reproduces it.
>>
>> I've been working on a fix to add support for this, but I have my doubts
>> that it really should be supported. I see that prior to fixing HHH-5855
>> (which caused HHH-11209), Hibernate simply ignored the queued operations in
>> the detached collection. [2].
>>
>> The fix for HHH-5855 properly dealt with merging a managed collection
>> that was uninitialized with queued operations. It introduced the bug where
>> a NullPointerException would get thrown if that collection  was detached.
>>
>> If we want to support merging the queued operations, then I would
>> consider that an improvement. Would this be a worthwhile improvement? I'm
>> guessing not, but I wanted to get some opinions.
>>
>> For now, I see a couple of ways to deal with this so that HHH-11209 can
>> be wrapped up:
>> 1) ignore queued operations in a detached collection when merging, as was
>> done before HHH-5855 was fixed.
>> 2) clear the queued operations when the collection is detached.
>>
>> Comments?
>>
>> Thanks,
>> Gail
>>
>> [1] https://github.com/hibernate/hibernate-orm/pull/2460
>> [2]
>> https://github.com/hibernate/hibernate-orm/commit/c1934b72edb4f781520937618b3b750bebb84576#diff-2c7912a47063b9ea81323bf9c6628895L651
>>
>

From mihalcea.vlad at gmail.com  Fri Oct  5 01:11:22 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 5 Oct 2018 08:11:22 +0300
Subject: [hibernate-dev] Should the LocalTimeType use the globally
	configured TimeZone?
Message-ID: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>

Hi,
While reviewing this Jira issue:

https://hibernate.atlassian.net/browse/HHH-12988

and further discussing it via Twitter, I wonder if we should persist
LocalTime as-is without any TimeZone transformation
that may be done if we enable `hibernate.jdbc.time_zone`?

According to the Date/Time API, LocalTime should not be relative to any
TimeZone.

If we make this change, it means we need to use a LocalTime SQL descriptor
that ignores the jdbc.time_zone property,
and the change is going to break compatibility as well.

Vlad

From gunnar at hibernate.org  Fri Oct  5 03:37:26 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 5 Oct 2018 09:37:26 +0200
Subject: [hibernate-dev] Should the LocalTimeType use the globally
 configured TimeZone?
In-Reply-To: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>
References: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>
Message-ID: <CADGJaX8Ej7J94ib1Ae6jWfwQfDHte7Cyet1Np-0+yU=wmHERMg@mail.gmail.com>

IMO no timezone conversion whatsoever should be applied when
persisting LocalDateTime as it doesn't contain any TZ information.

If the target column type requires a TZ, it should be set to UTC,
storing the given value without any shift. I.e. the LDT value
2007-12-03T10:15:30 should be stored as 2007-12-03T10:15:30 at UTC, no
matter what's the VM's timezone or any TZ related config. This allows
to retrieve the original value later on, also if e.g. the loading VM
is in a different TZ.

In fact I'd even recommend to use a string-based column type to store
LDT, as it avoids these kinds of issues altogether.

--Gunnar





Am Fr., 5. Okt. 2018 um 07:15 Uhr schrieb Vlad Mihalcea
<mihalcea.vlad at gmail.com>:
>
> Hi,
> While reviewing this Jira issue:
>
> https://hibernate.atlassian.net/browse/HHH-12988
>
> and further discussing it via Twitter, I wonder if we should persist
> LocalTime as-is without any TimeZone transformation
> that may be done if we enable `hibernate.jdbc.time_zone`?
>
> According to the Date/Time API, LocalTime should not be relative to any
> TimeZone.
>
> If we make this change, it means we need to use a LocalTime SQL descriptor
> that ignores the jdbc.time_zone property,
> and the change is going to break compatibility as well.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From yoann at hibernate.org  Fri Oct  5 04:17:12 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 5 Oct 2018 10:17:12 +0200
Subject: [hibernate-dev] Should the LocalTimeType use the globally
 configured TimeZone?
In-Reply-To: <CADGJaX8Ej7J94ib1Ae6jWfwQfDHte7Cyet1Np-0+yU=wmHERMg@mail.gmail.com>
References: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>
	<CADGJaX8Ej7J94ib1Ae6jWfwQfDHte7Cyet1Np-0+yU=wmHERMg@mail.gmail.com>
Message-ID: <CAEqagpqdXeLBFpvDB7HEnhBUsOSv3RL1hbKu141k6BAPSBFzDA@mail.gmail.com>

 > In fact I'd even recommend to use a string-based column type to store
> LDT, as it avoids these kinds of issues altogether.

Or just, you know, "timestamp without timezone". Where possible.

More to the point, I agree with Vlad's proposition, and I also think ORM
should avoid messing with timezones as much as possible: when the user
didn't provide one (LocalDate, LocalDateTime, Date), don't store one, when
he provided one (ZonedDateTime, OffsetDateTime, Calendar, ...), store it
exactly as provided. The goal being to return the exact value that was
persisted when later retrieving the data.
But unfortunately I think there is a lot of legacy behaviors that differ
from this, so any attempt at "fixing" it would break compatibility and make
someone angry.

Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
that would also impact how we map timezone-less types, would be a good idea?


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


On Fri, 5 Oct 2018 at 09:38, Gunnar Morling <gunnar at hibernate.org> wrote:

> IMO no timezone conversion whatsoever should be applied when
> persisting LocalDateTime as it doesn't contain any TZ information.
>
> If the target column type requires a TZ, it should be set to UTC,
> storing the given value without any shift. I.e. the LDT value
> 2007-12-03T10:15:30 should be stored as 2007-12-03T10:15:30 at UTC, no
> matter what's the VM's timezone or any TZ related config. This allows
> to retrieve the original value later on, also if e.g. the loading VM
> is in a different TZ.
>
> In fact I'd even recommend to use a string-based column type to store
> LDT, as it avoids these kinds of issues altogether.
>
> --Gunnar
>
>
>
>
>
> Am Fr., 5. Okt. 2018 um 07:15 Uhr schrieb Vlad Mihalcea
> <mihalcea.vlad at gmail.com>:
> >
> > Hi,
> > While reviewing this Jira issue:
> >
> > https://hibernate.atlassian.net/browse/HHH-12988
> >
> > and further discussing it via Twitter, I wonder if we should persist
> > LocalTime as-is without any TimeZone transformation
> > that may be done if we enable `hibernate.jdbc.time_zone`?
> >
> > According to the Date/Time API, LocalTime should not be relative to any
> > TimeZone.
> >
> > If we make this change, it means we need to use a LocalTime SQL
> descriptor
> > that ignores the jdbc.time_zone property,
> > and the change is going to break compatibility as well.
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Fri Oct  5 04:46:19 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 5 Oct 2018 11:46:19 +0300
Subject: [hibernate-dev] Should the LocalTimeType use the globally
 configured TimeZone?
In-Reply-To: <CAEqagpqdXeLBFpvDB7HEnhBUsOSv3RL1hbKu141k6BAPSBFzDA@mail.gmail.com>
References: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>
	<CADGJaX8Ej7J94ib1Ae6jWfwQfDHte7Cyet1Np-0+yU=wmHERMg@mail.gmail.com>
	<CAEqagpqdXeLBFpvDB7HEnhBUsOSv3RL1hbKu141k6BAPSBFzDA@mail.gmail.com>
Message-ID: <CA+gWKMB4wAnG0G95k6LrFsD_X+es5R6CsZ-W1eCC70+Sa5gXWA@mail.gmail.com>

Hi

IMO no timezone conversion whatsoever should be applied when
> persisting LocalDateTime as it doesn't contain any TZ information.


That's not very easy to do since either the JDBC Driver or the database
engine might to the timezone conversion based on the underlying setting.

In fact I'd even recommend to use a string-based column type to store
> LDT, as it avoids these kinds of issues altogether.


Actually, a Long (BigInt) column type with the epoch would be more suitable
than a CHAR-based column since it's more compact and achieves the same goal.
However, many clients will not want to store Date/Time in Int or String
columns as explained in the following article:

https://www.periscopedata.com/blog/better-sql-schema

Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
> that would also impact how we map timezone-less types, would be a good idea?


We would have to introduce a new configuration property as a strategy where
the current behavior is "legacy"
while the new one must be explicitly enabled.

Vlad

On Fri, Oct 5, 2018 at 11:17 AM Yoann Rodiere <yoann at hibernate.org> wrote:

> > In fact I'd even recommend to use a string-based column type to store
> > LDT, as it avoids these kinds of issues altogether.
>
> Or just, you know, "timestamp without timezone". Where possible.
>
> More to the point, I agree with Vlad's proposition, and I also think ORM
> should avoid messing with timezones as much as possible: when the user
> didn't provide one (LocalDate, LocalDateTime, Date), don't store one, when
> he provided one (ZonedDateTime, OffsetDateTime, Calendar, ...), store it
> exactly as provided. The goal being to return the exact value that was
> persisted when later retrieving the data.
> But unfortunately I think there is a lot of legacy behaviors that differ
> from this, so any attempt at "fixing" it would break compatibility and make
> someone angry.
>
> Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
> that would also impact how we map timezone-less types, would be a good idea?
>
>
> Yoann Rodi?re
> Hibernate NoORM Team
> yoann at hibernate.org
>
>
> On Fri, 5 Oct 2018 at 09:38, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> IMO no timezone conversion whatsoever should be applied when
>> persisting LocalDateTime as it doesn't contain any TZ information.
>>
>> If the target column type requires a TZ, it should be set to UTC,
>> storing the given value without any shift. I.e. the LDT value
>> 2007-12-03T10:15:30 should be stored as 2007-12-03T10:15:30 at UTC, no
>> matter what's the VM's timezone or any TZ related config. This allows
>> to retrieve the original value later on, also if e.g. the loading VM
>> is in a different TZ.
>>
>> In fact I'd even recommend to use a string-based column type to store
>> LDT, as it avoids these kinds of issues altogether.
>>
>> --Gunnar
>>
>>
>>
>>
>>
>> Am Fr., 5. Okt. 2018 um 07:15 Uhr schrieb Vlad Mihalcea
>> <mihalcea.vlad at gmail.com>:
>> >
>> > Hi,
>> > While reviewing this Jira issue:
>> >
>> > https://hibernate.atlassian.net/browse/HHH-12988
>> >
>> > and further discussing it via Twitter, I wonder if we should persist
>> > LocalTime as-is without any TimeZone transformation
>> > that may be done if we enable `hibernate.jdbc.time_zone`?
>> >
>> > According to the Date/Time API, LocalTime should not be relative to any
>> > TimeZone.
>> >
>> > If we make this change, it means we need to use a LocalTime SQL
>> descriptor
>> > that ignores the jdbc.time_zone property,
>> > and the change is going to break compatibility as well.
>> >
>> > Vlad
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From guillaume.smet at gmail.com  Fri Oct  5 05:33:29 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 5 Oct 2018 11:33:29 +0200
Subject: [hibernate-dev] StatelessSession and JTA platform without
	transaction manager
Message-ID: <CALt0+o9_fgerHVkBJnpd5+2jGzd43vJ2xF5pzYYJpwamd1ZR+g@mail.gmail.com>

Hi,

I'm triaging the latest issues and I stumbled upon this one:
https://hibernate.atlassian.net/browse/HHH-13002 .

This particular issue happens because our OSGi stuff enforce an
OsgiJtaPlatform even if there is no JTA transaction manager.

I'm not very familiar with JTA in ORM but I find suspicious that
StatelessSession doesn't check somehow that a JTA transaction manager is in
motion before checking things with it namely here:
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/internal/StatelessSessionImpl.java#L674

In SessionFactoryImpl, we somehow check that the JTA transaction manager is
OK here:
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/internal/SessionFactoryImpl.java#L1011
I suppose that's why standard sessions are not affected.

Not sure what the right fix would be so I thought I might as well ask.

Thanks for any insights.

-- 
Guillaume

From sanne at hibernate.org  Fri Oct  5 05:44:18 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 5 Oct 2018 10:44:18 +0100
Subject: [hibernate-dev] Should the LocalTimeType use the globally
 configured TimeZone?
In-Reply-To: <CA+gWKMB4wAnG0G95k6LrFsD_X+es5R6CsZ-W1eCC70+Sa5gXWA@mail.gmail.com>
References: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>
	<CADGJaX8Ej7J94ib1Ae6jWfwQfDHte7Cyet1Np-0+yU=wmHERMg@mail.gmail.com>
	<CAEqagpqdXeLBFpvDB7HEnhBUsOSv3RL1hbKu141k6BAPSBFzDA@mail.gmail.com>
	<CA+gWKMB4wAnG0G95k6LrFsD_X+es5R6CsZ-W1eCC70+Sa5gXWA@mail.gmail.com>
Message-ID: <CAFm4XO1MoZT+Cyp_1HZAEnWNeQh13NwBLh7dV9YxaNO7DwPbzA@mail.gmail.com>

On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
> Hi
>
> IMO no timezone conversion whatsoever should be applied when
> > persisting LocalDateTime as it doesn't contain any TZ information.
>
>
> That's not very easy to do since either the JDBC Driver or the database
> engine might to the timezone conversion based on the underlying setting.
>
> In fact I'd even recommend to use a string-based column type to store
> > LDT, as it avoids these kinds of issues altogether.

+1 I think we need to enforce that. Mapping a Java type which is
explicitly designed to be insensitive to TZ should not be stored into
a type which is sensitive to it. That would otherwise defeat the
purpose of using these specific types.

If people really want to convert stuff, that's business logic. So that
belong in the business layer: let them do explicit conversion in their
own code before invoking the setter of an entity, that will also help
to bring awareness on any conversion issue they might have.

>
>
> Actually, a Long (BigInt) column type with the epoch would be more suitable
> than a CHAR-based column since it's more compact and achieves the same goal.
> However, many clients will not want to store Date/Time in Int or String
> columns as explained in the following article:

-1

let's use Epoch based numerics for Java types which are based on
Epoch. e.g. java.time.Instant.

People can always transform a date into an epoch-independent number by
simply encoding it as a number;
e.g. "2018-10-31" -> 20181031 . I guess it could save you some bytes
but I'd be skeptical on doing this automatically.

>
> https://www.periscopedata.com/blog/better-sql-schema
>
> Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
> > that would also impact how we map timezone-less types, would be a good idea?
>
>
> We would have to introduce a new configuration property as a strategy where
> the current behavior is "legacy"
> while the new one must be explicitly enabled.
>
> Vlad
>
> On Fri, Oct 5, 2018 at 11:17 AM Yoann Rodiere <yoann at hibernate.org> wrote:
>
> > > In fact I'd even recommend to use a string-based column type to store
> > > LDT, as it avoids these kinds of issues altogether.
> >
> > Or just, you know, "timestamp without timezone". Where possible.
> >
> > More to the point, I agree with Vlad's proposition, and I also think ORM
> > should avoid messing with timezones as much as possible: when the user
> > didn't provide one (LocalDate, LocalDateTime, Date), don't store one, when
> > he provided one (ZonedDateTime, OffsetDateTime, Calendar, ...), store it
> > exactly as provided. The goal being to return the exact value that was
> > persisted when later retrieving the data.
> > But unfortunately I think there is a lot of legacy behaviors that differ
> > from this, so any attempt at "fixing" it would break compatibility and make
> > someone angry.
> >
> > Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
> > that would also impact how we map timezone-less types, would be a good idea?
> >
> >
> > Yoann Rodi?re
> > Hibernate NoORM Team
> > yoann at hibernate.org
> >
> >
> > On Fri, 5 Oct 2018 at 09:38, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> >> IMO no timezone conversion whatsoever should be applied when
> >> persisting LocalDateTime as it doesn't contain any TZ information.
> >>
> >> If the target column type requires a TZ, it should be set to UTC,
> >> storing the given value without any shift. I.e. the LDT value
> >> 2007-12-03T10:15:30 should be stored as 2007-12-03T10:15:30 at UTC, no
> >> matter what's the VM's timezone or any TZ related config. This allows
> >> to retrieve the original value later on, also if e.g. the loading VM
> >> is in a different TZ.
> >>
> >> In fact I'd even recommend to use a string-based column type to store
> >> LDT, as it avoids these kinds of issues altogether.
> >>
> >> --Gunnar
> >>
> >>
> >>
> >>
> >>
> >> Am Fr., 5. Okt. 2018 um 07:15 Uhr schrieb Vlad Mihalcea
> >> <mihalcea.vlad at gmail.com>:
> >> >
> >> > Hi,
> >> > While reviewing this Jira issue:
> >> >
> >> > https://hibernate.atlassian.net/browse/HHH-12988
> >> >
> >> > and further discussing it via Twitter, I wonder if we should persist
> >> > LocalTime as-is without any TimeZone transformation
> >> > that may be done if we enable `hibernate.jdbc.time_zone`?
> >> >
> >> > According to the Date/Time API, LocalTime should not be relative to any
> >> > TimeZone.
> >> >
> >> > If we make this change, it means we need to use a LocalTime SQL
> >> descriptor
> >> > that ignores the jdbc.time_zone property,
> >> > and the change is going to break compatibility as well.
> >> >
> >> > Vlad
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From andrea at hibernate.org  Fri Oct  5 05:45:48 2018
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 5 Oct 2018 10:45:48 +0100
Subject: [hibernate-dev] What should happen to queued operations when a
 collection is detached?
In-Reply-To: <CAFDzhiSgkEYV4ka9v584=tPcPJSbw45co53aunqDoELF4uEhXg@mail.gmail.com>
References: <CAFDzhiTShF65304wy5=0NThSUwA6u8kp8os99Exq1eCJVV_MtQ@mail.gmail.com>
	<CAFDzhiQEmgqUNsCrzfd07_kYVV-==KYvLwWWqS76atvEHUEFkg@mail.gmail.com>
	<CAFDzhiSgkEYV4ka9v584=tPcPJSbw45co53aunqDoELF4uEhXg@mail.gmail.com>
Message-ID: <CAL00eSQiy0_T5bnWFyssOEbG3NrEBy7kXgx0hmetqV1buooA+A@mail.gmail.com>

I would say to log a warning when the entity is detached and then clear the
queued operations.

On Fri, 5 Oct 2018 at 07:25, Gail Badner <gbadner at redhat.com> wrote:

>  Guillaume has reviewed my PR and I've pushed the fix to master.
>
> I still think the inconsistency should be resolved. I have no plans to do
> any more on this without any feedback.
>
> Regards,
> Gail
>
> On Tue, Oct 2, 2018 at 6:16 PM Gail Badner <gbadner at redhat.com> wrote:
>
> > Since I haven't heard anything back, I've gone ahead and updated my PR
> [1]
> > to ignore queued operations when merging a detached collection. This
> restores
> > the functionality that was in place prior to HHH-5855 (which caused
> > HHH-11209).
> >
> > In addition I've added warnings for the following situations:
> > * a detached collection is being merged that has queued operations;
> > * a collection with queued operations is attached to a session;
> > * a collection with queued operations is detached from a session.
> >
> > I've also added a test case that shows that Session#merge and
> > Session#saveOrUpdate have different results when called on an entity
> with a
> > collection with queued operations. When Session#merge is called, the
> queued
> > operations are ignored. When Session#saveOrUpdate is called, the queued
> > operations are executed on flush.
> >
> > I don't like this inconsistency, but I'm not sure what to do about it. I
> > don't think it's a good idea to have collections floating around with
> > queued operations. As far as the application knows, it is just an
> > uninitialized collection. I can see that the entity could find its way
> into
> > a new session, with surprising results.
> >
> > IIUC, an application probably shouldn't detach an entity with a
> collection
> > in this state (having queued operations), so I think it makes sense that
> a
> > warning be logged when this happens. On the other hand, the warning will
> > also be logged if a transaction involving updates to a collection with
> > queued operations fails.
> >
> > I would really appreciate some feedback on this, since HHH-11209 is a bad
> > regression that really should be fixed.
> >
> > Thanks,
> > Gail
> >
> > [1] https://github.com/hibernate/hibernate-orm/pull/2460
> >
> > On Fri, Sep 28, 2018 at 6:27 PM Gail Badner <gbadner at redhat.com> wrote:
> >
> >> HHH-11209 involves a bug merging a detached entity with an uninitialized
> >> collection that has queued operations.
> >>
> >> After looking into this issue I found a bug
> >> where AbstractPersistentCollection#operationQueue was not being cleared
> >> after a commit, if there was no cascade mapped for the collection.
> >>
> >> I've fixed that in a PR. [1]
> >>
> >> After that fix, the detached entity in the test case attached to
> >> HHH-11209 has an uninitialized entity without any queued operations
> after
> >> commit, which can be merged successfully in a new session/transaction.
> >>
> >> There is still a problem when Hibernate tries to merge a detached entity
> >> has an uninitialized collection with queued operations though. My PR
> throws
> >> UnsupportedOperationException in this case, and there is a test case
> that
> >> reproduces it.
> >>
> >> I've been working on a fix to add support for this, but I have my doubts
> >> that it really should be supported. I see that prior to fixing HHH-5855
> >> (which caused HHH-11209), Hibernate simply ignored the queued
> operations in
> >> the detached collection. [2].
> >>
> >> The fix for HHH-5855 properly dealt with merging a managed collection
> >> that was uninitialized with queued operations. It introduced the bug
> where
> >> a NullPointerException would get thrown if that collection  was
> detached.
> >>
> >> If we want to support merging the queued operations, then I would
> >> consider that an improvement. Would this be a worthwhile improvement?
> I'm
> >> guessing not, but I wanted to get some opinions.
> >>
> >> For now, I see a couple of ways to deal with this so that HHH-11209 can
> >> be wrapped up:
> >> 1) ignore queued operations in a detached collection when merging, as
> was
> >> done before HHH-5855 was fixed.
> >> 2) clear the queued operations when the collection is detached.
> >>
> >> Comments?
> >>
> >> Thanks,
> >> Gail
> >>
> >> [1] https://github.com/hibernate/hibernate-orm/pull/2460
> >> [2]
> >>
> https://github.com/hibernate/hibernate-orm/commit/c1934b72edb4f781520937618b3b750bebb84576#diff-2c7912a47063b9ea81323bf9c6628895L651
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Oct  5 07:28:03 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 5 Oct 2018 06:28:03 -0500
Subject: [hibernate-dev] Should the LocalTimeType use the globally
 configured TimeZone?
In-Reply-To: <CAFm4XO1MoZT+Cyp_1HZAEnWNeQh13NwBLh7dV9YxaNO7DwPbzA@mail.gmail.com>
References: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>
	<CADGJaX8Ej7J94ib1Ae6jWfwQfDHte7Cyet1Np-0+yU=wmHERMg@mail.gmail.com>
	<CAEqagpqdXeLBFpvDB7HEnhBUsOSv3RL1hbKu141k6BAPSBFzDA@mail.gmail.com>
	<CA+gWKMB4wAnG0G95k6LrFsD_X+es5R6CsZ-W1eCC70+Sa5gXWA@mail.gmail.com>
	<CAFm4XO1MoZT+Cyp_1HZAEnWNeQh13NwBLh7dV9YxaNO7DwPbzA@mail.gmail.com>
Message-ID: <CAFdSV9tHCw2TkzhgjbCJU18spaA8vqqBu0SSevbrzkitiDcCxA@mail.gmail.com>

Ah good, its time for this yearly discussion :D

The problem is as Vlad points out.  We are kind of forced to do *something*
wrt timezone to often times counteract what the JDBC driver will do.  As I
have always contended, imo that saving a date into the database with any
kind of timzone (other than UTC) is simply wrong.  I personally would never
do it - and I think we've seen enough of the down sides to doing it.  As
Sanne points out, storing epoch-based dates (Instant, etc) is always the
best option

One cool option would be an AttributeConverter that handles the timezone
transformation, combined with telling Hibernate to always use UTC for the
JDBC timezone


On Fri, Oct 5, 2018 at 4:44 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> >
> > Hi
> >
> > IMO no timezone conversion whatsoever should be applied when
> > > persisting LocalDateTime as it doesn't contain any TZ information.
> >
> >
> > That's not very easy to do since either the JDBC Driver or the database
> > engine might to the timezone conversion based on the underlying setting.
> >
> > In fact I'd even recommend to use a string-based column type to store
> > > LDT, as it avoids these kinds of issues altogether.
>
> +1 I think we need to enforce that. Mapping a Java type which is
> explicitly designed to be insensitive to TZ should not be stored into
> a type which is sensitive to it. That would otherwise defeat the
> purpose of using these specific types.
>
> If people really want to convert stuff, that's business logic. So that
> belong in the business layer: let them do explicit conversion in their
> own code before invoking the setter of an entity, that will also help
> to bring awareness on any conversion issue they might have.
>
> >
> >
> > Actually, a Long (BigInt) column type with the epoch would be more
> suitable
> > than a CHAR-based column since it's more compact and achieves the same
> goal.
> > However, many clients will not want to store Date/Time in Int or String
> > columns as explained in the following article:
>
> -1
>
> let's use Epoch based numerics for Java types which are based on
> Epoch. e.g. java.time.Instant.
>
> People can always transform a date into an epoch-independent number by
> simply encoding it as a number;
> e.g. "2018-10-31" -> 20181031 . I guess it could save you some bytes
> but I'd be skeptical on doing this automatically.
>
> >
> > https://www.periscopedata.com/blog/better-sql-schema
> >
> > Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
> > > that would also impact how we map timezone-less types, would be a good
> idea?
> >
> >
> > We would have to introduce a new configuration property as a strategy
> where
> > the current behavior is "legacy"
> > while the new one must be explicitly enabled.
> >
> > Vlad
> >
> > On Fri, Oct 5, 2018 at 11:17 AM Yoann Rodiere <yoann at hibernate.org>
> wrote:
> >
> > > > In fact I'd even recommend to use a string-based column type to store
> > > > LDT, as it avoids these kinds of issues altogether.
> > >
> > > Or just, you know, "timestamp without timezone". Where possible.
> > >
> > > More to the point, I agree with Vlad's proposition, and I also think
> ORM
> > > should avoid messing with timezones as much as possible: when the user
> > > didn't provide one (LocalDate, LocalDateTime, Date), don't store one,
> when
> > > he provided one (ZonedDateTime, OffsetDateTime, Calendar, ...), store
> it
> > > exactly as provided. The goal being to return the exact value that was
> > > persisted when later retrieving the data.
> > > But unfortunately I think there is a lot of legacy behaviors that
> differ
> > > from this, so any attempt at "fixing" it would break compatibility and
> make
> > > someone angry.
> > >
> > > Maybe introducing another value for "hibernate.jdbc.time_zone"
> ("as_is"?)
> > > that would also impact how we map timezone-less types, would be a good
> idea?
> > >
> > >
> > > Yoann Rodi?re
> > > Hibernate NoORM Team
> > > yoann at hibernate.org
> > >
> > >
> > > On Fri, 5 Oct 2018 at 09:38, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> > >
> > >> IMO no timezone conversion whatsoever should be applied when
> > >> persisting LocalDateTime as it doesn't contain any TZ information.
> > >>
> > >> If the target column type requires a TZ, it should be set to UTC,
> > >> storing the given value without any shift. I.e. the LDT value
> > >> 2007-12-03T10:15:30 should be stored as 2007-12-03T10:15:30 at UTC, no
> > >> matter what's the VM's timezone or any TZ related config. This allows
> > >> to retrieve the original value later on, also if e.g. the loading VM
> > >> is in a different TZ.
> > >>
> > >> In fact I'd even recommend to use a string-based column type to store
> > >> LDT, as it avoids these kinds of issues altogether.
> > >>
> > >> --Gunnar
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Am Fr., 5. Okt. 2018 um 07:15 Uhr schrieb Vlad Mihalcea
> > >> <mihalcea.vlad at gmail.com>:
> > >> >
> > >> > Hi,
> > >> > While reviewing this Jira issue:
> > >> >
> > >> > https://hibernate.atlassian.net/browse/HHH-12988
> > >> >
> > >> > and further discussing it via Twitter, I wonder if we should persist
> > >> > LocalTime as-is without any TimeZone transformation
> > >> > that may be done if we enable `hibernate.jdbc.time_zone`?
> > >> >
> > >> > According to the Date/Time API, LocalTime should not be relative to
> any
> > >> > TimeZone.
> > >> >
> > >> > If we make this change, it means we need to use a LocalTime SQL
> > >> descriptor
> > >> > that ignores the jdbc.time_zone property,
> > >> > and the change is going to break compatibility as well.
> > >> >
> > >> > Vlad
> > >> > _______________________________________________
> > >> > hibernate-dev mailing list
> > >> > hibernate-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri Oct  5 08:29:59 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 5 Oct 2018 13:29:59 +0100
Subject: [hibernate-dev] Should the LocalTimeType use the globally
 configured TimeZone?
In-Reply-To: <CAFdSV9tHCw2TkzhgjbCJU18spaA8vqqBu0SSevbrzkitiDcCxA@mail.gmail.com>
References: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>
	<CADGJaX8Ej7J94ib1Ae6jWfwQfDHte7Cyet1Np-0+yU=wmHERMg@mail.gmail.com>
	<CAEqagpqdXeLBFpvDB7HEnhBUsOSv3RL1hbKu141k6BAPSBFzDA@mail.gmail.com>
	<CA+gWKMB4wAnG0G95k6LrFsD_X+es5R6CsZ-W1eCC70+Sa5gXWA@mail.gmail.com>
	<CAFm4XO1MoZT+Cyp_1HZAEnWNeQh13NwBLh7dV9YxaNO7DwPbzA@mail.gmail.com>
	<CAFdSV9tHCw2TkzhgjbCJU18spaA8vqqBu0SSevbrzkitiDcCxA@mail.gmail.com>
Message-ID: <CAFm4XO0VH9rw1EiXPbuO6N=1ywkHzqmOG-XYvak6igDZzgJ=qQ@mail.gmail.com>

On Fri, 5 Oct 2018 at 12:47, Steve Ebersole <steve at hibernate.org> wrote:
>
> Ah good, its time for this yearly discussion :D

Lol :)

but don't we have better options now with the new Date/Time API?

The old "Date" certainly was ambiguous in this regard, as one had a
single business type which could be occasionally used as a universal
timestamp, occasionally as a local political/human meaning; with Date
it was up to us to try hard to do the "right thing", and it was hard.

With the new types I would expect that we can guide people by not
allowing mixed mappings; so the epoch based Instant gets mapped to
whatever the specific database has to map epoch based timestamps,
while the political types would not.

I would simply expect that we would disallow conversions between the
two - at least unless there's a very explicit request to break sanity
rules - but I'd rather have it sane by default so to encourage people
to use the right Java types for their specific needs.

Thanks,
Sanne

>
> The problem is as Vlad points out.  We are kind of forced to do *something* wrt timezone to often times counteract what the JDBC driver will do.  As I have always contended, imo that saving a date into the database with any kind of timzone (other than UTC) is simply wrong.  I personally would never do it - and I think we've seen enough of the down sides to doing it.  As Sanne points out, storing epoch-based dates (Instant, etc) is always the best option
>
> One cool option would be an AttributeConverter that handles the timezone transformation, combined with telling Hibernate to always use UTC for the JDBC timezone
>
>
> On Fri, Oct 5, 2018 at 4:44 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>> >
>> > Hi
>> >
>> > IMO no timezone conversion whatsoever should be applied when
>> > > persisting LocalDateTime as it doesn't contain any TZ information.
>> >
>> >
>> > That's not very easy to do since either the JDBC Driver or the database
>> > engine might to the timezone conversion based on the underlying setting.
>> >
>> > In fact I'd even recommend to use a string-based column type to store
>> > > LDT, as it avoids these kinds of issues altogether.
>>
>> +1 I think we need to enforce that. Mapping a Java type which is
>> explicitly designed to be insensitive to TZ should not be stored into
>> a type which is sensitive to it. That would otherwise defeat the
>> purpose of using these specific types.
>>
>> If people really want to convert stuff, that's business logic. So that
>> belong in the business layer: let them do explicit conversion in their
>> own code before invoking the setter of an entity, that will also help
>> to bring awareness on any conversion issue they might have.
>>
>> >
>> >
>> > Actually, a Long (BigInt) column type with the epoch would be more suitable
>> > than a CHAR-based column since it's more compact and achieves the same goal.
>> > However, many clients will not want to store Date/Time in Int or String
>> > columns as explained in the following article:
>>
>> -1
>>
>> let's use Epoch based numerics for Java types which are based on
>> Epoch. e.g. java.time.Instant.
>>
>> People can always transform a date into an epoch-independent number by
>> simply encoding it as a number;
>> e.g. "2018-10-31" -> 20181031 . I guess it could save you some bytes
>> but I'd be skeptical on doing this automatically.
>>
>> >
>> > https://www.periscopedata.com/blog/better-sql-schema
>> >
>> > Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
>> > > that would also impact how we map timezone-less types, would be a good idea?
>> >
>> >
>> > We would have to introduce a new configuration property as a strategy where
>> > the current behavior is "legacy"
>> > while the new one must be explicitly enabled.
>> >
>> > Vlad
>> >
>> > On Fri, Oct 5, 2018 at 11:17 AM Yoann Rodiere <yoann at hibernate.org> wrote:
>> >
>> > > > In fact I'd even recommend to use a string-based column type to store
>> > > > LDT, as it avoids these kinds of issues altogether.
>> > >
>> > > Or just, you know, "timestamp without timezone". Where possible.
>> > >
>> > > More to the point, I agree with Vlad's proposition, and I also think ORM
>> > > should avoid messing with timezones as much as possible: when the user
>> > > didn't provide one (LocalDate, LocalDateTime, Date), don't store one, when
>> > > he provided one (ZonedDateTime, OffsetDateTime, Calendar, ...), store it
>> > > exactly as provided. The goal being to return the exact value that was
>> > > persisted when later retrieving the data.
>> > > But unfortunately I think there is a lot of legacy behaviors that differ
>> > > from this, so any attempt at "fixing" it would break compatibility and make
>> > > someone angry.
>> > >
>> > > Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
>> > > that would also impact how we map timezone-less types, would be a good idea?
>> > >
>> > >
>> > > Yoann Rodi?re
>> > > Hibernate NoORM Team
>> > > yoann at hibernate.org
>> > >
>> > >
>> > > On Fri, 5 Oct 2018 at 09:38, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > >
>> > >> IMO no timezone conversion whatsoever should be applied when
>> > >> persisting LocalDateTime as it doesn't contain any TZ information.
>> > >>
>> > >> If the target column type requires a TZ, it should be set to UTC,
>> > >> storing the given value without any shift. I.e. the LDT value
>> > >> 2007-12-03T10:15:30 should be stored as 2007-12-03T10:15:30 at UTC, no
>> > >> matter what's the VM's timezone or any TZ related config. This allows
>> > >> to retrieve the original value later on, also if e.g. the loading VM
>> > >> is in a different TZ.
>> > >>
>> > >> In fact I'd even recommend to use a string-based column type to store
>> > >> LDT, as it avoids these kinds of issues altogether.
>> > >>
>> > >> --Gunnar
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> Am Fr., 5. Okt. 2018 um 07:15 Uhr schrieb Vlad Mihalcea
>> > >> <mihalcea.vlad at gmail.com>:
>> > >> >
>> > >> > Hi,
>> > >> > While reviewing this Jira issue:
>> > >> >
>> > >> > https://hibernate.atlassian.net/browse/HHH-12988
>> > >> >
>> > >> > and further discussing it via Twitter, I wonder if we should persist
>> > >> > LocalTime as-is without any TimeZone transformation
>> > >> > that may be done if we enable `hibernate.jdbc.time_zone`?
>> > >> >
>> > >> > According to the Date/Time API, LocalTime should not be relative to any
>> > >> > TimeZone.
>> > >> >
>> > >> > If we make this change, it means we need to use a LocalTime SQL
>> > >> descriptor
>> > >> > that ignores the jdbc.time_zone property,
>> > >> > and the change is going to break compatibility as well.
>> > >> >
>> > >> > Vlad
>> > >> > _______________________________________________
>> > >> > hibernate-dev mailing list
>> > >> > hibernate-dev at lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> _______________________________________________
>> > >> hibernate-dev mailing list
>> > >> hibernate-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>
>> > >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From mihalcea.vlad at gmail.com  Fri Oct  5 09:40:00 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 5 Oct 2018 16:40:00 +0300
Subject: [hibernate-dev] Should the LocalTimeType use the globally
 configured TimeZone?
In-Reply-To: <CAFdSV9tHCw2TkzhgjbCJU18spaA8vqqBu0SSevbrzkitiDcCxA@mail.gmail.com>
References: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>
	<CADGJaX8Ej7J94ib1Ae6jWfwQfDHte7Cyet1Np-0+yU=wmHERMg@mail.gmail.com>
	<CAEqagpqdXeLBFpvDB7HEnhBUsOSv3RL1hbKu141k6BAPSBFzDA@mail.gmail.com>
	<CA+gWKMB4wAnG0G95k6LrFsD_X+es5R6CsZ-W1eCC70+Sa5gXWA@mail.gmail.com>
	<CAFm4XO1MoZT+Cyp_1HZAEnWNeQh13NwBLh7dV9YxaNO7DwPbzA@mail.gmail.com>
	<CAFdSV9tHCw2TkzhgjbCJU18spaA8vqqBu0SSevbrzkitiDcCxA@mail.gmail.com>
Message-ID: <CA+gWKMCGhS3dSZud-E5Zv0MurSTxiw6v=QEQctYr7m8x8sRSUQ@mail.gmail.com>

Hi,

My question was more about LocalTime, which is much more straightforward to
address than LocalDateTime in the context of time zones.

For DateTime types which support timezones, I'll have to study to see what
other non-breaking alternatives we may have.

Vlad

On Fri, Oct 5, 2018 at 2:28 PM Steve Ebersole <steve at hibernate.org> wrote:

> Ah good, its time for this yearly discussion :D
>
> The problem is as Vlad points out.  We are kind of forced to do
> *something* wrt timezone to often times counteract what the JDBC driver
> will do.  As I have always contended, imo that saving a date into the
> database with any kind of timzone (other than UTC) is simply wrong.  I
> personally would never do it - and I think we've seen enough of the down
> sides to doing it.  As Sanne points out, storing epoch-based dates
> (Instant, etc) is always the best option
>
> One cool option would be an AttributeConverter that handles the timezone
> transformation, combined with telling Hibernate to always use UTC for the
> JDBC timezone
>
>
> On Fri, Oct 5, 2018 at 4:44 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>> >
>> > Hi
>> >
>> > IMO no timezone conversion whatsoever should be applied when
>> > > persisting LocalDateTime as it doesn't contain any TZ information.
>> >
>> >
>> > That's not very easy to do since either the JDBC Driver or the database
>> > engine might to the timezone conversion based on the underlying setting.
>> >
>> > In fact I'd even recommend to use a string-based column type to store
>> > > LDT, as it avoids these kinds of issues altogether.
>>
>> +1 I think we need to enforce that. Mapping a Java type which is
>> explicitly designed to be insensitive to TZ should not be stored into
>> a type which is sensitive to it. That would otherwise defeat the
>> purpose of using these specific types.
>>
>> If people really want to convert stuff, that's business logic. So that
>> belong in the business layer: let them do explicit conversion in their
>> own code before invoking the setter of an entity, that will also help
>> to bring awareness on any conversion issue they might have.
>>
>> >
>> >
>> > Actually, a Long (BigInt) column type with the epoch would be more
>> suitable
>> > than a CHAR-based column since it's more compact and achieves the same
>> goal.
>> > However, many clients will not want to store Date/Time in Int or String
>> > columns as explained in the following article:
>>
>> -1
>>
>> let's use Epoch based numerics for Java types which are based on
>> Epoch. e.g. java.time.Instant.
>>
>> People can always transform a date into an epoch-independent number by
>> simply encoding it as a number;
>> e.g. "2018-10-31" -> 20181031 . I guess it could save you some bytes
>> but I'd be skeptical on doing this automatically.
>>
>> >
>> > https://www.periscopedata.com/blog/better-sql-schema
>> >
>> > Maybe introducing another value for "hibernate.jdbc.time_zone"
>> ("as_is"?)
>> > > that would also impact how we map timezone-less types, would be a
>> good idea?
>> >
>> >
>> > We would have to introduce a new configuration property as a strategy
>> where
>> > the current behavior is "legacy"
>> > while the new one must be explicitly enabled.
>> >
>> > Vlad
>> >
>> > On Fri, Oct 5, 2018 at 11:17 AM Yoann Rodiere <yoann at hibernate.org>
>> wrote:
>> >
>> > > > In fact I'd even recommend to use a string-based column type to
>> store
>> > > > LDT, as it avoids these kinds of issues altogether.
>> > >
>> > > Or just, you know, "timestamp without timezone". Where possible.
>> > >
>> > > More to the point, I agree with Vlad's proposition, and I also think
>> ORM
>> > > should avoid messing with timezones as much as possible: when the user
>> > > didn't provide one (LocalDate, LocalDateTime, Date), don't store one,
>> when
>> > > he provided one (ZonedDateTime, OffsetDateTime, Calendar, ...), store
>> it
>> > > exactly as provided. The goal being to return the exact value that was
>> > > persisted when later retrieving the data.
>> > > But unfortunately I think there is a lot of legacy behaviors that
>> differ
>> > > from this, so any attempt at "fixing" it would break compatibility
>> and make
>> > > someone angry.
>> > >
>> > > Maybe introducing another value for "hibernate.jdbc.time_zone"
>> ("as_is"?)
>> > > that would also impact how we map timezone-less types, would be a
>> good idea?
>> > >
>> > >
>> > > Yoann Rodi?re
>> > > Hibernate NoORM Team
>> > > yoann at hibernate.org
>> > >
>> > >
>> > > On Fri, 5 Oct 2018 at 09:38, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> > >
>> > >> IMO no timezone conversion whatsoever should be applied when
>> > >> persisting LocalDateTime as it doesn't contain any TZ information.
>> > >>
>> > >> If the target column type requires a TZ, it should be set to UTC,
>> > >> storing the given value without any shift. I.e. the LDT value
>> > >> 2007-12-03T10:15:30 should be stored as 2007-12-03T10:15:30 at UTC, no
>> > >> matter what's the VM's timezone or any TZ related config. This allows
>> > >> to retrieve the original value later on, also if e.g. the loading VM
>> > >> is in a different TZ.
>> > >>
>> > >> In fact I'd even recommend to use a string-based column type to store
>> > >> LDT, as it avoids these kinds of issues altogether.
>> > >>
>> > >> --Gunnar
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> Am Fr., 5. Okt. 2018 um 07:15 Uhr schrieb Vlad Mihalcea
>> > >> <mihalcea.vlad at gmail.com>:
>> > >> >
>> > >> > Hi,
>> > >> > While reviewing this Jira issue:
>> > >> >
>> > >> > https://hibernate.atlassian.net/browse/HHH-12988
>> > >> >
>> > >> > and further discussing it via Twitter, I wonder if we should
>> persist
>> > >> > LocalTime as-is without any TimeZone transformation
>> > >> > that may be done if we enable `hibernate.jdbc.time_zone`?
>> > >> >
>> > >> > According to the Date/Time API, LocalTime should not be relative
>> to any
>> > >> > TimeZone.
>> > >> >
>> > >> > If we make this change, it means we need to use a LocalTime SQL
>> > >> descriptor
>> > >> > that ignores the jdbc.time_zone property,
>> > >> > and the change is going to break compatibility as well.
>> > >> >
>> > >> > Vlad
>> > >> > _______________________________________________
>> > >> > hibernate-dev mailing list
>> > >> > hibernate-dev at lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> _______________________________________________
>> > >> hibernate-dev mailing list
>> > >> hibernate-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>
>> > >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From sanne at hibernate.org  Fri Oct  5 10:06:59 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 5 Oct 2018 15:06:59 +0100
Subject: [hibernate-dev] Should the LocalTimeType use the globally
 configured TimeZone?
In-Reply-To: <CA+gWKMCGhS3dSZud-E5Zv0MurSTxiw6v=QEQctYr7m8x8sRSUQ@mail.gmail.com>
References: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>
	<CADGJaX8Ej7J94ib1Ae6jWfwQfDHte7Cyet1Np-0+yU=wmHERMg@mail.gmail.com>
	<CAEqagpqdXeLBFpvDB7HEnhBUsOSv3RL1hbKu141k6BAPSBFzDA@mail.gmail.com>
	<CA+gWKMB4wAnG0G95k6LrFsD_X+es5R6CsZ-W1eCC70+Sa5gXWA@mail.gmail.com>
	<CAFm4XO1MoZT+Cyp_1HZAEnWNeQh13NwBLh7dV9YxaNO7DwPbzA@mail.gmail.com>
	<CAFdSV9tHCw2TkzhgjbCJU18spaA8vqqBu0SSevbrzkitiDcCxA@mail.gmail.com>
	<CA+gWKMCGhS3dSZud-E5Zv0MurSTxiw6v=QEQctYr7m8x8sRSUQ@mail.gmail.com>
Message-ID: <CAFm4XO0mSD082C-jfMrVxAQLaiV9jrCBt-qenLfPaw20WW5GqQ@mail.gmail.com>

On Fri, 5 Oct 2018 at 14:40, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
> Hi,
>
> My question was more about LocalTime, which is much more straightforward to address than LocalDateTime in the context of time zones.

Ok so specifically discussing LocalTime.

If you *really must* store a LocalTime as an absolute timestamp then
using the "time_zone" configuration property sounds indeed like a
better than not ignoring it.

Yet my opinion - and what I believe many others here shared - is that
LocalTime should not be map to such a SQL type; it should map to a
different suitable type to represent "a description of the local time
as seen on a wall clock" (quoting the LocalTime javadoc), e.g. on
MySQL and PostgreSQL we map to TIME, not TIMESTAMP.

>
> For DateTime types which support timezones, I'll have to study to see what other non-breaking alternatives we may have.
>
> Vlad
>
> On Fri, Oct 5, 2018 at 2:28 PM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> Ah good, its time for this yearly discussion :D
>>
>> The problem is as Vlad points out.  We are kind of forced to do *something* wrt timezone to often times counteract what the JDBC driver will do.  As I have always contended, imo that saving a date into the database with any kind of timzone (other than UTC) is simply wrong.  I personally would never do it - and I think we've seen enough of the down sides to doing it.  As Sanne points out, storing epoch-based dates (Instant, etc) is always the best option
>>
>> One cool option would be an AttributeConverter that handles the timezone transformation, combined with telling Hibernate to always use UTC for the JDBC timezone
>>
>>
>> On Fri, Oct 5, 2018 at 4:44 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>>
>>> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>>> >
>>> > Hi
>>> >
>>> > IMO no timezone conversion whatsoever should be applied when
>>> > > persisting LocalDateTime as it doesn't contain any TZ information.
>>> >
>>> >
>>> > That's not very easy to do since either the JDBC Driver or the database
>>> > engine might to the timezone conversion based on the underlying setting.
>>> >
>>> > In fact I'd even recommend to use a string-based column type to store
>>> > > LDT, as it avoids these kinds of issues altogether.
>>>
>>> +1 I think we need to enforce that. Mapping a Java type which is
>>> explicitly designed to be insensitive to TZ should not be stored into
>>> a type which is sensitive to it. That would otherwise defeat the
>>> purpose of using these specific types.
>>>
>>> If people really want to convert stuff, that's business logic. So that
>>> belong in the business layer: let them do explicit conversion in their
>>> own code before invoking the setter of an entity, that will also help
>>> to bring awareness on any conversion issue they might have.
>>>
>>> >
>>> >
>>> > Actually, a Long (BigInt) column type with the epoch would be more suitable
>>> > than a CHAR-based column since it's more compact and achieves the same goal.
>>> > However, many clients will not want to store Date/Time in Int or String
>>> > columns as explained in the following article:
>>>
>>> -1
>>>
>>> let's use Epoch based numerics for Java types which are based on
>>> Epoch. e.g. java.time.Instant.
>>>
>>> People can always transform a date into an epoch-independent number by
>>> simply encoding it as a number;
>>> e.g. "2018-10-31" -> 20181031 . I guess it could save you some bytes
>>> but I'd be skeptical on doing this automatically.
>>>
>>> >
>>> > https://www.periscopedata.com/blog/better-sql-schema
>>> >
>>> > Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
>>> > > that would also impact how we map timezone-less types, would be a good idea?
>>> >
>>> >
>>> > We would have to introduce a new configuration property as a strategy where
>>> > the current behavior is "legacy"
>>> > while the new one must be explicitly enabled.
>>> >
>>> > Vlad
>>> >
>>> > On Fri, Oct 5, 2018 at 11:17 AM Yoann Rodiere <yoann at hibernate.org> wrote:
>>> >
>>> > > > In fact I'd even recommend to use a string-based column type to store
>>> > > > LDT, as it avoids these kinds of issues altogether.
>>> > >
>>> > > Or just, you know, "timestamp without timezone". Where possible.
>>> > >
>>> > > More to the point, I agree with Vlad's proposition, and I also think ORM
>>> > > should avoid messing with timezones as much as possible: when the user
>>> > > didn't provide one (LocalDate, LocalDateTime, Date), don't store one, when
>>> > > he provided one (ZonedDateTime, OffsetDateTime, Calendar, ...), store it
>>> > > exactly as provided. The goal being to return the exact value that was
>>> > > persisted when later retrieving the data.
>>> > > But unfortunately I think there is a lot of legacy behaviors that differ
>>> > > from this, so any attempt at "fixing" it would break compatibility and make
>>> > > someone angry.
>>> > >
>>> > > Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
>>> > > that would also impact how we map timezone-less types, would be a good idea?
>>> > >
>>> > >
>>> > > Yoann Rodi?re
>>> > > Hibernate NoORM Team
>>> > > yoann at hibernate.org
>>> > >
>>> > >
>>> > > On Fri, 5 Oct 2018 at 09:38, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> > >
>>> > >> IMO no timezone conversion whatsoever should be applied when
>>> > >> persisting LocalDateTime as it doesn't contain any TZ information.
>>> > >>
>>> > >> If the target column type requires a TZ, it should be set to UTC,
>>> > >> storing the given value without any shift. I.e. the LDT value
>>> > >> 2007-12-03T10:15:30 should be stored as 2007-12-03T10:15:30 at UTC, no
>>> > >> matter what's the VM's timezone or any TZ related config. This allows
>>> > >> to retrieve the original value later on, also if e.g. the loading VM
>>> > >> is in a different TZ.
>>> > >>
>>> > >> In fact I'd even recommend to use a string-based column type to store
>>> > >> LDT, as it avoids these kinds of issues altogether.
>>> > >>
>>> > >> --Gunnar
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >> Am Fr., 5. Okt. 2018 um 07:15 Uhr schrieb Vlad Mihalcea
>>> > >> <mihalcea.vlad at gmail.com>:
>>> > >> >
>>> > >> > Hi,
>>> > >> > While reviewing this Jira issue:
>>> > >> >
>>> > >> > https://hibernate.atlassian.net/browse/HHH-12988
>>> > >> >
>>> > >> > and further discussing it via Twitter, I wonder if we should persist
>>> > >> > LocalTime as-is without any TimeZone transformation
>>> > >> > that may be done if we enable `hibernate.jdbc.time_zone`?
>>> > >> >
>>> > >> > According to the Date/Time API, LocalTime should not be relative to any
>>> > >> > TimeZone.
>>> > >> >
>>> > >> > If we make this change, it means we need to use a LocalTime SQL
>>> > >> descriptor
>>> > >> > that ignores the jdbc.time_zone property,
>>> > >> > and the change is going to break compatibility as well.
>>> > >> >
>>> > >> > Vlad
>>> > >> > _______________________________________________
>>> > >> > hibernate-dev mailing list
>>> > >> > hibernate-dev at lists.jboss.org
>>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >> _______________________________________________
>>> > >> hibernate-dev mailing list
>>> > >> hibernate-dev at lists.jboss.org
>>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >>
>>> > >
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From mark at lawinegevaar.nl  Fri Oct  5 12:19:51 2018
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Fri, 5 Oct 2018 18:19:51 +0200
Subject: [hibernate-dev] Should the LocalTimeType use the globally
 configured TimeZone?
In-Reply-To: <CA+gWKMCGhS3dSZud-E5Zv0MurSTxiw6v=QEQctYr7m8x8sRSUQ@mail.gmail.com>
References: <CA+gWKMCSkUtw81wwRgcfV+jxG7=BmhUmb1eF2dbBuemnvxidjQ@mail.gmail.com>
	<CADGJaX8Ej7J94ib1Ae6jWfwQfDHte7Cyet1Np-0+yU=wmHERMg@mail.gmail.com>
	<CAEqagpqdXeLBFpvDB7HEnhBUsOSv3RL1hbKu141k6BAPSBFzDA@mail.gmail.com>
	<CA+gWKMB4wAnG0G95k6LrFsD_X+es5R6CsZ-W1eCC70+Sa5gXWA@mail.gmail.com>
	<CAFm4XO1MoZT+Cyp_1HZAEnWNeQh13NwBLh7dV9YxaNO7DwPbzA@mail.gmail.com>
	<CAFdSV9tHCw2TkzhgjbCJU18spaA8vqqBu0SSevbrzkitiDcCxA@mail.gmail.com>
	<CA+gWKMCGhS3dSZud-E5Zv0MurSTxiw6v=QEQctYr7m8x8sRSUQ@mail.gmail.com>
Message-ID: <6b48c975-08ba-698e-58f0-1e58249ee064@lawinegevaar.nl>

On 5-10-2018 15:40, Vlad Mihalcea wrote:
> Hi,
> 
> My question was more about LocalTime, which is much more straightforward to
> address than LocalDateTime in the context of time zones.
> 
> For DateTime types which support timezones, I'll have to study to see what
> other non-breaking alternatives we may have.

The JDBC expectation for use of LocalDate, LocalTime and LocalDateTime 
is that the time/date/datetime is stored **as is** in a DATE, TIME 
(without time zone), or TIMESTAMP (without time zone). So, no mangling 
of time zones.

Supporting the LocalTime/LocalDateTime types for a 'WITH TIMEZONE' type 
(java.sql.Types.TIME_WITH_TIMEZONE and 
java.sql.Types.TIMESTAMP_WITH_TIMEZONE) is not specified in the JDBC 
specification (see table B-4 in JDBC 4.3), it might make sense to map to 
OffsetTime / OffsetDateTime in those cases instead.

That does leaves us in the same place though: which time zone to choose 
for converting a LocalTime/LocalDateTime.

Similarly, a OffsetTime/OffsetDateTime is not specified to be supported 
for a TIME/TIMESTAMP (without timezone), which might necessitate a 
conversion to its LocalXXX equivalent (which, again implies a choice of 
time zone).

Mark
-- 
Mark Rotteveel

From yoann at hibernate.org  Fri Oct  5 12:56:07 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 5 Oct 2018 18:56:07 +0200
Subject: [hibernate-dev] Legacy Jenkins API tokens
Message-ID: <CAEqagpqFNp_QH=mwDZd1DRnRLH-WZ265WDL6y5pKTdKFm3amTA@mail.gmail.com>

Hello,

FYI, I just revoked all the legacy Jenkins API tokens, as recommended.
Don't worry, I'm talking about tokens issued by Jenkins to each user and
allowing to use Jenkins APIs; this is completely unrelated to GitHub/AWS
credentials and such.

More information: https://jenkins.io/blog/2018/07/02/new-api-token-system/

Apparently the tokens weren't being used by anyone, or at least haven't
been for a few weeks. But if you did need it, I guess you can always follow
the link above to find out how to use a new token.

Cheers,

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

From gbadner at redhat.com  Fri Oct  5 14:16:59 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 5 Oct 2018 11:16:59 -0700
Subject: [hibernate-dev] *-to-one associations and @NotFound
In-Reply-To: <CAFDzhiTDGbgCgnuC_HB77mBmjcoqHhk2+uQeXiqX=uXqwDH8eg@mail.gmail.com>
References: <CAFDzhiTDGbgCgnuC_HB77mBmjcoqHhk2+uQeXiqX=uXqwDH8eg@mail.gmail.com>
Message-ID: <CAFDzhiTvKHUJ6cJtxZtz6is_KdMjwQG4-1RE+HGJ7GUSYHV6SQ@mail.gmail.com>

After discussions with Stephen Fikes and Guillaume, I've added resolutions
to the document.

In a nutshell, here is what we decided.

1) Ccombination of @NotFound(IGNORE) and non-optional
one-to-one/many-to-one will throw MappingException.

2) Combination of @NotFound(IGNORE) and "mappedBy" one-to-one/many-to-one
will log a WARN message that @NotFound(IGNORE) will be ignored and should
be removed.

3) When a non-lazy association's join column is non-null and there is no
associated entity with the referenced column:

   - log an INFO message with the exception in an INFO message with
   ObjectNotFoundException including the entity name and referenced column and
   value that was not found; (we decided to continue logging as INFO because
   this condition can only happen if there is no foreign key; so in a sense,
   the application "knows" this condition is possible)
   - in the log message, if possible, include the association owner entity
   and its ID; this will make it easier to clean up the inconsistency in the
   database;
   - return a non-null entity with a null association.

Regards,
Gail

On Mon, Sep 24, 2018 at 4:03 PM Gail Badner <gbadner at redhat.com> wrote:

> As a result of fixing HHH-12436
> <https://hibernate.atlassian.net/browse/HHH-12436>, some eager *-to-one
> associations that were loaded using FetchMode.JOIN may instead be loaded
> using FetchMode.SELECT, and vice-versa. In some cases, @NotFound behavior
> is different depending on the FetchMode for the association.
>
>
> The reason why FetchMode may change due to HHH-12436
> <https://hibernate.atlassian.net/browse/HHH-12436> is that the
> ForeignKeyDirection of some *-to-one associations were incorrect.
> Correcting the ForeignKeyDirection will result in a different
> AssociationKey, which may ultimately affect the FetchMode Hibernate assigns
> to an association.
>
>
> My hope is to resolve the inconsistencies before fixing HHH-12436
> <https://hibernate.atlassian.net/browse/HHH-12436>, so it does not result
> in a change in application behavior.
>
>
> I've created a Google Doc to document the inconsistencies and to make it
> easier to discuss how to go about resolving them:
>
>
> https://docs.google.com/document/d/1o3Q6tYD5jjxC6Ok7vBYzxRGsixpG46p-5zDiDCAKLsI/
>
>
> Please feel free to request access to the document if you wish to review
> or add comments.
>
>
> Regards,
>
> Gail
>
>

From gbadner at redhat.com  Fri Oct  5 14:33:43 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 5 Oct 2018 11:33:43 -0700
Subject: [hibernate-dev] What should happen to queued operations when a
 collection is detached?
In-Reply-To: <CAL00eSQiy0_T5bnWFyssOEbG3NrEBy7kXgx0hmetqV1buooA+A@mail.gmail.com>
References: <CAFDzhiTShF65304wy5=0NThSUwA6u8kp8os99Exq1eCJVV_MtQ@mail.gmail.com>
	<CAFDzhiQEmgqUNsCrzfd07_kYVV-==KYvLwWWqS76atvEHUEFkg@mail.gmail.com>
	<CAFDzhiSgkEYV4ka9v584=tPcPJSbw45co53aunqDoELF4uEhXg@mail.gmail.com>
	<CAL00eSQiy0_T5bnWFyssOEbG3NrEBy7kXgx0hmetqV1buooA+A@mail.gmail.com>
Message-ID: <CAFDzhiTLSRWgb8CY1RzCYtLFtrdo6GJvMH08K4CCRBtKw-Ccbg@mail.gmail.com>

Before doing this, I'd like to get some feedback about these warnings
cropping up, just in case there is a valid use case that we're missing.

On Fri, Oct 5, 2018 at 2:46 AM andrea boriero <andrea at hibernate.org> wrote:

> I would say to log a warning when the entity is detached and then clear
> the queued operations.
>
> On Fri, 5 Oct 2018 at 07:25, Gail Badner <gbadner at redhat.com> wrote:
>
>>  Guillaume has reviewed my PR and I've pushed the fix to master.
>>
>> I still think the inconsistency should be resolved. I have no plans to do
>> any more on this without any feedback.
>>
>> Regards,
>> Gail
>>
>> On Tue, Oct 2, 2018 at 6:16 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>> > Since I haven't heard anything back, I've gone ahead and updated my PR
>> [1]
>> > to ignore queued operations when merging a detached collection. This
>> restores
>> > the functionality that was in place prior to HHH-5855 (which caused
>> > HHH-11209).
>> >
>> > In addition I've added warnings for the following situations:
>> > * a detached collection is being merged that has queued operations;
>> > * a collection with queued operations is attached to a session;
>> > * a collection with queued operations is detached from a session.
>> >
>> > I've also added a test case that shows that Session#merge and
>> > Session#saveOrUpdate have different results when called on an entity
>> with a
>> > collection with queued operations. When Session#merge is called, the
>> queued
>> > operations are ignored. When Session#saveOrUpdate is called, the queued
>> > operations are executed on flush.
>> >
>> > I don't like this inconsistency, but I'm not sure what to do about it. I
>> > don't think it's a good idea to have collections floating around with
>> > queued operations. As far as the application knows, it is just an
>> > uninitialized collection. I can see that the entity could find its way
>> into
>> > a new session, with surprising results.
>> >
>> > IIUC, an application probably shouldn't detach an entity with a
>> collection
>> > in this state (having queued operations), so I think it makes sense
>> that a
>> > warning be logged when this happens. On the other hand, the warning will
>> > also be logged if a transaction involving updates to a collection with
>> > queued operations fails.
>> >
>> > I would really appreciate some feedback on this, since HHH-11209 is a
>> bad
>> > regression that really should be fixed.
>> >
>> > Thanks,
>> > Gail
>> >
>> > [1] https://github.com/hibernate/hibernate-orm/pull/2460
>> >
>> > On Fri, Sep 28, 2018 at 6:27 PM Gail Badner <gbadner at redhat.com> wrote:
>> >
>> >> HHH-11209 involves a bug merging a detached entity with an
>> uninitialized
>> >> collection that has queued operations.
>> >>
>> >> After looking into this issue I found a bug
>> >> where AbstractPersistentCollection#operationQueue was not being cleared
>> >> after a commit, if there was no cascade mapped for the collection.
>> >>
>> >> I've fixed that in a PR. [1]
>> >>
>> >> After that fix, the detached entity in the test case attached to
>> >> HHH-11209 has an uninitialized entity without any queued operations
>> after
>> >> commit, which can be merged successfully in a new session/transaction.
>> >>
>> >> There is still a problem when Hibernate tries to merge a detached
>> entity
>> >> has an uninitialized collection with queued operations though. My PR
>> throws
>> >> UnsupportedOperationException in this case, and there is a test case
>> that
>> >> reproduces it.
>> >>
>> >> I've been working on a fix to add support for this, but I have my
>> doubts
>> >> that it really should be supported. I see that prior to fixing HHH-5855
>> >> (which caused HHH-11209), Hibernate simply ignored the queued
>> operations in
>> >> the detached collection. [2].
>> >>
>> >> The fix for HHH-5855 properly dealt with merging a managed collection
>> >> that was uninitialized with queued operations. It introduced the bug
>> where
>> >> a NullPointerException would get thrown if that collection  was
>> detached.
>> >>
>> >> If we want to support merging the queued operations, then I would
>> >> consider that an improvement. Would this be a worthwhile improvement?
>> I'm
>> >> guessing not, but I wanted to get some opinions.
>> >>
>> >> For now, I see a couple of ways to deal with this so that HHH-11209 can
>> >> be wrapped up:
>> >> 1) ignore queued operations in a detached collection when merging, as
>> was
>> >> done before HHH-5855 was fixed.
>> >> 2) clear the queued operations when the collection is detached.
>> >>
>> >> Comments?
>> >>
>> >> Thanks,
>> >> Gail
>> >>
>> >> [1] https://github.com/hibernate/hibernate-orm/pull/2460
>> >> [2]
>> >>
>> https://github.com/hibernate/hibernate-orm/commit/c1934b72edb4f781520937618b3b750bebb84576#diff-2c7912a47063b9ea81323bf9c6628895L651
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gbadner at redhat.com  Fri Oct  5 19:03:15 2018
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 5 Oct 2018 16:03:15 -0700
Subject: [hibernate-dev] *-to-one associations and @NotFound
In-Reply-To: <CAFDzhiTvKHUJ6cJtxZtz6is_KdMjwQG4-1RE+HGJ7GUSYHV6SQ@mail.gmail.com>
References: <CAFDzhiTDGbgCgnuC_HB77mBmjcoqHhk2+uQeXiqX=uXqwDH8eg@mail.gmail.com>
	<CAFDzhiTvKHUJ6cJtxZtz6is_KdMjwQG4-1RE+HGJ7GUSYHV6SQ@mail.gmail.com>
Message-ID: <CAFDzhiRvaDynTACtDOGNiTLKaaAepfLd5UijWrGcWurG2Ybo0A@mail.gmail.com>

I thought of another case that hasn't been discussed fully. It's covered in
the section, Possible Anomalies - @NotFound(EXCEPTION) has no effect in
some cases - Non-Optional Associations.

Guillaume and Stephen, please take a look and let me know your thoughts.

Thanks,
Gail

On Fri, Oct 5, 2018 at 11:16 AM Gail Badner <gbadner at redhat.com> wrote:

> After discussions with Stephen Fikes and Guillaume, I've added resolutions
> to the document.
>
> In a nutshell, here is what we decided.
>
> 1) Ccombination of @NotFound(IGNORE) and non-optional
> one-to-one/many-to-one will throw MappingException.
>
> 2) Combination of @NotFound(IGNORE) and "mappedBy" one-to-one/many-to-one
> will log a WARN message that @NotFound(IGNORE) will be ignored and should
> be removed.
>
> 3) When a non-lazy association's join column is non-null and there is no
> associated entity with the referenced column:
>
>    - log an INFO message with the exception in an INFO message with
>    ObjectNotFoundException including the entity name and referenced column and
>    value that was not found; (we decided to continue logging as INFO because
>    this condition can only happen if there is no foreign key; so in a sense,
>    the application "knows" this condition is possible)
>    - in the log message, if possible, include the association owner
>    entity and its ID; this will make it easier to clean up the inconsistency
>    in the database;
>    - return a non-null entity with a null association.
>
> Regards,
> Gail
>
> On Mon, Sep 24, 2018 at 4:03 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> As a result of fixing HHH-12436
>> <https://hibernate.atlassian.net/browse/HHH-12436>, some eager *-to-one
>> associations that were loaded using FetchMode.JOIN may instead be loaded
>> using FetchMode.SELECT, and vice-versa. In some cases, @NotFound behavior
>> is different depending on the FetchMode for the association.
>>
>>
>> The reason why FetchMode may change due to HHH-12436
>> <https://hibernate.atlassian.net/browse/HHH-12436> is that the
>> ForeignKeyDirection of some *-to-one associations were incorrect.
>> Correcting the ForeignKeyDirection will result in a different
>> AssociationKey, which may ultimately affect the FetchMode Hibernate assigns
>> to an association.
>>
>>
>> My hope is to resolve the inconsistencies before fixing HHH-12436
>> <https://hibernate.atlassian.net/browse/HHH-12436>, so it does not
>> result in a change in application behavior.
>>
>>
>> I've created a Google Doc to document the inconsistencies and to make it
>> easier to discuss how to go about resolving them:
>>
>>
>> https://docs.google.com/document/d/1o3Q6tYD5jjxC6Ok7vBYzxRGsixpG46p-5zDiDCAKLsI/
>>
>>
>> Please feel free to request access to the document if you wish to review
>> or add comments.
>>
>>
>> Regards,
>>
>> Gail
>>
>>

From guillaume.smet at gmail.com  Mon Oct  8 08:28:28 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 8 Oct 2018 14:28:28 +0200
Subject: [hibernate-dev] Should LiteralExpression support Enum?
Message-ID: <CALt0+o9Qs3x7BByyqt2xC25O7H=9ac9Z_aX2h_JHBDCVjjP1nw@mail.gmail.com>

Hi,

We had an interesting test case posted this week-end, namely
https://github.com/hibernate/hibernate-orm/pull/2562/files .

Apparently, enums as result of case expressions were (sort of) supported in
5.1, whereas they are not anymore in 5.3: you end up with a NPE.

The issue is that we don't have a ValueHandler for enums and thus the
handler in
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/criteria/internal/expression/LiteralExpression.java#L88
is null.

Not sure if it's something we should support tbh. I mean you can use the
name of the enum instead and I think it would be good enough.

But even if we decide to not support it, I think we should probably provide
a better error than a NPE.

Thoughts?

-- 
Guillaume

From gbadner at redhat.com  Mon Oct  8 14:57:24 2018
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 8 Oct 2018 11:57:24 -0700
Subject: [hibernate-dev] Should LiteralExpression support Enum?
In-Reply-To: <CALt0+o9Qs3x7BByyqt2xC25O7H=9ac9Z_aX2h_JHBDCVjjP1nw@mail.gmail.com>
References: <CALt0+o9Qs3x7BByyqt2xC25O7H=9ac9Z_aX2h_JHBDCVjjP1nw@mail.gmail.com>
Message-ID: <CAFDzhiTpd7=Qr5bb9pi0bxA7rM+6Vfx9hnVTjfsQw_iN9FRDUg@mail.gmail.com>

HHH-13016 looks like a duplicate of HHH-12184. Both mention that this
worked in 5.1.10.

The spec is clear that, for queries, this is supported. The overview for
Criteria API states, "The semantics of criteria queries are designed to
reflect those of Java Persistence query language queries."

 IMO, this should be supported for Critera queries as well.



On Mon, Oct 8, 2018 at 5:30 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> We had an interesting test case posted this week-end, namely
> https://github.com/hibernate/hibernate-orm/pull/2562/files .
>
> Apparently, enums as result of case expressions were (sort of) supported in
> 5.1, whereas they are not anymore in 5.3: you end up with a NPE.
>
> The issue is that we don't have a ValueHandler for enums and thus the
> handler in
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/criteria/internal/expression/LiteralExpression.java#L88
> is null.
>
> Not sure if it's something we should support tbh. I mean you can use the
> name of the enum instead and I think it would be good enough.
>
> But even if we decide to not support it, I think we should probably provide
> a better error than a NPE.
>
> Thoughts?
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue Oct  9 05:39:12 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 9 Oct 2018 10:39:12 +0100
Subject: [hibernate-dev] HCANN 5.0.5.Final released
Message-ID: <CAFm4XO0YV9_jkX2YKXehQid7AQRCr1Vqx+i+KZ1OJYwkt+95_Q@mail.gmail.com>

Hi all,

I tagged a 5.0.5.Final release for the sole purpose of aligning the
dependency of org.jboss.logging:jboss-logging with version 3.3.2.Final
: no other changes.

Next I'll upgrade ORM as I need this; I guess upgrading other projects
is entirely optional as there's no real benefit - except satisying
your OCD of dependency alignment :)

enjoy!

Sanne

From guillaume.smet at gmail.com  Tue Oct  9 09:45:15 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 9 Oct 2018 15:45:15 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o-E4C69=0io4mPN7AUQ624EmipetqdT7dUCDcg0hZZ86A@mail.gmail.com>

Hi everyone,

Here are the minutes of this week's meeting:

15:42 < jbott> Meeting ended Tue Oct  9 13:42:30 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:42 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-10-09-13.00.html
15:42 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-10-09-13.00.txt
15:42 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-10-09-13.00.log.html

Cheers,

-- 
Guillaume

From yoann at hibernate.org  Wed Oct 10 03:33:28 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 10 Oct 2018 09:33:28 +0200
Subject: [hibernate-dev] HCANN 5.0.5.Final released
In-Reply-To: <CAFm4XO0YV9_jkX2YKXehQid7AQRCr1Vqx+i+KZ1OJYwkt+95_Q@mail.gmail.com>
References: <CAFm4XO0YV9_jkX2YKXehQid7AQRCr1Vqx+i+KZ1OJYwkt+95_Q@mail.gmail.com>
Message-ID: <CAEqagpq1qF7fCrBvMOFuMkRdNhVUE=AyiTsaAyokPCiDrignmg@mail.gmail.com>

>except satisying  your OCD of dependency alignment

Message received, will do :)

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


On Tue, 9 Oct 2018 at 22:57, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
>
> I tagged a 5.0.5.Final release for the sole purpose of aligning the
> dependency of org.jboss.logging:jboss-logging with version 3.3.2.Final
> : no other changes.
>
> Next I'll upgrade ORM as I need this; I guess upgrading other projects
> is entirely optional as there's no real benefit - except satisying
> your OCD of dependency alignment :)
>
> enjoy!
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Thu Oct 11 10:01:29 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 11 Oct 2018 16:01:29 +0200
Subject: [hibernate-dev] CriteriaBuilder, aggregation and types
Message-ID: <CALt0+o-JRHxuiaibbL6KcE8VPSLv3-dOE9KgP0i9hjm2GPWOXw@mail.gmail.com>

Hi,

We have an interesting test case here
https://hibernate.atlassian.net/browse/HHH-13001 about the use of
LiteralHandlingMode with the criteria builder. It turns out that the
problem is a bit more general than that.

Let's take this (not so useful) example:
query.multiselect(
                        document.get( "id" ),
                        cb.sum( cb.parameter( Long.class ) ) )
                .groupBy( document.get( "id" ) );

It will lead to a NPE when trying to determine the return type of the sum
in:
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/function/StandardAnsiSqlAggregationFunctions.java#L157

The fact is that we totally lose the type information along the way.

I don't know if it's something addressed in 6 and if we should try to fix
it in 5.4. In any case, I think having a workaround would be nice.

There are a few paths we could follow:
1/ at least throw a more meaningful error and provide a workaround. I
thought about forcing the use of the cast function but it doesn't work as
we have an optimization not adding the cast function is the type is
corresponding (see
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/criteria/internal/expression/ExpressionImpl.java#L35).
If we remove this one and provide a helpful error message, that could help.
Note that I don't know if it's just an optimization or something mandated
by the spec itself.

2/ we could try to add a cast automatically for these functions needing a
proper type only when strictly necessary e.g. when you have a parameter (or
a LiteralExpression transformed to a parameter). That would mean adding a
method ExpressionImplementor (and change all our code to use
ExpressionImplementor as it currently uses the JPA version mostly
everywhere). That would be more transparent for the user but clearly a
significant amount of (dumb) work/changes. And probably a nightmare to
merge in 6 if this area has changed.

Thoughts?

-- 
Guillaume

From guillaume.smet at gmail.com  Mon Oct 15 06:09:28 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 15 Oct 2018 12:09:28 +0200
Subject: [hibernate-dev] persister.afterInitialize() called too early
Message-ID: <CALt0+o_ZxctO67RDdzm7pE7WcrOuOF5Q44x2VDW4vn6D142Gcw@mail.gmail.com>

Hi,

On Friday, I started to take a look at
https://hibernate.atlassian.net/browse/HHH-12425.

The current flow of operations is the following:
Loader#initializeEntitiesAndCollections
 \_ TwoPhaseLoad.initializeEntity()
      \_ initialize the entity
      \_ persister.afterInitialize()
 \_ endCollectionLoad of the collection persisters
 \_ TwoPhaseLoad.postLoad()

The issue we have is that afterInitialize() is called before the collection
loading has been done. The collections are not in the persistence context
yet when calling persister.afterInitialize(), which is required with
enhanced entities.

As afterInitialize() is supposed to be called after the properties have
been initialized, I think it makes sense to wait for the collections to be
properly initialized.

I'm wondering if we should isolate the persister.afterInitialize() call
into a TwoPhaseLoad.afterInitialize() method, which would be called after
the collection initialization.

Any thoughts or better ideas?

Thanks.

-- 
Guillaume

From rory.odonnell at oracle.com  Mon Oct 15 06:28:00 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 15 Oct 2018 11:28:00 +0100
Subject: [hibernate-dev] JDK 12 Early Access build 15 is available
Message-ID: <ebbe82ae-ff2b-a69f-202d-69da42517a2d@oracle.com>

Hi Sanne,

*JDK 12 Early Access build 15 is available at : - jdk.java.net/12/*

  * JDK 12 Schedule is confirmed.
      o 2018/12/13 Rampdown Phase One <http://openjdk.java.net/jeps/3#rdp-1>
      o 2019/01/17 Rampdown Phase Two <http://openjdk.java.net/jeps/3#rdp-2>
      o 2019/02/07 Release-Candidate Phase
        <http://openjdk.java.net/jeps/3#rc>
      o 2019/03/19 General Availability
  * Release Notes for JDK 12 [1]
  * JEPs targeted to JDK 12, so far
      o 325: Switch Expressions (Preview [2]) - Integrated
      o 326: Raw String Literals (Preview [2]) - Integrated
      o 340: One AArch64 Port, Not Two
        <http://openjdk.java.net/jeps/340> - Targeted
      o 341: Default CDS Archives <http://openjdk.java.net/jeps/341>-
        Integrated
  * Important fixes since last email
      o (b15)? Implementation of JEP 341: Default CDS Archives
      o (b14) LDAPS Communication Failure (JDK-8211107
        <https://bugs.openjdk.java.net/browse/JDK-8211107>)
      o (b14) Support dns_canonicalize_hostname in krb5.conf
        (JDK-8210821 <https://bugs.openjdk.java.net/browse/JDK-8210821>)
      o (b14) Removal of com.sun.awt.SecurityWarning Class (JDK-8210692
        <https://bugs.openjdk.java.net/browse/JDK-8210692>)


*JDK 8u202 planning [3]*

  * 8u202 is proposed to be the last Oracle led release for this OpenJDK
    Project.
  * A proposed timeline is as follows :
      o July 2018 8u-dev forest begins collecting 8u202 fixes
      o Mid October 2018 RampDown 2
      o Mid January 2019 GA

Rgds, Rory

[1] http://jdk.java.net/12/release-notes
[2] http://openjdk.java.net/jeps/12
[3] 
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html<http://jdk.java.net/12/release-notes>
<https://download.java.net/java/early_access/jmc7/core/common/docs/api/overview-summary.html> 


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


From guillaume.smet at gmail.com  Mon Oct 15 06:59:38 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 15 Oct 2018 12:59:38 +0200
Subject: [hibernate-dev] CriteriaBuilder, aggregation and types
In-Reply-To: <CALt0+o-JRHxuiaibbL6KcE8VPSLv3-dOE9KgP0i9hjm2GPWOXw@mail.gmail.com>
References: <CALt0+o-JRHxuiaibbL6KcE8VPSLv3-dOE9KgP0i9hjm2GPWOXw@mail.gmail.com>
Message-ID: <CALt0+o9rcf3mEh-0YxveBhgNFAD12FmE__YaBbHZH1fQNGeR+w@mail.gmail.com>

Hi,

We discussed a bit more with Fabio on Friday and we ended up discovering
that we have an issue with most Expressions that contain nested Expressions.

The Renderable contract is defined with these 3 methods:
    String render(RenderingContext renderingContext);

    default String renderProjection(RenderingContext renderingContext) {
        return render( renderingContext );
    }

    default String renderGroupBy(RenderingContext renderingContext) {
        return render( renderingContext );
    }

The issue is that most of the Expressions containting nested Expressions
only implement render().

This means that you basically do the following:
call renderProjection() -> expression1 only implement render() -> we call
render() on the nested expressions instead of renderProjection().

One possible workaround is to do what was done in SearchedCaseExpression
for all the Expressions containing nested expressions (e.g. implement the 3
methods and have a private method taking a lambda to propagate the
variation).

You can see an example of this change here:
https://github.com/hibernate/hibernate-orm/pull/2568/files#diff-8fcc837a76b1af31f11e16a01332fd1dR96
.

Note that it has to be done for *all* the Expressions containing nested
expressions. Either that or we simplify the Renderable contract to have
only one render() method and a parameter defining the context. That would
allow to avoid all these changes.

Thoughts?

-- 
Guillaume

On Thu, Oct 11, 2018 at 4:01 PM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> We have an interesting test case here
> https://hibernate.atlassian.net/browse/HHH-13001 about the use of
> LiteralHandlingMode with the criteria builder. It turns out that the
> problem is a bit more general than that.
>
> Let's take this (not so useful) example:
> query.multiselect(
>                         document.get( "id" ),
>                         cb.sum( cb.parameter( Long.class ) ) )
>                 .groupBy( document.get( "id" ) );
>
> It will lead to a NPE when trying to determine the return type of the sum
> in:
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/function/StandardAnsiSqlAggregationFunctions.java#L157
>
> The fact is that we totally lose the type information along the way.
>
> I don't know if it's something addressed in 6 and if we should try to fix
> it in 5.4. In any case, I think having a workaround would be nice.
>
> There are a few paths we could follow:
> 1/ at least throw a more meaningful error and provide a workaround. I
> thought about forcing the use of the cast function but it doesn't work as
> we have an optimization not adding the cast function is the type is
> corresponding (see
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/criteria/internal/expression/ExpressionImpl.java#L35).
> If we remove this one and provide a helpful error message, that could help.
> Note that I don't know if it's just an optimization or something mandated
> by the spec itself.
>
> 2/ we could try to add a cast automatically for these functions needing a
> proper type only when strictly necessary e.g. when you have a parameter (or
> a LiteralExpression transformed to a parameter). That would mean adding a
> method ExpressionImplementor (and change all our code to use
> ExpressionImplementor as it currently uses the JPA version mostly
> everywhere). That would be more transparent for the user but clearly a
> significant amount of (dumb) work/changes. And probably a nightmare to
> merge in 6 if this area has changed.
>
> Thoughts?
>
> --
> Guillaume
>

From steve at hibernate.org  Mon Oct 15 07:39:42 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 15 Oct 2018 06:39:42 -0500
Subject: [hibernate-dev] CriteriaBuilder, aggregation and types
In-Reply-To: <CALt0+o9rcf3mEh-0YxveBhgNFAD12FmE__YaBbHZH1fQNGeR+w@mail.gmail.com>
References: <CALt0+o-JRHxuiaibbL6KcE8VPSLv3-dOE9KgP0i9hjm2GPWOXw@mail.gmail.com>
	<CALt0+o9rcf3mEh-0YxveBhgNFAD12FmE__YaBbHZH1fQNGeR+w@mail.gmail.com>
Message-ID: <CAFdSV9v7tO7WL1_Ud-8-TBYtmp5EpG9-Xtf15KC4OvcfpfgHaw@mail.gmail.com>

Let's discuss on Hip Chat in a few after I have woken up and had some
coffee :)


On Mon, Oct 15, 2018, 6:02 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> We discussed a bit more with Fabio on Friday and we ended up discovering
> that we have an issue with most Expressions that contain nested
> Expressions.
>
> The Renderable contract is defined with these 3 methods:
>     String render(RenderingContext renderingContext);
>
>     default String renderProjection(RenderingContext renderingContext) {
>         return render( renderingContext );
>     }
>
>     default String renderGroupBy(RenderingContext renderingContext) {
>         return render( renderingContext );
>     }
>
> The issue is that most of the Expressions containting nested Expressions
> only implement render().
>
> This means that you basically do the following:
> call renderProjection() -> expression1 only implement render() -> we call
> render() on the nested expressions instead of renderProjection().
>
> One possible workaround is to do what was done in SearchedCaseExpression
> for all the Expressions containing nested expressions (e.g. implement the 3
> methods and have a private method taking a lambda to propagate the
> variation).
>
> You can see an example of this change here:
>
> https://github.com/hibernate/hibernate-orm/pull/2568/files#diff-8fcc837a76b1af31f11e16a01332fd1dR96
> .
>
> Note that it has to be done for *all* the Expressions containing nested
> expressions. Either that or we simplify the Renderable contract to have
> only one render() method and a parameter defining the context. That would
> allow to avoid all these changes.
>
> Thoughts?
>
> --
> Guillaume
>
> On Thu, Oct 11, 2018 at 4:01 PM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > Hi,
> >
> > We have an interesting test case here
> > https://hibernate.atlassian.net/browse/HHH-13001 about the use of
> > LiteralHandlingMode with the criteria builder. It turns out that the
> > problem is a bit more general than that.
> >
> > Let's take this (not so useful) example:
> > query.multiselect(
> >                         document.get( "id" ),
> >                         cb.sum( cb.parameter( Long.class ) ) )
> >                 .groupBy( document.get( "id" ) );
> >
> > It will lead to a NPE when trying to determine the return type of the sum
> > in:
> >
> >
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/function/StandardAnsiSqlAggregationFunctions.java#L157
> >
> > The fact is that we totally lose the type information along the way.
> >
> > I don't know if it's something addressed in 6 and if we should try to fix
> > it in 5.4. In any case, I think having a workaround would be nice.
> >
> > There are a few paths we could follow:
> > 1/ at least throw a more meaningful error and provide a workaround. I
> > thought about forcing the use of the cast function but it doesn't work as
> > we have an optimization not adding the cast function is the type is
> > corresponding (see
> >
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/criteria/internal/expression/ExpressionImpl.java#L35
> ).
> > If we remove this one and provide a helpful error message, that could
> help.
> > Note that I don't know if it's just an optimization or something mandated
> > by the spec itself.
> >
> > 2/ we could try to add a cast automatically for these functions needing a
> > proper type only when strictly necessary e.g. when you have a parameter
> (or
> > a LiteralExpression transformed to a parameter). That would mean adding a
> > method ExpressionImplementor (and change all our code to use
> > ExpressionImplementor as it currently uses the JPA version mostly
> > everywhere). That would be more transparent for the user but clearly a
> > significant amount of (dumb) work/changes. And probably a nightmare to
> > merge in 6 if this area has changed.
> >
> > Thoughts?
> >
> > --
> > Guillaume
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Mon Oct 15 08:49:41 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 15 Oct 2018 14:49:41 +0200
Subject: [hibernate-dev] CriteriaBuilder, aggregation and types
In-Reply-To: <CAFdSV9v7tO7WL1_Ud-8-TBYtmp5EpG9-Xtf15KC4OvcfpfgHaw@mail.gmail.com>
References: <CALt0+o-JRHxuiaibbL6KcE8VPSLv3-dOE9KgP0i9hjm2GPWOXw@mail.gmail.com>
	<CALt0+o9rcf3mEh-0YxveBhgNFAD12FmE__YaBbHZH1fQNGeR+w@mail.gmail.com>
	<CAFdSV9v7tO7WL1_Ud-8-TBYtmp5EpG9-Xtf15KC4OvcfpfgHaw@mail.gmail.com>
Message-ID: <CALt0+o99RKxOAh6LGCn=ar5Q0CQe2i1Ab3HcvxN1bUKUUvU4HQ@mail.gmail.com>

OK, ping me when you're ready!

On Mon, Oct 15, 2018 at 1:39 PM Steve Ebersole <steve at hibernate.org> wrote:

> Let's discuss on Hip Chat in a few after I have woken up and had some
> coffee :)
>
>
> On Mon, Oct 15, 2018, 6:02 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Hi,
>>
>> We discussed a bit more with Fabio on Friday and we ended up discovering
>> that we have an issue with most Expressions that contain nested
>> Expressions.
>>
>> The Renderable contract is defined with these 3 methods:
>>     String render(RenderingContext renderingContext);
>>
>>     default String renderProjection(RenderingContext renderingContext) {
>>         return render( renderingContext );
>>     }
>>
>>     default String renderGroupBy(RenderingContext renderingContext) {
>>         return render( renderingContext );
>>     }
>>
>> The issue is that most of the Expressions containting nested Expressions
>> only implement render().
>>
>> This means that you basically do the following:
>> call renderProjection() -> expression1 only implement render() -> we call
>> render() on the nested expressions instead of renderProjection().
>>
>> One possible workaround is to do what was done in SearchedCaseExpression
>> for all the Expressions containing nested expressions (e.g. implement the
>> 3
>> methods and have a private method taking a lambda to propagate the
>> variation).
>>
>> You can see an example of this change here:
>>
>> https://github.com/hibernate/hibernate-orm/pull/2568/files#diff-8fcc837a76b1af31f11e16a01332fd1dR96
>> .
>>
>> Note that it has to be done for *all* the Expressions containing nested
>> expressions. Either that or we simplify the Renderable contract to have
>> only one render() method and a parameter defining the context. That would
>> allow to avoid all these changes.
>>
>> Thoughts?
>>
>> --
>> Guillaume
>>
>> On Thu, Oct 11, 2018 at 4:01 PM Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > We have an interesting test case here
>> > https://hibernate.atlassian.net/browse/HHH-13001 about the use of
>> > LiteralHandlingMode with the criteria builder. It turns out that the
>> > problem is a bit more general than that.
>> >
>> > Let's take this (not so useful) example:
>> > query.multiselect(
>> >                         document.get( "id" ),
>> >                         cb.sum( cb.parameter( Long.class ) ) )
>> >                 .groupBy( document.get( "id" ) );
>> >
>> > It will lead to a NPE when trying to determine the return type of the
>> sum
>> > in:
>> >
>> >
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/function/StandardAnsiSqlAggregationFunctions.java#L157
>> >
>> > The fact is that we totally lose the type information along the way.
>> >
>> > I don't know if it's something addressed in 6 and if we should try to
>> fix
>> > it in 5.4. In any case, I think having a workaround would be nice.
>> >
>> > There are a few paths we could follow:
>> > 1/ at least throw a more meaningful error and provide a workaround. I
>> > thought about forcing the use of the cast function but it doesn't work
>> as
>> > we have an optimization not adding the cast function is the type is
>> > corresponding (see
>> >
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/criteria/internal/expression/ExpressionImpl.java#L35
>> ).
>> > If we remove this one and provide a helpful error message, that could
>> help.
>> > Note that I don't know if it's just an optimization or something
>> mandated
>> > by the spec itself.
>> >
>> > 2/ we could try to add a cast automatically for these functions needing
>> a
>> > proper type only when strictly necessary e.g. when you have a parameter
>> (or
>> > a LiteralExpression transformed to a parameter). That would mean adding
>> a
>> > method ExpressionImplementor (and change all our code to use
>> > ExpressionImplementor as it currently uses the JPA version mostly
>> > everywhere). That would be more transparent for the user but clearly a
>> > significant amount of (dumb) work/changes. And probably a nightmare to
>> > merge in 6 if this area has changed.
>> >
>> > Thoughts?
>> >
>> > --
>> > Guillaume
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Mon Oct 15 09:28:04 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 15 Oct 2018 08:28:04 -0500
Subject: [hibernate-dev] persister.afterInitialize() called too early
In-Reply-To: <CALt0+o_ZxctO67RDdzm7pE7WcrOuOF5Q44x2VDW4vn6D142Gcw@mail.gmail.com>
References: <CALt0+o_ZxctO67RDdzm7pE7WcrOuOF5Q44x2VDW4vn6D142Gcw@mail.gmail.com>
Message-ID: <CAFdSV9uJUrQTskj7HedHUiEf31YtTKE11gbmY60HVYVxx+9tww@mail.gmail.com>

The collection should be added to the persistence context as soon as
`CollectionType#resolve` is called, so this is interesting.


On Mon, Oct 15, 2018 at 5:49 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> On Friday, I started to take a look at
> https://hibernate.atlassian.net/browse/HHH-12425.
>
> The current flow of operations is the following:
> Loader#initializeEntitiesAndCollections
>  \_ TwoPhaseLoad.initializeEntity()
>       \_ initialize the entity
>       \_ persister.afterInitialize()
>  \_ endCollectionLoad of the collection persisters
>  \_ TwoPhaseLoad.postLoad()
>
> The issue we have is that afterInitialize() is called before the collection
> loading has been done. The collections are not in the persistence context
> yet when calling persister.afterInitialize(), which is required with
> enhanced entities.
>
> As afterInitialize() is supposed to be called after the properties have
> been initialized, I think it makes sense to wait for the collections to be
> properly initialized.
>
> I'm wondering if we should isolate the persister.afterInitialize() call
> into a TwoPhaseLoad.afterInitialize() method, which would be called after
> the collection initialization.
>
> Any thoughts or better ideas?
>
> Thanks.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Oct 15 22:38:38 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 15 Oct 2018 21:38:38 -0500
Subject: [hibernate-dev] CriteriaBuilder, aggregation and types
In-Reply-To: <CALt0+o99RKxOAh6LGCn=ar5Q0CQe2i1Ab3HcvxN1bUKUUvU4HQ@mail.gmail.com>
References: <CALt0+o-JRHxuiaibbL6KcE8VPSLv3-dOE9KgP0i9hjm2GPWOXw@mail.gmail.com>
	<CALt0+o9rcf3mEh-0YxveBhgNFAD12FmE__YaBbHZH1fQNGeR+w@mail.gmail.com>
	<CAFdSV9v7tO7WL1_Ud-8-TBYtmp5EpG9-Xtf15KC4OvcfpfgHaw@mail.gmail.com>
	<CALt0+o99RKxOAh6LGCn=ar5Q0CQe2i1Ab3HcvxN1bUKUUvU4HQ@mail.gmail.com>
Message-ID: <CAFdSV9tepTVumO736J8MGruix8z+Lxia1orp-qA16yGXTVNW4g@mail.gmail.com>

Are there actual tests for this besides the full zip on the issue?  How did
you guys investigate this?

On Mon, Oct 15, 2018 at 7:50 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> OK, ping me when you're ready!
>
> On Mon, Oct 15, 2018 at 1:39 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Let's discuss on Hip Chat in a few after I have woken up and had some
>> coffee :)
>>
>>
>> On Mon, Oct 15, 2018, 6:02 AM Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> We discussed a bit more with Fabio on Friday and we ended up discovering
>>> that we have an issue with most Expressions that contain nested
>>> Expressions.
>>>
>>> The Renderable contract is defined with these 3 methods:
>>>     String render(RenderingContext renderingContext);
>>>
>>>     default String renderProjection(RenderingContext renderingContext) {
>>>         return render( renderingContext );
>>>     }
>>>
>>>     default String renderGroupBy(RenderingContext renderingContext) {
>>>         return render( renderingContext );
>>>     }
>>>
>>> The issue is that most of the Expressions containting nested Expressions
>>> only implement render().
>>>
>>> This means that you basically do the following:
>>> call renderProjection() -> expression1 only implement render() -> we call
>>> render() on the nested expressions instead of renderProjection().
>>>
>>> One possible workaround is to do what was done in SearchedCaseExpression
>>> for all the Expressions containing nested expressions (e.g. implement
>>> the 3
>>> methods and have a private method taking a lambda to propagate the
>>> variation).
>>>
>>> You can see an example of this change here:
>>>
>>> https://github.com/hibernate/hibernate-orm/pull/2568/files#diff-8fcc837a76b1af31f11e16a01332fd1dR96
>>> .
>>>
>>> Note that it has to be done for *all* the Expressions containing nested
>>> expressions. Either that or we simplify the Renderable contract to have
>>> only one render() method and a parameter defining the context. That would
>>> allow to avoid all these changes.
>>>
>>> Thoughts?
>>>
>>> --
>>> Guillaume
>>>
>>> On Thu, Oct 11, 2018 at 4:01 PM Guillaume Smet <guillaume.smet at gmail.com
>>> >
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > We have an interesting test case here
>>> > https://hibernate.atlassian.net/browse/HHH-13001 about the use of
>>> > LiteralHandlingMode with the criteria builder. It turns out that the
>>> > problem is a bit more general than that.
>>> >
>>> > Let's take this (not so useful) example:
>>> > query.multiselect(
>>> >                         document.get( "id" ),
>>> >                         cb.sum( cb.parameter( Long.class ) ) )
>>> >                 .groupBy( document.get( "id" ) );
>>> >
>>> > It will lead to a NPE when trying to determine the return type of the
>>> sum
>>> > in:
>>> >
>>> >
>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/function/StandardAnsiSqlAggregationFunctions.java#L157
>>> >
>>> > The fact is that we totally lose the type information along the way.
>>> >
>>> > I don't know if it's something addressed in 6 and if we should try to
>>> fix
>>> > it in 5.4. In any case, I think having a workaround would be nice.
>>> >
>>> > There are a few paths we could follow:
>>> > 1/ at least throw a more meaningful error and provide a workaround. I
>>> > thought about forcing the use of the cast function but it doesn't work
>>> as
>>> > we have an optimization not adding the cast function is the type is
>>> > corresponding (see
>>> >
>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/criteria/internal/expression/ExpressionImpl.java#L35
>>> ).
>>> > If we remove this one and provide a helpful error message, that could
>>> help.
>>> > Note that I don't know if it's just an optimization or something
>>> mandated
>>> > by the spec itself.
>>> >
>>> > 2/ we could try to add a cast automatically for these functions
>>> needing a
>>> > proper type only when strictly necessary e.g. when you have a
>>> parameter (or
>>> > a LiteralExpression transformed to a parameter). That would mean
>>> adding a
>>> > method ExpressionImplementor (and change all our code to use
>>> > ExpressionImplementor as it currently uses the JPA version mostly
>>> > everywhere). That would be more transparent for the user but clearly a
>>> > significant amount of (dumb) work/changes. And probably a nightmare to
>>> > merge in 6 if this area has changed.
>>> >
>>> > Thoughts?
>>> >
>>> > --
>>> > Guillaume
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From guillaume.smet at gmail.com  Tue Oct 16 04:02:12 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 16 Oct 2018 10:02:12 +0200
Subject: [hibernate-dev] CriteriaBuilder, aggregation and types
In-Reply-To: <CAFdSV9tepTVumO736J8MGruix8z+Lxia1orp-qA16yGXTVNW4g@mail.gmail.com>
References: <CALt0+o-JRHxuiaibbL6KcE8VPSLv3-dOE9KgP0i9hjm2GPWOXw@mail.gmail.com>
	<CALt0+o9rcf3mEh-0YxveBhgNFAD12FmE__YaBbHZH1fQNGeR+w@mail.gmail.com>
	<CAFdSV9v7tO7WL1_Ud-8-TBYtmp5EpG9-Xtf15KC4OvcfpfgHaw@mail.gmail.com>
	<CALt0+o99RKxOAh6LGCn=ar5Q0CQe2i1Ab3HcvxN1bUKUUvU4HQ@mail.gmail.com>
	<CAFdSV9tepTVumO736J8MGruix8z+Lxia1orp-qA16yGXTVNW4g@mail.gmail.com>
Message-ID: <CALt0+o9FN4CCS1EmDtS=0Lt1LQfpmNqdo2RWf+qhtaMPdoXqrQ@mail.gmail.com>

Fabio put together a test in his PR:
https://github.com/hibernate/hibernate-orm/pull/2568/files#diff-ab60fb95866b43def421ef53163885ccR1

On Tue, Oct 16, 2018 at 4:38 AM Steve Ebersole <steve at hibernate.org> wrote:

> Are there actual tests for this besides the full zip on the issue?  How
> did you guys investigate this?
>
> On Mon, Oct 15, 2018 at 7:50 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> OK, ping me when you're ready!
>>
>> On Mon, Oct 15, 2018 at 1:39 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Let's discuss on Hip Chat in a few after I have woken up and had some
>>> coffee :)
>>>
>>>
>>> On Mon, Oct 15, 2018, 6:02 AM Guillaume Smet <guillaume.smet at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> We discussed a bit more with Fabio on Friday and we ended up discovering
>>>> that we have an issue with most Expressions that contain nested
>>>> Expressions.
>>>>
>>>> The Renderable contract is defined with these 3 methods:
>>>>     String render(RenderingContext renderingContext);
>>>>
>>>>     default String renderProjection(RenderingContext renderingContext) {
>>>>         return render( renderingContext );
>>>>     }
>>>>
>>>>     default String renderGroupBy(RenderingContext renderingContext) {
>>>>         return render( renderingContext );
>>>>     }
>>>>
>>>> The issue is that most of the Expressions containting nested Expressions
>>>> only implement render().
>>>>
>>>> This means that you basically do the following:
>>>> call renderProjection() -> expression1 only implement render() -> we
>>>> call
>>>> render() on the nested expressions instead of renderProjection().
>>>>
>>>> One possible workaround is to do what was done in SearchedCaseExpression
>>>> for all the Expressions containing nested expressions (e.g. implement
>>>> the 3
>>>> methods and have a private method taking a lambda to propagate the
>>>> variation).
>>>>
>>>> You can see an example of this change here:
>>>>
>>>> https://github.com/hibernate/hibernate-orm/pull/2568/files#diff-8fcc837a76b1af31f11e16a01332fd1dR96
>>>> .
>>>>
>>>> Note that it has to be done for *all* the Expressions containing nested
>>>> expressions. Either that or we simplify the Renderable contract to have
>>>> only one render() method and a parameter defining the context. That
>>>> would
>>>> allow to avoid all these changes.
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> Guillaume
>>>>
>>>> On Thu, Oct 11, 2018 at 4:01 PM Guillaume Smet <
>>>> guillaume.smet at gmail.com>
>>>> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > We have an interesting test case here
>>>> > https://hibernate.atlassian.net/browse/HHH-13001 about the use of
>>>> > LiteralHandlingMode with the criteria builder. It turns out that the
>>>> > problem is a bit more general than that.
>>>> >
>>>> > Let's take this (not so useful) example:
>>>> > query.multiselect(
>>>> >                         document.get( "id" ),
>>>> >                         cb.sum( cb.parameter( Long.class ) ) )
>>>> >                 .groupBy( document.get( "id" ) );
>>>> >
>>>> > It will lead to a NPE when trying to determine the return type of the
>>>> sum
>>>> > in:
>>>> >
>>>> >
>>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/function/StandardAnsiSqlAggregationFunctions.java#L157
>>>> >
>>>> > The fact is that we totally lose the type information along the way.
>>>> >
>>>> > I don't know if it's something addressed in 6 and if we should try to
>>>> fix
>>>> > it in 5.4. In any case, I think having a workaround would be nice.
>>>> >
>>>> > There are a few paths we could follow:
>>>> > 1/ at least throw a more meaningful error and provide a workaround. I
>>>> > thought about forcing the use of the cast function but it doesn't
>>>> work as
>>>> > we have an optimization not adding the cast function is the type is
>>>> > corresponding (see
>>>> >
>>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/criteria/internal/expression/ExpressionImpl.java#L35
>>>> ).
>>>> > If we remove this one and provide a helpful error message, that could
>>>> help.
>>>> > Note that I don't know if it's just an optimization or something
>>>> mandated
>>>> > by the spec itself.
>>>> >
>>>> > 2/ we could try to add a cast automatically for these functions
>>>> needing a
>>>> > proper type only when strictly necessary e.g. when you have a
>>>> parameter (or
>>>> > a LiteralExpression transformed to a parameter). That would mean
>>>> adding a
>>>> > method ExpressionImplementor (and change all our code to use
>>>> > ExpressionImplementor as it currently uses the JPA version mostly
>>>> > everywhere). That would be more transparent for the user but clearly a
>>>> > significant amount of (dumb) work/changes. And probably a nightmare to
>>>> > merge in 6 if this area has changed.
>>>> >
>>>> > Thoughts?
>>>> >
>>>> > --
>>>> > Guillaume
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>

From guillaume.smet at gmail.com  Tue Oct 16 05:06:33 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 16 Oct 2018 11:06:33 +0200
Subject: [hibernate-dev] CriteriaBuilder, aggregation and types
In-Reply-To: <CALt0+o9FN4CCS1EmDtS=0Lt1LQfpmNqdo2RWf+qhtaMPdoXqrQ@mail.gmail.com>
References: <CALt0+o-JRHxuiaibbL6KcE8VPSLv3-dOE9KgP0i9hjm2GPWOXw@mail.gmail.com>
	<CALt0+o9rcf3mEh-0YxveBhgNFAD12FmE__YaBbHZH1fQNGeR+w@mail.gmail.com>
	<CAFdSV9v7tO7WL1_Ud-8-TBYtmp5EpG9-Xtf15KC4OvcfpfgHaw@mail.gmail.com>
	<CALt0+o99RKxOAh6LGCn=ar5Q0CQe2i1Ab3HcvxN1bUKUUvU4HQ@mail.gmail.com>
	<CAFdSV9tepTVumO736J8MGruix8z+Lxia1orp-qA16yGXTVNW4g@mail.gmail.com>
	<CALt0+o9FN4CCS1EmDtS=0Lt1LQfpmNqdo2RWf+qhtaMPdoXqrQ@mail.gmail.com>
Message-ID: <CALt0+o8DU-uOpvzPGOLdQGAhxmX9591B1yLWivsmOOqYnfkZiA@mail.gmail.com>

Test added to your PR. It passes now.

On Tue, Oct 16, 2018 at 10:02 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Fabio put together a test in his PR:
> https://github.com/hibernate/hibernate-orm/pull/2568/files#diff-ab60fb95866b43def421ef53163885ccR1
>
> On Tue, Oct 16, 2018 at 4:38 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Are there actual tests for this besides the full zip on the issue?  How
>> did you guys investigate this?
>>
>> On Mon, Oct 15, 2018 at 7:50 AM Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>>
>>> OK, ping me when you're ready!
>>>
>>> On Mon, Oct 15, 2018 at 1:39 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> Let's discuss on Hip Chat in a few after I have woken up and had some
>>>> coffee :)
>>>>
>>>>
>>>> On Mon, Oct 15, 2018, 6:02 AM Guillaume Smet <guillaume.smet at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We discussed a bit more with Fabio on Friday and we ended up
>>>>> discovering
>>>>> that we have an issue with most Expressions that contain nested
>>>>> Expressions.
>>>>>
>>>>> The Renderable contract is defined with these 3 methods:
>>>>>     String render(RenderingContext renderingContext);
>>>>>
>>>>>     default String renderProjection(RenderingContext renderingContext)
>>>>> {
>>>>>         return render( renderingContext );
>>>>>     }
>>>>>
>>>>>     default String renderGroupBy(RenderingContext renderingContext) {
>>>>>         return render( renderingContext );
>>>>>     }
>>>>>
>>>>> The issue is that most of the Expressions containting nested
>>>>> Expressions
>>>>> only implement render().
>>>>>
>>>>> This means that you basically do the following:
>>>>> call renderProjection() -> expression1 only implement render() -> we
>>>>> call
>>>>> render() on the nested expressions instead of renderProjection().
>>>>>
>>>>> One possible workaround is to do what was done in
>>>>> SearchedCaseExpression
>>>>> for all the Expressions containing nested expressions (e.g. implement
>>>>> the 3
>>>>> methods and have a private method taking a lambda to propagate the
>>>>> variation).
>>>>>
>>>>> You can see an example of this change here:
>>>>>
>>>>> https://github.com/hibernate/hibernate-orm/pull/2568/files#diff-8fcc837a76b1af31f11e16a01332fd1dR96
>>>>> .
>>>>>
>>>>> Note that it has to be done for *all* the Expressions containing nested
>>>>> expressions. Either that or we simplify the Renderable contract to have
>>>>> only one render() method and a parameter defining the context. That
>>>>> would
>>>>> allow to avoid all these changes.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> --
>>>>> Guillaume
>>>>>
>>>>> On Thu, Oct 11, 2018 at 4:01 PM Guillaume Smet <
>>>>> guillaume.smet at gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Hi,
>>>>> >
>>>>> > We have an interesting test case here
>>>>> > https://hibernate.atlassian.net/browse/HHH-13001 about the use of
>>>>> > LiteralHandlingMode with the criteria builder. It turns out that the
>>>>> > problem is a bit more general than that.
>>>>> >
>>>>> > Let's take this (not so useful) example:
>>>>> > query.multiselect(
>>>>> >                         document.get( "id" ),
>>>>> >                         cb.sum( cb.parameter( Long.class ) ) )
>>>>> >                 .groupBy( document.get( "id" ) );
>>>>> >
>>>>> > It will lead to a NPE when trying to determine the return type of
>>>>> the sum
>>>>> > in:
>>>>> >
>>>>> >
>>>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/function/StandardAnsiSqlAggregationFunctions.java#L157
>>>>> >
>>>>> > The fact is that we totally lose the type information along the way.
>>>>> >
>>>>> > I don't know if it's something addressed in 6 and if we should try
>>>>> to fix
>>>>> > it in 5.4. In any case, I think having a workaround would be nice.
>>>>> >
>>>>> > There are a few paths we could follow:
>>>>> > 1/ at least throw a more meaningful error and provide a workaround. I
>>>>> > thought about forcing the use of the cast function but it doesn't
>>>>> work as
>>>>> > we have an optimization not adding the cast function is the type is
>>>>> > corresponding (see
>>>>> >
>>>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/criteria/internal/expression/ExpressionImpl.java#L35
>>>>> ).
>>>>> > If we remove this one and provide a helpful error message, that
>>>>> could help.
>>>>> > Note that I don't know if it's just an optimization or something
>>>>> mandated
>>>>> > by the spec itself.
>>>>> >
>>>>> > 2/ we could try to add a cast automatically for these functions
>>>>> needing a
>>>>> > proper type only when strictly necessary e.g. when you have a
>>>>> parameter (or
>>>>> > a LiteralExpression transformed to a parameter). That would mean
>>>>> adding a
>>>>> > method ExpressionImplementor (and change all our code to use
>>>>> > ExpressionImplementor as it currently uses the JPA version mostly
>>>>> > everywhere). That would be more transparent for the user but clearly
>>>>> a
>>>>> > significant amount of (dumb) work/changes. And probably a nightmare
>>>>> to
>>>>> > merge in 6 if this area has changed.
>>>>> >
>>>>> > Thoughts?
>>>>> >
>>>>> > --
>>>>> > Guillaume
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>

From steve at hibernate.org  Tue Oct 16 07:19:15 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 16 Oct 2018 06:19:15 -0500
Subject: [hibernate-dev] CriteriaBuilder, aggregation and types
In-Reply-To: <CALt0+o8DU-uOpvzPGOLdQGAhxmX9591B1yLWivsmOOqYnfkZiA@mail.gmail.com>
References: <CALt0+o-JRHxuiaibbL6KcE8VPSLv3-dOE9KgP0i9hjm2GPWOXw@mail.gmail.com>
	<CALt0+o9rcf3mEh-0YxveBhgNFAD12FmE__YaBbHZH1fQNGeR+w@mail.gmail.com>
	<CAFdSV9v7tO7WL1_Ud-8-TBYtmp5EpG9-Xtf15KC4OvcfpfgHaw@mail.gmail.com>
	<CALt0+o99RKxOAh6LGCn=ar5Q0CQe2i1Ab3HcvxN1bUKUUvU4HQ@mail.gmail.com>
	<CAFdSV9tepTVumO736J8MGruix8z+Lxia1orp-qA16yGXTVNW4g@mail.gmail.com>
	<CALt0+o9FN4CCS1EmDtS=0Lt1LQfpmNqdo2RWf+qhtaMPdoXqrQ@mail.gmail.com>
	<CALt0+o8DU-uOpvzPGOLdQGAhxmX9591B1yLWivsmOOqYnfkZiA@mail.gmail.com>
Message-ID: <CAFdSV9u6t-Xu7kVq45SrKSUphgKYiCeddeN-R+iopENA35YZ+g@mail.gmail.com>

Awesome, thanks!

On Tue, Oct 16, 2018, 4:07 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Test added to your PR. It passes now.
>
> On Tue, Oct 16, 2018 at 10:02 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Fabio put together a test in his PR:
>> https://github.com/hibernate/hibernate-orm/pull/2568/files#diff-ab60fb95866b43def421ef53163885ccR1
>>
>> On Tue, Oct 16, 2018 at 4:38 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Are there actual tests for this besides the full zip on the issue?  How
>>> did you guys investigate this?
>>>
>>> On Mon, Oct 15, 2018 at 7:50 AM Guillaume Smet <guillaume.smet at gmail.com>
>>> wrote:
>>>
>>>> OK, ping me when you're ready!
>>>>
>>>> On Mon, Oct 15, 2018 at 1:39 PM Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> Let's discuss on Hip Chat in a few after I have woken up and had some
>>>>> coffee :)
>>>>>
>>>>>
>>>>> On Mon, Oct 15, 2018, 6:02 AM Guillaume Smet <guillaume.smet at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We discussed a bit more with Fabio on Friday and we ended up
>>>>>> discovering
>>>>>> that we have an issue with most Expressions that contain nested
>>>>>> Expressions.
>>>>>>
>>>>>> The Renderable contract is defined with these 3 methods:
>>>>>>     String render(RenderingContext renderingContext);
>>>>>>
>>>>>>     default String renderProjection(RenderingContext
>>>>>> renderingContext) {
>>>>>>         return render( renderingContext );
>>>>>>     }
>>>>>>
>>>>>>     default String renderGroupBy(RenderingContext renderingContext) {
>>>>>>         return render( renderingContext );
>>>>>>     }
>>>>>>
>>>>>> The issue is that most of the Expressions containting nested
>>>>>> Expressions
>>>>>> only implement render().
>>>>>>
>>>>>> This means that you basically do the following:
>>>>>> call renderProjection() -> expression1 only implement render() -> we
>>>>>> call
>>>>>> render() on the nested expressions instead of renderProjection().
>>>>>>
>>>>>> One possible workaround is to do what was done in
>>>>>> SearchedCaseExpression
>>>>>> for all the Expressions containing nested expressions (e.g. implement
>>>>>> the 3
>>>>>> methods and have a private method taking a lambda to propagate the
>>>>>> variation).
>>>>>>
>>>>>> You can see an example of this change here:
>>>>>>
>>>>>> https://github.com/hibernate/hibernate-orm/pull/2568/files#diff-8fcc837a76b1af31f11e16a01332fd1dR96
>>>>>> .
>>>>>>
>>>>>> Note that it has to be done for *all* the Expressions containing
>>>>>> nested
>>>>>> expressions. Either that or we simplify the Renderable contract to
>>>>>> have
>>>>>> only one render() method and a parameter defining the context. That
>>>>>> would
>>>>>> allow to avoid all these changes.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> --
>>>>>> Guillaume
>>>>>>
>>>>>> On Thu, Oct 11, 2018 at 4:01 PM Guillaume Smet <
>>>>>> guillaume.smet at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> > Hi,
>>>>>> >
>>>>>> > We have an interesting test case here
>>>>>> > https://hibernate.atlassian.net/browse/HHH-13001 about the use of
>>>>>> > LiteralHandlingMode with the criteria builder. It turns out that the
>>>>>> > problem is a bit more general than that.
>>>>>> >
>>>>>> > Let's take this (not so useful) example:
>>>>>> > query.multiselect(
>>>>>> >                         document.get( "id" ),
>>>>>> >                         cb.sum( cb.parameter( Long.class ) ) )
>>>>>> >                 .groupBy( document.get( "id" ) );
>>>>>> >
>>>>>> > It will lead to a NPE when trying to determine the return type of
>>>>>> the sum
>>>>>> > in:
>>>>>> >
>>>>>> >
>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/function/StandardAnsiSqlAggregationFunctions.java#L157
>>>>>> >
>>>>>> > The fact is that we totally lose the type information along the way.
>>>>>> >
>>>>>> > I don't know if it's something addressed in 6 and if we should try
>>>>>> to fix
>>>>>> > it in 5.4. In any case, I think having a workaround would be nice.
>>>>>> >
>>>>>> > There are a few paths we could follow:
>>>>>> > 1/ at least throw a more meaningful error and provide a workaround.
>>>>>> I
>>>>>> > thought about forcing the use of the cast function but it doesn't
>>>>>> work as
>>>>>> > we have an optimization not adding the cast function is the type is
>>>>>> > corresponding (see
>>>>>> >
>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/criteria/internal/expression/ExpressionImpl.java#L35
>>>>>> ).
>>>>>> > If we remove this one and provide a helpful error message, that
>>>>>> could help.
>>>>>> > Note that I don't know if it's just an optimization or something
>>>>>> mandated
>>>>>> > by the spec itself.
>>>>>> >
>>>>>> > 2/ we could try to add a cast automatically for these functions
>>>>>> needing a
>>>>>> > proper type only when strictly necessary e.g. when you have a
>>>>>> parameter (or
>>>>>> > a LiteralExpression transformed to a parameter). That would mean
>>>>>> adding a
>>>>>> > method ExpressionImplementor (and change all our code to use
>>>>>> > ExpressionImplementor as it currently uses the JPA version mostly
>>>>>> > everywhere). That would be more transparent for the user but
>>>>>> clearly a
>>>>>> > significant amount of (dumb) work/changes. And probably a nightmare
>>>>>> to
>>>>>> > merge in 6 if this area has changed.
>>>>>> >
>>>>>> > Thoughts?
>>>>>> >
>>>>>> > --
>>>>>> > Guillaume
>>>>>> >
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>

From steve at hibernate.org  Wed Oct 17 09:12:22 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 17 Oct 2018 08:12:22 -0500
Subject: [hibernate-dev] Jira - edit comments
Message-ID: <CAFdSV9sa5Y=sndLrph3Kga-aXxjJvY1kEF_FH5=K2X5xBLN43g@mail.gmail.com>

Did someone remove the ability to edit one's comments?  I added a comment I
would like to adjust syntax (code fragment), but Jira will not let me

From chris at hibernate.org  Wed Oct 17 10:02:35 2018
From: chris at hibernate.org (Chris Cranford)
Date: Wed, 17 Oct 2018 10:02:35 -0400
Subject: [hibernate-dev] Jira - edit comments
In-Reply-To: <CAFdSV9sa5Y=sndLrph3Kga-aXxjJvY1kEF_FH5=K2X5xBLN43g@mail.gmail.com>
References: <CAFdSV9sa5Y=sndLrph3Kga-aXxjJvY1kEF_FH5=K2X5xBLN43g@mail.gmail.com>
Message-ID: <6c246b4e-5335-f475-7b59-8d36dab4e43f@hibernate.org>

Steve -

I have the option for my user.? Is the ellipsis button not showing up
for you on the comment?

On 10/17/18 9:12 AM, Steve Ebersole wrote:
> Did someone remove the ability to edit one's comments?  I added a comment I
> would like to adjust syntax (code fragment), but Jira will not let me

From sanne at hibernate.org  Wed Oct 17 11:26:41 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 17 Oct 2018 16:26:41 +0100
Subject: [hibernate-dev] Deprecating Environment#verifyProperties
Message-ID: <CAFm4XO08ky_-1VkxyPY4YMsHCRFGG9uucbsStY7AayLKkWMGNA@mail.gmail.com>

Currently this method is used but not doing much at all, as maps
OBSOLETE_PROPERTIES and RENAMED_PROPERTIES are constant and empty.

I'm wondering if this is because it's just a coincidence at this point
in time we have nothing registered in those maps, or if this strategy
is just no longer the preferred choice to handle "out of date
configuration properties".

I'm guessing that going forward we all rather implement such logic
using ad-hoc logic and more specific error messages?

In that case I'd want to deprecate this code and remove those maps. Objections?

Thanks,
Sanne

From sanne at hibernate.org  Wed Oct 17 11:50:05 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 17 Oct 2018 16:50:05 +0100
Subject: [hibernate-dev] Introducing a "none" BytecodeProvider
Message-ID: <CAFm4XO1Wi3ucNvikp_EkxvhG--z9zgNEEwfUtRz+c1iPt55ALg@mail.gmail.com>

After some experimentation I figured out that the BytecodeProvider is
not really necessary, if you are happy to use the tools we have to
enhance the entities upfront.

In some environments such as on GraalVM I need to pre-enhance the
entities (need as in "not optional"), but some further things would be
really much simpler if I then could exclude Byte Buddy from runtime
dependencies.

As the code stands today, the Byte Buddy engine is loaded very early
during bootstrap (even if the entities are already enhanced, as we
didn't test for that yet at this point) and can't be disabled.

I have a successful experiment which introduces a "none" configuration
value for the "hibernate.bytecode.provider" property which allows me
to fully disable the need to have ByteBuddy on classpath at runtime.

I would not generally recommend this as there is no safety net: if you
set this property AND did not enhance your entities, I expect trouble.

Also there's a strong limitation: I could not implement the
`BasicProxyFactory`, which is probably making this unfit for general
purpose; I could use some help to nail down why exactly we need this
and see if we can actually implement an alternative - possibly having
the build time entity enhancement tools generate the necessary
bytecode upfront?

Still, I'd propose to merge this feature as an advanced feature that
some power users will need when making progress on support for new
platforms. Because of this experimental aspect, I'm not bothering to
mention it on the user guide :)

Ok?

Thanks,
Sanne

From steve at hibernate.org  Wed Oct 17 11:53:55 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 17 Oct 2018 10:53:55 -0500
Subject: [hibernate-dev] Jira - edit comments
In-Reply-To: <6c246b4e-5335-f475-7b59-8d36dab4e43f@hibernate.org>
References: <CAFdSV9sa5Y=sndLrph3Kga-aXxjJvY1kEF_FH5=K2X5xBLN43g@mail.gmail.com>
	<6c246b4e-5335-f475-7b59-8d36dab4e43f@hibernate.org>
Message-ID: <CAFdSV9sw+Yo7tyEEvq_HCLHKKEK2PZs5L7cGpOmi7_vamZqmRA@mail.gmail.com>

The elipse is there but the only option is Permalink


On Wed, Oct 17, 2018, 9:53 AM Chris Cranford <chris at hibernate.org> wrote:

> Steve -
>
> I have the option for my user.  Is the ellipsis button not showing up
> for you on the comment?
>
> On 10/17/18 9:12 AM, Steve Ebersole wrote:
> > Did someone remove the ability to edit one's comments?  I added a
> comment I
> > would like to adjust syntax (code fragment), but Jira will not let me
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From andrea at hibernate.org  Wed Oct 17 12:52:42 2018
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 17 Oct 2018 17:52:42 +0100
Subject: [hibernate-dev] Jira - edit comments
In-Reply-To: <CAFdSV9sw+Yo7tyEEvq_HCLHKKEK2PZs5L7cGpOmi7_vamZqmRA@mail.gmail.com>
References: <CAFdSV9sa5Y=sndLrph3Kga-aXxjJvY1kEF_FH5=K2X5xBLN43g@mail.gmail.com>
	<6c246b4e-5335-f475-7b59-8d36dab4e43f@hibernate.org>
	<CAFdSV9sw+Yo7tyEEvq_HCLHKKEK2PZs5L7cGpOmi7_vamZqmRA@mail.gmail.com>
Message-ID: <CAL00eSQ-hOEJg5dAitE+0d_tsrq=kTVVBJWd5m0SPgmkhecwxQ@mail.gmail.com>

I think this happens when a Jira is closed.

On Wed, 17 Oct 2018 at 17:27, Steve Ebersole <steve at hibernate.org> wrote:

> The elipse is there but the only option is Permalink
>
>
> On Wed, Oct 17, 2018, 9:53 AM Chris Cranford <chris at hibernate.org> wrote:
>
> > Steve -
> >
> > I have the option for my user.  Is the ellipsis button not showing up
> > for you on the comment?
> >
> > On 10/17/18 9:12 AM, Steve Ebersole wrote:
> > > Did someone remove the ability to edit one's comments?  I added a
> > comment I
> > > would like to adjust syntax (code fragment), but Jira will not let me
> > _______________________________________________
> > 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  Thu Oct 18 02:39:00 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 18 Oct 2018 08:39:00 +0200
Subject: [hibernate-dev] Introducing a "none" BytecodeProvider
In-Reply-To: <CAFm4XO1Wi3ucNvikp_EkxvhG--z9zgNEEwfUtRz+c1iPt55ALg@mail.gmail.com>
References: <CAFm4XO1Wi3ucNvikp_EkxvhG--z9zgNEEwfUtRz+c1iPt55ALg@mail.gmail.com>
Message-ID: <CAEqagpoQmCA87YCtLp4tQjhEPJ8rUm0_b+ypNh584WCznXjpvg@mail.gmail.com>

Can't say if it's a good or bad idea, but if you don't document it in the
user guide, please at least document how dangerous it is and why it can be
useful in the source code where the "none" option appears. I expect some
users will find it while debugging, try it out to solve their problems or
maybe just "to improve performance" and will have a bad experience... Not
to mention ourselves in a few weeks, of course :)

Regarding "BasicProxyFactory", Guillaume and I had to fight with this think
a few weeks ago, I think. If I remember correctly, it's used in particular
to instantiate abstract classes (!) during bootstrap. It seems to be needed
when copying data around from an object to another in particular; maybe
when the type of an @Embedded property is abstract? Someone else probably
knows more. All I can say is it made some tests fail some time ago, so you
can try making it throw exceptions and run the tests that fail in debug
mode, to see why it's useful exactly.


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


On Wed, 17 Oct 2018 at 19:47, Sanne Grinovero <sanne at hibernate.org> wrote:

> After some experimentation I figured out that the BytecodeProvider is
> not really necessary, if you are happy to use the tools we have to
> enhance the entities upfront.
>
> In some environments such as on GraalVM I need to pre-enhance the
> entities (need as in "not optional"), but some further things would be
> really much simpler if I then could exclude Byte Buddy from runtime
> dependencies.
>
> As the code stands today, the Byte Buddy engine is loaded very early
> during bootstrap (even if the entities are already enhanced, as we
> didn't test for that yet at this point) and can't be disabled.
>
> I have a successful experiment which introduces a "none" configuration
> value for the "hibernate.bytecode.provider" property which allows me
> to fully disable the need to have ByteBuddy on classpath at runtime.
>
> I would not generally recommend this as there is no safety net: if you
> set this property AND did not enhance your entities, I expect trouble.
>
> Also there's a strong limitation: I could not implement the
> `BasicProxyFactory`, which is probably making this unfit for general
> purpose; I could use some help to nail down why exactly we need this
> and see if we can actually implement an alternative - possibly having
> the build time entity enhancement tools generate the necessary
> bytecode upfront?
>
> Still, I'd propose to merge this feature as an advanced feature that
> some power users will need when making progress on support for new
> platforms. Because of this experimental aspect, I'm not bothering to
> mention it on the user guide :)
>
> Ok?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Oct 18 06:17:06 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 18 Oct 2018 11:17:06 +0100
Subject: [hibernate-dev] Jira - edit comments
In-Reply-To: <CAFdSV9sa5Y=sndLrph3Kga-aXxjJvY1kEF_FH5=K2X5xBLN43g@mail.gmail.com>
References: <CAFdSV9sa5Y=sndLrph3Kga-aXxjJvY1kEF_FH5=K2X5xBLN43g@mail.gmail.com>
Message-ID: <CAFm4XO3HJY0UyUCWt-qL3GRvrOaixLLrRst1EhX0ijgCCzNoEQ@mail.gmail.com>

I can't remember ever being allowed to edit comments.

For sure it wasn't allowed years back, I don't honestly know about recent
times as I never tried - probably having been coached by the old rule :)


On Thu, 18 Oct 2018, 11:06 Steve Ebersole, <steve at hibernate.org> wrote:

> Did someone remove the ability to edit one's comments?  I added a comment I
> would like to adjust syntax (code fragment), but Jira will not let me
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Oct 18 07:06:36 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 18 Oct 2018 12:06:36 +0100
Subject: [hibernate-dev] Deprecating Environment#verifyProperties
In-Reply-To: <CAFm4XO08ky_-1VkxyPY4YMsHCRFGG9uucbsStY7AayLKkWMGNA@mail.gmail.com>
References: <CAFm4XO08ky_-1VkxyPY4YMsHCRFGG9uucbsStY7AayLKkWMGNA@mail.gmail.com>
Message-ID: <CAFm4XO02FAoMytxsUccF92f11OEYqwWF119Jv6752zeC-dV=Cw@mail.gmail.com>

Since this is a rather un-interesting topic I guess I'll just proceed with a PR:
- https://github.com/hibernate/hibernate-orm/pull/2594

It can easily be reverted in case someone badly wants it back.

On Wed, 17 Oct 2018 at 16:26, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> Currently this method is used but not doing much at all, as maps
> OBSOLETE_PROPERTIES and RENAMED_PROPERTIES are constant and empty.
>
> I'm wondering if this is because it's just a coincidence at this point
> in time we have nothing registered in those maps, or if this strategy
> is just no longer the preferred choice to handle "out of date
> configuration properties".
>
> I'm guessing that going forward we all rather implement such logic
> using ad-hoc logic and more specific error messages?
>
> In that case I'd want to deprecate this code and remove those maps. Objections?
>
> Thanks,
> Sanne

From steve at hibernate.org  Thu Oct 18 07:29:05 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 18 Oct 2018 06:29:05 -0500
Subject: [hibernate-dev] Deprecating Environment#verifyProperties
In-Reply-To: <CAFm4XO02FAoMytxsUccF92f11OEYqwWF119Jv6752zeC-dV=Cw@mail.gmail.com>
References: <CAFm4XO08ky_-1VkxyPY4YMsHCRFGG9uucbsStY7AayLKkWMGNA@mail.gmail.com>
	<CAFm4XO02FAoMytxsUccF92f11OEYqwWF119Jv6752zeC-dV=Cw@mail.gmail.com>
Message-ID: <CAFdSV9sfs5P7+39v5MQq7Ncn0RwPxf_pLbRY1i-VbaGLC89_bw@mail.gmail.com>

For me its ok.  We end up handling each of these specifically anyway
nowadays.

On Thu, Oct 18, 2018 at 6:16 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Since this is a rather un-interesting topic I guess I'll just proceed with
> a PR:
> - https://github.com/hibernate/hibernate-orm/pull/2594
>
> It can easily be reverted in case someone badly wants it back.
>
> On Wed, 17 Oct 2018 at 16:26, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> > Currently this method is used but not doing much at all, as maps
> > OBSOLETE_PROPERTIES and RENAMED_PROPERTIES are constant and empty.
> >
> > I'm wondering if this is because it's just a coincidence at this point
> > in time we have nothing registered in those maps, or if this strategy
> > is just no longer the preferred choice to handle "out of date
> > configuration properties".
> >
> > I'm guessing that going forward we all rather implement such logic
> > using ad-hoc logic and more specific error messages?
> >
> > In that case I'd want to deprecate this code and remove those maps.
> Objections?
> >
> > Thanks,
> > Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Oct 18 07:29:40 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 18 Oct 2018 12:29:40 +0100
Subject: [hibernate-dev] Introducing a "none" BytecodeProvider
In-Reply-To: <CAEqagpoQmCA87YCtLp4tQjhEPJ8rUm0_b+ypNh584WCznXjpvg@mail.gmail.com>
References: <CAFm4XO1Wi3ucNvikp_EkxvhG--z9zgNEEwfUtRz+c1iPt55ALg@mail.gmail.com>
	<CAEqagpoQmCA87YCtLp4tQjhEPJ8rUm0_b+ypNh584WCznXjpvg@mail.gmail.com>
Message-ID: <CAFm4XO2rxs94p+Y4iBKrukjJPJ+q6vnV6c-nttiABYcmr0iL9g@mail.gmail.com>

On Thu, 18 Oct 2018 at 07:39, Yoann Rodiere <yoann at hibernate.org> wrote:
>
> Can't say if it's a good or bad idea, but if you don't document it in the user guide, please at least document how dangerous it is and why it can be useful in the source code where the "none" option appears. I expect some users will find it while debugging, try it out to solve their problems or maybe just "to improve performance" and will have a bad experience... Not to mention ourselves in a few weeks, of course :)

+1
It's not terribly dangerous as it's going to throw very explicit
exceptions on misconfiguration. But I agree, and because of those same
concerns is that we're having this thread.

I'm thinking of it as a slighly experimental thing which does no harm
in being merged, as it's entirely isolated by a "feature flag".

> Regarding "BasicProxyFactory", Guillaume and I had to fight with this think a few weeks ago, I think. If I remember correctly, it's used in particular to instantiate abstract classes (!) during bootstrap. It seems to be needed when copying data around from an object to another in particular; maybe when the type of an @Embedded property is abstract? Someone else probably knows more. All I can say is it made some tests fail some time ago, so you can try making it throw exceptions and run the tests that fail in debug mode, to see why it's useful exactly.

Thanks for the hint.

I had found some similar clues, and I'm thinking to just limit its
applicability to models which don't have similar needs: in a second
phase we could look at creating the necessary bytecode to handle these
corner cases as well by having the build time enhancement generate the
additional support classes.

>
>
> Yoann Rodi?re
> Hibernate NoORM Team
> yoann at hibernate.org
>
>
> On Wed, 17 Oct 2018 at 19:47, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> After some experimentation I figured out that the BytecodeProvider is
>> not really necessary, if you are happy to use the tools we have to
>> enhance the entities upfront.
>>
>> In some environments such as on GraalVM I need to pre-enhance the
>> entities (need as in "not optional"), but some further things would be
>> really much simpler if I then could exclude Byte Buddy from runtime
>> dependencies.
>>
>> As the code stands today, the Byte Buddy engine is loaded very early
>> during bootstrap (even if the entities are already enhanced, as we
>> didn't test for that yet at this point) and can't be disabled.
>>
>> I have a successful experiment which introduces a "none" configuration
>> value for the "hibernate.bytecode.provider" property which allows me
>> to fully disable the need to have ByteBuddy on classpath at runtime.
>>
>> I would not generally recommend this as there is no safety net: if you
>> set this property AND did not enhance your entities, I expect trouble.
>>
>> Also there's a strong limitation: I could not implement the
>> `BasicProxyFactory`, which is probably making this unfit for general
>> purpose; I could use some help to nail down why exactly we need this
>> and see if we can actually implement an alternative - possibly having
>> the build time entity enhancement tools generate the necessary
>> bytecode upfront?
>>
>> Still, I'd propose to merge this feature as an advanced feature that
>> some power users will need when making progress on support for new
>> platforms. Because of this experimental aspect, I'm not bothering to
>> mention it on the user guide :)
>>
>> Ok?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Thu Oct 18 07:39:10 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 18 Oct 2018 06:39:10 -0500
Subject: [hibernate-dev] Jira - edit comments
In-Reply-To: <CAFm4XO3HJY0UyUCWt-qL3GRvrOaixLLrRst1EhX0ijgCCzNoEQ@mail.gmail.com>
References: <CAFdSV9sa5Y=sndLrph3Kga-aXxjJvY1kEF_FH5=K2X5xBLN43g@mail.gmail.com>
	<CAFm4XO3HJY0UyUCWt-qL3GRvrOaixLLrRst1EhX0ijgCCzNoEQ@mail.gmail.com>
Message-ID: <CAFdSV9vZh+LQEwYiz5QGOr13ArvGCZobydUBmoczDT-pU6SxGA@mail.gmail.com>

For sure it *was* allowed for years ;)

Initially I set up the permissions that a user could edit their own
comments.  I think admins could edit any, but I do not remember that part
for sure.

On Thu, Oct 18, 2018 at 5:17 AM Sanne Grinovero <sanne at hibernate.org> wrote:

>
> I can't remember ever being allowed to edit comments.
>
> For sure it wasn't allowed years back, I don't honestly know about recent
> times as I never tried - probably having been coached by the old rule :)
>
>
> On Thu, 18 Oct 2018, 11:06 Steve Ebersole, <steve at hibernate.org> wrote:
>
>> Did someone remove the ability to edit one's comments?  I added a comment
>> I
>> would like to adjust syntax (code fragment), but Jira will not let me
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From sanne at hibernate.org  Thu Oct 18 07:45:00 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 18 Oct 2018 12:45:00 +0100
Subject: [hibernate-dev] Jira - edit comments
In-Reply-To: <CAFdSV9vZh+LQEwYiz5QGOr13ArvGCZobydUBmoczDT-pU6SxGA@mail.gmail.com>
References: <CAFdSV9sa5Y=sndLrph3Kga-aXxjJvY1kEF_FH5=K2X5xBLN43g@mail.gmail.com>
	<CAFm4XO3HJY0UyUCWt-qL3GRvrOaixLLrRst1EhX0ijgCCzNoEQ@mail.gmail.com>
	<CAFdSV9vZh+LQEwYiz5QGOr13ArvGCZobydUBmoczDT-pU6SxGA@mail.gmail.com>
Message-ID: <CAFm4XO2qn6D7zNP7z4hAZOsE5W0Za_jf4xWHFn_edqFpA3-01g@mail.gmail.com>

On Thu, 18 Oct 2018 at 12:39, Steve Ebersole <steve at hibernate.org> wrote:
>
> For sure it *was* allowed for years ;)

Ok, maybe it was just in my mind, but because of that I never tried so
I would never have noticed any change :)

For sure I didn't reconfigure that myself.

>
> Initially I set up the permissions that a user could edit their own comments.  I think admins could edit any, but I do not remember that part for sure.
>
> On Thu, Oct 18, 2018 at 5:17 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>>
>> I can't remember ever being allowed to edit comments.
>>
>> For sure it wasn't allowed years back, I don't honestly know about recent times as I never tried - probably having been coached by the old rule :)
>>
>>
>> On Thu, 18 Oct 2018, 11:06 Steve Ebersole, <steve at hibernate.org> wrote:
>>>
>>> Did someone remove the ability to edit one's comments?  I added a comment I
>>> would like to adjust syntax (code fragment), but Jira will not let me
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Thu Oct 18 07:46:06 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 18 Oct 2018 12:46:06 +0100
Subject: [hibernate-dev] Deprecating Environment#verifyProperties
In-Reply-To: <CAFdSV9sfs5P7+39v5MQq7Ncn0RwPxf_pLbRY1i-VbaGLC89_bw@mail.gmail.com>
References: <CAFm4XO08ky_-1VkxyPY4YMsHCRFGG9uucbsStY7AayLKkWMGNA@mail.gmail.com>
	<CAFm4XO02FAoMytxsUccF92f11OEYqwWF119Jv6752zeC-dV=Cw@mail.gmail.com>
	<CAFdSV9sfs5P7+39v5MQq7Ncn0RwPxf_pLbRY1i-VbaGLC89_bw@mail.gmail.com>
Message-ID: <CAFm4XO0uOKkthesRTJ_WUawDZpQ6_WSFpOeVxpGtvi_0xNxeBw@mail.gmail.com>

On Thu, 18 Oct 2018 at 12:29, Steve Ebersole <steve at hibernate.org> wrote:
>
> For me its ok.  We end up handling each of these specifically anyway nowadays.

Thanks! I'll merge then.

>
> On Thu, Oct 18, 2018 at 6:16 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Since this is a rather un-interesting topic I guess I'll just proceed with a PR:
>> - https://github.com/hibernate/hibernate-orm/pull/2594
>>
>> It can easily be reverted in case someone badly wants it back.
>>
>> On Wed, 17 Oct 2018 at 16:26, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >
>> > Currently this method is used but not doing much at all, as maps
>> > OBSOLETE_PROPERTIES and RENAMED_PROPERTIES are constant and empty.
>> >
>> > I'm wondering if this is because it's just a coincidence at this point
>> > in time we have nothing registered in those maps, or if this strategy
>> > is just no longer the preferred choice to handle "out of date
>> > configuration properties".
>> >
>> > I'm guessing that going forward we all rather implement such logic
>> > using ad-hoc logic and more specific error messages?
>> >
>> > In that case I'd want to deprecate this code and remove those maps. Objections?
>> >
>> > Thanks,
>> > Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Oct 18 08:03:10 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 18 Oct 2018 07:03:10 -0500
Subject: [hibernate-dev] Jira - edit comments
In-Reply-To: <CAFm4XO2qn6D7zNP7z4hAZOsE5W0Za_jf4xWHFn_edqFpA3-01g@mail.gmail.com>
References: <CAFdSV9sa5Y=sndLrph3Kga-aXxjJvY1kEF_FH5=K2X5xBLN43g@mail.gmail.com>
	<CAFm4XO3HJY0UyUCWt-qL3GRvrOaixLLrRst1EhX0ijgCCzNoEQ@mail.gmail.com>
	<CAFdSV9vZh+LQEwYiz5QGOr13ArvGCZobydUBmoczDT-pU6SxGA@mail.gmail.com>
	<CAFm4XO2qn6D7zNP7z4hAZOsE5W0Za_jf4xWHFn_edqFpA3-01g@mail.gmail.com>
Message-ID: <CAFdSV9uP_nMiwgunD6JptMLuMhuKTbcZfMu=9ob=dUxe78MDmQ@mail.gmail.com>

Interesting... That is still the permission in the settings.  But for
some reason I cannot.  I do not think the issue was closed, but honestly
its now been a few days and I forget which issue it is :(

On Thu, Oct 18, 2018 at 6:45 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On Thu, 18 Oct 2018 at 12:39, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > For sure it *was* allowed for years ;)
>
> Ok, maybe it was just in my mind, but because of that I never tried so
> I would never have noticed any change :)
>
> For sure I didn't reconfigure that myself.
>
> >
> > Initially I set up the permissions that a user could edit their own
> comments.  I think admins could edit any, but I do not remember that part
> for sure.
> >
> > On Thu, Oct 18, 2018 at 5:17 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >>
> >> I can't remember ever being allowed to edit comments.
> >>
> >> For sure it wasn't allowed years back, I don't honestly know about
> recent times as I never tried - probably having been coached by the old
> rule :)
> >>
> >>
> >> On Thu, 18 Oct 2018, 11:06 Steve Ebersole, <steve at hibernate.org> wrote:
> >>>
> >>> Did someone remove the ability to edit one's comments?  I added a
> comment I
> >>> would like to adjust syntax (code fragment), but Jira will not let me
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Thu Oct 18 09:01:43 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 18 Oct 2018 15:01:43 +0200
Subject: [hibernate-dev] Introducing a "none" BytecodeProvider
In-Reply-To: <CAFm4XO2rxs94p+Y4iBKrukjJPJ+q6vnV6c-nttiABYcmr0iL9g@mail.gmail.com>
References: <CAFm4XO1Wi3ucNvikp_EkxvhG--z9zgNEEwfUtRz+c1iPt55ALg@mail.gmail.com>
	<CAEqagpoQmCA87YCtLp4tQjhEPJ8rUm0_b+ypNh584WCznXjpvg@mail.gmail.com>
	<CAFm4XO2rxs94p+Y4iBKrukjJPJ+q6vnV6c-nttiABYcmr0iL9g@mail.gmail.com>
Message-ID: <CALt0+o-15i=KhNYN2DyKoTiuYBdz_1SGTBtX3ROgedxc4fw6gg@mail.gmail.com>

Hi,

On Thu, Oct 18, 2018 at 1:33 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> > Regarding "BasicProxyFactory", Guillaume and I had to fight with this
> think a few weeks ago, I think. If I remember correctly, it's used in
> particular to instantiate abstract classes (!) during bootstrap. It seems
> to be needed when copying data around from an object to another in
> particular; maybe when the type of an @Embedded property is abstract?
> Someone else probably knows more. All I can say is it made some tests fail
> some time ago, so you can try making it throw exceptions and run the tests
> that fail in debug mode, to see why it's useful exactly.
>
> Thanks for the hint.
>
> I had found some similar clues, and I'm thinking to just limit its
> applicability to models which don't have similar needs: in a second
> phase we could look at creating the necessary bytecode to handle these
> corner cases as well by having the build time enhancement generate the
> additional support classes.


All I can say is that it's useful in some corner cases. If I remember
correctly, Yoann is right about abstract @Embedded properties.

Creating the classes at enhancement time could be a possibility but I'm not
sure we have all the information required to do that when we enhance the
entities.

I think it goes without saying but we still need to have ORM working
without enhancement, considering how many bugs we have related to enhanced
classes.

-- 
Guillaume

From steve at hibernate.org  Thu Oct 18 09:39:25 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 18 Oct 2018 08:39:25 -0500
Subject: [hibernate-dev] Introducing a "none" BytecodeProvider
In-Reply-To: <CALt0+o-15i=KhNYN2DyKoTiuYBdz_1SGTBtX3ROgedxc4fw6gg@mail.gmail.com>
References: <CAFm4XO1Wi3ucNvikp_EkxvhG--z9zgNEEwfUtRz+c1iPt55ALg@mail.gmail.com>
	<CAEqagpoQmCA87YCtLp4tQjhEPJ8rUm0_b+ypNh584WCznXjpvg@mail.gmail.com>
	<CAFm4XO2rxs94p+Y4iBKrukjJPJ+q6vnV6c-nttiABYcmr0iL9g@mail.gmail.com>
	<CALt0+o-15i=KhNYN2DyKoTiuYBdz_1SGTBtX3ROgedxc4fw6gg@mail.gmail.com>
Message-ID: <CAFdSV9u70c0YYTvbwB=NwtfBuzPj6ROAVk8bkRDRE5O1u+-bwQ@mail.gmail.com>

We need to keep it working without enhancement, bugs or not


On Thu, Oct 18, 2018, 8:27 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> On Thu, Oct 18, 2018 at 1:33 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > > Regarding "BasicProxyFactory", Guillaume and I had to fight with this
> > think a few weeks ago, I think. If I remember correctly, it's used in
> > particular to instantiate abstract classes (!) during bootstrap. It seems
> > to be needed when copying data around from an object to another in
> > particular; maybe when the type of an @Embedded property is abstract?
> > Someone else probably knows more. All I can say is it made some tests
> fail
> > some time ago, so you can try making it throw exceptions and run the
> tests
> > that fail in debug mode, to see why it's useful exactly.
> >
> > Thanks for the hint.
> >
> > I had found some similar clues, and I'm thinking to just limit its
> > applicability to models which don't have similar needs: in a second
> > phase we could look at creating the necessary bytecode to handle these
> > corner cases as well by having the build time enhancement generate the
> > additional support classes.
>
>
> All I can say is that it's useful in some corner cases. If I remember
> correctly, Yoann is right about abstract @Embedded properties.
>
> Creating the classes at enhancement time could be a possibility but I'm not
> sure we have all the information required to do that when we enhance the
> entities.
>
> I think it goes without saying but we still need to have ORM working
> without enhancement, considering how many bugs we have related to enhanced
> classes.
>
> --
> Guillaume
> _______________________________________________
> 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  Thu Oct 18 10:33:31 2018
From: graham_hibernate at collo.me.uk (Graham Collinson)
Date: Thu, 18 Oct 2018 15:33:31 +0100
Subject: [hibernate-dev] HBX-1193 (oracle) reverse engineering of
 UniqueConstraint annotation for function-based indexes
Message-ID: <CAK_6CLOonem4SQzngWYx1fZgnuyqJ7WeGzC0RmfeoH6gLDUbog@mail.gmail.com>



From sfikes at redhat.com  Fri Oct 19 18:31:06 2018
From: sfikes at redhat.com (Stephen Fikes)
Date: Fri, 19 Oct 2018 17:31:06 -0500
Subject: [hibernate-dev] XML access to entities
Message-ID: <0b27a63d-ba8c-b99f-45be-72ef55c67645@redhat.com>

Is there a known / recommended solution for working with Hibernate entities as XML?

There used to be an XML based session (DOM4J) but this is no longer a part of current Hibernate versions.

Thanks!
Stephen


From sanne at hibernate.org  Sun Oct 21 15:48:44 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 21 Oct 2018 20:48:44 +0100
Subject: [hibernate-dev] Introducing a "none" BytecodeProvider
In-Reply-To: <CALt0+o-15i=KhNYN2DyKoTiuYBdz_1SGTBtX3ROgedxc4fw6gg@mail.gmail.com>
References: <CAFm4XO1Wi3ucNvikp_EkxvhG--z9zgNEEwfUtRz+c1iPt55ALg@mail.gmail.com>
	<CAEqagpoQmCA87YCtLp4tQjhEPJ8rUm0_b+ypNh584WCznXjpvg@mail.gmail.com>
	<CAFm4XO2rxs94p+Y4iBKrukjJPJ+q6vnV6c-nttiABYcmr0iL9g@mail.gmail.com>
	<CALt0+o-15i=KhNYN2DyKoTiuYBdz_1SGTBtX3ROgedxc4fw6gg@mail.gmail.com>
Message-ID: <CAFm4XO3R3xmyJSzv=r8dvuvQ3kMj9R2+nEHRnR8b7RYWMuE-tQ@mail.gmail.com>

On Thu, 18 Oct 2018 at 14:02, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>
> Hi,
>
> On Thu, Oct 18, 2018 at 1:33 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> > Regarding "BasicProxyFactory", Guillaume and I had to fight with this think a few weeks ago, I think. If I remember correctly, it's used in particular to instantiate abstract classes (!) during bootstrap. It seems to be needed when copying data around from an object to another in particular; maybe when the type of an @Embedded property is abstract? Someone else probably knows more. All I can say is it made some tests fail some time ago, so you can try making it throw exceptions and run the tests that fail in debug mode, to see why it's useful exactly.
>>
>> Thanks for the hint.
>>
>> I had found some similar clues, and I'm thinking to just limit its
>> applicability to models which don't have similar needs: in a second
>> phase we could look at creating the necessary bytecode to handle these
>> corner cases as well by having the build time enhancement generate the
>> additional support classes.
>
>
> All I can say is that it's useful in some corner cases. If I remember correctly, Yoann is right about abstract @Embedded properties.
>
> Creating the classes at enhancement time could be a possibility but I'm not sure we have all the information required to do that when we enhance the entities.
>
> I think it goes without saying but we still need to have ORM working without enhancement, considering how many bugs we have related to enhanced classes.

I didn't understand thist last sentence. Could you please clarify?

Thanks,
Sanne


From steve at hibernate.org  Sun Oct 21 17:18:49 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 21 Oct 2018 16:18:49 -0500
Subject: [hibernate-dev] XML access to entities
In-Reply-To: <0b27a63d-ba8c-b99f-45be-72ef55c67645@redhat.com>
References: <0b27a63d-ba8c-b99f-45be-72ef55c67645@redhat.com>
Message-ID: <CAFdSV9sWeuc9dsPdf11XLernWfw=RyhC=NEwfQuudRN2Vd4cNQ@mail.gmail.com>

Yes, there used to be very buggy and extremely limited support for DOM4J as
an EntityMode.  It was removed because it was, well, buggy and extremely
limited ;)

IMO the proper solution is something more like JAXB or other XML
transformations.

On Fri, Oct 19, 2018 at 11:34 PM Stephen Fikes <sfikes at redhat.com> wrote:

> Is there a known / recommended solution for working with Hibernate
> entities as XML?
>
> There used to be an XML based session (DOM4J) but this is no longer a part
> of current Hibernate versions.
>
> Thanks!
> Stephen
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From yoann at hibernate.org  Mon Oct 22 04:00:14 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 22 Oct 2018 10:00:14 +0200
Subject: [hibernate-dev] ORM 5.4 breaking SPIs - MetamodelImplementor
Message-ID: <CAEqagpogXPbLt61v+auvxj2GMNJw5DiMnneYo8Ch8nt5SzABpA@mail.gmail.com>

Hello,

Thanks to a periodic Hibernate Search build I set up to run against
Hibernate ORM 5.4, I just noticed [1] a backward-incompatible change in ORM
5.4 [2]: mainly, the MetamodelImplementor class was moved from
org.hibernate.metamodel.spi to org.hibernate.metamodel.model.domain.spi.

While I understand that SPI changes are allowed in minor version
increments, it was my understanding that 5.4 was supposed to only bring
fixes that we are not comfortable with merging into 5.3, not new features
or improvements. Did I understand that correctly?

If so, I'd suggest to cancel this renaming, or at least restore the old
interface, deprecate it and make it a superinterface of the new one, to
restore backward compatibility. And see if other SPIs should benefit from
the same treatment.

If not, I will give up on the idea of Search 5.10 being compatible with ORM
5.4, and will plan for a 5.11. Let's hope the changes in ORM 5.4 won't
affect EAP/Spring/etc., though. I suppose if it's only SPI it should be
alright...

Steve, folks, WDYT?

[1]
http://ci.hibernate.org/blue/organizations/jenkins/hibernate-search-yoann/detail/tracking-orm5.4-5.10/37/pipeline
[2]
https://github.com/hibernate/hibernate-orm/commit/5e8781f8fa123d4e437f669b57cfa1456a169873#diff-ec7b62fc3d87a760b16c20b1710d2e70L7


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

From guillaume.smet at gmail.com  Mon Oct 22 04:52:42 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 22 Oct 2018 10:52:42 +0200
Subject: [hibernate-dev] Introducing a "none" BytecodeProvider
In-Reply-To: <CAFm4XO3R3xmyJSzv=r8dvuvQ3kMj9R2+nEHRnR8b7RYWMuE-tQ@mail.gmail.com>
References: <CAFm4XO1Wi3ucNvikp_EkxvhG--z9zgNEEwfUtRz+c1iPt55ALg@mail.gmail.com>
	<CAEqagpoQmCA87YCtLp4tQjhEPJ8rUm0_b+ypNh584WCznXjpvg@mail.gmail.com>
	<CAFm4XO2rxs94p+Y4iBKrukjJPJ+q6vnV6c-nttiABYcmr0iL9g@mail.gmail.com>
	<CALt0+o-15i=KhNYN2DyKoTiuYBdz_1SGTBtX3ROgedxc4fw6gg@mail.gmail.com>
	<CAFm4XO3R3xmyJSzv=r8dvuvQ3kMj9R2+nEHRnR8b7RYWMuE-tQ@mail.gmail.com>
Message-ID: <CALt0+o_=A1xoxueFf9tHk7u00FWCnHGqkQVBvxiyfbNivmNn3w@mail.gmail.com>

On Sun, Oct 21, 2018 at 9:48 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> > I think it goes without saying but we still need to have ORM working
> without enhancement, considering how many bugs we have related to enhanced
> classes.
>
> I didn't understand thist last sentence. Could you please clarify?
>

Even if we move the proxy creation to the enhancement phase, we would still
need it in the main code for people not using enhancement.

E.g. it would have to be conditioned but still present.

-- 
Guillaume

From sanne at hibernate.org  Mon Oct 22 04:56:15 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 22 Oct 2018 09:56:15 +0100
Subject: [hibernate-dev] Introducing a "none" BytecodeProvider
In-Reply-To: <CALt0+o_=A1xoxueFf9tHk7u00FWCnHGqkQVBvxiyfbNivmNn3w@mail.gmail.com>
References: <CAFm4XO1Wi3ucNvikp_EkxvhG--z9zgNEEwfUtRz+c1iPt55ALg@mail.gmail.com>
	<CAEqagpoQmCA87YCtLp4tQjhEPJ8rUm0_b+ypNh584WCznXjpvg@mail.gmail.com>
	<CAFm4XO2rxs94p+Y4iBKrukjJPJ+q6vnV6c-nttiABYcmr0iL9g@mail.gmail.com>
	<CALt0+o-15i=KhNYN2DyKoTiuYBdz_1SGTBtX3ROgedxc4fw6gg@mail.gmail.com>
	<CAFm4XO3R3xmyJSzv=r8dvuvQ3kMj9R2+nEHRnR8b7RYWMuE-tQ@mail.gmail.com>
	<CALt0+o_=A1xoxueFf9tHk7u00FWCnHGqkQVBvxiyfbNivmNn3w@mail.gmail.com>
Message-ID: <CAFm4XO3p_PrexftO+f9r-BM6oPCooJfP3H6HWLW5r_Gb2jZmdg@mail.gmail.com>

On Mon, 22 Oct 2018 at 09:53, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>
> On Sun, Oct 21, 2018 at 9:48 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> > I think it goes without saying but we still need to have ORM working without enhancement, considering how many bugs we have related to enhanced classes.
>>
>> I didn't understand thist last sentence. Could you please clarify?
>
>
> Even if we move the proxy creation to the enhancement phase, we would still need it in the main code for people not using enhancement.
>
> E.g. it would have to be conditioned but still present.

Yes of course! Thanks

>
> --
> Guillaume

From sanne at hibernate.org  Mon Oct 22 13:46:18 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 22 Oct 2018 18:46:18 +0100
Subject: [hibernate-dev] Github storage / consensus protocol
Message-ID: <CAFm4XO1RVuSvs3AXAZtS6F4WMGH_CrQ3fA_pX-zS-u3Q=NcPoA@mail.gmail.com>

Hi all,

github had some problems last night / this morning with their storage service.

Problem should have been solved by now, but social media highlithed
some reports of people having some of the most recent commits; in some
cases pull requests.

Nothing to panic about as git is well distributed and we all have replicas :)

So let's take advante of its design and perform a consensus check:
could you all please make sure that what you've recently pushed is still there?

I don't expect we'll find any discrepancies, but if you do please
report them here.

Thanks,
Sanne

From yoann at hibernate.org  Tue Oct 23 04:28:59 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 23 Oct 2018 10:28:59 +0200
Subject: [hibernate-dev] Chat migration - D minus 115 until the death of
	HipChat
Message-ID: <CAEqagpqit=rUeNA+ZagM0NYA2rPhxXspqRDRQuNq-UqmMnLppg@mail.gmail.com>

Hi,

TL;DR: please vote here if you don't want to end up having to use a chat
tool you don't like: https://doodle.com/poll/h6scc9bsh6a4ymre

HipChat Cloud will stop working on February 15th, 2019 [1]. We need to
choose an alternative before we have our back against the wall, so I'll try
to resurrect the conversation.

As a reminder, Stride is no longer an option: Atlassian cancelled the
project, and encourages users to migrate to Slack.

The discussed options so far were:

   - *Moving back to IRC*. Aye: ?; nay: ?
   Pros: simple as hell.
   Cons: basic as hell; we won't keep the chat history.
   - *Migrating to Slack* [6], as suggested by Atlassian [2]. Aye:
   Christian B; Nay: ?
   Pros: we will keep the chat history (I think).
   Cons: not open-source; desktop client consumes a lot of resources.
   - *Migrating to Zulip* [3]. Aye: Emmanuel, Yoann. Nay: Guillaume (kind
   of).
   Pros: Advanced conversation management thanks to the "topics" feature.
   Cons: Complex to use because of the "topics" feature; we won't keep the
   chat history (1).
   - *Migrating to Gitter* [5] (we'll create different rooms, probably).
   Aye: ?, Nay: ?
   Pros: Users seem to actually go there, so we could have our "live
   support" rooms next to our "internal discussion" rooms.
   Cons: not open-source; we won't keep the chat history (1).

I created a poll based on the discussion we had on the thread
"[hibernate-dev] Stride". I think everyone had the time to suggest another
option.

Please vote here and now, or remain silent forever ;):
https://doodle.com/poll/h6scc9bsh6a4ymre

I'd suggest the following rules: if there's a single clear winner (a
platform that everyone would be happy with), we'll pick that one. If there
are multiple clear winners, whoever does the migration work will pick
what's easier to set up (taking into account the various integrations).
Otherwise, back to discussing it on this thread...

(1) There seems to be some work in progress on a migration tool from
HipChat to Zulip, but it doesn't seem to be ready yet [4]

[1]
https://www.atlassian.com/partnerships/slack/faq#faq-da2b66a1-53d3-4c4e-a405-467d961336f7
[2] https://www.atlassian.com/partnerships/slack/migration
[3] https://hibernate.zulipchat.com/
[4] https://github.com/zulip/zulip/issues/10647
[5] https://gitter.im/hibernate/hibernate-orm
[6] https://slackdemo.com/

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

From sanne at hibernate.org  Tue Oct 23 06:02:06 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 23 Oct 2018 11:02:06 +0100
Subject: [hibernate-dev] Chat migration - D minus 115 until the death of
	HipChat
In-Reply-To: <CAEqagpqit=rUeNA+ZagM0NYA2rPhxXspqRDRQuNq-UqmMnLppg@mail.gmail.com>
References: <CAEqagpqit=rUeNA+ZagM0NYA2rPhxXspqRDRQuNq-UqmMnLppg@mail.gmail.com>
Message-ID: <CAFm4XO31HS2KN5v2rGYjcDf23+2+NC_97oKn2_RLK-HPC5usGQ@mail.gmail.com>

Thanks for starting this!

The choice of IRC is a bit special on the list as we never intended it
to be killed: it has been historically important and we should
maintain some level of reachability on it.  So voting for the "IRC"
choice just means a preference to not use anything else on top of it,
while alternatively we'' be using X on top of IRC, albeit with a
preference to use X for team conversations.

Also good to remind: please try to be on IRC as well occasionally as
many in the OSS community we integrate with will reach out there.

Thanks,
Sanne

On Tue, 23 Oct 2018 at 09:46, Yoann Rodiere <yoann at hibernate.org> wrote:
>
> Hi,
>
> TL;DR: please vote here if you don't want to end up having to use a chat
> tool you don't like: https://doodle.com/poll/h6scc9bsh6a4ymre
>
> HipChat Cloud will stop working on February 15th, 2019 [1]. We need to
> choose an alternative before we have our back against the wall, so I'll try
> to resurrect the conversation.
>
> As a reminder, Stride is no longer an option: Atlassian cancelled the
> project, and encourages users to migrate to Slack.
>
> The discussed options so far were:
>
>    - *Moving back to IRC*. Aye: ?; nay: ?
>    Pros: simple as hell.
>    Cons: basic as hell; we won't keep the chat history.
>    - *Migrating to Slack* [6], as suggested by Atlassian [2]. Aye:
>    Christian B; Nay: ?
>    Pros: we will keep the chat history (I think).
>    Cons: not open-source; desktop client consumes a lot of resources.
>    - *Migrating to Zulip* [3]. Aye: Emmanuel, Yoann. Nay: Guillaume (kind
>    of).
>    Pros: Advanced conversation management thanks to the "topics" feature.
>    Cons: Complex to use because of the "topics" feature; we won't keep the
>    chat history (1).
>    - *Migrating to Gitter* [5] (we'll create different rooms, probably).
>    Aye: ?, Nay: ?
>    Pros: Users seem to actually go there, so we could have our "live
>    support" rooms next to our "internal discussion" rooms.
>    Cons: not open-source; we won't keep the chat history (1).
>
> I created a poll based on the discussion we had on the thread
> "[hibernate-dev] Stride". I think everyone had the time to suggest another
> option.
>
> Please vote here and now, or remain silent forever ;):
> https://doodle.com/poll/h6scc9bsh6a4ymre
>
> I'd suggest the following rules: if there's a single clear winner (a
> platform that everyone would be happy with), we'll pick that one. If there
> are multiple clear winners, whoever does the migration work will pick
> what's easier to set up (taking into account the various integrations).
> Otherwise, back to discussing it on this thread...
>
> (1) There seems to be some work in progress on a migration tool from
> HipChat to Zulip, but it doesn't seem to be ready yet [4]
>
> [1]
> https://www.atlassian.com/partnerships/slack/faq#faq-da2b66a1-53d3-4c4e-a405-467d961336f7
> [2] https://www.atlassian.com/partnerships/slack/migration
> [3] https://hibernate.zulipchat.com/
> [4] https://github.com/zulip/zulip/issues/10647
> [5] https://gitter.im/hibernate/hibernate-orm
> [6] https://slackdemo.com/
>
> 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


From guillaume.smet at gmail.com  Tue Oct 23 09:23:09 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 23 Oct 2018 15:23:09 +0200
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o_sU4se7wjfLFxV4q8Di_e_63a=K84A5FZsuLmVFpKeNQ@mail.gmail.com>

Hi,

Here are the minutes of our IRC meeting:
15:20 < jbott> Meeting ended Tue Oct 23 13:20:49 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:20 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-10-23-13.00.html
15:20 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-10-23-13.00.txt
15:20 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-10-23-13.00.log.html

Cheers,

-- 
Guillaume

From graham_hibernate at collo.me.uk  Tue Oct 23 16:52:34 2018
From: graham_hibernate at collo.me.uk (Graham Collinson)
Date: Tue, 23 Oct 2018 21:52:34 +0100
Subject: [hibernate-dev] HBX-1193 (oracle) reverse engineering of
 UniqueConstraint annotation for function-based indexes
In-Reply-To: <CAK_6CLOonem4SQzngWYx1fZgnuyqJ7WeGzC0RmfeoH6gLDUbog@mail.gmail.com>
References: <CAK_6CLOonem4SQzngWYx1fZgnuyqJ7WeGzC0RmfeoH6gLDUbog@mail.gmail.com>
Message-ID: <CAK_6CLPJbTot-BNXXGfkGcyTKzepy6tgeDYS+oiOUspj6oHK2Q@mail.gmail.com>

Apologies for the empty email last time

https://hibernate.atlassian.net/browse/HBX-1193

Hi,

I've submitted a pull request for this issue.
Is there anything more I need to do or could help with to close this one
off?

Thanks,
Graham

From coladict at gmail.com  Wed Oct 24 06:41:24 2018
From: coladict at gmail.com (Jordan Gigov)
Date: Wed, 24 Oct 2018 13:41:24 +0300
Subject: [hibernate-dev] Getting automatically removed from the list for
	"excessive bounces"?
Message-ID: <CA+nBocCv_KOVoLL4gvDBP_Jd+xMVgN3QUtm2RM0OicUHtRzR5Q@mail.gmail.com>

I've started getting these every month from this list:
> Your membership in the mailing list hibernate-dev has been disabled
> due to excessive bounces The last bounce received from you was dated
> 24-Oct-2018.  You will not get any more messages from this list until
> you re-enable your membership.  You will receive 3 more reminders like
> this before your membership in the list is deleted.

Otherwise messages from the list come in normally in my inbox and not
marked as spam.

Does this only affect me, all GMail subscribers, or an even wider audience?

From sanne at hibernate.org  Wed Oct 24 07:12:50 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 24 Oct 2018 12:12:50 +0100
Subject: [hibernate-dev] Getting automatically removed from the list for
 "excessive bounces"?
In-Reply-To: <CA+nBocCv_KOVoLL4gvDBP_Jd+xMVgN3QUtm2RM0OicUHtRzR5Q@mail.gmail.com>
References: <CA+nBocCv_KOVoLL4gvDBP_Jd+xMVgN3QUtm2RM0OicUHtRzR5Q@mail.gmail.com>
Message-ID: <CAFm4XO2=AnXDvswNNEhj74bAzsxZ21C-EnYtH4qgGcbpt9voNA@mail.gmail.com>

Hi Jordan,

I have an error message from our mail server stating that messages to
you (and 8 more people, among them we also have regulars like Vlad and
Christian Beikov) have been bouncing back often in the past 2 days. It
eventually gave up so you might miss some emails from this list.

I'm not sure why; but it's interesting to note that all 9 people on
this error message are using gmail. I'll open a support ticket for
those managing the mail server but I'm not sure if they will be able
to to anything, as it seems it's gmail refusing them.

Thanks,
Sanne
On Wed, 24 Oct 2018 at 11:42, Jordan Gigov <coladict at gmail.com> wrote:
>
> I've started getting these every month from this list:
> > Your membership in the mailing list hibernate-dev has been disabled
> > due to excessive bounces The last bounce received from you was dated
> > 24-Oct-2018.  You will not get any more messages from this list until
> > you re-enable your membership.  You will receive 3 more reminders like
> > this before your membership in the list is deleted.
>
> Otherwise messages from the list come in normally in my inbox and not
> marked as spam.
>
> Does this only affect me, all GMail subscribers, or an even wider audience?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From alessiostalla at gmail.com  Wed Oct 24 09:26:02 2018
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Wed, 24 Oct 2018 15:26:02 +0200
Subject: [hibernate-dev] Getting automatically removed from the list for
 "excessive bounces"?
In-Reply-To: <CAFm4XO2=AnXDvswNNEhj74bAzsxZ21C-EnYtH4qgGcbpt9voNA@mail.gmail.com>
References: <CA+nBocCv_KOVoLL4gvDBP_Jd+xMVgN3QUtm2RM0OicUHtRzR5Q@mail.gmail.com>
	<CAFm4XO2=AnXDvswNNEhj74bAzsxZ21C-EnYtH4qgGcbpt9voNA@mail.gmail.com>
Message-ID: <CAL2Kp+iSy+mXfWn4CH=j_HHUG7-okp=RyL086iH61=t3AR_M_Q@mail.gmail.com>

Hi,
I've got the excessive bounces message several times, too, and I'm using
Gmail.

Alessio

On Wed, 24 Oct 2018 at 15:24, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Jordan,
>
> I have an error message from our mail server stating that messages to
> you (and 8 more people, among them we also have regulars like Vlad and
> Christian Beikov) have been bouncing back often in the past 2 days. It
> eventually gave up so you might miss some emails from this list.
>
> I'm not sure why; but it's interesting to note that all 9 people on
> this error message are using gmail. I'll open a support ticket for
> those managing the mail server but I'm not sure if they will be able
> to to anything, as it seems it's gmail refusing them.
>
> Thanks,
> Sanne
> On Wed, 24 Oct 2018 at 11:42, Jordan Gigov <coladict at gmail.com> wrote:
> >
> > I've started getting these every month from this list:
> > > Your membership in the mailing list hibernate-dev has been disabled
> > > due to excessive bounces The last bounce received from you was dated
> > > 24-Oct-2018.  You will not get any more messages from this list until
> > > you re-enable your membership.  You will receive 3 more reminders like
> > > this before your membership in the list is deleted.
> >
> > Otherwise messages from the list come in normally in my inbox and not
> > marked as spam.
> >
> > Does this only affect me, all GMail subscribers, or an even wider
> audience?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Wed Oct 24 09:50:00 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 24 Oct 2018 15:50:00 +0200
Subject: [hibernate-dev] Getting automatically removed from the list for
 "excessive bounces"?
In-Reply-To: <CAFm4XO2=AnXDvswNNEhj74bAzsxZ21C-EnYtH4qgGcbpt9voNA@mail.gmail.com>
References: <CA+nBocCv_KOVoLL4gvDBP_Jd+xMVgN3QUtm2RM0OicUHtRzR5Q@mail.gmail.com>
	<CAFm4XO2=AnXDvswNNEhj74bAzsxZ21C-EnYtH4qgGcbpt9voNA@mail.gmail.com>
Message-ID: <CALt0+o_b9TdzvOWXNcvX7XHy=1uBMTrtaNzMeGJQ9u7K0WaQmw@mail.gmail.com>

FWIW, I also received these emails and apparently Chris too as we talked
about it. I wasn't sure of who to contact for this sort of issues.

We are using GMail too.

I tried to take a look at the Mailman administration page to see if I could
get a hand on one of those bounce messages but to no avail.

Hopefully, support will be able to get more information.

Thanks.

On Wed, Oct 24, 2018 at 3:24 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Jordan,
>
> I have an error message from our mail server stating that messages to
> you (and 8 more people, among them we also have regulars like Vlad and
> Christian Beikov) have been bouncing back often in the past 2 days. It
> eventually gave up so you might miss some emails from this list.
>
> I'm not sure why; but it's interesting to note that all 9 people on
> this error message are using gmail. I'll open a support ticket for
> those managing the mail server but I'm not sure if they will be able
> to to anything, as it seems it's gmail refusing them.
>
> Thanks,
> Sanne
> On Wed, 24 Oct 2018 at 11:42, Jordan Gigov <coladict at gmail.com> wrote:
> >
> > I've started getting these every month from this list:
> > > Your membership in the mailing list hibernate-dev has been disabled
> > > due to excessive bounces The last bounce received from you was dated
> > > 24-Oct-2018.  You will not get any more messages from this list until
> > > you re-enable your membership.  You will receive 3 more reminders like
> > > this before your membership in the list is deleted.
> >
> > Otherwise messages from the list come in normally in my inbox and not
> > marked as spam.
> >
> > Does this only affect me, all GMail subscribers, or an even wider
> audience?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Oct 24 13:21:09 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 24 Oct 2018 18:21:09 +0100
Subject: [hibernate-dev] HBX-1193 (oracle) reverse engineering of
 UniqueConstraint annotation for function-based indexes
In-Reply-To: <CAK_6CLPJbTot-BNXXGfkGcyTKzepy6tgeDYS+oiOUspj6oHK2Q@mail.gmail.com>
References: <CAK_6CLOonem4SQzngWYx1fZgnuyqJ7WeGzC0RmfeoH6gLDUbog@mail.gmail.com>
	<CAK_6CLPJbTot-BNXXGfkGcyTKzepy6tgeDYS+oiOUspj6oHK2Q@mail.gmail.com>
Message-ID: <CAFm4XO1BaQHEAS-r-67=7=soByAEOLfajr_HwPM-4RAj7EBCTA@mail.gmail.com>

Hi Graham,

many thanks for your help!

Sorry for the lack of feedback on your PR, I'll remind the Tools
maintainer; looks like he might have missed the notification.

Thanks,
Sanne

On Tue, 23 Oct 2018 at 21:57, Graham Collinson
<graham_hibernate at collo.me.uk> wrote:
>
> Apologies for the empty email last time
>
> https://hibernate.atlassian.net/browse/HBX-1193
>
> Hi,
>
> I've submitted a pull request for this issue.
> Is there anything more I need to do or could help with to close this one
> off?
>
> Thanks,
> Graham
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Fri Oct 26 05:50:46 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 26 Oct 2018 11:50:46 +0200
Subject: [hibernate-dev] [ORM] RowSelection#definesLimit() looking weird
Message-ID: <CALt0+o9Oa8jgW3zVBPBDQBac1QtzUds0Nruze9v3kR2zCuFTSQ@mail.gmail.com>

Hi,

RowSelection#definesLimit() [1] is defined as:
    public boolean definesLimits() {
        return maxRows != null || (firstRow != null && firstRow <= 0);
    }

The firstRow <= 0 condition looks exactly like the opposite condition I
would have used intuitively.

Tests pass with either conditions.

Could someone confirm that either it needs fixing or I missed something?

Thanks!

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/engine/spi/RowSelection.java#L71

From sanne at hibernate.org  Fri Oct 26 08:46:13 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 26 Oct 2018 13:46:13 +0100
Subject: [hibernate-dev] Getting automatically removed from the list for
 "excessive bounces"?
In-Reply-To: <CAL2Kp+iSy+mXfWn4CH=j_HHUG7-okp=RyL086iH61=t3AR_M_Q@mail.gmail.com>
References: <CA+nBocCv_KOVoLL4gvDBP_Jd+xMVgN3QUtm2RM0OicUHtRzR5Q@mail.gmail.com>
	<CAFm4XO2=AnXDvswNNEhj74bAzsxZ21C-EnYtH4qgGcbpt9voNA@mail.gmail.com>
	<CAL2Kp+iSy+mXfWn4CH=j_HHUG7-okp=RyL086iH61=t3AR_M_Q@mail.gmail.com>
Message-ID: <CAFm4XO26NdrXbe90=T=EV8zy3eoqxnJA0QkLhgEr0XpTaWmCAA@mail.gmail.com>

Thanks for confirming that Alessio; indeed I have your address on this list too.

I'm sure they'll figure it out, will just need some time :)

Sanne
On Wed, 24 Oct 2018 at 14:26, Alessio Stalla <alessiostalla at gmail.com> wrote:
>
> Hi,
> I've got the excessive bounces message several times, too, and I'm using Gmail.
>
> Alessio
>
> On Wed, 24 Oct 2018 at 15:24, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi Jordan,
>>
>> I have an error message from our mail server stating that messages to
>> you (and 8 more people, among them we also have regulars like Vlad and
>> Christian Beikov) have been bouncing back often in the past 2 days. It
>> eventually gave up so you might miss some emails from this list.
>>
>> I'm not sure why; but it's interesting to note that all 9 people on
>> this error message are using gmail. I'll open a support ticket for
>> those managing the mail server but I'm not sure if they will be able
>> to to anything, as it seems it's gmail refusing them.
>>
>> Thanks,
>> Sanne
>> On Wed, 24 Oct 2018 at 11:42, Jordan Gigov <coladict at gmail.com> wrote:
>> >
>> > I've started getting these every month from this list:
>> > > Your membership in the mailing list hibernate-dev has been disabled
>> > > due to excessive bounces The last bounce received from you was dated
>> > > 24-Oct-2018.  You will not get any more messages from this list until
>> > > you re-enable your membership.  You will receive 3 more reminders like
>> > > this before your membership in the list is deleted.
>> >
>> > Otherwise messages from the list come in normally in my inbox and not
>> > marked as spam.
>> >
>> > Does this only affect me, all GMail subscribers, or an even wider audience?
>> > _______________________________________________
>> > 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  Tue Oct 30 00:24:45 2018
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 29 Oct 2018 21:24:45 -0700
Subject: [hibernate-dev] Does <one-to-one ... constrained="false"> make
 sense for unidirectional association?
Message-ID: <CAFDzhiQVLj3xD0SSOZPnTCbVY9GMNUzwnPP2KPH9P4Bdn=Xkhw@mail.gmail.com>

The fix for HHH-12436 involves correcting the foreign key direction for
some one-to-one assocations. In the process of making changes I see that we
have a unit test that has a unidirectional one-to-one association mapped
with constrained="false". [1]

ModelBinder assumes that <one-to-one ... constrained = "true"> means that
the foreign key direction is FROM_PARENT; if constrained = "false", it
assumes that the foreign key direction is TO_PARENT. [2]

It seems odd to me that the foreign key direction for a unidirectional
association would be TO_PARENT.

Should the unit test have constrained = "true"?

If not, should ModelBinder check to see if the association is bidirectional
and determine which side owns the association? This would probably require
adding a SecondPass.

Please let me know your thoughts.

Regards,
Gail

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/onetoone/optional/Person.hbm.xml
[2]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/boot/model/source/internal/hbm/ModelBinder.java#L2114-L2131

From gbadner at redhat.com  Tue Oct 30 01:08:09 2018
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 29 Oct 2018 22:08:09 -0700
Subject: [hibernate-dev] Does <one-to-one ... constrained="false"> make
 sense for unidirectional association?
In-Reply-To: <CAFDzhiQVLj3xD0SSOZPnTCbVY9GMNUzwnPP2KPH9P4Bdn=Xkhw@mail.gmail.com>
References: <CAFDzhiQVLj3xD0SSOZPnTCbVY9GMNUzwnPP2KPH9P4Bdn=Xkhw@mail.gmail.com>
Message-ID: <CAFDzhiQdKo_aFgtrrUhDTHx2roLkCwaB4t9bz6MLd9EqFrhRcg@mail.gmail.com>

If <one-to-one ... constrained="false"/> does make sense for a
unidirectional association, and the foreign key really should be
FROM_PARENT, then, AFAICT, the only way the unit tests could pass is if
Hibernate assumes such associations would have an implicit
ignoreNotFound="true".

As an example, take a look at OptionalOneToOneTest [1] with the mapping
[2]. The reason why OptionalOneToOneTest passes is because, currently,
OneToOneType#isNullable()
returns foreignKeyType==ForeignKeyDirection.TO_PARENT. For this
association, OneToOneType#isNullable returns true because its foreign key
direction is (incorrectly?) ForeignKeyDirection.TO_PARENT.

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/onetoone/optional/OptionalOneToOneTest.java
[2]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/onetoone/optional/Person.hbm.xml


On Mon, Oct 29, 2018 at 9:24 PM Gail Badner <gbadner at redhat.com> wrote:

> The fix for HHH-12436 involves correcting the foreign key direction for
> some one-to-one assocations. In the process of making changes I see that we
> have a unit test that has a unidirectional one-to-one association mapped
> with constrained="false". [1]
>
> ModelBinder assumes that <one-to-one ... constrained = "true"> means that
> the foreign key direction is FROM_PARENT; if constrained = "false", it
> assumes that the foreign key direction is TO_PARENT. [2]
>
> It seems odd to me that the foreign key direction for a unidirectional
> association would be TO_PARENT.
>
> Should the unit test have constrained = "true"?
>
> If not, should ModelBinder check to see if the association is
> bidirectional and determine which side owns the association? This would
> probably require adding a SecondPass.
>
> Please let me know your thoughts.
>
> Regards,
> Gail
>
> [1]
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/onetoone/optional/Person.hbm.xml
> [2]
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/boot/model/source/internal/hbm/ModelBinder.java#L2114-L2131
>
>

From davide at hibernate.org  Tue Oct 30 07:51:33 2018
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 30 Oct 2018 11:51:33 +0000
Subject: [hibernate-dev] Hibernate OGM 5.4.0.Final release
Message-ID: <CANoTJYP0+T907xhZ57O2HfZ_s+TEE=hTRqguKvSJhsK=0zD0Sg@mail.gmail.com>

Hibernate OGM 5.4.0.Final has been released!

Here's some of the new features included in this release:

- Infinispan remote transactions over HotRod client
- JPQL and native queries support for Infinispan remote
- server side procedures calls for Infinispan Remote
- Cache creation and configuration for Infinispan remote
- GridFS support for MongoDB

More details available in the blog post:
http://in.relation.to/2018/10/30/hibernate-ogm-5-4-Final-released/

Thanks

From sanne at hibernate.org  Tue Oct 30 08:04:43 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 30 Oct 2018 12:04:43 +0000
Subject: [hibernate-dev] [hibernate-announce] Hibernate OGM 5.4.0.Final
	release
In-Reply-To: <CANoTJYP0+T907xhZ57O2HfZ_s+TEE=hTRqguKvSJhsK=0zD0Sg@mail.gmail.com>
References: <CANoTJYP0+T907xhZ57O2HfZ_s+TEE=hTRqguKvSJhsK=0zD0Sg@mail.gmail.com>
Message-ID: <CAFm4XO2SGKWeLGT+vBKqgeMGLPABXL7Bzoi_9Bus8Q9WJvyN1w@mail.gmail.com>

Awesome list of improvements. Congratulations all, gret release!
On Tue, 30 Oct 2018 at 11:52, Davide D'Alto <davide at hibernate.org> wrote:
>
> Hibernate OGM 5.4.0.Final has been released!
>
> Here's some of the new features included in this release:
>
> - Infinispan remote transactions over HotRod client
> - JPQL and native queries support for Infinispan remote
> - server side procedures calls for Infinispan Remote
> - Cache creation and configuration for Infinispan remote
> - GridFS support for MongoDB
>
> More details available in the blog post:
> http://in.relation.to/2018/10/30/hibernate-ogm-5-4-Final-released/
>
> Thanks
> _______________________________________________
> hibernate-announce mailing list
> hibernate-announce at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-announce