Re: [hibernate-dev] 6.0 - HQL literals
Hi, As one of the maintainers of the postgres jdbc driver I am interested in this discussion. Postgres only stores date/times in UTC. Everything else is a translation. The driver uses the client's timezone for all dates/times (for better or worse) If there is anything I can do to help make things easier, let me know. -- Sent from: http://hibernate-development.74578.x6.nabble.com/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 6.0 - HQL literals
Hi Steve, I'm not sure there is a better way to store the data in the database. Doing any kind of date/time math in anything else but UTC seems fraught with danger. See below as to how we handle Java 8 types. https://github.com/pgjdbc/pgjdbc/blob/db228a4ffd8b356a9028363b35b0eb9055ea53f0/pgjdbc/src/main/java/org/postgresql/jdbc/PgPreparedStatement.java#L961-L968 Also tells you which driver I maintain. As far as my interest in this discussion goes. What is the pgjdbc driver doing that is not consistent with what hibernate is doing/wants ? I'd certainly be up for a hibernate compatibility mode. Thanks, Dave Cramer On Sun, 12 Jan 2020 at 23:36, Steve Ebersole wrote: > Hi Dave. > > Same - I was swamped with stuff at the end of last week. > > Yes, from what I was reading postgres is a bit strange in storing temporal > values. Not unique to postgres - many databases do interesting things. > > I'm curious how the driver handles binding Java 8 types directly. The > JDBC spec was updated to support these types through the generic > `#setObject` methods (`#getObject` as well?). Does the driver handle this. > > Out of curiosity, which jdbc driver are you helping with? > > > > On Thu, Jan 9, 2020 at 10:23 AM Dave Cramer wrote: > >> Hi, >> >> As one of the maintainers of the postgres jdbc driver I am interested in >> this discussion. >> Postgres only stores date/times in UTC. Everything else is a translation. >> The driver uses the client's timezone for all dates/times (for better or >> worse) If there is anything I can do to help make things easier, let me >> know. >> >> >> >> -- >> Sent from: http://hibernate-development.74578.x6.nabble.com/ >> ___ >> 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] 6.0 - HQL literals
Dave Cramer On Mon, 13 Jan 2020 at 11:10, Yoann Rodiere wrote: > Hi, > > As far as I know there wasn't any specific time-related problem with the > org.postgresql:postrgresql driver. I'm not sure we run tests against > pgjdbc, that might be something to consider. > Please do run your tests against that. One thing I noted was that you were not using the native interval type for intervals. > The problems were mainly with MariaDB/MySQL/Sybase drivers, and we > upgraded our dependencies since then, so they may behave better now. > > In any case, most of the problems come from the conversion to javax.sql > types and the rendering of these types by the JDBC drivers. If we can pass > the java.time types to the drivers directly, that would indeed solve lots > of problems. That would mean losing support for older versions of those > drivers when it comes to java.time, but maybe it's not a big deal? > > Always a tough call, In my experience guaranteed to annoy at least half of the users. Dave > > On Mon, 13 Jan 2020 at 14:30, Dave Cramer wrote: > >> Hi Steve, >> >> I'm not sure there is a better way to store the data in the database. >> Doing >> any kind of date/time math in anything else but UTC seems fraught with >> danger. >> >> >> See below as to how we handle Java 8 types. >> >> https://github.com/pgjdbc/pgjdbc/blob/db228a4ffd8b356a9028363b35b0eb9055ea53f0/pgjdbc/src/main/java/org/postgresql/jdbc/PgPreparedStatement.java#L961-L968 >> >> Also tells you which driver I maintain. >> >> As far as my interest in this discussion goes. What is the pgjdbc driver >> doing that is not consistent with what hibernate is doing/wants ? >> >> I'd certainly be up for a hibernate compatibility mode. >> >> Thanks, >> >> Dave Cramer >> >> >> On Sun, 12 Jan 2020 at 23:36, Steve Ebersole wrote: >> >> > Hi Dave. >> > >> > Same - I was swamped with stuff at the end of last week. >> > >> > Yes, from what I was reading postgres is a bit strange in storing >> temporal >> > values. Not unique to postgres - many databases do interesting things. >> > >> > I'm curious how the driver handles binding Java 8 types directly. The >> > JDBC spec was updated to support these types through the generic >> > `#setObject` methods (`#getObject` as well?). Does the driver handle >> this. >> > >> > Out of curiosity, which jdbc driver are you helping with? >> > >> > >> > >> > On Thu, Jan 9, 2020 at 10:23 AM Dave Cramer >> wrote: >> > >> >> Hi, >> >> >> >> As one of the maintainers of the postgres jdbc driver I am interested >> in >> >> this discussion. >> >> Postgres only stores date/times in UTC. Everything else is a >> translation. >> >> The driver uses the client's timezone for all dates/times (for better >> or >> >> worse) If there is anything I can do to help make things easier, let me >> >> know. >> >> >> >> >> >> >> >> -- >> >> Sent from: http://hibernate-development.74578.x6.nabble.com/ >> >> ___ >> >> 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] api/doc suggestions
On Sun, 9 Feb 2020 at 03:34, Max Rydahl Andersen
wrote:
> Heya,
>
> While working on Quarkus a few of us (Georgios in cc and I in
> particular) been pondering on doing a guide on best approaches on
> how to access data a bit more raw (i.e. raw sql, stateless season, etc.)
> as we got quite a lot of feedback stating Hibernate/JPA was considered
> complex in comparison to things like Spring Data and JDBC.
>
> When you go look its as if Spring Data and JDBC copied a lot of the
> patterns/access patterns we had in Hibernate before neither of those two
> existed :)
>
> Unfortunately, there are though a few gotchas I think would be great if
> we could somehow improve.
>
> Sanne suggested me to post to this list to start the conversation -
> there might come some more once I get going on writing the full guide;
> but wanted to get it started sooner rather than later.
>
> ### Document simplest programatic configuration
> (This might just be "max is stupid" issue - please tell me :)
>
> Trying to do a simple java main method booting Hibernate I could not
> figure out with the "new" metadata API a simple way to just start
> Hibernate.
>
> What is the equivalent way to do this in new metadata api:
>
> ```
> new Configuration().setProperty("hibernate.dialect",
> "org.hibernate.dialect.H2Dialect")
> .setProperty("hibernate.connection.url",
> "jdbc:h2:./sakila")
> .setProperty("hibernate.connection.username", "sa")
> .buildSessionFactory();
> ```
>
> Just setup dialect, give connection info and get a
> sessionfactory/entitymanager ?
>
> I found apis to start from a file containing those settings; but I
> really just want a programmatic api
> to use in batch script etc. without a need for external files.
>
Stellar idea, +1 from me.
>
> ### Non-documented Deprecation of `setResultTransformer()` and friends
>
> The [approach of using
> `setResultTransformer`](
> https://in.relation.to/2006/03/17/hibernate-32-transformers-for-hql-and-sql/)
>
> we've had "forever" and its exactly what spring data and jdbc are using
> in examples where they say data access are easier.
>
> We want to focus and use this kind of API in our Quarkus guides to
> educate this is available.
>
> Unfortunately in Hibernate 5.2+ that api got marked [as
> deprecated](
> https://github.com/hibernate/hibernate-orm/blob/7a51b12cbb9a33c4569e8fa8cac0e234c65bd9ba/hibernate-core/src/main/java/org/hibernate/query/Query.java#L1101)
>
> with no other documentation than a `@todo develop a new approach to
> result transformers`.
>
> The actual only proper reason I could find was mentioned in
> https://vladmihalcea.com/hibernate-resulttransformer/ where its pointed
> out that for now we couldn't do a related functional style api for this
> until Hibernate 6.
>
> The @deprecation makes all code using this in many ides get a strike
> through of that code, making people think it is bad to use when it is
> very much not the case.
>
> Any chance that deprecation can either be removed or at least documented
> to be less scary/more informative ?
> (I'll happily make a PR if can be pointed to the new better api?)
>
>
> ### doWork missing on stateless session
>
> In similar vein `.connection()` on stateless session is marked as
> deprecated with [no alternative nor actual
> docs/info](
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/StatelessSession.java#L169
> ).
>
> on Session the alternative is `doWork`. Any reason why that api isn't
> available on stateless session ?
>
> Here again, the ask is so we can educate and point people to use
> statelessSession rather than dropping Hibernate fully and from that
> api if needed go do `.doWork()` rather than refer to deprecated
> `.connection()`
>
>
Makes sense
Dave Cramer
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
