[hibernate-dev] HHH-11396 - Timezone handling

[Christian Beikov]

Hey everyone,

I'd like to get your opinion on something. We had this issues regarding 
timezone handling which Vlad closed pretty quickly saying it isn't a 
Hibernate problem and I generally agree, but still would like to know 
what you think about it.

So basically what we do in the LocalDateJavaDescriptor(and also in some 
other places) is to use the value returned by java.sql.Date in some way 
and pack that into the target type. In this case this happens behind the 
scenes when invoking java.sql.Date.toLocalDate() but internally it just 
calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).

Now IMO the problem really is in java.sql.Date because it does a 
timezone conversion. The user who created the issue HHH-11396 
 pointed out he was 
using a DATE column type because he wanted to have a simple date i.e. 
year, month and date. When using java.sql.Date and the consumer is in a 
timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will 
subtract that offset during /normalization/ and the millisecond value 
will change by that offset. This means that a date in the DBMS that is 
2000-01-01 will become 1999-12-31 when the client is in UTC+1.

One possible fix is to simply configure UTC for the consumer, then there 
will be no timezone shift.

I think what java.sql.Date does is wrong because a date has no time 
part, so there shouldn't be any time shifts. We should workaround that 
by shifting the millisecond value back when constructing a LocalDate.

What do you think should we do? Does anyone maybe know why java.sql.Date 
behaves that way?


-- 

Mit freundlichen Grüßen,

*Christian Beikov*
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-11396 - Timezone handling

[Jordan Gigov]

What java.sql.Date does is wrong for many reasons (mostly because it
extends java.util.Date which is a horrible API), but I think Vlad laid
it out pretty well why it's a JDBC driver configuration problem and
not a Hibernate problem. If you simply rely on the Java API to use
handle it's l own TZ conversion without telling it any zones (which
that JDBC URL tells it), the problem should go away. The driver does
try to read the server's time-zone, though, so maybe using
`useTimezone=false` in the JDBC URL is the right solution, but it
certainly shouldn't be to try and appease every driver's individual
quirks.

Even MySQL's own API works under the assumption that LocalDate should
be converted using the JVM's default time-zone.
https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50

On 14 March 2017 at 09:38, Christian Beikov  wrote:
> Hey everyone,
>
> I'd like to get your opinion on something. We had this issues regarding
> timezone handling which Vlad closed pretty quickly saying it isn't a
> Hibernate problem and I generally agree, but still would like to know
> what you think about it.
>
> So basically what we do in the LocalDateJavaDescriptor(and also in some
> other places) is to use the value returned by java.sql.Date in some way
> and pack that into the target type. In this case this happens behind the
> scenes when invoking java.sql.Date.toLocalDate() but internally it just
> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
>
> Now IMO the problem really is in java.sql.Date because it does a
> timezone conversion. The user who created the issue HHH-11396
>  pointed out he was
> using a DATE column type because he wanted to have a simple date i.e.
> year, month and date. When using java.sql.Date and the consumer is in a
> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
> subtract that offset during /normalization/ and the millisecond value
> will change by that offset. This means that a date in the DBMS that is
> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
>
> One possible fix is to simply configure UTC for the consumer, then there
> will be no timezone shift.
>
> I think what java.sql.Date does is wrong because a date has no time
> part, so there shouldn't be any time shifts. We should workaround that
> by shifting the millisecond value back when constructing a LocalDate.
>
> What do you think should we do? Does anyone maybe know why java.sql.Date
> behaves that way?
>
>
> --
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> ___
> 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] HHH-11396 - Timezone handling

[Christian Beikov]

So you are saying that it should be the JDBC drivers responsibility to 
add the JVMs local timezone offset to the java.sql.Date so the 
normalization can subtract the offset again? I would be ok with that, 
but is it really the responsibility of the JDBC driver?


Mit freundlichen Grüßen,

*Christian Beikov*
Am 14.03.2017 um 10:39 schrieb Jordan Gigov:
> What java.sql.Date does is wrong for many reasons (mostly because it
> extends java.util.Date which is a horrible API), but I think Vlad laid
> it out pretty well why it's a JDBC driver configuration problem and
> not a Hibernate problem. If you simply rely on the Java API to use
> handle it's l own TZ conversion without telling it any zones (which
> that JDBC URL tells it), the problem should go away. The driver does
> try to read the server's time-zone, though, so maybe using
> `useTimezone=false` in the JDBC URL is the right solution, but it
> certainly shouldn't be to try and appease every driver's individual
> quirks.
>
> Even MySQL's own API works under the assumption that LocalDate should
> be converted using the JVM's default time-zone.
> https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50
>
> On 14 March 2017 at 09:38, Christian Beikov  
> wrote:
>> Hey everyone,
>>
>> I'd like to get your opinion on something. We had this issues regarding
>> timezone handling which Vlad closed pretty quickly saying it isn't a
>> Hibernate problem and I generally agree, but still would like to know
>> what you think about it.
>>
>> So basically what we do in the LocalDateJavaDescriptor(and also in some
>> other places) is to use the value returned by java.sql.Date in some way
>> and pack that into the target type. In this case this happens behind the
>> scenes when invoking java.sql.Date.toLocalDate() but internally it just
>> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
>>
>> Now IMO the problem really is in java.sql.Date because it does a
>> timezone conversion. The user who created the issue HHH-11396
>>  pointed out he was
>> using a DATE column type because he wanted to have a simple date i.e.
>> year, month and date. When using java.sql.Date and the consumer is in a
>> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
>> subtract that offset during /normalization/ and the millisecond value
>> will change by that offset. This means that a date in the DBMS that is
>> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
>>
>> One possible fix is to simply configure UTC for the consumer, then there
>> will be no timezone shift.
>>
>> I think what java.sql.Date does is wrong because a date has no time
>> part, so there shouldn't be any time shifts. We should workaround that
>> by shifting the millisecond value back when constructing a LocalDate.
>>
>> What do you think should we do? Does anyone maybe know why java.sql.Date
>> behaves that way?
>>
>>
>> --
>>
>> Mit freundlichen Grüßen,
>> 
>> *Christian Beikov*
>> ___
>> 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] HHH-11396 - Timezone handling

[Jordan Gigov]

The driver just has to use the available `getDate/getMonth/getYear`
functions of the java.sql.Date class, because they're what's intended
by the API. The problem is that the MySQL driver tries to do more than
that, when their database doesn't even support time zones.

On 14 March 2017 at 12:17, Christian Beikov  wrote:
> So you are saying that it should be the JDBC drivers responsibility to
> add the JVMs local timezone offset to the java.sql.Date so the
> normalization can subtract the offset again? I would be ok with that,
> but is it really the responsibility of the JDBC driver?
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 14.03.2017 um 10:39 schrieb Jordan Gigov:
>> What java.sql.Date does is wrong for many reasons (mostly because it
>> extends java.util.Date which is a horrible API), but I think Vlad laid
>> it out pretty well why it's a JDBC driver configuration problem and
>> not a Hibernate problem. If you simply rely on the Java API to use
>> handle it's l own TZ conversion without telling it any zones (which
>> that JDBC URL tells it), the problem should go away. The driver does
>> try to read the server's time-zone, though, so maybe using
>> `useTimezone=false` in the JDBC URL is the right solution, but it
>> certainly shouldn't be to try and appease every driver's individual
>> quirks.
>>
>> Even MySQL's own API works under the assumption that LocalDate should
>> be converted using the JVM's default time-zone.
>> https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50
>>
>> On 14 March 2017 at 09:38, Christian Beikov  
>> wrote:
>>> Hey everyone,
>>>
>>> I'd like to get your opinion on something. We had this issues regarding
>>> timezone handling which Vlad closed pretty quickly saying it isn't a
>>> Hibernate problem and I generally agree, but still would like to know
>>> what you think about it.
>>>
>>> So basically what we do in the LocalDateJavaDescriptor(and also in some
>>> other places) is to use the value returned by java.sql.Date in some way
>>> and pack that into the target type. In this case this happens behind the
>>> scenes when invoking java.sql.Date.toLocalDate() but internally it just
>>> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
>>>
>>> Now IMO the problem really is in java.sql.Date because it does a
>>> timezone conversion. The user who created the issue HHH-11396
>>>  pointed out he was
>>> using a DATE column type because he wanted to have a simple date i.e.
>>> year, month and date. When using java.sql.Date and the consumer is in a
>>> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
>>> subtract that offset during /normalization/ and the millisecond value
>>> will change by that offset. This means that a date in the DBMS that is
>>> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
>>>
>>> One possible fix is to simply configure UTC for the consumer, then there
>>> will be no timezone shift.
>>>
>>> I think what java.sql.Date does is wrong because a date has no time
>>> part, so there shouldn't be any time shifts. We should workaround that
>>> by shifting the millisecond value back when constructing a LocalDate.
>>>
>>> What do you think should we do? Does anyone maybe know why java.sql.Date
>>> behaves that way?
>>>
>>>
>>> --
>>>
>>> Mit freundlichen Grüßen,
>>> 
>>> *Christian Beikov*
>>> ___
>>> 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] Hibernate NoORM IRC meeting minutes

[Guillaume Smet]

Hi!

Here are the minutes of the meeting:

15:33 < jbott> Meeting ended Tue Mar 14 14:32:54 2017 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:33 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-14-14.01.html
15:33 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-14-14.01.txt
15:33 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-14-14.01.log.html

Cheers,

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.1.5

[Gail Badner]

It turns out that I need to release Hibernate ORM 5.1.5 after all, so it
can be included in WildFly. I created the 5.1.5 tag yesterday, and now I am
going through the steps to release 5.1.5 to the community.

In the process I will have to reopen all the jiras that were backported to
add 5.1.5 as a fix version, then re-close them.

There may be more 5.1 community releases after 5.1.5. If there is something
you think should be backported to 5.1 (or 5.0) please feel free to let me
know by clicking the "Backport" checkbox in the Jira or adding a jira
comment directed to me using [~gbadner] or @gbadner.

Please do not backport a fix yourself without checking with me first.

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Cursor leak

[Vikas Bali]

Hi
I've observed cursor leak when using hibernate core version 4.1.6 with Java 8 
and JBOSS EAP 7 env. I simply loading objects from database using hibernate and 
I do see for each hibernate execution, cursor is opened and it never closed 
till jobs server instance is down.

I have tried using current session, new session and stateless session, cursor 
never gets closed.

Please suggest any workaround to deal with this leak.

Thanks
Vikas
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.1.5.Final has been released

[Gail Badner]

We decided to do another release of the 5.1 series to fix critical bugs to
be included in an upcoming version of WildFly. This may be the last release
of the 5.1 series, so we recommend that you migrate to 5.2 for future
bugfixes.

For details:
http://in.relation.to/2017/03/14/hibernate-orm-515-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-11144

[Gail Badner]

Emmanuel or Steve, please provide feedback.

Thanks,
Gail

On Mon, Jan 23, 2017 at 3:17 AM, Gail Badner  wrote:

> This fell through the cracks.
>
> Emmanuel or Steve, please provide some feedback.
>
> Thanks,
> Gail
>
> On Wed, Oct 26, 2016 at 6:48 AM, Gail Badner  wrote:
>
>> HHH-11144 involves an entity that has 2 one-to-many associations with the
>> same type of entity, and both associations have orphanRemoval = true.
>> Andrea created a PR with test case at [1]
>>
>> I am not sure if this is a valid mapping. I I would like your thoughts on
>> this.
>>
>> Here is an excerpt of the relevant bits:
>>
>> @Entity(name = "Item")
>> public static class Item {
>>@OneToMany(mappedBy = "parent", cascade = CascadeType.ALL,
>> orphanRemoval = true)
>>protected Set lowerItemRelations = new LinkedHashSet<>
>> ();
>>@OneToMany(mappedBy = "child", cascade = CascadeType.ALL,
>> orphanRemoval = true)
>>protected Set higherItemRelations = new LinkedHashSet<>
>> ();
>> }
>>
>> @Entity(name = "ItemRelation")
>> public static class ItemRelation {
>> @ManyToOne(optional = false)
>> @JoinColumn(name = "PARENT_ID")
>> private Item parent;
>> @ManyToOne(optional = false)
>> @JoinColumn(name = "CHILD_ID")
>> private Item child;
>> }
>>
>> HHH-11144 describes inconsistent behavior observed when
>> Item#lowerItemRelations and Item#higherItemRelations both contain the same
>> ItemRelation, then one of the collections is cleared.
>>
>> If the non-cleared collection is uninitialized, then the ItemRelation is
>> orphan deleted.
>>
>> If the non-cleared collection is initialized, then the orphan-deleted
>> ItemRelation is rescued when PERSIST_ON_FLUSH cascades to the non-cleared
>> collection elements. The next time the collections are loaded from the
>> database, both will still contain that same ItemRelation.
>>
>> The spec says:
>>
>> "Portable applications must otherwise not depend upon a specific order
>> of removal, and must not reassign an entity that has been orphaned to
>> another
>> relationship or *otherwise attempt to persist it*"
>>
>> Is Hibernate doing the right thing by rescuing an orphan-deleted entity?
>>
>> In addition, this mapping allows a particular EntityRelation to be
>> associated with 2 different Item entities, which would mean that the same
>> ItemRelation would have 2 different owners with respect to orphan deletion..
>>
>> The spec says:
>>
>> "The orphanRemoval functionality is intended for entities that are privately
>> “owned” by their parent entity."
>>
>> Does this mean that the mapping is invalid, since it would allow multiple
>> parent entities, or does it mean that the resulting behavior is undefined
>> (thus non-portable)?
>>
>> Please let me know your thoughts.
>>
>> Thanks,
>> Gail
>>
>> [1] https://github.com/hibernate/hibernate-orm/pull/1607
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Can someone confirm if DB2 9.5 supports "cross join"?

[Gail Badner]

Since no one responded, I'll name the new dialect DB297Dialect.

On Thu, Feb 16, 2017 at 3:18 PM, Gail Badner  wrote:

> I created HHH-11499 to create a new dialect for DB2 to use "cross join"
> syntax instead of "," (as is currently done in DB2Dialect).
>
> Although DB2 9.1 reached its end of life April 30, 2015, some applications
> may still be using that version, so I will create a new DB2 dialect that
> extends DB2Dialect and overrides getCrossJoinSeparator() to return "
> cross join ".
>
> The question is what to call the new dialect.
>
> According to DB2 9.5 and 9.7 documentation, "cross join" syntax is
> supported in those versions. I am able to confirm this on 9.7, but I do not
> have access to DB2 9.5 to try it out.
>
> If someone can confirm this will work on DB2 9.5 by the time Hibernate
> 5.2.9 is released, then I'll name the new dialect DB295Dialect; otherwise,
> I'll name it DB297Dialect.
>
> Thanks!
>
> Gail
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Cursor leak

[Vlad Mihalcea]

Hi,

You should replicate this behavior using our test case templates:

http://in.relation.to/2015/06/26/hibernate-test-case-templates/

You can choose the hibernate-orm-4 first:

https://github.com/hibernate/hibernate-test-case-templates/tree/master/orm/hibernate-orm-4

and then check it out with Hibernate 5 as well, and see if the problem was
fixed.

Vlad

On Wed, Mar 15, 2017 at 3:42 AM, Vikas Bali  wrote:

> Hi
> I've observed cursor leak when using hibernate core version 4.1.6 with
> Java 8 and JBOSS EAP 7 env. I simply loading objects from database using
> hibernate and I do see for each hibernate execution, cursor is opened and
> it never closed till jobs server instance is down.
>
> I have tried using current session, new session and stateless session,
> cursor never gets closed.
>
> Please suggest any workaround to deal with this leak.
>
> Thanks
> Vikas
> ___
> 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