Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Gunnar Morling]

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@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
:
>
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Yoann Rodiere]

 > 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
yo...@hibernate.org


On Fri, 5 Oct 2018 at 09:38, Gunnar Morling  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@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
> :
> >
> > 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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Vlad Mihalcea]

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  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
> yo...@hibernate.org
>
>
> On Fri, 5 Oct 2018 at 09:38, Gunnar Morling  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@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
>> :
>> >
>> > 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@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] StatelessSession and JTA platform without transaction manager

[Guillaume Smet]

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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Sanne Grinovero]

On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea  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  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
> > yo...@hibernate.org
> >
> >
> > On Fri, 5 Oct 2018 at 09:38, Gunnar Morling  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@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
> >> :
> >> >
> >> > 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@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> _

Re: [hibernate-dev] What should happen to queued operations when a collection is detached?

[andrea boriero]

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  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  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  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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Steve Ebersole]

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  wrote:

> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea 
> 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 
> 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
> > > yo...@hibernate.org
> > >
> > >
> > > On Fri, 5 Oct 2018 at 09:38, Gunnar Morling 
> 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@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
> > >> :
> > >> >
> > >> > Hi,
> > >> > While reviewing this Jira issue:
> > >> >
> > >> > https://hibe

Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Sanne Grinovero]

On Fri, 5 Oct 2018 at 12:47, Steve Ebersole  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  wrote:
>>
>> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea  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  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

Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Vlad Mihalcea]

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  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 
> wrote:
>
>> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea 
>> 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 
>> 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
>> > > yo...@hibernate.org
>> > >
>> > >
>> > > On Fri, 5 Oct 2018 at 09:38, Gunnar Morling 
>> 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@UTC, no
>> > >> matter what's the VM's timezone or any TZ related config. This allows
>> > >> to 

Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Sanne Grinovero]

On Fri, 5 Oct 2018 at 14: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.

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  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  wrote:
>>>
>>> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea  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  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"?)
>

Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Mark Rotteveel]

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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Legacy Jenkins API tokens

[Yoann Rodiere]

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
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] *-to-one associations and @NotFound

[Gail Badner]

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  wrote:

> As a result of fixing 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
>  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
> , 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
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] What should happen to queued operations when a collection is detached?

[Gail Badner]

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  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  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  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  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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailin

Re: [hibernate-dev] *-to-one associations and @NotFound

[Gail Badner]

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  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  wrote:
>
>> As a result of fixing 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
>>  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
>> , 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
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev