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

[Christian Beikov]

I tried very hard to reproduce this scenario today and came to the 
conclusion that what the user does must be very wrong. The test he 
posted wrongly assumes that a java.sql.Date object created in one 
timezone produces the same LocalDate object when toLocalDate() is 
invoked in a different timezone. I'm not sure how that can actually 
happen, as I tried various MySQL JDBC configurations and MySQL timezone 
configurations but could never get the driver to report something wrong.

I'm going to ask that user about specifics, but for now everything seems 
to work as expected.

Sorry for the fuss, this timezone handling really is hard :D


Mit freundlichen Grüßen,

*Christian Beikov*
Am 15.03.2017 um 18:02 schrieb Steve Ebersole:
> I'm not sure exactly where the fault lies (java.util versus java.sql), but
> we should certainly help hide that if we reasonably can.  But conceptually,
> milliseconds on a DATE (no time) makes zero sense at all.  So where does
> the milliseconds come from?
>
> It is also possible that the db is (incorrectly IMO) storing millisecond
> portion of a DATE value.  In your example Christian, is the driver
> returning to us a DATE reference will a non-zero millisecond portion?  And
> if so, does the outcome change if we reset the Date's milliseconds to zero
> before we call toLocalDate()?  If so, maybe the correct solution (certainly
> the easiest) is to simply set the Date's milliseconds value to zero
> whenever we read them from the db.  IIRC I think I did change that once and
> people complained, but I forget the details - I tried searching Jira but
> could not find it.  Like I said, IMO that is conceptually correct anyway.
>
> On Wed, Mar 15, 2017 at 2:03 AM Vlad Mihalcea 
> wrote:
>
>> Hi,
>>
>> I recently helped one of our users with a MySQL timezone issue, and I
>> realized that the default legacy timezone handling is to be avoided.
>>
>> Basically, you want to set this "useLegacyDatetimeCode' configuration
>> property to false.
>>
>> for more details, check out this article:
>>
>>
>> https://vladmihalcea.com/2017/03/14/how-to-store-date-time-and-timestamps-in-utc-time-zone-with-jdbc-and-hibernate/
>>
>> However, for LocalDate, I'll have to think it more thoroughly to see if
>> there is something we could do to address the problem raised by Christian
>> even if it implies adding a section to our User Guide to help users set the
>> driver properly to avoid some possible issues.
>>
>> Vlad
>>
>> On Tue, Mar 14, 2017 at 12:40 PM, Jordan Gigov  wrote:
>>
>>> 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 <
>> christian.bei...@gmail.com>
>>> 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

Re: [hibernate-dev] HHH-10162 Inheritance and L2 cache

[Christian Beikov]

Hey Gail,

comments inline..

Am 15.03.2017 um 23:21 schrieb Gail Badner:
> Hi Christian,
>
> More comments below...
>
> On Fri, Mar 3, 2017 at 4:38 PM, Christian Beikov 
> mailto:christian.bei...@gmail.com>> wrote:
>
> Thanks for the comments, I have updated the PR.
>
> I think that it is important to have a complete fix and I am
> already working on that, but this issue was specifically about the
> L2 cache, so I wanted to keep that stuff separate.
>
> Here are some other polymorphism related issues:
>
>   * https://hibernate.atlassian.net/browse/HHH-9845
> 
>   * https://hibernate.atlassian.net/browse/HHH-11280
> 
>   * https://hibernate.atlassian.net/browse/HHH-4742
> 
>   * https://hibernate.atlassian.net/browse/HHH-2927
> 
>
> Thanks for looking into this. It is definitely and area that 
> can/should be improved.
>
> The fix provided by Josh Landin for HHH-11280 would break
> reference equality and I think that is something we all want to
> keep. Which brings us to the actual problems.
>
>
> I agree. We definitely do not want to break reference equality.
>
>
> 1. Whenever we encounter an association that is of a polymorphic
> entity type, we should actually internally, regardless of what the
> user configures, always fetch that association with subtypes.
> Otherwise we could run into that same problem again, that we
> "pollute" the L1 cache with a proxy of the wrong type. Since we
> want to keep reference equality, we can't replace that instance.
>
>
> IIUC, this is only a problem if the association is with a polymorphic 
> entity Class that has a subclass. Since a fix would probably affect 
> performance, I think it would be best to only deal with this 
> particular case. Maybe you are saying the same thing; I just wanted to 
> clarify.
Yep saying the same thing.
>
> What you are suggesting is to eagerly fetch the association. IIUC, a 
> workaround is to map such associations as eager. That way a proxy 
> would not be created, avoiding the problem altogether.
Correct.
>
> IMO, if the entity is mapped as lazy, it really should be 
> lazily-loaded. That said, I think that it would be worthwhile for 
> Hibernate to determine the concrete subclass for the associated entity 
> and create the appropriate proxy. I can think of some alternatives, 
> but I think they would all affect performance. Maybe there should be a 
> property for indicating the strategy to use. Some strategies that come 
> to mind are:
>
> 1) by default, create an uninitialized proxy using the type indicated 
> in the mapping (as is done currently);
> 2) try loading from second-level cache (as done in your fix for 
> HHH-10162); if the entity is not found in the cache, then execute a 
> query to determine the associated entity's concrete subclass;
> 3) add a join to the original query to determine the associated 
> entity's concrete subclass, and create the appropriate uninitialized 
> proxy.
I roughly thought of the same strategies, but I'd like to propose a 1b) 
strategy that would also check the L2 cache in case of a polymorphic 
association. So maybe the config for whether a L2 lookup should be done 
should be a "separate" and independent config.
>
> You mentioned that you are working on something. Is tihs along the 
> lines of what you are thinking? Did you have other ideas?
Just what I wrote up so far.
>
> 2. When using bytecode enhancement, the loading of *ToOne
> instances could be deferred to the first access.
>
>
> Yes, this is another workaround.
I wouldn't say workaround but performance improvement :)
>
>
> 3. Actually it would also be possible if property access is used
> without bytecode enhancement, but that would require to use a
> special proxy for every object that might contain a
> non-initialized polymorphic association. The speciality about it
> is that it loads the association on first access.
>
>
> I'm not sure I'm following this.
When querying for an entity A like "FROM A", currently we always return 
A instances although we could return special proxy A instances. The 
special thing about the proxy is, that it has all state initialized 
except for polymorphic associations. These associations are only loaded 
from the DB when accessing them through their respective property 
accessors. Note that this proxy is also something that we can use for 
optional "toParent" one-to-one associations.

The only proxies that we have right now are for uninitialized 
associations which trigger loading the full entity on non-id property 
access. Either we extend the existing proxy implementation by the 
explained functionality, or we create a separate proxy type.
>
> 4. Another thing that we should cons

[hibernate-dev] Starting 5.2.9 release

[andrea boriero]

Please do not push anything to master branch.


Thanks,

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

[hibernate-dev] JIRA usage for OGM

[Sanne Grinovero]

There are more than 300 open issues, which is fine but rather than
being these well-defined issues most sound like wishful thinking of
someone having a (possibly cool) idea but not really executing on it.

Since JIRA is an issue tracker and not really a planning tool / note
taking app I wish we could limit this practice of having issues like
"explore integration with.." ?

More specifically, could we move "out of the way" all issues related
to Databases which we're moving into the "contrib" repository?
I think it would be nice to have these in a different JIRA project.

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

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

[andrea boriero]

For details:

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