From gunnar at hibernate.org  Thu Sep  1 02:11:36 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 1 Sep 2016 08:11:36 +0200
Subject: [hibernate-dev] Centralized access to "bootstrap only" resources
In-Reply-To: <CAFdSV9sgbP=ueka06a2=JBedvvE3RGf9ZO8BNRfbCSsPU30+hg@mail.gmail.com>
References: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>
	<20160830090913.GP90254@hibernate.org>
	<CAFm4XO3tBLerceVFZQ+Gzwa9xbdH2KMdv+0qLwDogUU3yBbnPg@mail.gmail.com>
	<CAFdSV9uOTunswVB7pGGnRAn=zadUOSZkiHAis_O7xD14TJNNqg@mail.gmail.com>
	<CAFdSV9u+wg3iWWLwxp7ePNT+n0CmbXpZC_PM56uxSAXpkOgypg@mail.gmail.com>
	<CAL00eSTPNaiV2_afdY5+gqKqfs-k2PbBimANWxiwP3VjG4+rgA@mail.gmail.com>
	<CAFdSV9sgbP=ueka06a2=JBedvvE3RGf9ZO8BNRfbCSsPU30+hg@mail.gmail.com>
Message-ID: <CADGJaX89wBk6vuNeM=XBobvN-nvM8xqHOCraq3MCrnf6N3u7Bw@mail.gmail.com>

> Do we want to change JpaIntegrator#integrate signature to pass its
context
> as a parameter object

If you think that's the better approach, I'd say 6 is the right time to do
it. Users (or integrators) will be prepared for this sort of breakage in a
major.

> do other projects supply custom
> org.hibernate.service.spi.SessionFactoryServiceInitiator impls

Yes, OGM does. Though I'm not too concerned about such change, it should be
easy for us to adjust and at this point we don't aim for compatibility with
several ORM (major) versions.

2016-09-01 4:09 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> One contract I would need to adjust for this
> is org.hibernate.service.spi.SessionFactoryServiceInitiator
> #initiateService.
> I can find all the implementations of that in ORM, but do other projects
> supply custom org.hibernate.service.spi.SessionFactoryServiceInitiator
> impls?
>
>
> On Wed, Aug 31, 2016 at 5:18 AM andrea boriero <andrea at hibernate.org>
> wrote:
>
> > I'm fine with combining native and JPA events handling, about the second
> > point, ideally I would change the signature but due to the problems you
> > listed I vote for the in-line solution.
> >
> > On 30 August 2016 at 19:20, Steve Ebersole <steve at hibernate.org> wrote:
> >
> >> Any thoughts on the JpaIntegrator parts of the discussion?
>  Specifically
> >> there are 2 main considerations:
> >>
> >>    1. To change the Integrator#integrate contract - ideally, in
> >> retrospect,
> >
> >
> >>    #integrate probably should have taken a "parameter object" to help
> >> insulate
> >>    from these types of changes.  But I wanted to get y'alls thoughts on
> >> this
> >>    especially since this one potentially causes upgrade problems in
> terms
> >> of
> >>    applications or problems supporting multiple ORM versions in terms
> >>    of integrations.
> >>
> >    2. The alternative I mentioned was to move the JpaIntegrator#integrate
> >
> >
> >>    functionality in-line with the building of the SessionFactory.  This
> >> has
> >>    some really nice benefits as discussed (like JPA callback support
> from
> >>    native bootstrapping), but it has some challenges to handle as well
> >> mainly
> >>    in terms of seamlessly combining the different Hibernate event
> >> listeners
> >>    used to implement the native versus JPA behavior.  The simple JPA
> >>    callback/listener case is pretty easy to support regardless.  The
> more
> >>    difficult ones are event listeners that implement event handling
> >>    differently () or the ones that cascade different actions depending
> on
> >>    native/jpa bootstrapping ().  I think even the latter bucket may be
> >> easy to
> >>    handle leveraging SessionFactoryOptions#isJpaBootstrap inside the
> >>    listeners.  The former bucket is really the one I am more concerned
> >> with.
> >>    So let's look at this as 2 distinct questions:
> >>
> >       1. Do we want to combine event listeners for native and JPA
> handling
> >>       of events?
> >>       2. Do we want to change JpaIntegrator#integrate signature to pass
> >> its
> >
> >
> >>       context as a parameter object in order to facilitate this?  Or do
> we
> >>       in-line the decisions/actions done in JpaIntegrator into
> >> SessionFactory
> >>       init?
> >>
> >
> >>
> >> On Tue, Aug 30, 2016 at 8:50 AM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >> > On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero <sanne at hibernate.org>
> >> > wrote:
> >> >
> >> >> On 30 August 2016 at 10:09, Emmanuel Bernard <emmanuel at hibernate.org
> >
> >> >> wrote:
> >> >> > I am not sure if that is still relevant but in the past, either
> >> HSEARCH
> >> >> > or HV were keeping the ReflectionManager around to use it at
> runtime
> >> >> > (either because metadata was loaded lazily or because of a reboot
> of
> >> the
> >> >> > factories due to a configuration change.
> >> >> >
> >> >> > So we need to check that losing access to ReflectionManager after
> SF
> >> is
> >> >> > created won't be problematic for these projects.
> >> >>
> >> >> In the "dynamic reconfiguration" case we create our own
> >> >> ReflectionManager instance:
> >> >>  -
> >> >>
> >> https://github.com/hibernate/hibernate-search/blob/
> fd4acb5d8f396201f5dccc89ba3cbc07becea08a/engine/src/main/
> java/org/hibernate/search/engine/impl/IncrementalSearchConfiguration
> .java#L26-L35
> >> >
> >> >
> >> > Interesting that y'all do not specify classloading behavior there (the
> >> > ClassLoaderDelegate stuff I added to HCANN)...
> >> >
> >> >
> >> >
> >> >> Steve, we had a similar notion of "boot only available components" in
> >> >> Search but over time we started to have various "special needs" of
> >> >> various other components holding a reference on these.
> >> >> When I later tried to re-instate order, it was too late and we got in
> >> >> arguments like the API's intent not having been clear enough and too
> >> >> much entanglement had happened.
> >> >>
> >> >
> >> > Hard to say without specifics. I hate "general rules" :)
> >> >
> >> > So let's look at the specifics in terms of things I have moved to
> >> > BootstrapContext...
> >> >
> >> >
> >>
> > >    1. HCANN ReflectionManager - as you said, y'all create your own for
> >>
> >
> >> >    your use case.  You'd own the lifecycle of that one you create.  I
> >> see no
> >> >    conflict there.   Also we know that in 7.0 HCANN use will go away
> >> and we
> >> >    will move to Jandex.  The Jandex IndexView reference is only valid
> >> for a
> >> >    limited period of time when WF hands it to us.
> >>
> > >    2.  JPA "temp ClassLoader" - I think this one is self-evident.  JPA
> >>
> >
> >> >    states that this ClassLoader (if one) is available for only a
> >> limited time.
> >>
> > >    3. ClassmateContext - I centralized this so that we did not have to
> >>
> >
> >> >    keep "priming" the classmate caches each time we needed to use
> >> classmate.
> >> >    Aside from a possible performance hit, there really is nothing
> >> special here
> >> >    versus creating a new ClassmateContext each time you need it.  For
> >> ORM we
> >> >    currently never use classmate outside of bootstrap.  Could that
> >> change?
> >> >    Maybe, and we'd deal with that if/when it does.
> >>
> > >    4. scanning components
> >>
> >
> >> >    (ArchiveDescriptorFactory, ScanOptions, ScanEnvironment, Scanner) -
> >> maybe
> >> >    going back to your "dynamic reconfiguration" scenario this makes
> >> sense.  No
> >> >    idea.  But in ORM holding on to these after bootstrap makes no
> sense.
> >>
> > >    5. I've also started making BootstrapContext the holder for
> bootstrap
> >>
> >
> >> >    metadata-related collectors.  Here we collect
> >> >    SQLFunctions, AuxiliaryDatabaseObjects,
> >> AttributeConverterDefinitions,
> >> >    and CacheRegionDefinitions.
> >>
> > >    6. There are 2 other (new in 6.0) delegates that I keep here too.
> >>
> >
> >> >    Interestingly, one is fully intended to be held beyond bootstrap.
> >> But I
> >> >    think that these intentions just need to be documented.
> >> >
> >> >
> >> > Overall I'd view a "dynamic reconfiguration" scenario very much like a
> >> > limite bootstrap scenario.  Personally I'd expect to have to maker
> many
> >> of
> >> > these "boot only resources" available to that process.  Not
> necessarily
> >> the
> >> > same ones as used during the primary bootstrap though.  I personally
> >> would
> >> > prefer to not hold reference to these "just in case" we have a
> "dynamic
> >> > reconfiguration" situation later; I'd just rebuild them.  Granted
> things
> >> > like a WF-handed Jandex IndexView would be difficult to handle in
> there,
> >> > but that is the case regardless of whether we hold reference to it or
> >> not;
> >> > that has to do with WF eventually invalidating that reference it
> handed
> >> us.
> >> >
> >> >
> >> > So while I think it's a good idea, and also Search should try this
> >> >> again, I think we'd need to design it from day 1 to be defensive
> >> >> against future code attempting to hold on these services.
> >> >> Not sure what would be the best approach for ORM, but I guess that
> >> >> simply invalidating/closing these components after bootstrap and
> >> >> having these throw an exception after that would be a good start.
> >> >>
> >> >
> >> > That is roughly what I do.  There is a BootstrapContext#release
> method.
> >> > It in turn releases the delegates it holds.  I can add some defensive
> >> > checking for throwing some "unavailable" exceptions in case stuff
> holds
> >> > references to these.  That's a good idea.
> >> >
> >> >
> >> > However, please allow some flexibility for the case in which someone
> >> >> really needs one of the services you're dooming at runtime.
> >> >> For example Search might need to re-read configuration properties at
> >> >> runtime; we can of course make a copy, but then we'd need a way to be
> >> >> able to make such a copy (We currently actually make such a copy of
> >> >> the cfg Properties).
> >> >> Configuration properties being just an example, maybe we need a
> >> >> generic way to be able to declare which services should not be
> cleaned
> >> >> up after bootstrap?
> >> >>
> >> >
> >> > We already hold on to configuration properties into the SF.  See
> >> > ConfigurationService.
> >> >
> >> >
> >> >
> >> >> In practice, the services you've listed should be fine today but the
> >> >> need for us to make a copy (or to invoke some API to ask for a life
> >> >> extension) might show up in future.
> >> >>
> >> >> Rough proposal :
> >> >>
> >> >> interface BootService {
> >> >>   void flagForUsageBeyondBootstrap();
> >> >> }
> >> >>
> >> >
> >> > -1 I think the BootstrapContext is not the right place for this.  It
> is
> >> > not the BootstrapContext itself that needs to remain valid, it is the
> >> > delegates it exposes.  That is where the "extension" should be
> >> allowed.  If
> >> > that is voted as generally worthwhile, I can see 2 options:
> >> >
> >>
> > >    1. Expose #allowExtendedAccess (or somesuch method name) to the
> actual
> >>
> >
> >> >    delegates.  This would be an indicator to not release its resources
> >> when
> >> >    the BootstrapContext#release method tells the delegate to release
> >> itself.
> >>
> > >    2. Allow OGM, Search, etc to specify specific impls for these
> >>
> >
> >> >    delegates.  It could handle the delegate's #release method however
> it
> >> >    wanted.
> >> >
> >> > However, realize that if these things are not released by
> >> > BootstrapContext#release then ORM washes its hands of cleaning them up
> >> (it
> >> > would have no "scope" to do that).
> >> >
> >>
> > _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Thu Sep  1 02:46:43 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 1 Sep 2016 08:46:43 +0200
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
In-Reply-To: <CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>
References: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
	<CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>
Message-ID: <CADGJaX_FCSYFqrsRFWUJPOKASPU87hwf-AphajAQ+zuHJWzOqg@mail.gmail.com>

> it is a huge mistake to save the specific TZ differences to the DB

I once was working on a globally deployed shipping management application
where that was a requirement.

Say there is a shipment from Austin (one TZ) to London (another TZ). In
that application an operator based in Hamburg (yet another TZ) should be
able to know when the shipment was brought in in Austin (the local time in
Austin at that point) and when it was delivered in Hamburg (again the local
time there at that point).

So we stored all dates in UTC, but also the TZ (in a *different column*; I
don't quite remember whether it was just a string with the TZ (offset) or
again the entire date-time using TIMESTAMP_WITH_TZ). Storing it in UTC
allowed for comparisons whereas the other column allowed to show each date
in its local TZ. So an operator in Hamburg (at CET) could see a delivery
was brought in in Austin at 8:32 CST.

Something like that would still be my preference for handling TZ-bound
types such as ZonedDateTime: store the UTC timestamp in one column and the
TZ info (either id or offset from UTC) in another.

Relying on the JVM TZ or something like a single "application TZ" won't cut
it for cases like the one above: the operator in Hamburg wants to see dates
from Austin and London, using their respective time zones. Instead, the TZ
of the incoming ZonedDateTime would have to be persisted so it's available
when reading it back.




2016-08-31 20:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> We discussed this on HipChat, but for the benefit of all on this
> discussion...
>
> Part of this (the original report) speaks to a difference in how we map
> (org.hibernate.type.Type) java.time temporal versus a java.util temporal -
> specifically java.util.Calendar.  When we are passed a Calendar (the model
> defines its attribute as Calendar) we pass along that Calendar reference to
> the JDBC driver which forces the driver to use that Calendar's TZ.  For
> java.time temporal types, we always resolve them to UTC values mainly
> because of how we get to the java.sql.Timestamp value from the java.time
> value.  For example, for ZonedDateTime we call:
>
>     return (X) Timestamp.from( zonedDateTime.toInstant() );
>
> The call to #toInstant there essentially forces the value to UTC because it
> converted directly to epoch-based numeric.
>
> Thinking about this some more and "stepping back", the real problem is that
> there are a few different timezones in play here that need to be balanced
> and handled:
>
>    1. The database default TZ
>    2. The stored TZ
>    3. The JVM/JDBC TZ
>    4. The application TZ
>
> The whole idea of "stored TZ" really depends on how the database/driver
> treats TIMESTAMP and whether it supports a "TIMESTAMP_WITH_TIMEZONE"
> type.  I
> personally think it is a huge mistake to save the specific TZ differences
> to the DB, so I would personally continue to not support
> TIMESTAMP_WITH_TIMEZONE
> types.  This would mean we never have to bind the Calendar because we could
> simply convert the value to to the JVM/JDBC TZ ourselves.  Specifically I
> would suggest that we (continue to) assume that the driver has been set up
> such that the same TZ is used when
>
>    1. when binding a Timestamp (without passing a Calendar)
>    2. reading a Timestamp (without passing a Calendar).
>
> Specifically this would mean setting the JVM TZ, or for JDBC drivers that
> support it setting the "default TZ" on the driver.  If we start storing
> values in the TZ specific to the Calendar we really have no idea how to
> properly read those values back because we'd lose context to that TZ.  For
> that reason I suggest we drop passing along the Calender and instead
> perform all these conversions in memory and pass the converted Timestamp to
> JDBC.  When reading back, that should mean the driver would return us
> Timestamps relative to that same TZ.
>
> The last piece is "application TZ" which would be an optional setting
> indicating the TZ zone-based values should be returned in.
>
> E.g., let's say a user maps a ZonedDataTime using @Temporal(TIMESTAMP).  If
> following my suggestions, when saving these values we would:
>
>    1. convert the ZonedDateTime to a ZonedDateTime in the "JVM/JDBC TZ" (if
>    different from the incoming ZonedDateTime's TZ)
>    2. use that to construct a Timestamp to bind to JDBC
>
> When reading back these values, we would:
>
>    1. get back the Timestamp from JDBC
>    2. assume the value is relative to the "JVM/JDBC TZ" and build the
>    ZonedDateTime via `ZonedDateTime.ofInstant( timestamp.toInstant(),
>    jvmJdbcZoneId )`
>    3. convert that built ZonedDateTime to the application TZ:
>    `builtZonedDateTime.withZoneSameInstant( applicationZoneId )` - it
> might
>    be possible to combine this step with the previous, not sure...
>
>
> Some if this is type-specific.  Assuming the suggestions above:
>
>    - Instant - inherently epoch-based.
>       - to convert this to a Timestamp for binding we would use
> `Timestamp#from(Instant).
>       Because of the above assumptions, the driver would interpret
> this relative
>       to JVM/JDBC TZ
>       - Reading back we simply use `Timestamp#toInstant()`
>    - LocalDateTime - is the relative idea of a date+time outside the
>    context of any specific TZ.
>       - When binding we would resolve this into the JVM/JDBC TZ (using
>       LocalDateTime#atZone(jvmJdbcZoneId), convert to an Instant and
> create a
>       Timestamp and bind that Timestamp to JDBC.
>       - When reading back we'd get the Instant from Timestamp and use that
>       in `LocalDateTime#ofInstant` using the application TZ
>    - LocalDate - relative idea of a date outside of any specific TZ.  Of
>    course this could also be mapped to a JDBC DATE which circumvents some
> of
>    this, but mapped to a TIMESTAMP...
>       - When binding we'd convert to a LocalDateTime using
>       `LocalDate#atStartOfDay` and treat that LocalDateTime as above.
>       - When reading back we would create a LocalDateTime using
> `LocalDateTime.ofInstant(timestamp.toInstant(),
>       applicationZoneId )`
>    - LocalTime - relative idea of a time outside any specific TZ.  Could
>    also be mapped to a JDBC TIME...
>       - When binding we'd create a LocalDateTime using `LocalTime.atDate(
>       LocalDate.of( 1970, 1, 1 ) )`, converting that to a ZonedDateTime
> using
>       `LocalDateTime#atZone( jvmJdbcZoneId )` and finally converting that
> to a
>       Timestamp
>       - When reading we would call `LocalDateTime.ofInstant(
>       timestamp.toInstant(), applicationZoneId ).toLocalTime()`
>    - ZonedDateTime - like a Calendar bundles a date+time with a TZ, and so
>    is directly convertible to an epoch-based value (Instant, Timestamp,
> etc).
>       - When binding we would convert this to an Instant and then to a
>       Timestamp
>       - When reading we would convert the Timestamp to an Instant and then
>       convert the Instant to a ZonedDateTime using
> `ZonedDateTime.ofInstant(
>       timestamp.toInstant(), applicationZoneId )`
>    - OffsetDateTime - handled similar to ZonedDateTime.
>       - When binding we would convert the value to a ZonedDateTime using
>       `OffsetDateTime#atZoneSameInstant( jvmJdbcZoneId )` and then follows
>       ZonedDateTime
>       - When reading we would use `OffsetDateTime.ofInstant(
>       timestamp.toInstant(), applicationZoneId )`
>    - OffsetTime - atm we just drop the ZoneOffset
>    - for java.util.Date and java.sql.Timstamp mapping we have to decide
>    what those concepts model in regards to their value relative to a TZ.
> Are
>    they a LocalDateTime relative to the system TimeZone?  Are they a
>    LocalDateTime relative to UTC?  At the moment how we handled these
> "legacy
>    Java temporal types" ends up answering this question as them being "a
>    LocalDateTime relative to the system TimeZone".
>    - what about java.sql.Time?  Is this a LocalTime?  An OffsetTime
>    relative to UTC (+0)?
>    - and java.sql.Date?
>
> Lot of moving parts when you actually start looking deep at "supporting
> timezones".
>
>
> [1]
> http://stackoverflow.com/questions/18447995/postgresql-
> 9-2-jdbc-driver-uses-client-time-zone,
> etc
>
> On Wed, Aug 31, 2016 at 9:10 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
> > Hi,
> >
> > While reviewing the Pull Request for this issue:
> > https://github.com/hibernate/hibernate-orm/pull/1536
> >
> > I realized that we can improve the default TimestampType as follows:
> >
> > 1. We could make it parameterizable so that it can also take a custom
> > timezone (UTC) during mapping.
> > 2. We could also define a default timezone so that we don't rely on the
> JVM
> > one. This might be desirable when the UI requires to display the time in
> a
> > certain timezone, while we want to save all timestamps in UTC.
> >
> > Let me know what you think.
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Sep  1 03:13:07 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 1 Sep 2016 10:13:07 +0300
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
In-Reply-To: <CADGJaX_FCSYFqrsRFWUJPOKASPU87hwf-AphajAQ+zuHJWzOqg@mail.gmail.com>
References: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
	<CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>
	<CADGJaX_FCSYFqrsRFWUJPOKASPU87hwf-AphajAQ+zuHJWzOqg@mail.gmail.com>
Message-ID: <CA+gWKMB_do0mmrWarGTUh3ExqiE9fLYZsJQNSYL0uYXfESv6dg@mail.gmail.com>

Hi,

For the moment, by adding a SF/Session-level configuration, we can at least
save Timestamps in UTC, which is indeed a very common scenario.

Later on, we can address the situation that you described in this email by
adding new types or introducing a new annotation to specify the secondary
field where the TZ info should be stored.

Vlad

On Thu, Sep 1, 2016 at 9:46 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> > it is a huge mistake to save the specific TZ differences to the DB
>
> I once was working on a globally deployed shipping management application
> where that was a requirement.
>
> Say there is a shipment from Austin (one TZ) to London (another TZ). In
> that application an operator based in Hamburg (yet another TZ) should be
> able to know when the shipment was brought in in Austin (the local time in
> Austin at that point) and when it was delivered in Hamburg (again the
> local time there at that point).
>
> So we stored all dates in UTC, but also the TZ (in a *different column*; I
> don't quite remember whether it was just a string with the TZ (offset) or
> again the entire date-time using TIMESTAMP_WITH_TZ). Storing it in UTC
> allowed for comparisons whereas the other column allowed to show each date
> in its local TZ. So an operator in Hamburg (at CET) could see a delivery
> was brought in in Austin at 8:32 CST.
>
> Something like that would still be my preference for handling TZ-bound
> types such as ZonedDateTime: store the UTC timestamp in one column and the
> TZ info (either id or offset from UTC) in another.
>
> Relying on the JVM TZ or something like a single "application TZ" won't
> cut it for cases like the one above: the operator in Hamburg wants to see
> dates from Austin and London, using their respective time zones. Instead,
> the TZ of the incoming ZonedDateTime would have to be persisted so it's
> available when reading it back.
>
>
>
>
> 2016-08-31 20:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> We discussed this on HipChat, but for the benefit of all on this
>> discussion...
>>
>> Part of this (the original report) speaks to a difference in how we map
>> (org.hibernate.type.Type) java.time temporal versus a java.util temporal -
>> specifically java.util.Calendar.  When we are passed a Calendar (the model
>> defines its attribute as Calendar) we pass along that Calendar reference
>> to
>> the JDBC driver which forces the driver to use that Calendar's TZ.  For
>> java.time temporal types, we always resolve them to UTC values mainly
>> because of how we get to the java.sql.Timestamp value from the java.time
>> value.  For example, for ZonedDateTime we call:
>>
>>     return (X) Timestamp.from( zonedDateTime.toInstant() );
>>
>> The call to #toInstant there essentially forces the value to UTC because
>> it
>> converted directly to epoch-based numeric.
>>
>> Thinking about this some more and "stepping back", the real problem is
>> that
>> there are a few different timezones in play here that need to be balanced
>> and handled:
>>
>>    1. The database default TZ
>>    2. The stored TZ
>>    3. The JVM/JDBC TZ
>>    4. The application TZ
>>
>> The whole idea of "stored TZ" really depends on how the database/driver
>> treats TIMESTAMP and whether it supports a "TIMESTAMP_WITH_TIMEZONE"
>> type.  I
>> personally think it is a huge mistake to save the specific TZ differences
>> to the DB, so I would personally continue to not support
>> TIMESTAMP_WITH_TIMEZONE
>> types.  This would mean we never have to bind the Calendar because we
>> could
>> simply convert the value to to the JVM/JDBC TZ ourselves.  Specifically I
>> would suggest that we (continue to) assume that the driver has been set up
>> such that the same TZ is used when
>>
>>    1. when binding a Timestamp (without passing a Calendar)
>>    2. reading a Timestamp (without passing a Calendar).
>>
>> Specifically this would mean setting the JVM TZ, or for JDBC drivers that
>> support it setting the "default TZ" on the driver.  If we start storing
>> values in the TZ specific to the Calendar we really have no idea how to
>> properly read those values back because we'd lose context to that TZ.  For
>> that reason I suggest we drop passing along the Calender and instead
>> perform all these conversions in memory and pass the converted Timestamp
>> to
>> JDBC.  When reading back, that should mean the driver would return us
>> Timestamps relative to that same TZ.
>>
>> The last piece is "application TZ" which would be an optional setting
>> indicating the TZ zone-based values should be returned in.
>>
>> E.g., let's say a user maps a ZonedDataTime using @Temporal(TIMESTAMP).
>> If
>> following my suggestions, when saving these values we would:
>>
>>    1. convert the ZonedDateTime to a ZonedDateTime in the "JVM/JDBC TZ"
>> (if
>>    different from the incoming ZonedDateTime's TZ)
>>    2. use that to construct a Timestamp to bind to JDBC
>>
>> When reading back these values, we would:
>>
>>    1. get back the Timestamp from JDBC
>>    2. assume the value is relative to the "JVM/JDBC TZ" and build the
>>    ZonedDateTime via `ZonedDateTime.ofInstant( timestamp.toInstant(),
>>    jvmJdbcZoneId )`
>>    3. convert that built ZonedDateTime to the application TZ:
>>    `builtZonedDateTime.withZoneSameInstant( applicationZoneId )` - it
>> might
>>    be possible to combine this step with the previous, not sure...
>>
>>
>> Some if this is type-specific.  Assuming the suggestions above:
>>
>>    - Instant - inherently epoch-based.
>>       - to convert this to a Timestamp for binding we would use
>> `Timestamp#from(Instant).
>>       Because of the above assumptions, the driver would interpret
>> this relative
>>       to JVM/JDBC TZ
>>       - Reading back we simply use `Timestamp#toInstant()`
>>    - LocalDateTime - is the relative idea of a date+time outside the
>>    context of any specific TZ.
>>       - When binding we would resolve this into the JVM/JDBC TZ (using
>>       LocalDateTime#atZone(jvmJdbcZoneId), convert to an Instant and
>> create a
>>       Timestamp and bind that Timestamp to JDBC.
>>       - When reading back we'd get the Instant from Timestamp and use that
>>       in `LocalDateTime#ofInstant` using the application TZ
>>    - LocalDate - relative idea of a date outside of any specific TZ.  Of
>>    course this could also be mapped to a JDBC DATE which circumvents some
>> of
>>    this, but mapped to a TIMESTAMP...
>>       - When binding we'd convert to a LocalDateTime using
>>       `LocalDate#atStartOfDay` and treat that LocalDateTime as above.
>>       - When reading back we would create a LocalDateTime using
>> `LocalDateTime.ofInstant(timestamp.toInstant(),
>>       applicationZoneId )`
>>    - LocalTime - relative idea of a time outside any specific TZ.  Could
>>    also be mapped to a JDBC TIME...
>>       - When binding we'd create a LocalDateTime using `LocalTime.atDate(
>>       LocalDate.of( 1970, 1, 1 ) )`, converting that to a ZonedDateTime
>> using
>>       `LocalDateTime#atZone( jvmJdbcZoneId )` and finally converting that
>> to a
>>       Timestamp
>>       - When reading we would call `LocalDateTime.ofInstant(
>>       timestamp.toInstant(), applicationZoneId ).toLocalTime()`
>>    - ZonedDateTime - like a Calendar bundles a date+time with a TZ, and so
>>    is directly convertible to an epoch-based value (Instant, Timestamp,
>> etc).
>>       - When binding we would convert this to an Instant and then to a
>>       Timestamp
>>       - When reading we would convert the Timestamp to an Instant and then
>>       convert the Instant to a ZonedDateTime using
>> `ZonedDateTime.ofInstant(
>>       timestamp.toInstant(), applicationZoneId )`
>>    - OffsetDateTime - handled similar to ZonedDateTime.
>>       - When binding we would convert the value to a ZonedDateTime using
>>       `OffsetDateTime#atZoneSameInstant( jvmJdbcZoneId )` and then
>> follows
>>       ZonedDateTime
>>       - When reading we would use `OffsetDateTime.ofInstant(
>>       timestamp.toInstant(), applicationZoneId )`
>>    - OffsetTime - atm we just drop the ZoneOffset
>>    - for java.util.Date and java.sql.Timstamp mapping we have to decide
>>    what those concepts model in regards to their value relative to a TZ.
>> Are
>>    they a LocalDateTime relative to the system TimeZone?  Are they a
>>    LocalDateTime relative to UTC?  At the moment how we handled these
>> "legacy
>>    Java temporal types" ends up answering this question as them being "a
>>    LocalDateTime relative to the system TimeZone".
>>    - what about java.sql.Time?  Is this a LocalTime?  An OffsetTime
>>    relative to UTC (+0)?
>>    - and java.sql.Date?
>>
>>
>> Lot of moving parts when you actually start looking deep at "supporting
>> timezones".
>>
>>
>> [1]
>> http://stackoverflow.com/questions/18447995/postgresql-9-2-
>> jdbc-driver-uses-client-time-zone,
>> etc
>>
>> On Wed, Aug 31, 2016 at 9:10 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > While reviewing the Pull Request for this issue:
>> > https://github.com/hibernate/hibernate-orm/pull/1536
>> >
>> > I realized that we can improve the default TimestampType as follows:
>> >
>> > 1. We could make it parameterizable so that it can also take a custom
>> > timezone (UTC) during mapping.
>> > 2. We could also define a default timezone so that we don't rely on the
>> JVM
>> > one. This might be desirable when the UI requires to display the time
>> in a
>> > certain timezone, while we want to save all timestamps in UTC.
>> >
>> > Let me know what you think.
>> >
>> > Vlad
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Thu Sep  1 03:19:33 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 1 Sep 2016 09:19:33 +0200
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
In-Reply-To: <CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>
References: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
	<CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>
Message-ID: <CADGJaX9BDOAnwa0dhzrYQY=Q8ppgrGJZ2NjE30sXiiJ4Z0GNHw@mail.gmail.com>

Regarding

> LocalDateTime [...]
> When binding we would resolve this into the JVM/JDBC TZ (using
> LocalDateTime#atZone(jvmJdbcZoneId)

Couldn't you rather use UTC when handling these TZ-less types?

This will make the solution more robust in cases where you requirement "JVM
TZ when saving = JVM TZ when reading back" isn't met. As these types have
no TZ component, the JVM TZ should take no influence whatsoever.


2016-08-31 20:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> We discussed this on HipChat, but for the benefit of all on this
> discussion...
>
> Part of this (the original report) speaks to a difference in how we map
> (org.hibernate.type.Type) java.time temporal versus a java.util temporal -
> specifically java.util.Calendar.  When we are passed a Calendar (the model
> defines its attribute as Calendar) we pass along that Calendar reference to
> the JDBC driver which forces the driver to use that Calendar's TZ.  For
> java.time temporal types, we always resolve them to UTC values mainly
> because of how we get to the java.sql.Timestamp value from the java.time
> value.  For example, for ZonedDateTime we call:
>
>     return (X) Timestamp.from( zonedDateTime.toInstant() );
>
> The call to #toInstant there essentially forces the value to UTC because it
> converted directly to epoch-based numeric.
>
> Thinking about this some more and "stepping back", the real problem is that
> there are a few different timezones in play here that need to be balanced
> and handled:
>
>    1. The database default TZ
>    2. The stored TZ
>    3. The JVM/JDBC TZ
>    4. The application TZ
>
> The whole idea of "stored TZ" really depends on how the database/driver
> treats TIMESTAMP and whether it supports a "TIMESTAMP_WITH_TIMEZONE"
> type.  I
> personally think it is a huge mistake to save the specific TZ differences
> to the DB, so I would personally continue to not support
> TIMESTAMP_WITH_TIMEZONE
> types.  This would mean we never have to bind the Calendar because we could
> simply convert the value to to the JVM/JDBC TZ ourselves.  Specifically I
> would suggest that we (continue to) assume that the driver has been set up
> such that the same TZ is used when
>
>    1. when binding a Timestamp (without passing a Calendar)
>    2. reading a Timestamp (without passing a Calendar).
>
> Specifically this would mean setting the JVM TZ, or for JDBC drivers that
> support it setting the "default TZ" on the driver.  If we start storing
> values in the TZ specific to the Calendar we really have no idea how to
> properly read those values back because we'd lose context to that TZ.  For
> that reason I suggest we drop passing along the Calender and instead
> perform all these conversions in memory and pass the converted Timestamp to
> JDBC.  When reading back, that should mean the driver would return us
> Timestamps relative to that same TZ.
>
> The last piece is "application TZ" which would be an optional setting
> indicating the TZ zone-based values should be returned in.
>
> E.g., let's say a user maps a ZonedDataTime using @Temporal(TIMESTAMP).  If
> following my suggestions, when saving these values we would:
>
>    1. convert the ZonedDateTime to a ZonedDateTime in the "JVM/JDBC TZ" (if
>    different from the incoming ZonedDateTime's TZ)
>    2. use that to construct a Timestamp to bind to JDBC
>
> When reading back these values, we would:
>
>    1. get back the Timestamp from JDBC
>    2. assume the value is relative to the "JVM/JDBC TZ" and build the
>    ZonedDateTime via `ZonedDateTime.ofInstant( timestamp.toInstant(),
>    jvmJdbcZoneId )`
>    3. convert that built ZonedDateTime to the application TZ:
>    `builtZonedDateTime.withZoneSameInstant( applicationZoneId )` - it
> might
>    be possible to combine this step with the previous, not sure...
>
>
> Some if this is type-specific.  Assuming the suggestions above:
>
>    - Instant - inherently epoch-based.
>       - to convert this to a Timestamp for binding we would use
> `Timestamp#from(Instant).
>       Because of the above assumptions, the driver would interpret
> this relative
>       to JVM/JDBC TZ
>       - Reading back we simply use `Timestamp#toInstant()`
>    - LocalDateTime - is the relative idea of a date+time outside the
>    context of any specific TZ.
>       - When binding we would resolve this into the JVM/JDBC TZ (using
>       LocalDateTime#atZone(jvmJdbcZoneId), convert to an Instant and
> create a
>       Timestamp and bind that Timestamp to JDBC.
>       - When reading back we'd get the Instant from Timestamp and use that
>       in `LocalDateTime#ofInstant` using the application TZ
>    - LocalDate - relative idea of a date outside of any specific TZ.  Of
>    course this could also be mapped to a JDBC DATE which circumvents some
> of
>    this, but mapped to a TIMESTAMP...
>       - When binding we'd convert to a LocalDateTime using
>       `LocalDate#atStartOfDay` and treat that LocalDateTime as above.
>       - When reading back we would create a LocalDateTime using
> `LocalDateTime.ofInstant(timestamp.toInstant(),
>       applicationZoneId )`
>    - LocalTime - relative idea of a time outside any specific TZ.  Could
>    also be mapped to a JDBC TIME...
>       - When binding we'd create a LocalDateTime using `LocalTime.atDate(
>       LocalDate.of( 1970, 1, 1 ) )`, converting that to a ZonedDateTime
> using
>       `LocalDateTime#atZone( jvmJdbcZoneId )` and finally converting that
> to a
>       Timestamp
>       - When reading we would call `LocalDateTime.ofInstant(
>       timestamp.toInstant(), applicationZoneId ).toLocalTime()`
>    - ZonedDateTime - like a Calendar bundles a date+time with a TZ, and so
>    is directly convertible to an epoch-based value (Instant, Timestamp,
> etc).
>       - When binding we would convert this to an Instant and then to a
>       Timestamp
>       - When reading we would convert the Timestamp to an Instant and then
>       convert the Instant to a ZonedDateTime using
> `ZonedDateTime.ofInstant(
>       timestamp.toInstant(), applicationZoneId )`
>    - OffsetDateTime - handled similar to ZonedDateTime.
>       - When binding we would convert the value to a ZonedDateTime using
>       `OffsetDateTime#atZoneSameInstant( jvmJdbcZoneId )` and then follows
>       ZonedDateTime
>       - When reading we would use `OffsetDateTime.ofInstant(
>       timestamp.toInstant(), applicationZoneId )`
>    - OffsetTime - atm we just drop the ZoneOffset
>    - for java.util.Date and java.sql.Timstamp mapping we have to decide
>    what those concepts model in regards to their value relative to a TZ.
> Are
>    they a LocalDateTime relative to the system TimeZone?  Are they a
>    LocalDateTime relative to UTC?  At the moment how we handled these
> "legacy
>    Java temporal types" ends up answering this question as them being "a
>    LocalDateTime relative to the system TimeZone".
>    - what about java.sql.Time?  Is this a LocalTime?  An OffsetTime
>    relative to UTC (+0)?
>    - and java.sql.Date?
>
> Lot of moving parts when you actually start looking deep at "supporting
> timezones".
>
>
> [1]
> http://stackoverflow.com/questions/18447995/postgresql-
> 9-2-jdbc-driver-uses-client-time-zone,
> etc
>
> On Wed, Aug 31, 2016 at 9:10 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
> > Hi,
> >
> > While reviewing the Pull Request for this issue:
> > https://github.com/hibernate/hibernate-orm/pull/1536
> >
> > I realized that we can improve the default TimestampType as follows:
> >
> > 1. We could make it parameterizable so that it can also take a custom
> > timezone (UTC) during mapping.
> > 2. We could also define a default timezone so that we don't rely on the
> JVM
> > one. This might be desirable when the UI requires to display the time in
> a
> > certain timezone, while we want to save all timestamps in UTC.
> >
> > Let me know what you think.
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Sep  1 05:59:01 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 1 Sep 2016 10:59:01 +0100
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
In-Reply-To: <CADGJaX_FCSYFqrsRFWUJPOKASPU87hwf-AphajAQ+zuHJWzOqg@mail.gmail.com>
References: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
	<CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>
	<CADGJaX_FCSYFqrsRFWUJPOKASPU87hwf-AphajAQ+zuHJWzOqg@mail.gmail.com>
Message-ID: <CAFm4XO2HB8JAtwQU3NUPHLZwTfM-gsdHxjg=0o8b_gg2Bh=xkg@mail.gmail.com>

To be fair I would have mapped that differently.
Your Shipment arrives at a certain *point in time* (long, UTC based)
in a certain Port (mapped with Foreign Key).
A Port would have a reference to a local Timezone, and UI could decide
to use that (or a different one) for rendering, based on other
aspects, like the location of the user actually looking at the UI, or
even a switchable user option.

Saving in "timezoned" instants is prone to several bugs: you're then
exposed to ambiguities as time doesn't flow linearly in all zones.

Storing a timezoned instant only makes sense when you're quoting a
political/legal source; i.e. you'ave passed under OCR some legal
paperwork and you need to store the date printed on the header in a
dedicated field, in Java8 time type you'd never use an Instant for
this though, there are dedicated types which make the limitations of
this representation clear. AFAIR some kinds of comparisons are made
impossible.

I'd not spend time with improvements on Calendar: the "old Date types"
should be deprecated.


On 1 September 2016 at 07:46, Gunnar Morling <gunnar at hibernate.org> wrote:
>> it is a huge mistake to save the specific TZ differences to the DB
>
> I once was working on a globally deployed shipping management application
> where that was a requirement.
>
> Say there is a shipment from Austin (one TZ) to London (another TZ). In
> that application an operator based in Hamburg (yet another TZ) should be
> able to know when the shipment was brought in in Austin (the local time in
> Austin at that point) and when it was delivered in Hamburg (again the local
> time there at that point).
>
> So we stored all dates in UTC, but also the TZ (in a *different column*; I
> don't quite remember whether it was just a string with the TZ (offset) or
> again the entire date-time using TIMESTAMP_WITH_TZ). Storing it in UTC
> allowed for comparisons whereas the other column allowed to show each date
> in its local TZ. So an operator in Hamburg (at CET) could see a delivery
> was brought in in Austin at 8:32 CST.
>
> Something like that would still be my preference for handling TZ-bound
> types such as ZonedDateTime: store the UTC timestamp in one column and the
> TZ info (either id or offset from UTC) in another.
>
> Relying on the JVM TZ or something like a single "application TZ" won't cut
> it for cases like the one above: the operator in Hamburg wants to see dates
> from Austin and London, using their respective time zones. Instead, the TZ
> of the incoming ZonedDateTime would have to be persisted so it's available
> when reading it back.
>
>
>
>
> 2016-08-31 20:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> We discussed this on HipChat, but for the benefit of all on this
>> discussion...
>>
>> Part of this (the original report) speaks to a difference in how we map
>> (org.hibernate.type.Type) java.time temporal versus a java.util temporal -
>> specifically java.util.Calendar.  When we are passed a Calendar (the model
>> defines its attribute as Calendar) we pass along that Calendar reference to
>> the JDBC driver which forces the driver to use that Calendar's TZ.  For
>> java.time temporal types, we always resolve them to UTC values mainly
>> because of how we get to the java.sql.Timestamp value from the java.time
>> value.  For example, for ZonedDateTime we call:
>>
>>     return (X) Timestamp.from( zonedDateTime.toInstant() );
>>
>> The call to #toInstant there essentially forces the value to UTC because it
>> converted directly to epoch-based numeric.
>>
>> Thinking about this some more and "stepping back", the real problem is that
>> there are a few different timezones in play here that need to be balanced
>> and handled:
>>
>>    1. The database default TZ
>>    2. The stored TZ
>>    3. The JVM/JDBC TZ
>>    4. The application TZ
>>
>> The whole idea of "stored TZ" really depends on how the database/driver
>> treats TIMESTAMP and whether it supports a "TIMESTAMP_WITH_TIMEZONE"
>> type.  I
>> personally think it is a huge mistake to save the specific TZ differences
>> to the DB, so I would personally continue to not support
>> TIMESTAMP_WITH_TIMEZONE
>> types.  This would mean we never have to bind the Calendar because we could
>> simply convert the value to to the JVM/JDBC TZ ourselves.  Specifically I
>> would suggest that we (continue to) assume that the driver has been set up
>> such that the same TZ is used when
>>
>>    1. when binding a Timestamp (without passing a Calendar)
>>    2. reading a Timestamp (without passing a Calendar).
>>
>> Specifically this would mean setting the JVM TZ, or for JDBC drivers that
>> support it setting the "default TZ" on the driver.  If we start storing
>> values in the TZ specific to the Calendar we really have no idea how to
>> properly read those values back because we'd lose context to that TZ.  For
>> that reason I suggest we drop passing along the Calender and instead
>> perform all these conversions in memory and pass the converted Timestamp to
>> JDBC.  When reading back, that should mean the driver would return us
>> Timestamps relative to that same TZ.
>>
>> The last piece is "application TZ" which would be an optional setting
>> indicating the TZ zone-based values should be returned in.
>>
>> E.g., let's say a user maps a ZonedDataTime using @Temporal(TIMESTAMP).  If
>> following my suggestions, when saving these values we would:
>>
>>    1. convert the ZonedDateTime to a ZonedDateTime in the "JVM/JDBC TZ" (if
>>    different from the incoming ZonedDateTime's TZ)
>>    2. use that to construct a Timestamp to bind to JDBC
>>
>> When reading back these values, we would:
>>
>>    1. get back the Timestamp from JDBC
>>    2. assume the value is relative to the "JVM/JDBC TZ" and build the
>>    ZonedDateTime via `ZonedDateTime.ofInstant( timestamp.toInstant(),
>>    jvmJdbcZoneId )`
>>    3. convert that built ZonedDateTime to the application TZ:
>>    `builtZonedDateTime.withZoneSameInstant( applicationZoneId )` - it
>> might
>>    be possible to combine this step with the previous, not sure...
>>
>>
>> Some if this is type-specific.  Assuming the suggestions above:
>>
>>    - Instant - inherently epoch-based.
>>       - to convert this to a Timestamp for binding we would use
>> `Timestamp#from(Instant).
>>       Because of the above assumptions, the driver would interpret
>> this relative
>>       to JVM/JDBC TZ
>>       - Reading back we simply use `Timestamp#toInstant()`
>>    - LocalDateTime - is the relative idea of a date+time outside the
>>    context of any specific TZ.
>>       - When binding we would resolve this into the JVM/JDBC TZ (using
>>       LocalDateTime#atZone(jvmJdbcZoneId), convert to an Instant and
>> create a
>>       Timestamp and bind that Timestamp to JDBC.
>>       - When reading back we'd get the Instant from Timestamp and use that
>>       in `LocalDateTime#ofInstant` using the application TZ
>>    - LocalDate - relative idea of a date outside of any specific TZ.  Of
>>    course this could also be mapped to a JDBC DATE which circumvents some
>> of
>>    this, but mapped to a TIMESTAMP...
>>       - When binding we'd convert to a LocalDateTime using
>>       `LocalDate#atStartOfDay` and treat that LocalDateTime as above.
>>       - When reading back we would create a LocalDateTime using
>> `LocalDateTime.ofInstant(timestamp.toInstant(),
>>       applicationZoneId )`
>>    - LocalTime - relative idea of a time outside any specific TZ.  Could
>>    also be mapped to a JDBC TIME...
>>       - When binding we'd create a LocalDateTime using `LocalTime.atDate(
>>       LocalDate.of( 1970, 1, 1 ) )`, converting that to a ZonedDateTime
>> using
>>       `LocalDateTime#atZone( jvmJdbcZoneId )` and finally converting that
>> to a
>>       Timestamp
>>       - When reading we would call `LocalDateTime.ofInstant(
>>       timestamp.toInstant(), applicationZoneId ).toLocalTime()`
>>    - ZonedDateTime - like a Calendar bundles a date+time with a TZ, and so
>>    is directly convertible to an epoch-based value (Instant, Timestamp,
>> etc).
>>       - When binding we would convert this to an Instant and then to a
>>       Timestamp
>>       - When reading we would convert the Timestamp to an Instant and then
>>       convert the Instant to a ZonedDateTime using
>> `ZonedDateTime.ofInstant(
>>       timestamp.toInstant(), applicationZoneId )`
>>    - OffsetDateTime - handled similar to ZonedDateTime.
>>       - When binding we would convert the value to a ZonedDateTime using
>>       `OffsetDateTime#atZoneSameInstant( jvmJdbcZoneId )` and then follows
>>       ZonedDateTime
>>       - When reading we would use `OffsetDateTime.ofInstant(
>>       timestamp.toInstant(), applicationZoneId )`
>>    - OffsetTime - atm we just drop the ZoneOffset
>>    - for java.util.Date and java.sql.Timstamp mapping we have to decide
>>    what those concepts model in regards to their value relative to a TZ.
>> Are
>>    they a LocalDateTime relative to the system TimeZone?  Are they a
>>    LocalDateTime relative to UTC?  At the moment how we handled these
>> "legacy
>>    Java temporal types" ends up answering this question as them being "a
>>    LocalDateTime relative to the system TimeZone".
>>    - what about java.sql.Time?  Is this a LocalTime?  An OffsetTime
>>    relative to UTC (+0)?
>>    - and java.sql.Date?
>>
>> Lot of moving parts when you actually start looking deep at "supporting
>> timezones".
>>
>>
>> [1]
>> http://stackoverflow.com/questions/18447995/postgresql-
>> 9-2-jdbc-driver-uses-client-time-zone,
>> etc
>>
>> On Wed, Aug 31, 2016 at 9:10 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > While reviewing the Pull Request for this issue:
>> > https://github.com/hibernate/hibernate-orm/pull/1536
>> >
>> > I realized that we can improve the default TimestampType as follows:
>> >
>> > 1. We could make it parameterizable so that it can also take a custom
>> > timezone (UTC) during mapping.
>> > 2. We could also define a default timezone so that we don't rely on the
>> JVM
>> > one. This might be desirable when the UI requires to display the time in
>> a
>> > certain timezone, while we want to save all timestamps in UTC.
>> >
>> > Let me know what you think.
>> >
>> > Vlad
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Thu Sep  1 06:13:44 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 1 Sep 2016 12:13:44 +0200
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
In-Reply-To: <CAFm4XO2HB8JAtwQU3NUPHLZwTfM-gsdHxjg=0o8b_gg2Bh=xkg@mail.gmail.com>
References: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
	<CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>
	<CADGJaX_FCSYFqrsRFWUJPOKASPU87hwf-AphajAQ+zuHJWzOqg@mail.gmail.com>
	<CAFm4XO2HB8JAtwQU3NUPHLZwTfM-gsdHxjg=0o8b_gg2Bh=xkg@mail.gmail.com>
Message-ID: <CADGJaX-c4NipcksKV6H8duA=Ucja4uuGJ5tO_wTa5KV+gwUUJQ@mail.gmail.com>

> Saving in "timezoned" instants is prone to several bugs: you're then
> exposed to ambiguities as time doesn't flow linearly in all zones.

I see it the other way around: the indirection you suggest is prone to
errors.

Rules about TZ constantly change (e.g. when switching to/from DST),
locations change time zones more often than one would expect. Saving the
then valid TZ "next to" an UTC timestamp is much easier and more reliable
then trying to reconstruct that info from some historical TZ DB.


2016-09-01 11:59 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> To be fair I would have mapped that differently.
> Your Shipment arrives at a certain *point in time* (long, UTC based)
> in a certain Port (mapped with Foreign Key).
> A Port would have a reference to a local Timezone, and UI could decide
> to use that (or a different one) for rendering, based on other
> aspects, like the location of the user actually looking at the UI, or
> even a switchable user option.
>
> Saving in "timezoned" instants is prone to several bugs: you're then
> exposed to ambiguities as time doesn't flow linearly in all zones.
>
> Storing a timezoned instant only makes sense when you're quoting a
> political/legal source; i.e. you'ave passed under OCR some legal
> paperwork and you need to store the date printed on the header in a
> dedicated field, in Java8 time type you'd never use an Instant for
> this though, there are dedicated types which make the limitations of
> this representation clear. AFAIR some kinds of comparisons are made
> impossible.
>
> I'd not spend time with improvements on Calendar: the "old Date types"
> should be deprecated.
>
>
> On 1 September 2016 at 07:46, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> it is a huge mistake to save the specific TZ differences to the DB
> >
> > I once was working on a globally deployed shipping management application
> > where that was a requirement.
> >
> > Say there is a shipment from Austin (one TZ) to London (another TZ). In
> > that application an operator based in Hamburg (yet another TZ) should be
> > able to know when the shipment was brought in in Austin (the local time
> in
> > Austin at that point) and when it was delivered in Hamburg (again the
> local
> > time there at that point).
> >
> > So we stored all dates in UTC, but also the TZ (in a *different column*;
> I
> > don't quite remember whether it was just a string with the TZ (offset) or
> > again the entire date-time using TIMESTAMP_WITH_TZ). Storing it in UTC
> > allowed for comparisons whereas the other column allowed to show each
> date
> > in its local TZ. So an operator in Hamburg (at CET) could see a delivery
> > was brought in in Austin at 8:32 CST.
> >
> > Something like that would still be my preference for handling TZ-bound
> > types such as ZonedDateTime: store the UTC timestamp in one column and
> the
> > TZ info (either id or offset from UTC) in another.
> >
> > Relying on the JVM TZ or something like a single "application TZ" won't
> cut
> > it for cases like the one above: the operator in Hamburg wants to see
> dates
> > from Austin and London, using their respective time zones. Instead, the
> TZ
> > of the incoming ZonedDateTime would have to be persisted so it's
> available
> > when reading it back.
> >
> >
> >
> >
> > 2016-08-31 20:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >
> >> We discussed this on HipChat, but for the benefit of all on this
> >> discussion...
> >>
> >> Part of this (the original report) speaks to a difference in how we map
> >> (org.hibernate.type.Type) java.time temporal versus a java.util
> temporal -
> >> specifically java.util.Calendar.  When we are passed a Calendar (the
> model
> >> defines its attribute as Calendar) we pass along that Calendar
> reference to
> >> the JDBC driver which forces the driver to use that Calendar's TZ.  For
> >> java.time temporal types, we always resolve them to UTC values mainly
> >> because of how we get to the java.sql.Timestamp value from the java.time
> >> value.  For example, for ZonedDateTime we call:
> >>
> >>     return (X) Timestamp.from( zonedDateTime.toInstant() );
> >>
> >> The call to #toInstant there essentially forces the value to UTC
> because it
> >> converted directly to epoch-based numeric.
> >>
> >> Thinking about this some more and "stepping back", the real problem is
> that
> >> there are a few different timezones in play here that need to be
> balanced
> >> and handled:
> >>
> >>    1. The database default TZ
> >>    2. The stored TZ
> >>    3. The JVM/JDBC TZ
> >>    4. The application TZ
> >>
> >> The whole idea of "stored TZ" really depends on how the database/driver
> >> treats TIMESTAMP and whether it supports a "TIMESTAMP_WITH_TIMEZONE"
> >> type.  I
> >> personally think it is a huge mistake to save the specific TZ
> differences
> >> to the DB, so I would personally continue to not support
> >> TIMESTAMP_WITH_TIMEZONE
> >> types.  This would mean we never have to bind the Calendar because we
> could
> >> simply convert the value to to the JVM/JDBC TZ ourselves.  Specifically
> I
> >> would suggest that we (continue to) assume that the driver has been set
> up
> >> such that the same TZ is used when
> >>
> >>    1. when binding a Timestamp (without passing a Calendar)
> >>    2. reading a Timestamp (without passing a Calendar).
> >>
> >> Specifically this would mean setting the JVM TZ, or for JDBC drivers
> that
> >> support it setting the "default TZ" on the driver.  If we start storing
> >> values in the TZ specific to the Calendar we really have no idea how to
> >> properly read those values back because we'd lose context to that TZ.
> For
> >> that reason I suggest we drop passing along the Calender and instead
> >> perform all these conversions in memory and pass the converted
> Timestamp to
> >> JDBC.  When reading back, that should mean the driver would return us
> >> Timestamps relative to that same TZ.
> >>
> >> The last piece is "application TZ" which would be an optional setting
> >> indicating the TZ zone-based values should be returned in.
> >>
> >> E.g., let's say a user maps a ZonedDataTime using
> @Temporal(TIMESTAMP).  If
> >> following my suggestions, when saving these values we would:
> >>
> >>    1. convert the ZonedDateTime to a ZonedDateTime in the "JVM/JDBC TZ"
> (if
> >>    different from the incoming ZonedDateTime's TZ)
> >>    2. use that to construct a Timestamp to bind to JDBC
> >>
> >> When reading back these values, we would:
> >>
> >>    1. get back the Timestamp from JDBC
> >>    2. assume the value is relative to the "JVM/JDBC TZ" and build the
> >>    ZonedDateTime via `ZonedDateTime.ofInstant( timestamp.toInstant(),
> >>    jvmJdbcZoneId )`
> >>    3. convert that built ZonedDateTime to the application TZ:
> >>    `builtZonedDateTime.withZoneSameInstant( applicationZoneId )` - it
> >> might
> >>    be possible to combine this step with the previous, not sure...
> >>
> >>
> >> Some if this is type-specific.  Assuming the suggestions above:
> >>
> >>    - Instant - inherently epoch-based.
> >>       - to convert this to a Timestamp for binding we would use
> >> `Timestamp#from(Instant).
> >>       Because of the above assumptions, the driver would interpret
> >> this relative
> >>       to JVM/JDBC TZ
> >>       - Reading back we simply use `Timestamp#toInstant()`
> >>    - LocalDateTime - is the relative idea of a date+time outside the
> >>    context of any specific TZ.
> >>       - When binding we would resolve this into the JVM/JDBC TZ (using
> >>       LocalDateTime#atZone(jvmJdbcZoneId), convert to an Instant and
> >> create a
> >>       Timestamp and bind that Timestamp to JDBC.
> >>       - When reading back we'd get the Instant from Timestamp and use
> that
> >>       in `LocalDateTime#ofInstant` using the application TZ
> >>    - LocalDate - relative idea of a date outside of any specific TZ.  Of
> >>    course this could also be mapped to a JDBC DATE which circumvents
> some
> >> of
> >>    this, but mapped to a TIMESTAMP...
> >>       - When binding we'd convert to a LocalDateTime using
> >>       `LocalDate#atStartOfDay` and treat that LocalDateTime as above.
> >>       - When reading back we would create a LocalDateTime using
> >> `LocalDateTime.ofInstant(timestamp.toInstant(),
> >>       applicationZoneId )`
> >>    - LocalTime - relative idea of a time outside any specific TZ.  Could
> >>    also be mapped to a JDBC TIME...
> >>       - When binding we'd create a LocalDateTime using
> `LocalTime.atDate(
> >>       LocalDate.of( 1970, 1, 1 ) )`, converting that to a ZonedDateTime
> >> using
> >>       `LocalDateTime#atZone( jvmJdbcZoneId )` and finally converting
> that
> >> to a
> >>       Timestamp
> >>       - When reading we would call `LocalDateTime.ofInstant(
> >>       timestamp.toInstant(), applicationZoneId ).toLocalTime()`
> >>    - ZonedDateTime - like a Calendar bundles a date+time with a TZ, and
> so
> >>    is directly convertible to an epoch-based value (Instant, Timestamp,
> >> etc).
> >>       - When binding we would convert this to an Instant and then to a
> >>       Timestamp
> >>       - When reading we would convert the Timestamp to an Instant and
> then
> >>       convert the Instant to a ZonedDateTime using
> >> `ZonedDateTime.ofInstant(
> >>       timestamp.toInstant(), applicationZoneId )`
> >>    - OffsetDateTime - handled similar to ZonedDateTime.
> >>       - When binding we would convert the value to a ZonedDateTime using
> >>       `OffsetDateTime#atZoneSameInstant( jvmJdbcZoneId )` and then
> follows
> >>       ZonedDateTime
> >>       - When reading we would use `OffsetDateTime.ofInstant(
> >>       timestamp.toInstant(), applicationZoneId )`
> >>    - OffsetTime - atm we just drop the ZoneOffset
> >>    - for java.util.Date and java.sql.Timstamp mapping we have to decide
> >>    what those concepts model in regards to their value relative to a TZ.
> >> Are
> >>    they a LocalDateTime relative to the system TimeZone?  Are they a
> >>    LocalDateTime relative to UTC?  At the moment how we handled these
> >> "legacy
> >>    Java temporal types" ends up answering this question as them being "a
> >>    LocalDateTime relative to the system TimeZone".
> >>    - what about java.sql.Time?  Is this a LocalTime?  An OffsetTime
> >>    relative to UTC (+0)?
> >>    - and java.sql.Date?
> >>
> >> Lot of moving parts when you actually start looking deep at "supporting
> >> timezones".
> >>
> >>
> >> [1]
> >> http://stackoverflow.com/questions/18447995/postgresql-
> >> 9-2-jdbc-driver-uses-client-time-zone,
> >> etc
> >>
> >> On Wed, Aug 31, 2016 at 9:10 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > While reviewing the Pull Request for this issue:
> >> > https://github.com/hibernate/hibernate-orm/pull/1536
> >> >
> >> > I realized that we can improve the default TimestampType as follows:
> >> >
> >> > 1. We could make it parameterizable so that it can also take a custom
> >> > timezone (UTC) during mapping.
> >> > 2. We could also define a default timezone so that we don't rely on
> the
> >> JVM
> >> > one. This might be desirable when the UI requires to display the time
> in
> >> a
> >> > certain timezone, while we want to save all timestamps in UTC.
> >> >
> >> > Let me know what you think.
> >> >
> >> > Vlad
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From devstack74 at gmail.com  Thu Sep  1 06:14:07 2016
From: devstack74 at gmail.com (Dev Stack)
Date: Thu, 1 Sep 2016 12:14:07 +0200
Subject: [hibernate-dev] Hibernate Envers > link between to auditable
	entities
Message-ID: <CAKYNcuNZvYoi8=id4KhboDC=TKOqqkgmC6zpe3QMcNRi3J=jPw@mail.gmail.com>

Hello,

we have in our model entity P (product) and entity O (offer). The two
entities have a link.
one instance of P can have one or many O instances.
an instance O has a reference to only one instance of P.
The link is managed in the O side.

P and O are revisioned by Hibernate Envers.

Two use cases to cover:
1) If P instance is updated (new revision) we want that O keep the link
with the old revision of P.
2) When I update O instance, I will move the reference to the last revision
of O instance.

What we did is, inside O class we added to attributes P.id and P.revision.
So when we load the object P we use these to fields to load manually (O DAO
has reference P DAO).

Is there a better way to do it?
Should we keep the reference of P in O instance as auditable and Envers
will manage?

Thanks,
Tarek

From christian.beikov at gmail.com  Thu Sep  1 06:18:47 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 1 Sep 2016 12:18:47 +0200
Subject: [hibernate-dev] HHH-11042 Count distinct tuples
Message-ID: <9bda3dd4-4440-1e9f-1ddc-1021b6eafccd@gmail.com>

Hey,

I wanted to start a discussion regarding this issue: 
https://hibernate.atlassian.net/browse/HHH-11042

Although the Dialect class contains the method 
"supportsTupleDistinctCount", it is never used, so when doing a count 
distinct on a tuple, it just renders the tuple instead of doing a 
fallback or throwing an error.

I suggested the OP to override the count function in the dialect to do 
whatever he thinks is best but then I realized that the count function 
is not even used as the logic is hard coded in some locations. The 
problematic location in this case is 
"org.hibernate.hql.internal.ast.tree.IdentNode.resolveAsAlias" which 
does not consider the function at all but renders the SQL directly.

After suggesting him to introduce a custom function instead and some 
discussion on how count distinct could be reliably implemented I think I 
found a solution that might work for most databases.

On stackoverflow and other sites it is often suggested to use a checksum 
to workaround this limitation which obviously is not a good idea. I 
proposed to do concatenation with a separator that doesn't appear in the 
string and apparently the character '\0' is a valid character which 
makes it a good candidate as that should normally not appear in a string.

The final solution to the problem looks something like the following

count(distinct case when col1 is null or col2 is null then null else 
col1 || '\0' || col2 end) + count(case when col1 is null or col2 is null 
then 1 end)

The first count does a count distinct on all columns concatenated with 
'\0' where all values are not null. The second just counts the cases 
where one of the column values was null. Together that emits the proper 
count based on the assumption that '\0' does not appear in the columns.

What do you think about that solution? I would like to implement it that 
way and do a PR.

I would also like to make use of the count function registered in the 
dialect to make this overrideable. Hope that's okay?


Regards,
Christian

From steve at hibernate.org  Thu Sep  1 06:52:08 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 01 Sep 2016 10:52:08 +0000
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
In-Reply-To: <CADGJaX-c4NipcksKV6H8duA=Ucja4uuGJ5tO_wTa5KV+gwUUJQ@mail.gmail.com>
References: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
	<CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>
	<CADGJaX_FCSYFqrsRFWUJPOKASPU87hwf-AphajAQ+zuHJWzOqg@mail.gmail.com>
	<CAFm4XO2HB8JAtwQU3NUPHLZwTfM-gsdHxjg=0o8b_gg2Bh=xkg@mail.gmail.com>
	<CADGJaX-c4NipcksKV6H8duA=Ucja4uuGJ5tO_wTa5KV+gwUUJQ@mail.gmail.com>
Message-ID: <CAFdSV9uMeXvkkJVrGRc8x4UL74sy5tbmJgH74o4GUN1ebP3ogQ@mail.gmail.com>

I think your example is actually a perfect example of when to not store the
TZ.

On Thu, Sep 1, 2016, 5:16 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> > Saving in "timezoned" instants is prone to several bugs: you're then
> > exposed to ambiguities as time doesn't flow linearly in all zones.
>
> I see it the other way around: the indirection you suggest is prone to
> errors.
>
> Rules about TZ constantly change (e.g. when switching to/from DST),
> locations change time zones more often than one would expect. Saving the
> then valid TZ "next to" an UTC timestamp is much easier and more reliable
> then trying to reconstruct that info from some historical TZ DB.
>
>
> 2016-09-01 11:59 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
> > To be fair I would have mapped that differently.
> > Your Shipment arrives at a certain *point in time* (long, UTC based)
> > in a certain Port (mapped with Foreign Key).
> > A Port would have a reference to a local Timezone, and UI could decide
> > to use that (or a different one) for rendering, based on other
> > aspects, like the location of the user actually looking at the UI, or
> > even a switchable user option.
> >
> > Saving in "timezoned" instants is prone to several bugs: you're then
> > exposed to ambiguities as time doesn't flow linearly in all zones.
> >
> > Storing a timezoned instant only makes sense when you're quoting a
> > political/legal source; i.e. you'ave passed under OCR some legal
> > paperwork and you need to store the date printed on the header in a
> > dedicated field, in Java8 time type you'd never use an Instant for
> > this though, there are dedicated types which make the limitations of
> > this representation clear. AFAIR some kinds of comparisons are made
> > impossible.
> >
> > I'd not spend time with improvements on Calendar: the "old Date types"
> > should be deprecated.
> >
> >
> > On 1 September 2016 at 07:46, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> > >> it is a huge mistake to save the specific TZ differences to the DB
> > >
> > > I once was working on a globally deployed shipping management
> application
> > > where that was a requirement.
> > >
> > > Say there is a shipment from Austin (one TZ) to London (another TZ). In
> > > that application an operator based in Hamburg (yet another TZ) should
> be
> > > able to know when the shipment was brought in in Austin (the local time
> > in
> > > Austin at that point) and when it was delivered in Hamburg (again the
> > local
> > > time there at that point).
> > >
> > > So we stored all dates in UTC, but also the TZ (in a *different
> column*;
> > I
> > > don't quite remember whether it was just a string with the TZ (offset)
> or
> > > again the entire date-time using TIMESTAMP_WITH_TZ). Storing it in UTC
> > > allowed for comparisons whereas the other column allowed to show each
> > date
> > > in its local TZ. So an operator in Hamburg (at CET) could see a
> delivery
> > > was brought in in Austin at 8:32 CST.
> > >
> > > Something like that would still be my preference for handling TZ-bound
> > > types such as ZonedDateTime: store the UTC timestamp in one column and
> > the
> > > TZ info (either id or offset from UTC) in another.
> > >
> > > Relying on the JVM TZ or something like a single "application TZ" won't
> > cut
> > > it for cases like the one above: the operator in Hamburg wants to see
> > dates
> > > from Austin and London, using their respective time zones. Instead, the
> > TZ
> > > of the incoming ZonedDateTime would have to be persisted so it's
> > available
> > > when reading it back.
> > >
> > >
> > >
> > >
> > > 2016-08-31 20:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> > >
> > >> We discussed this on HipChat, but for the benefit of all on this
> > >> discussion...
> > >>
> > >> Part of this (the original report) speaks to a difference in how we
> map
> > >> (org.hibernate.type.Type) java.time temporal versus a java.util
> > temporal -
> > >> specifically java.util.Calendar.  When we are passed a Calendar (the
> > model
> > >> defines its attribute as Calendar) we pass along that Calendar
> > reference to
> > >> the JDBC driver which forces the driver to use that Calendar's TZ.
> For
> > >> java.time temporal types, we always resolve them to UTC values mainly
> > >> because of how we get to the java.sql.Timestamp value from the
> java.time
> > >> value.  For example, for ZonedDateTime we call:
> > >>
> > >>     return (X) Timestamp.from( zonedDateTime.toInstant() );
> > >>
> > >> The call to #toInstant there essentially forces the value to UTC
> > because it
> > >> converted directly to epoch-based numeric.
> > >>
> > >> Thinking about this some more and "stepping back", the real problem is
> > that
> > >> there are a few different timezones in play here that need to be
> > balanced
> > >> and handled:
> > >>
> > >>    1. The database default TZ
> > >>    2. The stored TZ
> > >>    3. The JVM/JDBC TZ
> > >>    4. The application TZ
> > >>
> > >> The whole idea of "stored TZ" really depends on how the
> database/driver
> > >> treats TIMESTAMP and whether it supports a "TIMESTAMP_WITH_TIMEZONE"
> > >> type.  I
> > >> personally think it is a huge mistake to save the specific TZ
> > differences
> > >> to the DB, so I would personally continue to not support
> > >> TIMESTAMP_WITH_TIMEZONE
> > >> types.  This would mean we never have to bind the Calendar because we
> > could
> > >> simply convert the value to to the JVM/JDBC TZ ourselves.
> Specifically
> > I
> > >> would suggest that we (continue to) assume that the driver has been
> set
> > up
> > >> such that the same TZ is used when
> > >>
> > >>    1. when binding a Timestamp (without passing a Calendar)
> > >>    2. reading a Timestamp (without passing a Calendar).
> > >>
> > >> Specifically this would mean setting the JVM TZ, or for JDBC drivers
> > that
> > >> support it setting the "default TZ" on the driver.  If we start
> storing
> > >> values in the TZ specific to the Calendar we really have no idea how
> to
> > >> properly read those values back because we'd lose context to that TZ.
> > For
> > >> that reason I suggest we drop passing along the Calender and instead
> > >> perform all these conversions in memory and pass the converted
> > Timestamp to
> > >> JDBC.  When reading back, that should mean the driver would return us
> > >> Timestamps relative to that same TZ.
> > >>
> > >> The last piece is "application TZ" which would be an optional setting
> > >> indicating the TZ zone-based values should be returned in.
> > >>
> > >> E.g., let's say a user maps a ZonedDataTime using
> > @Temporal(TIMESTAMP).  If
> > >> following my suggestions, when saving these values we would:
> > >>
> > >>    1. convert the ZonedDateTime to a ZonedDateTime in the "JVM/JDBC
> TZ"
> > (if
> > >>    different from the incoming ZonedDateTime's TZ)
> > >>    2. use that to construct a Timestamp to bind to JDBC
> > >>
> > >> When reading back these values, we would:
> > >>
> > >>    1. get back the Timestamp from JDBC
> > >>    2. assume the value is relative to the "JVM/JDBC TZ" and build the
> > >>    ZonedDateTime via `ZonedDateTime.ofInstant( timestamp.toInstant(),
> > >>    jvmJdbcZoneId )`
> > >>    3. convert that built ZonedDateTime to the application TZ:
> > >>    `builtZonedDateTime.withZoneSameInstant( applicationZoneId )` - it
> > >> might
> > >>    be possible to combine this step with the previous, not sure...
> > >>
> > >>
> > >> Some if this is type-specific.  Assuming the suggestions above:
> > >>
> > >>    - Instant - inherently epoch-based.
> > >>       - to convert this to a Timestamp for binding we would use
> > >> `Timestamp#from(Instant).
> > >>       Because of the above assumptions, the driver would interpret
> > >> this relative
> > >>       to JVM/JDBC TZ
> > >>       - Reading back we simply use `Timestamp#toInstant()`
> > >>    - LocalDateTime - is the relative idea of a date+time outside the
> > >>    context of any specific TZ.
> > >>       - When binding we would resolve this into the JVM/JDBC TZ (using
> > >>       LocalDateTime#atZone(jvmJdbcZoneId), convert to an Instant and
> > >> create a
> > >>       Timestamp and bind that Timestamp to JDBC.
> > >>       - When reading back we'd get the Instant from Timestamp and use
> > that
> > >>       in `LocalDateTime#ofInstant` using the application TZ
> > >>    - LocalDate - relative idea of a date outside of any specific TZ.
> Of
> > >>    course this could also be mapped to a JDBC DATE which circumvents
> > some
> > >> of
> > >>    this, but mapped to a TIMESTAMP...
> > >>       - When binding we'd convert to a LocalDateTime using
> > >>       `LocalDate#atStartOfDay` and treat that LocalDateTime as above.
> > >>       - When reading back we would create a LocalDateTime using
> > >> `LocalDateTime.ofInstant(timestamp.toInstant(),
> > >>       applicationZoneId )`
> > >>    - LocalTime - relative idea of a time outside any specific TZ.
> Could
> > >>    also be mapped to a JDBC TIME...
> > >>       - When binding we'd create a LocalDateTime using
> > `LocalTime.atDate(
> > >>       LocalDate.of( 1970, 1, 1 ) )`, converting that to a
> ZonedDateTime
> > >> using
> > >>       `LocalDateTime#atZone( jvmJdbcZoneId )` and finally converting
> > that
> > >> to a
> > >>       Timestamp
> > >>       - When reading we would call `LocalDateTime.ofInstant(
> > >>       timestamp.toInstant(), applicationZoneId ).toLocalTime()`
> > >>    - ZonedDateTime - like a Calendar bundles a date+time with a TZ,
> and
> > so
> > >>    is directly convertible to an epoch-based value (Instant,
> Timestamp,
> > >> etc).
> > >>       - When binding we would convert this to an Instant and then to a
> > >>       Timestamp
> > >>       - When reading we would convert the Timestamp to an Instant and
> > then
> > >>       convert the Instant to a ZonedDateTime using
> > >> `ZonedDateTime.ofInstant(
> > >>       timestamp.toInstant(), applicationZoneId )`
> > >>    - OffsetDateTime - handled similar to ZonedDateTime.
> > >>       - When binding we would convert the value to a ZonedDateTime
> using
> > >>       `OffsetDateTime#atZoneSameInstant( jvmJdbcZoneId )` and then
> > follows
> > >>       ZonedDateTime
> > >>       - When reading we would use `OffsetDateTime.ofInstant(
> > >>       timestamp.toInstant(), applicationZoneId )`
> > >>    - OffsetTime - atm we just drop the ZoneOffset
> > >>    - for java.util.Date and java.sql.Timstamp mapping we have to
> decide
> > >>    what those concepts model in regards to their value relative to a
> TZ.
> > >> Are
> > >>    they a LocalDateTime relative to the system TimeZone?  Are they a
> > >>    LocalDateTime relative to UTC?  At the moment how we handled these
> > >> "legacy
> > >>    Java temporal types" ends up answering this question as them being
> "a
> > >>    LocalDateTime relative to the system TimeZone".
> > >>    - what about java.sql.Time?  Is this a LocalTime?  An OffsetTime
> > >>    relative to UTC (+0)?
> > >>    - and java.sql.Date?
> > >>
> > >> Lot of moving parts when you actually start looking deep at
> "supporting
> > >> timezones".
> > >>
> > >>
> > >> [1]
> > >> http://stackoverflow.com/questions/18447995/postgresql-
> > >> 9-2-jdbc-driver-uses-client-time-zone,
> > >> etc
> > >>
> > >> On Wed, Aug 31, 2016 at 9:10 AM Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > While reviewing the Pull Request for this issue:
> > >> > https://github.com/hibernate/hibernate-orm/pull/1536
> > >> >
> > >> > I realized that we can improve the default TimestampType as follows:
> > >> >
> > >> > 1. We could make it parameterizable so that it can also take a
> custom
> > >> > timezone (UTC) during mapping.
> > >> > 2. We could also define a default timezone so that we don't rely on
> > the
> > >> JVM
> > >> > one. This might be desirable when the UI requires to display the
> time
> > in
> > >> a
> > >> > certain timezone, while we want to save all timestamps in UTC.
> > >> >
> > >> > Let me know what you think.
> > >> >
> > >> > Vlad
> > >> > _______________________________________________
> > >> > hibernate-dev mailing list
> > >> > hibernate-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Sep  1 07:13:15 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 01 Sep 2016 11:13:15 +0000
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
In-Reply-To: <CAFdSV9uMeXvkkJVrGRc8x4UL74sy5tbmJgH74o4GUN1ebP3ogQ@mail.gmail.com>
References: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
	<CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>
	<CADGJaX_FCSYFqrsRFWUJPOKASPU87hwf-AphajAQ+zuHJWzOqg@mail.gmail.com>
	<CAFm4XO2HB8JAtwQU3NUPHLZwTfM-gsdHxjg=0o8b_gg2Bh=xkg@mail.gmail.com>
	<CADGJaX-c4NipcksKV6H8duA=Ucja4uuGJ5tO_wTa5KV+gwUUJQ@mail.gmail.com>
	<CAFdSV9uMeXvkkJVrGRc8x4UL74sy5tbmJgH74o4GUN1ebP3ogQ@mail.gmail.com>
Message-ID: <CAFdSV9uSLppV_NTYq_6Y_APd0gTDqfAGNQSHNB+zU0-bi8L_BQ@mail.gmail.com>

Hit send accidentally...

The "problem" is normalization.  You are storing a TZ that is specific to
the place  (Austin, London) a shipment event occurs on the shipment event.
So even if your app had the requirment to display the shipment event in the
local TZ that that event occurred in, data-normalization says you'd store
the TZ/offset on the place and use that to render the event.

But even then, I'd personally never do that.  I think rendering the
shipping event Instant in the TZ of place it happens is confusing and not
the norm anyway.  I think the norm, for apps that want to render this, is
more a TZ relative to the the user.  When I go to Amazon, or FedEx, etc to
track a package I could care less about the London TZ.  The whole idea of a
unified "period" would mean that I see them in my local TZ (if not UTC).

Also... this will *not* involve 2 columns.  We covered why in the last
email discussion we had about this a few months ago.  Now your app could do
all this...  map the @Temporal and then map the TZ and apply them in
memory.



On Thu, Sep 1, 2016 at 5:52 AM Steve Ebersole <steve at hibernate.org> wrote:

> I think your example is actually a perfect example of when to not store
> the TZ.
>
> On Thu, Sep 1, 2016, 5:16 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> > Saving in "timezoned" instants is prone to several bugs: you're then
>> > exposed to ambiguities as time doesn't flow linearly in all zones.
>>
>> I see it the other way around: the indirection you suggest is prone to
>> errors.
>>
>> Rules about TZ constantly change (e.g. when switching to/from DST),
>> locations change time zones more often than one would expect. Saving the
>> then valid TZ "next to" an UTC timestamp is much easier and more reliable
>> then trying to reconstruct that info from some historical TZ DB.
>>
>>
>> 2016-09-01 11:59 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> > To be fair I would have mapped that differently.
>> > Your Shipment arrives at a certain *point in time* (long, UTC based)
>> > in a certain Port (mapped with Foreign Key).
>> > A Port would have a reference to a local Timezone, and UI could decide
>> > to use that (or a different one) for rendering, based on other
>> > aspects, like the location of the user actually looking at the UI, or
>> > even a switchable user option.
>> >
>> > Saving in "timezoned" instants is prone to several bugs: you're then
>> > exposed to ambiguities as time doesn't flow linearly in all zones.
>> >
>> > Storing a timezoned instant only makes sense when you're quoting a
>> > political/legal source; i.e. you'ave passed under OCR some legal
>> > paperwork and you need to store the date printed on the header in a
>> > dedicated field, in Java8 time type you'd never use an Instant for
>> > this though, there are dedicated types which make the limitations of
>> > this representation clear. AFAIR some kinds of comparisons are made
>> > impossible.
>> >
>> > I'd not spend time with improvements on Calendar: the "old Date types"
>> > should be deprecated.
>> >
>> >
>> > On 1 September 2016 at 07:46, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> > >> it is a huge mistake to save the specific TZ differences to the DB
>> > >
>> > > I once was working on a globally deployed shipping management
>> application
>> > > where that was a requirement.
>> > >
>> > > Say there is a shipment from Austin (one TZ) to London (another TZ).
>> In
>> > > that application an operator based in Hamburg (yet another TZ) should
>> be
>> > > able to know when the shipment was brought in in Austin (the local
>> time
>> > in
>> > > Austin at that point) and when it was delivered in Hamburg (again the
>> > local
>> > > time there at that point).
>> > >
>> > > So we stored all dates in UTC, but also the TZ (in a *different
>> column*;
>> > I
>> > > don't quite remember whether it was just a string with the TZ
>> (offset) or
>> > > again the entire date-time using TIMESTAMP_WITH_TZ). Storing it in UTC
>> > > allowed for comparisons whereas the other column allowed to show each
>> > date
>> > > in its local TZ. So an operator in Hamburg (at CET) could see a
>> delivery
>> > > was brought in in Austin at 8:32 CST.
>> > >
>> > > Something like that would still be my preference for handling TZ-bound
>> > > types such as ZonedDateTime: store the UTC timestamp in one column and
>> > the
>> > > TZ info (either id or offset from UTC) in another.
>> > >
>> > > Relying on the JVM TZ or something like a single "application TZ"
>> won't
>> > cut
>> > > it for cases like the one above: the operator in Hamburg wants to see
>> > dates
>> > > from Austin and London, using their respective time zones. Instead,
>> the
>> > TZ
>> > > of the incoming ZonedDateTime would have to be persisted so it's
>> > available
>> > > when reading it back.
>> > >
>> > >
>> > >
>> > >
>> > > 2016-08-31 20:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> > >
>> > >> We discussed this on HipChat, but for the benefit of all on this
>> > >> discussion...
>> > >>
>> > >> Part of this (the original report) speaks to a difference in how we
>> map
>> > >> (org.hibernate.type.Type) java.time temporal versus a java.util
>> > temporal -
>> > >> specifically java.util.Calendar.  When we are passed a Calendar (the
>> > model
>> > >> defines its attribute as Calendar) we pass along that Calendar
>> > reference to
>> > >> the JDBC driver which forces the driver to use that Calendar's TZ.
>> For
>> > >> java.time temporal types, we always resolve them to UTC values mainly
>> > >> because of how we get to the java.sql.Timestamp value from the
>> java.time
>> > >> value.  For example, for ZonedDateTime we call:
>> > >>
>> > >>     return (X) Timestamp.from( zonedDateTime.toInstant() );
>> > >>
>> > >> The call to #toInstant there essentially forces the value to UTC
>> > because it
>> > >> converted directly to epoch-based numeric.
>> > >>
>> > >> Thinking about this some more and "stepping back", the real problem
>> is
>> > that
>> > >> there are a few different timezones in play here that need to be
>> > balanced
>> > >> and handled:
>> > >>
>> > >>    1. The database default TZ
>> > >>    2. The stored TZ
>> > >>    3. The JVM/JDBC TZ
>> > >>    4. The application TZ
>> > >>
>> > >> The whole idea of "stored TZ" really depends on how the
>> database/driver
>> > >> treats TIMESTAMP and whether it supports a "TIMESTAMP_WITH_TIMEZONE"
>> > >> type.  I
>> > >> personally think it is a huge mistake to save the specific TZ
>> > differences
>> > >> to the DB, so I would personally continue to not support
>> > >> TIMESTAMP_WITH_TIMEZONE
>> > >> types.  This would mean we never have to bind the Calendar because we
>> > could
>> > >> simply convert the value to to the JVM/JDBC TZ ourselves.
>> Specifically
>> > I
>> > >> would suggest that we (continue to) assume that the driver has been
>> set
>> > up
>> > >> such that the same TZ is used when
>> > >>
>> > >>    1. when binding a Timestamp (without passing a Calendar)
>> > >>    2. reading a Timestamp (without passing a Calendar).
>> > >>
>> > >> Specifically this would mean setting the JVM TZ, or for JDBC drivers
>> > that
>> > >> support it setting the "default TZ" on the driver.  If we start
>> storing
>> > >> values in the TZ specific to the Calendar we really have no idea how
>> to
>> > >> properly read those values back because we'd lose context to that TZ.
>> > For
>> > >> that reason I suggest we drop passing along the Calender and instead
>> > >> perform all these conversions in memory and pass the converted
>> > Timestamp to
>> > >> JDBC.  When reading back, that should mean the driver would return us
>> > >> Timestamps relative to that same TZ.
>> > >>
>> > >> The last piece is "application TZ" which would be an optional setting
>> > >> indicating the TZ zone-based values should be returned in.
>> > >>
>> > >> E.g., let's say a user maps a ZonedDataTime using
>> > @Temporal(TIMESTAMP).  If
>> > >> following my suggestions, when saving these values we would:
>> > >>
>> > >>    1. convert the ZonedDateTime to a ZonedDateTime in the "JVM/JDBC
>> TZ"
>> > (if
>> > >>    different from the incoming ZonedDateTime's TZ)
>> > >>    2. use that to construct a Timestamp to bind to JDBC
>> > >>
>> > >> When reading back these values, we would:
>> > >>
>> > >>    1. get back the Timestamp from JDBC
>> > >>    2. assume the value is relative to the "JVM/JDBC TZ" and build the
>> > >>    ZonedDateTime via `ZonedDateTime.ofInstant( timestamp.toInstant(),
>> > >>    jvmJdbcZoneId )`
>> > >>    3. convert that built ZonedDateTime to the application TZ:
>> > >>    `builtZonedDateTime.withZoneSameInstant( applicationZoneId )` - it
>> > >> might
>> > >>    be possible to combine this step with the previous, not sure...
>> > >>
>> > >>
>> > >> Some if this is type-specific.  Assuming the suggestions above:
>> > >>
>> > >>    - Instant - inherently epoch-based.
>> > >>       - to convert this to a Timestamp for binding we would use
>> > >> `Timestamp#from(Instant).
>> > >>       Because of the above assumptions, the driver would interpret
>> > >> this relative
>> > >>       to JVM/JDBC TZ
>> > >>       - Reading back we simply use `Timestamp#toInstant()`
>> > >>    - LocalDateTime - is the relative idea of a date+time outside the
>> > >>    context of any specific TZ.
>> > >>       - When binding we would resolve this into the JVM/JDBC TZ
>> (using
>> > >>       LocalDateTime#atZone(jvmJdbcZoneId), convert to an Instant and
>> > >> create a
>> > >>       Timestamp and bind that Timestamp to JDBC.
>> > >>       - When reading back we'd get the Instant from Timestamp and use
>> > that
>> > >>       in `LocalDateTime#ofInstant` using the application TZ
>> > >>    - LocalDate - relative idea of a date outside of any specific
>> TZ.  Of
>> > >>    course this could also be mapped to a JDBC DATE which circumvents
>> > some
>> > >> of
>> > >>    this, but mapped to a TIMESTAMP...
>> > >>       - When binding we'd convert to a LocalDateTime using
>> > >>       `LocalDate#atStartOfDay` and treat that LocalDateTime as above.
>> > >>       - When reading back we would create a LocalDateTime using
>> > >> `LocalDateTime.ofInstant(timestamp.toInstant(),
>> > >>       applicationZoneId )`
>> > >>    - LocalTime - relative idea of a time outside any specific TZ.
>> Could
>> > >>    also be mapped to a JDBC TIME...
>> > >>       - When binding we'd create a LocalDateTime using
>> > `LocalTime.atDate(
>> > >>       LocalDate.of( 1970, 1, 1 ) )`, converting that to a
>> ZonedDateTime
>> > >> using
>> > >>       `LocalDateTime#atZone( jvmJdbcZoneId )` and finally converting
>> > that
>> > >> to a
>> > >>       Timestamp
>> > >>       - When reading we would call `LocalDateTime.ofInstant(
>> > >>       timestamp.toInstant(), applicationZoneId ).toLocalTime()`
>> > >>    - ZonedDateTime - like a Calendar bundles a date+time with a TZ,
>> and
>> > so
>> > >>    is directly convertible to an epoch-based value (Instant,
>> Timestamp,
>> > >> etc).
>> > >>       - When binding we would convert this to an Instant and then to
>> a
>> > >>       Timestamp
>> > >>       - When reading we would convert the Timestamp to an Instant and
>> > then
>> > >>       convert the Instant to a ZonedDateTime using
>> > >> `ZonedDateTime.ofInstant(
>> > >>       timestamp.toInstant(), applicationZoneId )`
>> > >>    - OffsetDateTime - handled similar to ZonedDateTime.
>> > >>       - When binding we would convert the value to a ZonedDateTime
>> using
>> > >>       `OffsetDateTime#atZoneSameInstant( jvmJdbcZoneId )` and then
>> > follows
>> > >>       ZonedDateTime
>> > >>       - When reading we would use `OffsetDateTime.ofInstant(
>> > >>       timestamp.toInstant(), applicationZoneId )`
>> > >>    - OffsetTime - atm we just drop the ZoneOffset
>> > >>    - for java.util.Date and java.sql.Timstamp mapping we have to
>> decide
>> > >>    what those concepts model in regards to their value relative to a
>> TZ.
>> > >> Are
>> > >>    they a LocalDateTime relative to the system TimeZone?  Are they a
>> > >>    LocalDateTime relative to UTC?  At the moment how we handled these
>> > >> "legacy
>> > >>    Java temporal types" ends up answering this question as them
>> being "a
>> > >>    LocalDateTime relative to the system TimeZone".
>> > >>    - what about java.sql.Time?  Is this a LocalTime?  An OffsetTime
>> > >>    relative to UTC (+0)?
>> > >>    - and java.sql.Date?
>> > >>
>> > >> Lot of moving parts when you actually start looking deep at
>> "supporting
>> > >> timezones".
>> > >>
>> > >>
>> > >> [1]
>> > >> http://stackoverflow.com/questions/18447995/postgresql-
>> > >> 9-2-jdbc-driver-uses-client-time-zone,
>> > >> etc
>> > >>
>> > >> On Wed, Aug 31, 2016 at 9:10 AM Vlad Mihalcea <
>> mihalcea.vlad at gmail.com>
>> > >> wrote:
>> > >>
>> > >> > Hi,
>> > >> >
>> > >> > While reviewing the Pull Request for this issue:
>> > >> > https://github.com/hibernate/hibernate-orm/pull/1536
>> > >> >
>> > >> > I realized that we can improve the default TimestampType as
>> follows:
>> > >> >
>> > >> > 1. We could make it parameterizable so that it can also take a
>> custom
>> > >> > timezone (UTC) during mapping.
>> > >> > 2. We could also define a default timezone so that we don't rely on
>> > the
>> > >> JVM
>> > >> > one. This might be desirable when the UI requires to display the
>> time
>> > in
>> > >> a
>> > >> > certain timezone, while we want to save all timestamps in UTC.
>> > >> >
>> > >> > Let me know what you think.
>> > >> >
>> > >> > Vlad
>> > >> > _______________________________________________
>> > >> > hibernate-dev mailing list
>> > >> > hibernate-dev at lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >
>> > >> _______________________________________________
>> > >> hibernate-dev mailing list
>> > >> hibernate-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Thu Sep  1 08:02:12 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 01 Sep 2016 12:02:12 +0000
Subject: [hibernate-dev] Centralized access to "bootstrap only" resources
In-Reply-To: <CADGJaX89wBk6vuNeM=XBobvN-nvM8xqHOCraq3MCrnf6N3u7Bw@mail.gmail.com>
References: <CAFdSV9s8rdt7W97uWVcdeJZq5JetbRj1FX5=kYh5=gqX2PtwBg@mail.gmail.com>
	<20160830090913.GP90254@hibernate.org>
	<CAFm4XO3tBLerceVFZQ+Gzwa9xbdH2KMdv+0qLwDogUU3yBbnPg@mail.gmail.com>
	<CAFdSV9uOTunswVB7pGGnRAn=zadUOSZkiHAis_O7xD14TJNNqg@mail.gmail.com>
	<CAFdSV9u+wg3iWWLwxp7ePNT+n0CmbXpZC_PM56uxSAXpkOgypg@mail.gmail.com>
	<CAL00eSTPNaiV2_afdY5+gqKqfs-k2PbBimANWxiwP3VjG4+rgA@mail.gmail.com>
	<CAFdSV9sgbP=ueka06a2=JBedvvE3RGf9ZO8BNRfbCSsPU30+hg@mail.gmail.com>
	<CADGJaX89wBk6vuNeM=XBobvN-nvM8xqHOCraq3MCrnf6N3u7Bw@mail.gmail.com>
Message-ID: <CAFdSV9sgvp8jScPpkJ_C1K-_OfAmd3Z_XNW-Q+TUibesXLDPmQ@mail.gmail.com>

In order to validate that unifying the event listener impls between
"native" and "jpa" is actually workable I applied that idea on top of 5.2.
And it works.  ANd since I did the work, I created a PR from it for us to:

   1. review that specific set of changes (slightly different accounting
   for ongoing 6.0 work)
   2. consider incorporating it into 5.2

https://github.com/hibernate/hibernate-orm/pull/1541


On Thu, Sep 1, 2016 at 1:11 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> > Do we want to change JpaIntegrator#integrate signature to pass its
> context
> > as a parameter object
>
> If you think that's the better approach, I'd say 6 is the right time to do
> it. Users (or integrators) will be prepared for this sort of breakage in a
> major.
>
> > do other projects supply custom
> > org.hibernate.service.spi.SessionFactoryServiceInitiator impls
>
> Yes, OGM does. Though I'm not too concerned about such change, it should
> be easy for us to adjust and at this point we don't aim
> for compatibility with several ORM (major) versions.
>
> 2016-09-01 4:09 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> One contract I would need to adjust for this
>> is
>> org.hibernate.service.spi.SessionFactoryServiceInitiator#initiateService.
>> I can find all the implementations of that in ORM, but do other projects
>> supply custom org.hibernate.service.spi.SessionFactoryServiceInitiator
>> impls?
>>
>>
>> On Wed, Aug 31, 2016 at 5:18 AM andrea boriero <andrea at hibernate.org>
>> wrote:
>>
>> > I'm fine with combining native and JPA events handling, about the second
>> > point, ideally I would change the signature but due to the problems you
>> > listed I vote for the in-line solution.
>> >
>> > On 30 August 2016 at 19:20, Steve Ebersole <steve at hibernate.org> wrote:
>> >
>> >> Any thoughts on the JpaIntegrator parts of the discussion?
>>  Specifically
>> >> there are 2 main considerations:
>> >>
>> >>    1. To change the Integrator#integrate contract - ideally, in
>> >> retrospect,
>> >
>> >
>> >>    #integrate probably should have taken a "parameter object" to help
>> >> insulate
>> >>    from these types of changes.  But I wanted to get y'alls thoughts on
>> >> this
>> >>    especially since this one potentially causes upgrade problems in
>> terms
>> >> of
>> >>    applications or problems supporting multiple ORM versions in terms
>> >>    of integrations.
>> >>
>> >    2. The alternative I mentioned was to move the
>> JpaIntegrator#integrate
>> >
>> >
>> >>    functionality in-line with the building of the SessionFactory.  This
>> >> has
>> >>    some really nice benefits as discussed (like JPA callback support
>> from
>> >>    native bootstrapping), but it has some challenges to handle as well
>> >> mainly
>> >>    in terms of seamlessly combining the different Hibernate event
>> >> listeners
>> >>    used to implement the native versus JPA behavior.  The simple JPA
>> >>    callback/listener case is pretty easy to support regardless.  The
>> more
>> >>    difficult ones are event listeners that implement event handling
>> >>    differently () or the ones that cascade different actions depending
>> on
>> >>    native/jpa bootstrapping ().  I think even the latter bucket may be
>> >> easy to
>> >>    handle leveraging SessionFactoryOptions#isJpaBootstrap inside the
>> >>    listeners.  The former bucket is really the one I am more concerned
>> >> with.
>> >>    So let's look at this as 2 distinct questions:
>> >>
>> >       1. Do we want to combine event listeners for native and JPA
>> handling
>> >>       of events?
>> >>       2. Do we want to change JpaIntegrator#integrate signature to pass
>> >> its
>> >
>> >
>> >>       context as a parameter object in order to facilitate this?  Or
>> do we
>> >>       in-line the decisions/actions done in JpaIntegrator into
>> >> SessionFactory
>> >>       init?
>> >>
>> >
>> >>
>> >> On Tue, Aug 30, 2016 at 8:50 AM Steve Ebersole <steve at hibernate.org>
>> >> wrote:
>> >>
>> >> > On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero <sanne at hibernate.org
>> >
>> >> > wrote:
>> >> >
>> >> >> On 30 August 2016 at 10:09, Emmanuel Bernard <
>> emmanuel at hibernate.org>
>> >> >> wrote:
>> >> >> > I am not sure if that is still relevant but in the past, either
>> >> HSEARCH
>> >> >> > or HV were keeping the ReflectionManager around to use it at
>> runtime
>> >> >> > (either because metadata was loaded lazily or because of a reboot
>> of
>> >> the
>> >> >> > factories due to a configuration change.
>> >> >> >
>> >> >> > So we need to check that losing access to ReflectionManager after
>> SF
>> >> is
>> >> >> > created won't be problematic for these projects.
>> >> >>
>> >> >> In the "dynamic reconfiguration" case we create our own
>> >> >> ReflectionManager instance:
>> >> >>  -
>> >> >>
>> >>
>> https://github.com/hibernate/hibernate-search/blob/fd4acb5d8f396201f5dccc89ba3cbc07becea08a/engine/src/main/java/org/hibernate/search/engine/impl/IncrementalSearchConfiguration.java#L26-L35
>> >> >
>> >> >
>> >> > Interesting that y'all do not specify classloading behavior there
>> (the
>> >> > ClassLoaderDelegate stuff I added to HCANN)...
>> >> >
>> >> >
>> >> >
>> >> >> Steve, we had a similar notion of "boot only available components"
>> in
>> >> >> Search but over time we started to have various "special needs" of
>> >> >> various other components holding a reference on these.
>> >> >> When I later tried to re-instate order, it was too late and we got
>> in
>> >> >> arguments like the API's intent not having been clear enough and too
>> >> >> much entanglement had happened.
>> >> >>
>> >> >
>> >> > Hard to say without specifics. I hate "general rules" :)
>> >> >
>> >> > So let's look at the specifics in terms of things I have moved to
>> >> > BootstrapContext...
>> >> >
>> >> >
>> >>
>> > >    1. HCANN ReflectionManager - as you said, y'all create your own for
>> >>
>> >
>> >> >    your use case.  You'd own the lifecycle of that one you create.  I
>> >> see no
>> >> >    conflict there.   Also we know that in 7.0 HCANN use will go away
>> >> and we
>> >> >    will move to Jandex.  The Jandex IndexView reference is only valid
>> >> for a
>> >> >    limited period of time when WF hands it to us.
>> >>
>> > >    2.  JPA "temp ClassLoader" - I think this one is self-evident.  JPA
>> >>
>> >
>> >> >    states that this ClassLoader (if one) is available for only a
>> >> limited time.
>> >>
>> > >    3. ClassmateContext - I centralized this so that we did not have to
>> >>
>> >
>> >> >    keep "priming" the classmate caches each time we needed to use
>> >> classmate.
>> >> >    Aside from a possible performance hit, there really is nothing
>> >> special here
>> >> >    versus creating a new ClassmateContext each time you need it.  For
>> >> ORM we
>> >> >    currently never use classmate outside of bootstrap.  Could that
>> >> change?
>> >> >    Maybe, and we'd deal with that if/when it does.
>> >>
>> > >    4. scanning components
>> >>
>> >
>> >> >    (ArchiveDescriptorFactory, ScanOptions, ScanEnvironment, Scanner)
>> -
>> >> maybe
>> >> >    going back to your "dynamic reconfiguration" scenario this makes
>> >> sense.  No
>> >> >    idea.  But in ORM holding on to these after bootstrap makes no
>> sense.
>> >>
>> > >    5. I've also started making BootstrapContext the holder for
>> bootstrap
>> >>
>> >
>> >> >    metadata-related collectors.  Here we collect
>> >> >    SQLFunctions, AuxiliaryDatabaseObjects,
>> >> AttributeConverterDefinitions,
>> >> >    and CacheRegionDefinitions.
>> >>
>> > >    6. There are 2 other (new in 6.0) delegates that I keep here too.
>> >>
>> >
>> >> >    Interestingly, one is fully intended to be held beyond bootstrap.
>> >> But I
>> >> >    think that these intentions just need to be documented.
>> >> >
>> >> >
>> >> > Overall I'd view a "dynamic reconfiguration" scenario very much like
>> a
>> >> > limite bootstrap scenario.  Personally I'd expect to have to maker
>> many
>> >> of
>> >> > these "boot only resources" available to that process.  Not
>> necessarily
>> >> the
>> >> > same ones as used during the primary bootstrap though.  I personally
>> >> would
>> >> > prefer to not hold reference to these "just in case" we have a
>> "dynamic
>> >> > reconfiguration" situation later; I'd just rebuild them.  Granted
>> things
>> >> > like a WF-handed Jandex IndexView would be difficult to handle in
>> there,
>> >> > but that is the case regardless of whether we hold reference to it or
>> >> not;
>> >> > that has to do with WF eventually invalidating that reference it
>> handed
>> >> us.
>> >> >
>> >> >
>> >> > So while I think it's a good idea, and also Search should try this
>> >> >> again, I think we'd need to design it from day 1 to be defensive
>> >> >> against future code attempting to hold on these services.
>> >> >> Not sure what would be the best approach for ORM, but I guess that
>> >> >> simply invalidating/closing these components after bootstrap and
>> >> >> having these throw an exception after that would be a good start.
>> >> >>
>> >> >
>> >> > That is roughly what I do.  There is a BootstrapContext#release
>> method.
>> >> > It in turn releases the delegates it holds.  I can add some defensive
>> >> > checking for throwing some "unavailable" exceptions in case stuff
>> holds
>> >> > references to these.  That's a good idea.
>> >> >
>> >> >
>> >> > However, please allow some flexibility for the case in which someone
>> >> >> really needs one of the services you're dooming at runtime.
>> >> >> For example Search might need to re-read configuration properties at
>> >> >> runtime; we can of course make a copy, but then we'd need a way to
>> be
>> >> >> able to make such a copy (We currently actually make such a copy of
>> >> >> the cfg Properties).
>> >> >> Configuration properties being just an example, maybe we need a
>> >> >> generic way to be able to declare which services should not be
>> cleaned
>> >> >> up after bootstrap?
>> >> >>
>> >> >
>> >> > We already hold on to configuration properties into the SF.  See
>> >> > ConfigurationService.
>> >> >
>> >> >
>> >> >
>> >> >> In practice, the services you've listed should be fine today but the
>> >> >> need for us to make a copy (or to invoke some API to ask for a life
>> >> >> extension) might show up in future.
>> >> >>
>> >> >> Rough proposal :
>> >> >>
>> >> >> interface BootService {
>> >> >>   void flagForUsageBeyondBootstrap();
>> >> >> }
>> >> >>
>> >> >
>> >> > -1 I think the BootstrapContext is not the right place for this.  It
>> is
>> >> > not the BootstrapContext itself that needs to remain valid, it is the
>> >> > delegates it exposes.  That is where the "extension" should be
>> >> allowed.  If
>> >> > that is voted as generally worthwhile, I can see 2 options:
>> >> >
>> >>
>> > >    1. Expose #allowExtendedAccess (or somesuch method name) to the
>> actual
>> >>
>> >
>> >> >    delegates.  This would be an indicator to not release its
>> resources
>> >> when
>> >> >    the BootstrapContext#release method tells the delegate to release
>> >> itself.
>> >>
>> > >    2. Allow OGM, Search, etc to specify specific impls for these
>> >>
>> >
>> >> >    delegates.  It could handle the delegate's #release method
>> however it
>> >> >    wanted.
>> >> >
>> >> > However, realize that if these things are not released by
>> >> > BootstrapContext#release then ORM washes its hands of cleaning them
>> up
>> >> (it
>> >> > would have no "scope" to do that).
>> >> >
>> >>
>> > _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Thu Sep  1 08:25:30 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 1 Sep 2016 14:25:30 +0200
Subject: [hibernate-dev] Supporting timezone in Timestamp Type
In-Reply-To: <CAFdSV9uSLppV_NTYq_6Y_APd0gTDqfAGNQSHNB+zU0-bi8L_BQ@mail.gmail.com>
References: <CA+gWKMC+7XnuYD3motfb2zTuCfozi5x1PhOmv25q-GEUe68QWA@mail.gmail.com>
	<CAFdSV9vBoFkaiHsQyvvZ6aMyStgELbzjWb_XC2ZkM35Hv5HNBA@mail.gmail.com>
	<CADGJaX_FCSYFqrsRFWUJPOKASPU87hwf-AphajAQ+zuHJWzOqg@mail.gmail.com>
	<CAFm4XO2HB8JAtwQU3NUPHLZwTfM-gsdHxjg=0o8b_gg2Bh=xkg@mail.gmail.com>
	<CADGJaX-c4NipcksKV6H8duA=Ucja4uuGJ5tO_wTa5KV+gwUUJQ@mail.gmail.com>
	<CAFdSV9uMeXvkkJVrGRc8x4UL74sy5tbmJgH74o4GUN1ebP3ogQ@mail.gmail.com>
	<CAFdSV9uSLppV_NTYq_6Y_APd0gTDqfAGNQSHNB+zU0-bi8L_BQ@mail.gmail.com>
Message-ID: <CADGJaX8TYXVO90jbYspy+hMhnoC4xvz4AoAkF+dYiX18_yfsNw@mail.gmail.com>

Am 01.09.2016 1:13 nachm. schrieb "Steve Ebersole" <steve at hibernate.org>:
>
> Hit send accidentally...
>
> The "problem" is normalization.  You are storing a TZ that is specific to
the place  (Austin, London) a shipment event occurs on the shipment event.
So even if your app had the requirment to display the shipment event in the
local TZ that that event occurred in, data-normalization says you'd store
the TZ/offset on the place and use that to render the event.

Yes, I think that is what Sanne has been proposing, too. You only need to
do that in a historized fashion as TZs may change over time. Personally, I
don't see big advantages of normalization here.

>
> But even then, I'd personally never do that.  I think rendering the
shipping event Instant in the TZ of place it happens is confusing and not
the norm anyway.  I think the norm, for apps that want to render this, is
more a TZ relative to the the user.  When I go to Amazon, or FedEx, etc to
track a package I could care less about the London TZ.  The whole idea of a
unified "period" would mean that I see them in my local TZ (if not UTC).

Sure, different use cases, different requirements.

>
> Also... this will *not* involve 2 columns.  We covered why in the last
email discussion we had about this a few months ago.  Now your app could do
all this...  map the @Temporal and then map the TZ and apply them in
memory.

Hum, ok. I remember a discussion on querying but would have assumed that to
be addressed by having the UTC column and converting query params into UTC
as well.

My thinking is that people use date-time types with TZ info for a reason
after all, so there should be a way (an option at least) to retain this
IMHO. But yes, people could do it themselves...

>
>
>
> On Thu, Sep 1, 2016 at 5:52 AM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> I think your example is actually a perfect example of when to not store
the TZ.
>>
>>
>> On Thu, Sep 1, 2016, 5:16 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>>
>>> > Saving in "timezoned" instants is prone to several bugs: you're then
>>> > exposed to ambiguities as time doesn't flow linearly in all zones.
>>>
>>> I see it the other way around: the indirection you suggest is prone to
>>> errors.
>>>
>>> Rules about TZ constantly change (e.g. when switching to/from DST),
>>> locations change time zones more often than one would expect. Saving the
>>> then valid TZ "next to" an UTC timestamp is much easier and more
reliable
>>> then trying to reconstruct that info from some historical TZ DB.
>>>
>>>
>>> 2016-09-01 11:59 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>>
>>> > To be fair I would have mapped that differently.
>>> > Your Shipment arrives at a certain *point in time* (long, UTC based)
>>> > in a certain Port (mapped with Foreign Key).
>>> > A Port would have a reference to a local Timezone, and UI could decide
>>> > to use that (or a different one) for rendering, based on other
>>> > aspects, like the location of the user actually looking at the UI, or
>>> > even a switchable user option.
>>> >
>>> > Saving in "timezoned" instants is prone to several bugs: you're then
>>> > exposed to ambiguities as time doesn't flow linearly in all zones.
>>> >
>>> > Storing a timezoned instant only makes sense when you're quoting a
>>> > political/legal source; i.e. you'ave passed under OCR some legal
>>> > paperwork and you need to store the date printed on the header in a
>>> > dedicated field, in Java8 time type you'd never use an Instant for
>>> > this though, there are dedicated types which make the limitations of
>>> > this representation clear. AFAIR some kinds of comparisons are made
>>> > impossible.
>>> >
>>> > I'd not spend time with improvements on Calendar: the "old Date types"
>>> > should be deprecated.
>>> >
>>> >
>>> > On 1 September 2016 at 07:46, Gunnar Morling <gunnar at hibernate.org>
wrote:
>>> > >> it is a huge mistake to save the specific TZ differences to the DB
>>> > >
>>> > > I once was working on a globally deployed shipping management
application
>>> > > where that was a requirement.
>>> > >
>>> > > Say there is a shipment from Austin (one TZ) to London (another
TZ). In
>>> > > that application an operator based in Hamburg (yet another TZ)
should be
>>> > > able to know when the shipment was brought in in Austin (the local
time
>>> > in
>>> > > Austin at that point) and when it was delivered in Hamburg (again
the
>>> > local
>>> > > time there at that point).
>>> > >
>>> > > So we stored all dates in UTC, but also the TZ (in a *different
column*;
>>> > I
>>> > > don't quite remember whether it was just a string with the TZ
(offset) or
>>> > > again the entire date-time using TIMESTAMP_WITH_TZ). Storing it in
UTC
>>> > > allowed for comparisons whereas the other column allowed to show
each
>>> > date
>>> > > in its local TZ. So an operator in Hamburg (at CET) could see a
delivery
>>> > > was brought in in Austin at 8:32 CST.
>>> > >
>>> > > Something like that would still be my preference for handling
TZ-bound
>>> > > types such as ZonedDateTime: store the UTC timestamp in one column
and
>>> > the
>>> > > TZ info (either id or offset from UTC) in another.
>>> > >
>>> > > Relying on the JVM TZ or something like a single "application TZ"
won't
>>> > cut
>>> > > it for cases like the one above: the operator in Hamburg wants to
see
>>> > dates
>>> > > from Austin and London, using their respective time zones. Instead,
the
>>> > TZ
>>> > > of the incoming ZonedDateTime would have to be persisted so it's
>>> > available
>>> > > when reading it back.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > 2016-08-31 20:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>> > >
>>> > >> We discussed this on HipChat, but for the benefit of all on this
>>> > >> discussion...
>>> > >>
>>> > >> Part of this (the original report) speaks to a difference in how
we map
>>> > >> (org.hibernate.type.Type) java.time temporal versus a java.util
>>> > temporal -
>>> > >> specifically java.util.Calendar.  When we are passed a Calendar
(the
>>> > model
>>> > >> defines its attribute as Calendar) we pass along that Calendar
>>> > reference to
>>> > >> the JDBC driver which forces the driver to use that Calendar's
TZ.  For
>>> > >> java.time temporal types, we always resolve them to UTC values
mainly
>>> > >> because of how we get to the java.sql.Timestamp value from the
java.time
>>> > >> value.  For example, for ZonedDateTime we call:
>>> > >>
>>> > >>     return (X) Timestamp.from( zonedDateTime.toInstant() );
>>> > >>
>>> > >> The call to #toInstant there essentially forces the value to UTC
>>> > because it
>>> > >> converted directly to epoch-based numeric.
>>> > >>
>>> > >> Thinking about this some more and "stepping back", the real
problem is
>>> > that
>>> > >> there are a few different timezones in play here that need to be
>>> > balanced
>>> > >> and handled:
>>> > >>
>>> > >>    1. The database default TZ
>>> > >>    2. The stored TZ
>>> > >>    3. The JVM/JDBC TZ
>>> > >>    4. The application TZ
>>> > >>
>>> > >> The whole idea of "stored TZ" really depends on how the
database/driver
>>> > >> treats TIMESTAMP and whether it supports a
"TIMESTAMP_WITH_TIMEZONE"
>>> > >> type.  I
>>> > >> personally think it is a huge mistake to save the specific TZ
>>> > differences
>>> > >> to the DB, so I would personally continue to not support
>>> > >> TIMESTAMP_WITH_TIMEZONE
>>> > >> types.  This would mean we never have to bind the Calendar because
we
>>> > could
>>> > >> simply convert the value to to the JVM/JDBC TZ ourselves.
Specifically
>>> > I
>>> > >> would suggest that we (continue to) assume that the driver has
been set
>>> > up
>>> > >> such that the same TZ is used when
>>> > >>
>>> > >>    1. when binding a Timestamp (without passing a Calendar)
>>> > >>    2. reading a Timestamp (without passing a Calendar).
>>> > >>
>>> > >> Specifically this would mean setting the JVM TZ, or for JDBC
drivers
>>> > that
>>> > >> support it setting the "default TZ" on the driver.  If we start
storing
>>> > >> values in the TZ specific to the Calendar we really have no idea
how to
>>> > >> properly read those values back because we'd lose context to that
TZ.
>>> > For
>>> > >> that reason I suggest we drop passing along the Calender and
instead
>>> > >> perform all these conversions in memory and pass the converted
>>> > Timestamp to
>>> > >> JDBC.  When reading back, that should mean the driver would return
us
>>> > >> Timestamps relative to that same TZ.
>>> > >>
>>> > >> The last piece is "application TZ" which would be an optional
setting
>>> > >> indicating the TZ zone-based values should be returned in.
>>> > >>
>>> > >> E.g., let's say a user maps a ZonedDataTime using
>>> > @Temporal(TIMESTAMP).  If
>>> > >> following my suggestions, when saving these values we would:
>>> > >>
>>> > >>    1. convert the ZonedDateTime to a ZonedDateTime in the
"JVM/JDBC TZ"
>>> > (if
>>> > >>    different from the incoming ZonedDateTime's TZ)
>>> > >>    2. use that to construct a Timestamp to bind to JDBC
>>> > >>
>>> > >> When reading back these values, we would:
>>> > >>
>>> > >>    1. get back the Timestamp from JDBC
>>> > >>    2. assume the value is relative to the "JVM/JDBC TZ" and build
the
>>> > >>    ZonedDateTime via `ZonedDateTime.ofInstant(
timestamp.toInstant(),
>>> > >>    jvmJdbcZoneId )`
>>> > >>    3. convert that built ZonedDateTime to the application TZ:
>>> > >>    `builtZonedDateTime.withZoneSameInstant( applicationZoneId )` -
it
>>> > >> might
>>> > >>    be possible to combine this step with the previous, not sure...
>>> > >>
>>> > >>
>>> > >> Some if this is type-specific.  Assuming the suggestions above:
>>> > >>
>>> > >>    - Instant - inherently epoch-based.
>>> > >>       - to convert this to a Timestamp for binding we would use
>>> > >> `Timestamp#from(Instant).
>>> > >>       Because of the above assumptions, the driver would interpret
>>> > >> this relative
>>> > >>       to JVM/JDBC TZ
>>> > >>       - Reading back we simply use `Timestamp#toInstant()`
>>> > >>    - LocalDateTime - is the relative idea of a date+time outside
the
>>> > >>    context of any specific TZ.
>>> > >>       - When binding we would resolve this into the JVM/JDBC TZ
(using
>>> > >>       LocalDateTime#atZone(jvmJdbcZoneId), convert to an Instant
and
>>> > >> create a
>>> > >>       Timestamp and bind that Timestamp to JDBC.
>>> > >>       - When reading back we'd get the Instant from Timestamp and
use
>>> > that
>>> > >>       in `LocalDateTime#ofInstant` using the application TZ
>>> > >>    - LocalDate - relative idea of a date outside of any specific
TZ.  Of
>>> > >>    course this could also be mapped to a JDBC DATE which
circumvents
>>> > some
>>> > >> of
>>> > >>    this, but mapped to a TIMESTAMP...
>>> > >>       - When binding we'd convert to a LocalDateTime using
>>> > >>       `LocalDate#atStartOfDay` and treat that LocalDateTime as
above.
>>> > >>       - When reading back we would create a LocalDateTime using
>>> > >> `LocalDateTime.ofInstant(timestamp.toInstant(),
>>> > >>       applicationZoneId )`
>>> > >>    - LocalTime - relative idea of a time outside any specific TZ.
Could
>>> > >>    also be mapped to a JDBC TIME...
>>> > >>       - When binding we'd create a LocalDateTime using
>>> > `LocalTime.atDate(
>>> > >>       LocalDate.of( 1970, 1, 1 ) )`, converting that to a
ZonedDateTime
>>> > >> using
>>> > >>       `LocalDateTime#atZone( jvmJdbcZoneId )` and finally
converting
>>> > that
>>> > >> to a
>>> > >>       Timestamp
>>> > >>       - When reading we would call `LocalDateTime.ofInstant(
>>> > >>       timestamp.toInstant(), applicationZoneId ).toLocalTime()`
>>> > >>    - ZonedDateTime - like a Calendar bundles a date+time with a
TZ, and
>>> > so
>>> > >>    is directly convertible to an epoch-based value (Instant,
Timestamp,
>>> > >> etc).
>>> > >>       - When binding we would convert this to an Instant and then
to a
>>> > >>       Timestamp
>>> > >>       - When reading we would convert the Timestamp to an Instant
and
>>> > then
>>> > >>       convert the Instant to a ZonedDateTime using
>>> > >> `ZonedDateTime.ofInstant(
>>> > >>       timestamp.toInstant(), applicationZoneId )`
>>> > >>    - OffsetDateTime - handled similar to ZonedDateTime.
>>> > >>       - When binding we would convert the value to a ZonedDateTime
using
>>> > >>       `OffsetDateTime#atZoneSameInstant( jvmJdbcZoneId )` and then
>>> > follows
>>> > >>       ZonedDateTime
>>> > >>       - When reading we would use `OffsetDateTime.ofInstant(
>>> > >>       timestamp.toInstant(), applicationZoneId )`
>>> > >>    - OffsetTime - atm we just drop the ZoneOffset
>>> > >>    - for java.util.Date and java.sql.Timstamp mapping we have to
decide
>>> > >>    what those concepts model in regards to their value relative to
a TZ.
>>> > >> Are
>>> > >>    they a LocalDateTime relative to the system TimeZone?  Are they
a
>>> > >>    LocalDateTime relative to UTC?  At the moment how we handled
these
>>> > >> "legacy
>>> > >>    Java temporal types" ends up answering this question as them
being "a
>>> > >>    LocalDateTime relative to the system TimeZone".
>>> > >>    - what about java.sql.Time?  Is this a LocalTime?  An OffsetTime
>>> > >>    relative to UTC (+0)?
>>> > >>    - and java.sql.Date?
>>> > >>
>>> > >> Lot of moving parts when you actually start looking deep at
"supporting
>>> > >> timezones".
>>> > >>
>>> > >>
>>> > >> [1]
>>> > >> http://stackoverflow.com/questions/18447995/postgresql-
>>> > >> 9-2-jdbc-driver-uses-client-time-zone,
>>> > >> etc
>>> > >>
>>> > >> On Wed, Aug 31, 2016 at 9:10 AM Vlad Mihalcea <
mihalcea.vlad at gmail.com>
>>> > >> wrote:
>>> > >>
>>> > >> > Hi,
>>> > >> >
>>> > >> > While reviewing the Pull Request for this issue:
>>> > >> > https://github.com/hibernate/hibernate-orm/pull/1536
>>> > >> >
>>> > >> > I realized that we can improve the default TimestampType as
follows:
>>> > >> >
>>> > >> > 1. We could make it parameterizable so that it can also take a
custom
>>> > >> > timezone (UTC) during mapping.
>>> > >> > 2. We could also define a default timezone so that we don't rely
on
>>> > the
>>> > >> JVM
>>> > >> > one. This might be desirable when the UI requires to display the
time
>>> > in
>>> > >> a
>>> > >> > certain timezone, while we want to save all timestamps in UTC.
>>> > >> >
>>> > >> > Let me know what you think.
>>> > >> >
>>> > >> > Vlad
>>> > >> > _______________________________________________
>>> > >> > hibernate-dev mailing list
>>> > >> > hibernate-dev at lists.jboss.org
>>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >> >
>>> > >> _______________________________________________
>>> > >> hibernate-dev mailing list
>>> > >> hibernate-dev at lists.jboss.org
>>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >>
>>> > > _______________________________________________
>>> > > hibernate-dev mailing list
>>> > > hibernate-dev at lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From crancran at gmail.com  Thu Sep  1 09:55:35 2016
From: crancran at gmail.com (Chris Cranford)
Date: Thu, 1 Sep 2016 09:55:35 -0400
Subject: [hibernate-dev] Hibernate Envers > link between to auditable
 entities
In-Reply-To: <CAKYNcuNZvYoi8=id4KhboDC=TKOqqkgmC6zpe3QMcNRi3J=jPw@mail.gmail.com>
References: <CAKYNcuNZvYoi8=id4KhboDC=TKOqqkgmC6zpe3QMcNRi3J=jPw@mail.gmail.com>
Message-ID: <46d84bdd-830f-fff8-7a69-ccbe1107185d@gmail.com>

Tarek -

There are a few ways we can tackle what you want all within the scope of 
Envers,
but some of it highly depends upon details specific to the relationship 
between
Product (P) and Offer (O).

1. What is the collection type used in Product for the related offers?
    If this happens to be a List<>, would it be possible to use a Set<> 
instead?

2. Is there a requirement that Offer should own the relationship with 
Product?
    In other words, is it possible to invert the relationship such that the
    collection side is the owner instead?

Chris

On 09/01/2016 06:14 AM, Dev Stack wrote:
> Hello,
>
> we have in our model entity P (product) and entity O (offer). The two
> entities have a link.
> one instance of P can have one or many O instances.
> an instance O has a reference to only one instance of P.
> The link is managed in the O side.
>
> P and O are revisioned by Hibernate Envers.
>
> Two use cases to cover:
> 1) If P instance is updated (new revision) we want that O keep the link
> with the old revision of P.
> 2) When I update O instance, I will move the reference to the last revision
> of O instance.
>
> What we did is, inside O class we added to attributes P.id and P.revision.
> So when we load the object P we use these to fields to load manually (O DAO
> has reference P DAO).
>
> Is there a better way to do it?
> Should we keep the reference of P in O instance as auditable and Envers
> will manage?
>
> Thanks,
> Tarek
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From devstack74 at gmail.com  Thu Sep  1 10:11:56 2016
From: devstack74 at gmail.com (Dev Stack)
Date: Thu, 1 Sep 2016 16:11:56 +0200
Subject: [hibernate-dev] Hibernate Envers > link between to auditable
	entities
In-Reply-To: <46d84bdd-830f-fff8-7a69-ccbe1107185d@gmail.com>
References: <CAKYNcuNZvYoi8=id4KhboDC=TKOqqkgmC6zpe3QMcNRi3J=jPw@mail.gmail.com>
	<46d84bdd-830f-fff8-7a69-ccbe1107185d@gmail.com>
Message-ID: <CAKYNcuPT6ZS0pye-T1xU+8ZfQYx1qgXP_GhXnKMpRForx5-CRw@mail.gmail.com>

Hi Chris,

Thank you for your answer.

1) yes, we can use Set<>
2) When we load an offer we have to load also the associated product.
So, we have to keep the link from offer to product.
the link from product to offer is not needed for now.

Thanks,
Tarek

2016-09-01 15:55 GMT+02:00 Chris Cranford <crancran at gmail.com>:

> Tarek -
>
> There are a few ways we can tackle what you want all within the scope of
> Envers,
> but some of it highly depends upon details specific to the relationship
> between
> Product (P) and Offer (O).
>
> 1. What is the collection type used in Product for the related offers?
>    If this happens to be a List<>, would it be possible to use a Set<>
> instead?
>
> 2. Is there a requirement that Offer should own the relationship with
> Product?
>    In other words, is it possible to invert the relationship such that the
>    collection side is the owner instead?
>
> Chris
>
>
> On 09/01/2016 06:14 AM, Dev Stack wrote:
>
>> Hello,
>>
>> we have in our model entity P (product) and entity O (offer). The two
>> entities have a link.
>> one instance of P can have one or many O instances.
>> an instance O has a reference to only one instance of P.
>> The link is managed in the O side.
>>
>> P and O are revisioned by Hibernate Envers.
>>
>> Two use cases to cover:
>> 1) If P instance is updated (new revision) we want that O keep the link
>> with the old revision of P.
>> 2) When I update O instance, I will move the reference to the last
>> revision
>> of O instance.
>>
>> What we did is, inside O class we added to attributes P.id and P.revision.
>> So when we load the object P we use these to fields to load manually (O
>> DAO
>> has reference P DAO).
>>
>> Is there a better way to do it?
>> Should we keep the reference of P in O instance as auditable and Envers
>> will manage?
>>
>> Thanks,
>> Tarek
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From crancran at gmail.com  Thu Sep  1 11:51:46 2016
From: crancran at gmail.com (Chris Cranford)
Date: Thu, 1 Sep 2016 11:51:46 -0400
Subject: [hibernate-dev] Hibernate Envers > link between to auditable
 entities
In-Reply-To: <CAKYNcuPT6ZS0pye-T1xU+8ZfQYx1qgXP_GhXnKMpRForx5-CRw@mail.gmail.com>
References: <CAKYNcuNZvYoi8=id4KhboDC=TKOqqkgmC6zpe3QMcNRi3J=jPw@mail.gmail.com>
	<46d84bdd-830f-fff8-7a69-ccbe1107185d@gmail.com>
	<CAKYNcuPT6ZS0pye-T1xU+8ZfQYx1qgXP_GhXnKMpRForx5-CRw@mail.gmail.com>
Message-ID: <8e3e4333-73a9-9d54-bdaf-78ba0d1ee65d@gmail.com>

Tarek -

See inline.

On 09/01/2016 10:11 AM, Dev Stack wrote:
> Hi Chris,
>
> Thank you for your answer.
>
> 1) yes, we can use Set<>
> 2) When we load an offer we have to load also the associated product.
> So, we have to keep the link from offer to product.
> the link from product to offer is not needed for now.
What I meant here was more along the lines of keeping the bidirectional 
relation,
but instead of the @ManyToOne being the owner of the mapping, we'd 
invert it so
that the @OneToMany owned the relationship.  The mapping would then be:

@Entity
@Audited
public class Product {
   ...
   @OneToMany
   @JoinColumn(name = "product_offer")
   @AuditMappedBy(mappedBy = "product")
   private Set<Offer> offers;
   ...
}

@Entity
@Audited
public class Offer {
   ...
   @ManyToOne
   @JoinColumn(name = "product_offer", insertable = false, updatable = 
false)
   private Product product;
   ...
}

We want to do this to take advantage of Envers' 
REVISION_ON_COLLECTION_CHANGE.
See below in your point 2 as to why.

> Thanks,
> Tarek
>
> 2016-09-01 15:55 GMT+02:00 Chris Cranford <crancran at gmail.com 
> <mailto:crancran at gmail.com>>:
>
>     Tarek -
>
>     There are a few ways we can tackle what you want all within the
>     scope of Envers,
>     but some of it highly depends upon details specific to the
>     relationship between
>     Product (P) and Offer (O).
>
>     1. What is the collection type used in Product for the related offers?
>        If this happens to be a List<>, would it be possible to use a
>     Set<> instead?
>
>     2. Is there a requirement that Offer should own the relationship
>     with Product?
>        In other words, is it possible to invert the relationship such
>     that the
>        collection side is the owner instead?
>
>     Chris
>
>
>     On 09/01/2016 06:14 AM, Dev Stack wrote:
>
>         Hello,
>
>         we have in our model entity P (product) and entity O (offer).
>         The two
>         entities have a link.
>         one instance of P can have one or many O instances.
>         an instance O has a reference to only one instance of P.
>         The link is managed in the O side.
>
>         P and O are revisioned by Hibernate Envers.
>
>         Two use cases to cover:
>         1) If P instance is updated (new revision) we want that O keep
>         the link
>         with the old revision of P.
>
You get this by default.

Regardless of which side owns the relationship, any change made 
specifically to a
Product that does not change the associated Offer instances, only a 
revision is
triggered for Product, allowing Offer instances to point to the older 
versions of a
Product when they're queried.

If we assume a Product and Offer were created in revision 1 and 
subsequently the
Product was modified in revision 2, the following are true:

   auditReader.getRevisions( Offer.class, offerId ) = [1]
   auditReader.getRevisions( Product.class, productId) = [1, 2]

So querying Offer at revision 1 would give you the product instance at 
revision 1

   Offer offer = auditReader.find( Offer.class, offerId, 1 );
   offer.getProduct() = Product at revision 1

>         2) When I update O instance, I will move the reference to the
>         last revision
>         of O instance.
>
>         What we did is, inside O class we added to attributes P.id and
>         P.revision.
>         So when we load the object P we use these to fields to load
>         manually (O DAO
>         has reference P DAO).
>
I think it makes more sense to enforce this through Envers than 
polluting the domain
model, but that's just my opinion ;).

The cleanest way is to invert the relationship as I described above and 
change the
collection type to a Set<>.  The setting REVISION_ON_COLLECTION_CHANGE will
take affect since Product now owns the relationship and any change you 
make to
an Offer, the owning entity (Product) will be revised automatically.

In other words, changes to an Offer will force Product to update and so 
the revision
number query logic from 1) holds true and helps us here too.

NOTE: Just be sure you implement the appropriate equals/hashCode logic 
for Offer
so that changes are properly detected.

If you decide you don't want to use REVISION_ON_COLLECTION_CHANGE and invert
the relationship between Product and Offer, the only other partial 
Envers' solution
I see might be to introduce some attribute on Product that is audited 
that your
business tier couldchange when an offer is modified, causing the Product to
be audited like the following:

   entityManager.getTransaction().begin();
   changedOffer.setCode( "NEWCODE" );
   changedOffer.getProduct().pulse(); // updates a field to trigger revision
   entityManager.merge( changedOffer );
   entityManager.getTransaction().commit();

Hope this helps.
Chris



From gbadner at redhat.com  Thu Sep  1 17:13:03 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 1 Sep 2016 14:13:03 -0700
Subject: [hibernate-dev] HHH-11042 Count distinct tuples
In-Reply-To: <9bda3dd4-4440-1e9f-1ddc-1021b6eafccd@gmail.com>
References: <9bda3dd4-4440-1e9f-1ddc-1021b6eafccd@gmail.com>
Message-ID: <CAFDzhiRSFWeiwYDuHnQ2akApdK7Uty=r9R_aHVA_C9nncoEUEQ@mail.gmail.com>

Hi Christian,

I've been following your discussion on HHH-11042 and thinking about your
solution. I am concerned that some dialects do not treat null the way you
describe. SQL Server has a property that changes how null is treated:

SET ANSI_NULLS { ON | OFF } [1]

[1] mentions that in a future release it will not be possible to set
to OFF, but for now, this is a concern.

I also found [2] which says:

"For the DISTINCT keyword, null values are considered to be duplicates of
 each other. When DISTINCT is included in a SELECT statement, only one
NULL is returned in the results, regardless of how many null values are
encountered."

Sybase may be similar. I'm not sure if there are other dialects that
could be affected.

I agree that the dialect should be able to override the behavior.

Regards,

Gail


[1] https://msdn.microsoft.com/en-us/library/ms188048.aspx
[2] https://technet.microsoft.com/en-us/library/ms187831(v=sql.105).aspx


On Thu, Sep 1, 2016 at 3:18 AM, Christian Beikov <christian.beikov at gmail.com
> wrote:

> Hey,
>
> I wanted to start a discussion regarding this issue:
> https://hibernate.atlassian.net/browse/HHH-11042
>
> Although the Dialect class contains the method
> "supportsTupleDistinctCount", it is never used, so when doing a count
> distinct on a tuple, it just renders the tuple instead of doing a
> fallback or throwing an error.
>
> I suggested the OP to override the count function in the dialect to do
> whatever he thinks is best but then I realized that the count function
> is not even used as the logic is hard coded in some locations. The
> problematic location in this case is
> "org.hibernate.hql.internal.ast.tree.IdentNode.resolveAsAlias" which
> does not consider the function at all but renders the SQL directly.
>
> After suggesting him to introduce a custom function instead and some
> discussion on how count distinct could be reliably implemented I think I
> found a solution that might work for most databases.
>
> On stackoverflow and other sites it is often suggested to use a checksum
> to workaround this limitation which obviously is not a good idea. I
> proposed to do concatenation with a separator that doesn't appear in the
> string and apparently the character '\0' is a valid character which
> makes it a good candidate as that should normally not appear in a string.
>
> The final solution to the problem looks something like the following
>
> count(distinct case when col1 is null or col2 is null then null else
> col1 || '\0' || col2 end) + count(case when col1 is null or col2 is null
> then 1 end)
>
> The first count does a count distinct on all columns concatenated with
> '\0' where all values are not null. The second just counts the cases
> where one of the column values was null. Together that emits the proper
> count based on the assumption that '\0' does not appear in the columns.
>
> What do you think about that solution? I would like to implement it that
> way and do a PR.
>
> I would also like to make use of the count function registered in the
> dialect to make this overrideable. Hope that's okay?
>
>
> Regards,
> Christian
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Sep  1 17:22:09 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 1 Sep 2016 22:22:09 +0100
Subject: [hibernate-dev] Hibernate ORM repository using modules?
Message-ID: <CAFm4XO2-acc7eq=JPmMZOaL+pXSoE_DgNGR3AbNw+FeERFfSRw@mail.gmail.com>

Hi all,
the Infinispan/Hibernate integration test - which is run by the
Infinispan team and uses TeamCity instead of Jenkins - is failing with
the below cryptic error.

Did the ORM switch to using Git modules?

Error collecting changes for VCS repository
'"https://github.com/hibernate/hibernate-orm.git#master" {instance
id=4, parent internal id=2, parent
id=https___github_com_hibernate_hibernate_orm_git_master, description:
"https://github.com/hibernate/hibernate-orm.git#master"}'
Collecting changes failed:
jetbrains.buildServer.buildTriggers.vcs.git.submodules.MissingSubmoduleConfigException:
The 'https://github.com/hibernate/hibernate-orm.git' repository has a
submodule in the '8de4ff2a3a6a30541d463fdb373e1e8f0de953b5' commit at
the 'hibernate-orm' path, but has not .gitmodules configuration in the
root directory

Thanks,
Sanne

From steve at hibernate.org  Thu Sep  1 17:37:45 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 01 Sep 2016 21:37:45 +0000
Subject: [hibernate-dev] Hibernate ORM repository using modules?
In-Reply-To: <CAFm4XO2-acc7eq=JPmMZOaL+pXSoE_DgNGR3AbNw+FeERFfSRw@mail.gmail.com>
References: <CAFm4XO2-acc7eq=JPmMZOaL+pXSoE_DgNGR3AbNw+FeERFfSRw@mail.gmail.com>
Message-ID: <CAFdSV9vd0nMgDB-3WYs0yQm2OrohQVOLTL2DDqaoxf=UrgvuCA@mail.gmail.com>

Nope

On Thu, Sep 1, 2016, 4:25 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
> the Infinispan/Hibernate integration test - which is run by the
> Infinispan team and uses TeamCity instead of Jenkins - is failing with
> the below cryptic error.
>
> Did the ORM switch to using Git modules?
>
> Error collecting changes for VCS repository
> '"https://github.com/hibernate/hibernate-orm.git#master" {instance
> id=4, parent internal id=2, parent
> id=https___github_com_hibernate_hibernate_orm_git_master, description:
> "https://github.com/hibernate/hibernate-orm.git#master"}'
> Collecting changes failed:
>
> jetbrains.buildServer.buildTriggers.vcs.git.submodules.MissingSubmoduleConfigException:
> The 'https://github.com/hibernate/hibernate-orm.git' repository has a
> submodule in the '8de4ff2a3a6a30541d463fdb373e1e8f0de953b5' commit at
> the 'hibernate-orm' path, but has not .gitmodules configuration in the
> root directory
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Sep  2 07:34:19 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 2 Sep 2016 12:34:19 +0100
Subject: [hibernate-dev] Hibernate ORM repository using modules?
In-Reply-To: <CAFdSV9vd0nMgDB-3WYs0yQm2OrohQVOLTL2DDqaoxf=UrgvuCA@mail.gmail.com>
References: <CAFm4XO2-acc7eq=JPmMZOaL+pXSoE_DgNGR3AbNw+FeERFfSRw@mail.gmail.com>
	<CAFdSV9vd0nMgDB-3WYs0yQm2OrohQVOLTL2DDqaoxf=UrgvuCA@mail.gmail.com>
Message-ID: <CAFm4XO2qN=i2tyck0TJPDLsC+uk1A9wJosJ6_uEhZc-Xu-a5uA@mail.gmail.com>

Sebastian Laskawiec pointed out that there is indeed a submodule,
introduced by this commit:

https://github.com/hibernate/hibernate-orm/commit/e75b017a4664d158e1197d19dca204273c4a2d66#diff-b82723dbef3c19115685625a04d6071dR1

I guess it's a mistake... I'll delete it soon, ping me if I shouldn't.

Thanks,
Sanne


On 1 September 2016 at 22:37, Steve Ebersole <steve at hibernate.org> wrote:
> Nope
>
>
> On Thu, Sep 1, 2016, 4:25 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi all,
>> the Infinispan/Hibernate integration test - which is run by the
>> Infinispan team and uses TeamCity instead of Jenkins - is failing with
>> the below cryptic error.
>>
>> Did the ORM switch to using Git modules?
>>
>> Error collecting changes for VCS repository
>> '"https://github.com/hibernate/hibernate-orm.git#master" {instance
>> id=4, parent internal id=2, parent
>> id=https___github_com_hibernate_hibernate_orm_git_master, description:
>> "https://github.com/hibernate/hibernate-orm.git#master"}'
>> Collecting changes failed:
>>
>> jetbrains.buildServer.buildTriggers.vcs.git.submodules.MissingSubmoduleConfigException:
>> The 'https://github.com/hibernate/hibernate-orm.git' repository has a
>> submodule in the '8de4ff2a3a6a30541d463fdb373e1e8f0de953b5' commit at
>> the 'hibernate-orm' path, but has not .gitmodules configuration in the
>> root directory
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri Sep  2 07:56:01 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 02 Sep 2016 11:56:01 +0000
Subject: [hibernate-dev] Hibernate ORM repository using modules?
In-Reply-To: <CAFm4XO2qN=i2tyck0TJPDLsC+uk1A9wJosJ6_uEhZc-Xu-a5uA@mail.gmail.com>
References: <CAFm4XO2-acc7eq=JPmMZOaL+pXSoE_DgNGR3AbNw+FeERFfSRw@mail.gmail.com>
	<CAFdSV9vd0nMgDB-3WYs0yQm2OrohQVOLTL2DDqaoxf=UrgvuCA@mail.gmail.com>
	<CAFm4XO2qN=i2tyck0TJPDLsC+uk1A9wJosJ6_uEhZc-Xu-a5uA@mail.gmail.com>
Message-ID: <CAFdSV9uObm2QmP+mv2MN95h524MkLA8dtf_=0NZNBA1Ab=7R9Q@mail.gmail.com>

Ah, looks like it came from a contribution and not noticed as it was
applied.  Yes that is a mistake.


On Fri, Sep 2, 2016 at 6:34 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Sebastian Laskawiec pointed out that there is indeed a submodule,
> introduced by this commit:
>
>
> https://github.com/hibernate/hibernate-orm/commit/e75b017a4664d158e1197d19dca204273c4a2d66#diff-b82723dbef3c19115685625a04d6071dR1
>
> I guess it's a mistake... I'll delete it soon, ping me if I shouldn't.
>
> Thanks,
> Sanne
>
>
> On 1 September 2016 at 22:37, Steve Ebersole <steve at hibernate.org> wrote:
> > Nope
> >
> >
> > On Thu, Sep 1, 2016, 4:25 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> Hi all,
> >> the Infinispan/Hibernate integration test - which is run by the
> >> Infinispan team and uses TeamCity instead of Jenkins - is failing with
> >> the below cryptic error.
> >>
> >> Did the ORM switch to using Git modules?
> >>
> >> Error collecting changes for VCS repository
> >> '"https://github.com/hibernate/hibernate-orm.git#master" {instance
> >> id=4, parent internal id=2, parent
> >> id=https___github_com_hibernate_hibernate_orm_git_master, description:
> >> "https://github.com/hibernate/hibernate-orm.git#master"}'
> >> Collecting changes failed:
> >>
> >>
> jetbrains.buildServer.buildTriggers.vcs.git.submodules.MissingSubmoduleConfigException:
> >> The 'https://github.com/hibernate/hibernate-orm.git' repository has a
> >> submodule in the '8de4ff2a3a6a30541d463fdb373e1e8f0de953b5' commit at
> >> the 'hibernate-orm' path, but has not .gitmodules configuration in the
> >> root directory
> >>
> >> Thanks,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From andrea at hibernate.org  Fri Sep  2 07:57:52 2016
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 2 Sep 2016 12:57:52 +0100
Subject: [hibernate-dev] Hibernate ORM repository using modules?
In-Reply-To: <CAFm4XO2qN=i2tyck0TJPDLsC+uk1A9wJosJ6_uEhZc-Xu-a5uA@mail.gmail.com>
References: <CAFm4XO2-acc7eq=JPmMZOaL+pXSoE_DgNGR3AbNw+FeERFfSRw@mail.gmail.com>
	<CAFdSV9vd0nMgDB-3WYs0yQm2OrohQVOLTL2DDqaoxf=UrgvuCA@mail.gmail.com>
	<CAFm4XO2qN=i2tyck0TJPDLsC+uk1A9wJosJ6_uEhZc-Xu-a5uA@mail.gmail.com>
Message-ID: <CAL00eSQjoQcqrvSOvenPpQj-8bJtKsSOTqPadY0+2M+bcsPJOA@mail.gmail.com>

yes I also believe it was a mistake

On 2 September 2016 at 12:34, Sanne Grinovero <sanne at hibernate.org> wrote:

> Sebastian Laskawiec pointed out that there is indeed a submodule,
> introduced by this commit:
>
> https://github.com/hibernate/hibernate-orm/commit/
> e75b017a4664d158e1197d19dca204273c4a2d66#diff-
> b82723dbef3c19115685625a04d6071dR1
>
> I guess it's a mistake... I'll delete it soon, ping me if I shouldn't.
>
> Thanks,
> Sanne
>
>
> On 1 September 2016 at 22:37, Steve Ebersole <steve at hibernate.org> wrote:
> > Nope
> >
> >
> > On Thu, Sep 1, 2016, 4:25 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> Hi all,
> >> the Infinispan/Hibernate integration test - which is run by the
> >> Infinispan team and uses TeamCity instead of Jenkins - is failing with
> >> the below cryptic error.
> >>
> >> Did the ORM switch to using Git modules?
> >>
> >> Error collecting changes for VCS repository
> >> '"https://github.com/hibernate/hibernate-orm.git#master" {instance
> >> id=4, parent internal id=2, parent
> >> id=https___github_com_hibernate_hibernate_orm_git_master, description:
> >> "https://github.com/hibernate/hibernate-orm.git#master"}'
> >> Collecting changes failed:
> >>
> >> jetbrains.buildServer.buildTriggers.vcs.git.submodules.
> MissingSubmoduleConfigException:
> >> The 'https://github.com/hibernate/hibernate-orm.git' repository has a
> >> submodule in the '8de4ff2a3a6a30541d463fdb373e1e8f0de953b5' commit at
> >> the 'hibernate-orm' path, but has not .gitmodules configuration in the
> >> root directory
> >>
> >> Thanks,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Fri Sep  2 08:16:15 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 2 Sep 2016 15:16:15 +0300
Subject: [hibernate-dev] Hibernate ORM repository using modules?
In-Reply-To: <CAL00eSQjoQcqrvSOvenPpQj-8bJtKsSOTqPadY0+2M+bcsPJOA@mail.gmail.com>
References: <CAFm4XO2-acc7eq=JPmMZOaL+pXSoE_DgNGR3AbNw+FeERFfSRw@mail.gmail.com>
	<CAFdSV9vd0nMgDB-3WYs0yQm2OrohQVOLTL2DDqaoxf=UrgvuCA@mail.gmail.com>
	<CAFm4XO2qN=i2tyck0TJPDLsC+uk1A9wJosJ6_uEhZc-Xu-a5uA@mail.gmail.com>
	<CAL00eSQjoQcqrvSOvenPpQj-8bJtKsSOTqPadY0+2M+bcsPJOA@mail.gmail.com>
Message-ID: <CA+gWKMAxSNBODpYCt+aYBmNR2AS+mzG+Js8dYNEuEvFBwgaN6Q@mail.gmail.com>

Damn. I must have missed it when I reviewed the PR.
Good thing that you caught it.

Vlad

On Fri, Sep 2, 2016 at 2:57 PM, andrea boriero <andrea at hibernate.org> wrote:

> yes I also believe it was a mistake
>
> On 2 September 2016 at 12:34, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> > Sebastian Laskawiec pointed out that there is indeed a submodule,
> > introduced by this commit:
> >
> > https://github.com/hibernate/hibernate-orm/commit/
> > e75b017a4664d158e1197d19dca204273c4a2d66#diff-
> > b82723dbef3c19115685625a04d6071dR1
> >
> > I guess it's a mistake... I'll delete it soon, ping me if I shouldn't.
> >
> > Thanks,
> > Sanne
> >
> >
> > On 1 September 2016 at 22:37, Steve Ebersole <steve at hibernate.org>
> wrote:
> > > Nope
> > >
> > >
> > > On Thu, Sep 1, 2016, 4:25 PM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> > >>
> > >> Hi all,
> > >> the Infinispan/Hibernate integration test - which is run by the
> > >> Infinispan team and uses TeamCity instead of Jenkins - is failing with
> > >> the below cryptic error.
> > >>
> > >> Did the ORM switch to using Git modules?
> > >>
> > >> Error collecting changes for VCS repository
> > >> '"https://github.com/hibernate/hibernate-orm.git#master" {instance
> > >> id=4, parent internal id=2, parent
> > >> id=https___github_com_hibernate_hibernate_orm_git_master,
> description:
> > >> "https://github.com/hibernate/hibernate-orm.git#master"}'
> > >> Collecting changes failed:
> > >>
> > >> jetbrains.buildServer.buildTriggers.vcs.git.submodules.
> > MissingSubmoduleConfigException:
> > >> The 'https://github.com/hibernate/hibernate-orm.git' repository has a
> > >> submodule in the '8de4ff2a3a6a30541d463fdb373e1e8f0de953b5' commit at
> > >> the 'hibernate-orm' path, but has not .gitmodules configuration in the
> > >> root directory
> > >>
> > >> Thanks,
> > >> Sanne
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Sep  2 08:22:31 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 2 Sep 2016 13:22:31 +0100
Subject: [hibernate-dev] Hibernate ORM repository using modules?
In-Reply-To: <CA+gWKMAxSNBODpYCt+aYBmNR2AS+mzG+Js8dYNEuEvFBwgaN6Q@mail.gmail.com>
References: <CAFm4XO2-acc7eq=JPmMZOaL+pXSoE_DgNGR3AbNw+FeERFfSRw@mail.gmail.com>
	<CAFdSV9vd0nMgDB-3WYs0yQm2OrohQVOLTL2DDqaoxf=UrgvuCA@mail.gmail.com>
	<CAFm4XO2qN=i2tyck0TJPDLsC+uk1A9wJosJ6_uEhZc-Xu-a5uA@mail.gmail.com>
	<CAL00eSQjoQcqrvSOvenPpQj-8bJtKsSOTqPadY0+2M+bcsPJOA@mail.gmail.com>
	<CA+gWKMAxSNBODpYCt+aYBmNR2AS+mzG+Js8dYNEuEvFBwgaN6Q@mail.gmail.com>
Message-ID: <CAFm4XO2=3vKL7AMQDHo0Nmn-3sFninkvOtebgH2_3=Xuis1-=Q@mail.gmail.com>

N.P. It's fixed now on master.

I checked other branches but didn't seem to have this problem.


On 2 September 2016 at 13:16, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Damn. I must have missed it when I reviewed the PR.
> Good thing that you caught it.
>
> Vlad
>
> On Fri, Sep 2, 2016 at 2:57 PM, andrea boriero <andrea at hibernate.org> wrote:
>>
>> yes I also believe it was a mistake
>>
>> On 2 September 2016 at 12:34, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> > Sebastian Laskawiec pointed out that there is indeed a submodule,
>> > introduced by this commit:
>> >
>> > https://github.com/hibernate/hibernate-orm/commit/
>> > e75b017a4664d158e1197d19dca204273c4a2d66#diff-
>> > b82723dbef3c19115685625a04d6071dR1
>> >
>> > I guess it's a mistake... I'll delete it soon, ping me if I shouldn't.
>> >
>> > Thanks,
>> > Sanne
>> >
>> >
>> > On 1 September 2016 at 22:37, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> > > Nope
>> > >
>> > >
>> > > On Thu, Sep 1, 2016, 4:25 PM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> > >>
>> > >> Hi all,
>> > >> the Infinispan/Hibernate integration test - which is run by the
>> > >> Infinispan team and uses TeamCity instead of Jenkins - is failing
>> > >> with
>> > >> the below cryptic error.
>> > >>
>> > >> Did the ORM switch to using Git modules?
>> > >>
>> > >> Error collecting changes for VCS repository
>> > >> '"https://github.com/hibernate/hibernate-orm.git#master" {instance
>> > >> id=4, parent internal id=2, parent
>> > >> id=https___github_com_hibernate_hibernate_orm_git_master,
>> > >> description:
>> > >> "https://github.com/hibernate/hibernate-orm.git#master"}'
>> > >> Collecting changes failed:
>> > >>
>> > >> jetbrains.buildServer.buildTriggers.vcs.git.submodules.
>> > MissingSubmoduleConfigException:
>> > >> The 'https://github.com/hibernate/hibernate-orm.git' repository has a
>> > >> submodule in the '8de4ff2a3a6a30541d463fdb373e1e8f0de953b5' commit at
>> > >> the 'hibernate-orm' path, but has not .gitmodules configuration in
>> > >> the
>> > >> root directory
>> > >>
>> > >> Thanks,
>> > >> Sanne
>> > >> _______________________________________________
>> > >> hibernate-dev mailing list
>> > >> hibernate-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From christian.beikov at gmail.com  Sat Sep  3 03:48:05 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 3 Sep 2016 09:48:05 +0200
Subject: [hibernate-dev] HHH-11042 Count distinct tuples
In-Reply-To: <CAFDzhiRSFWeiwYDuHnQ2akApdK7Uty=r9R_aHVA_C9nncoEUEQ@mail.gmail.com>
References: <9bda3dd4-4440-1e9f-1ddc-1021b6eafccd@gmail.com>
	<CAFDzhiRSFWeiwYDuHnQ2akApdK7Uty=r9R_aHVA_C9nncoEUEQ@mail.gmail.com>
Message-ID: <b93a3da9-8fbd-03e3-5245-4fabd23b0686@gmail.com>

Hey Gail,

I guess we have to introduce a configuration parameter then or extend 
the dialect with a method for these cases?
Should I implement a POC? If so, which approach should I use and how 
would I access the parameter if I should do it like that?

Regards,
Christian

Am 01.09.2016 um 23:13 schrieb Gail Badner:
> Hi Christian,
>
> I've been following your discussion on HHH-11042 and thinking about 
> your solution. I am concerned that some dialects do not treat null the 
> way you describe. SQL Server has a property that changes how null is 
> treated:
> SET ANSI_NULLS { ON | OFF } [1]
> [1] mentions that in a future release it will not be possible to set 
> to OFF, but for now, this is a concern. I also found [2] which says: 
> "For the DISTINCT keyword, null values are considered to be duplicates 
> of each other. When DISTINCT is included in a SELECT statement, only 
> one NULL is returned in the results, regardless of how many null 
> values are encountered."
> Sybase may be similar. I'm not sure if there are other dialects that 
> could be affected.
> I agree that the dialect should be able to override the behavior.
> Regards,
> Gail
> [1] https://msdn.microsoft.com/en-us/library/ms188048.aspx [2] 
> https://technet.microsoft.com/en-us/library/ms187831(v=sql.105).aspx 
> <https://technet.microsoft.com/en-us/library/ms187831%28v=sql.105%29.aspx> 
>
>
> On Thu, Sep 1, 2016 at 3:18 AM, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Hey,
>
>     I wanted to start a discussion regarding this issue:
>     https://hibernate.atlassian.net/browse/HHH-11042
>     <https://hibernate.atlassian.net/browse/HHH-11042>
>
>     Although the Dialect class contains the method
>     "supportsTupleDistinctCount", it is never used, so when doing a count
>     distinct on a tuple, it just renders the tuple instead of doing a
>     fallback or throwing an error.
>
>     I suggested the OP to override the count function in the dialect to do
>     whatever he thinks is best but then I realized that the count function
>     is not even used as the logic is hard coded in some locations. The
>     problematic location in this case is
>     "org.hibernate.hql.internal.ast.tree.IdentNode.resolveAsAlias" which
>     does not consider the function at all but renders the SQL directly.
>
>     After suggesting him to introduce a custom function instead and some
>     discussion on how count distinct could be reliably implemented I
>     think I
>     found a solution that might work for most databases.
>
>     On stackoverflow and other sites it is often suggested to use a
>     checksum
>     to workaround this limitation which obviously is not a good idea. I
>     proposed to do concatenation with a separator that doesn't appear
>     in the
>     string and apparently the character '\0' is a valid character which
>     makes it a good candidate as that should normally not appear in a
>     string.
>
>     The final solution to the problem looks something like the following
>
>     count(distinct case when col1 is null or col2 is null then null else
>     col1 || '\0' || col2 end) + count(case when col1 is null or col2
>     is null
>     then 1 end)
>
>     The first count does a count distinct on all columns concatenated with
>     '\0' where all values are not null. The second just counts the cases
>     where one of the column values was null. Together that emits the
>     proper
>     count based on the assumption that '\0' does not appear in the
>     columns.
>
>     What do you think about that solution? I would like to implement
>     it that
>     way and do a PR.
>
>     I would also like to make use of the count function registered in the
>     dialect to make this overrideable. Hope that's okay?
>
>
>     Regards,
>     Christian
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>


From guillaume.smet at hibernate.org  Mon Sep  5 11:13:42 2016
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Mon, 5 Sep 2016 17:13:42 +0200
Subject: [hibernate-dev] Hibernate Validator 5.3.0.CR1 released
Message-ID: <CALt0+o_sbfp4sJ3eMcWmbe=Xg8HH2Qx8z4UZ3ojxXthBZVioaw@mail.gmail.com>

Hi,

It's with great pleasure that I announce you the first Candidate Release of
Hibernate Validator 5.3.0.

The idea behind this release is to provide our users with enhancements and
bugfixes while we are making progress towards Bean Validation 2.0 and
Hibernate Validator 6.

Expect a quick release of Hibernate Validator 5.3.0.Final if no outstanding
issues are discovered.

See the announcement post
http://in.relation.to/2016/09/05/hibernate-validator-530-cr1-out/ for more
information about this release!

As always, your feedback is highly welcome!

On a side note, if you are interested in defining the future of Bean
Validation, please come join us working on BV 2.0 here:
http://beanvalidation.org/.

Happy testing!

-- 
Guillaume

From sanne at hibernate.org  Mon Sep  5 16:08:51 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 5 Sep 2016 21:08:51 +0100
Subject: [hibernate-dev] Java 9 upgraded on CI : build b134
Message-ID: <CAFm4XO3azC1kKsdkPT=VDUy0CBJGS7xrfVkpWpSfzFE9h5cmvA@mail.gmail.com>

Hi all,

I just upgraded all of our CI servers to use build b134 of the preview
of Java 9, so you might see some regressions when the next builds
trigger (please don't ignore them!).

Also, I'm happy to see we were listed among the projects which
provided some useful feedback:
 - https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+September+2016

I'm surprised that we didn't report many actual bugs directly affecting us.
My guess is that Hibernate actually depends on many other projects
which had to pave the road, in some cases with our help (Maven,
Gradle, Javassist, Lucene, Byteman, JRuby, WildFly, Infinispan,
Narayana... to list a few which have been problematic!).

Some of our features are still disabled when running CI on Java 9. I'd
hope in the next few weeks we could try to re-enable some of them?

Thanks,
Sanne

From steve at hibernate.org  Mon Sep  5 16:43:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 05 Sep 2016 20:43:47 +0000
Subject: [hibernate-dev] Java 9 upgraded on CI : build b134
In-Reply-To: <CAFm4XO3azC1kKsdkPT=VDUy0CBJGS7xrfVkpWpSfzFE9h5cmvA@mail.gmail.com>
References: <CAFm4XO3azC1kKsdkPT=VDUy0CBJGS7xrfVkpWpSfzFE9h5cmvA@mail.gmail.com>
Message-ID: <CAFdSV9sTvx9h8-P34JRkDWks1z7SA6+DgSviEmc7ox2eQVuh8A@mail.gmail.com>

We could update to a WF snapshot supporting Java 9 and possibly re-enable
those tests.

I have not kept up with Javassist which is the other one we have issue with
in ORM, both directly and through Hikari CP

On Mon, Sep 5, 2016, 3:13 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
>
> I just upgraded all of our CI servers to use build b134 of the preview
> of Java 9, so you might see some regressions when the next builds
> trigger (please don't ignore them!).
>
> Also, I'm happy to see we were listed among the projects which
> provided some useful feedback:
>  -
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+September+2016
>
> I'm surprised that we didn't report many actual bugs directly affecting us.
> My guess is that Hibernate actually depends on many other projects
> which had to pave the road, in some cases with our help (Maven,
> Gradle, Javassist, Lucene, Byteman, JRuby, WildFly, Infinispan,
> Narayana... to list a few which have been problematic!).
>
> Some of our features are still disabled when running CI on Java 9. I'd
> hope in the next few weeks we could try to re-enable some of them?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue Sep  6 08:55:03 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 6 Sep 2016 13:55:03 +0100
Subject: [hibernate-dev] Hibernate Search 5.6.0.Beta2 released
Message-ID: <CAFm4XO2m26SsJFcp3rUypsi9LtH7t3Uyv4gq+JNMwU_P5EYQ3Q@mail.gmail.com>

Hello all,

tonight we released Hibernate Search 5.6.0.Beta2

More details can be found on our blog:
 - http://in.relation.to/2016/09/06/ElasticsearchIntegrationBeta2/

Regards,
Sanne

From jan-willem at youngmediaexperts.nl  Tue Sep  6 21:41:15 2016
From: jan-willem at youngmediaexperts.nl (Jan-Willem Gmelig Meyling)
Date: Wed, 7 Sep 2016 03:41:15 +0200
Subject: [hibernate-dev] Add entity with InheritanceType.JOINED to native
	query
Message-ID: <A25A791B-6F09-4910-ABC9-2CC3EDA52F99@youngmediaexperts.nl>

Hi Hibernate developers,

I stumbled upon an issue today and I am wondering whether the following would be possible using Hibernate, and if not, whether such could actually be implemented, or if I actually hit a boundary of the alias injection.

My problem has to do with trying to map the result set of a native query to an entity that uses the JOINED InheritanceType. After adding the enitity to my NativeQuery as follows, the aliases for the tables of the subclasses are not set properly (obviously). My question is, though, would it be possible to set these as well? As I can?t figure this out from the current documentation (that only states that all columns should be present in the result set, which I assume to apply to a InheritanceType.SINGLE_TABLE primarily).

The code I am currently using to construct the query is as follows:


session
   .createNativeQuery("SELECT {s.*} FROM my_super {s} LEFT JOIN my_sub_a {a} USING (id)")
   .addEntity("s", MySuper.class)
   .getSingleResult();

Additional code is available on Github gist: https://gist.github.com/JWGmeligMeyling/51e8a305f3c268eda473511e202f76e8

And my question is also posted on Stackoverflow (to gain some extra credits for the answer ;-) ): 
http://stackoverflow.com/questions/39359924/add-entity-with-inheritancetype-joined-to-native-query

Thanks in advance,

Jan-Willem

From steve at hibernate.org  Thu Sep  8 10:03:25 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 08 Sep 2016 14:03:25 +0000
Subject: [hibernate-dev] Hibernate mapping deprecation
In-Reply-To: <000f01d209d7$640e19b0$2c2a4d10$@error.be>
References: <000f01d209d7$640e19b0$2c2a4d10$@error.be>
Message-ID: <CAFdSV9sBfzBjzeHFmzNobFhvuLcTBZ8apHoP2rjVQwE_6gh_vA@mail.gmail.com>

Yes that will happen:
https://github.com/hibernate/hibernate-orm/wiki/Roadmap7.0

But not any time soon.  Basically we will support an "extended" version of
the JPA orm.xml schema that introduces Hibernate specific concepts.
Historically we stayed away from that because IMO it really is against the
spirit, in not the letter, of the JPA spec.  However, IIUC this is exactly
what other JPA providers do.  So we will go that route.

For a short time we will continue to support hbm.xml files even after 7.0
*to a point*.  There are certain hbm.xml concepts that simply do not map
well to JPA - things JPA handles differently.  The main one that comes to
mind is property-ref.  There will be a "converter" for converting hbm.xml
-> orm.xml.  The intention is to allow build-time conversion of hbm.xml
files to the corresponding orm.xml.  For a short time we will continue to
support that conversion on the fly at runtime too.  Handling of any
non-supported constructs (property-ref, e.g.) is still being discussed.
For sure as part of the on-the-fly runtime conversion it wouyld result in
an exception.  For the build-time tool though we'd ideally inject a comment
of some sort into the generated file and log a warning; the difficulty with
that is that JAXB (to my limited knowledge, at least) does not provide a
way to inject an XML comment somewhere in the doc.

Also, keep in mind that a lot of this conversion work is already done on a
branch.  Ideally I would love to offer the "extended orm.xml" feature in
6.x (for some x > 0).  So even as part of 6.x you'd be able to play around
with that.  TBD exactly when we'd drop support for hbm.xml altogether;
obviously some point after 7


On Thu, Sep 8, 2016 at 8:46 AM Koen Serneels <ks at error.be> wrote:

> Hi Steve,
>
>
>
> You probably don?t remember me, but we spoke a while back on IRC about
> some stuff regarding hibernate5<->spring4 integration (like SF building)
> and inconsistencies between metadata build from Hibernate mapping files
> compared to their annotation equivalent. Anyway, if I remember correctly
> you mentioned something during our conversation that Hibernate wants to
> more or less deprecate Hibernate mapping files in the future. I would be
> thankful if you could shed some more light on this.
>
>
>
> To explain the situation: at the moment we are considering migrating our
> Hibernate XML mappings to annotations. But as we have a wrapper/super class
> structure with generics, we are trying to make this fit with annotations.
> However, while this might work (we are still testing, as we want to retain
> compatibility with our existing code) we were also thinking on using the
> JPA mapping format as we have the feeling this could be more elegant (to be
> honest, the mapping files never hurted us)
>
>
>
> Now, is it true that Hibernate is going to deprecate the Hibernate mapping
> format? And is using the JPA mapping format instead a sound (read: future
> proof) choice?
> Unless I?m mistaking, Hibernate as a JPA compliant provider, is supposed
> to continue supporting the JPA mapping format unless this would become
> deprecated in specs, which should not happen anytime soon, no?
>
>
>
> Thanks for your time
>
>
>
> Regards,
>
>
>
> Koen.
>

From steve at hibernate.org  Fri Sep  9 08:20:19 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 09 Sep 2016 12:20:19 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
Message-ID: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>

To be clear, this is the feature that lets you define a query like:

select ... from Person p where p.name in (:names)

And then bind varied multiple values into that single parameter holder:

query.setParameterList( "names", new String[] { "Larry", "Curly", "Moe" } );
query.setParameterList( "names", new String[] { "John", "Jane" } );

Which magically transforms to the following (rough) SQL:

select ... from PERSON p where p.name in (?, ?, ?)
select ... from PERSON p where p.name in (?, ?)

Effectively parameter lists allow expansion of the HQL statement - they
literally are handled by altering the HQL on the fly as we prepare to
execute the query.  What that means is that we can really not cache these
queries, at least not until the parameters are bound (which kind of defeats
the purpose).

I'd like to discuss dropping support for parameter lists.  There are quite
a few reasons I would like to drop this support:

   1. This is the main culprit that leads to the ever-resurrecting
   discussion about DB limits on IN clauses.  The one valid use case I saw for
   that lead me to add multi-load support in 5.1.
   2. In terms of a QueryPlan cache, this support means we can never
   effectively cache the plans for these queries because the SQL is different
   every time we execute the query.  The problem though is that we do not know
   this until well after the point that we'd resolve the QueryPlan.
    chicken-egg.
   3. This is more an internal detail, but handling the parameter bindings
   for these differently gets quite complicated.
   4. An additional internal detail is that re-writing the HQL on the fly
   is problematic.  And some of that leaks to the user in terms of result
   caching and stats (which HQL do we use?).

I get that this can be a useful feature for apps that dynamically build
HQL, although really for dynamic query building I think a criteria approach
is more appropriate.  It is not so much supporting this feature that bugs
me, it's how we expose it.  So an alternative to dropping this support
would be to support it in a different way.  The main issue is that I would
like to *syntactically* understanding that a parameter placeholder will be
used for multi-valued parameter from the query itself.  This is a
beyond-JPA feature, so we definitely have some leeway here to define this
however we want.

I am open to suggestions as to the best syntax to declare that.

An alternative would be to make some assumptions.  Specifically, the only
time I can think this is used is inside an IN predicate.  Am I missing
others?  If that is the case, we could simply assume that a IN predicate
with a single parameter placeholder is going to be a multivalued
parameter.  That assumption holds valid even if just a single value is
bound.  The main win there is that we can get rid of the Query#setParameterList
variants.  setParameterList was only ever needed so that we could
understand that the parameter is multivalued - here we'd assume that from
its context as the IN predicate value.

Continuing to support parameters-lists in any form does not really
address point
(1) above; but that's ok - the user really could , But each of the
alternatives does help with the other problems currently stemming from
parameter-list support.

From christian.beikov at gmail.com  Fri Sep  9 08:44:09 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 9 Sep 2016 14:44:09 +0200
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
Message-ID: <1fe2a03b-1006-ace6-f31a-2718b1206a6f@gmail.com>

Well the BNF in the JPA 2.1 spec contains 
"collection_valued_input_parameter" which resembles this parameter list, 
so dropping support for that would make Hibernate non JPA compliant I guess.

If you are concerned with caching, I think the parameter lists could be 
expanded to a fixed(configurable?) size and filling up empty parameter 
values with NULL.

Regards,

Christian

Am 09.09.2016 um 14:20 schrieb Steve Ebersole:
> To be clear, this is the feature that lets you define a query like:
>
> select ... from Person p where p.name in (:names)
>
> And then bind varied multiple values into that single parameter holder:
>
> query.setParameterList( "names", new String[] { "Larry", "Curly", "Moe" } );
> query.setParameterList( "names", new String[] { "John", "Jane" } );
>
> Which magically transforms to the following (rough) SQL:
>
> select ... from PERSON p where p.name in (?, ?, ?)
> select ... from PERSON p where p.name in (?, ?)
>
> Effectively parameter lists allow expansion of the HQL statement - they
> literally are handled by altering the HQL on the fly as we prepare to
> execute the query.  What that means is that we can really not cache these
> queries, at least not until the parameters are bound (which kind of defeats
> the purpose).
>
> I'd like to discuss dropping support for parameter lists.  There are quite
> a few reasons I would like to drop this support:
>
>     1. This is the main culprit that leads to the ever-resurrecting
>     discussion about DB limits on IN clauses.  The one valid use case I saw for
>     that lead me to add multi-load support in 5.1.
>     2. In terms of a QueryPlan cache, this support means we can never
>     effectively cache the plans for these queries because the SQL is different
>     every time we execute the query.  The problem though is that we do not know
>     this until well after the point that we'd resolve the QueryPlan.
>      chicken-egg.
>     3. This is more an internal detail, but handling the parameter bindings
>     for these differently gets quite complicated.
>     4. An additional internal detail is that re-writing the HQL on the fly
>     is problematic.  And some of that leaks to the user in terms of result
>     caching and stats (which HQL do we use?).
>
> I get that this can be a useful feature for apps that dynamically build
> HQL, although really for dynamic query building I think a criteria approach
> is more appropriate.  It is not so much supporting this feature that bugs
> me, it's how we expose it.  So an alternative to dropping this support
> would be to support it in a different way.  The main issue is that I would
> like to *syntactically* understanding that a parameter placeholder will be
> used for multi-valued parameter from the query itself.  This is a
> beyond-JPA feature, so we definitely have some leeway here to define this
> however we want.
>
> I am open to suggestions as to the best syntax to declare that.
>
> An alternative would be to make some assumptions.  Specifically, the only
> time I can think this is used is inside an IN predicate.  Am I missing
> others?  If that is the case, we could simply assume that a IN predicate
> with a single parameter placeholder is going to be a multivalued
> parameter.  That assumption holds valid even if just a single value is
> bound.  The main win there is that we can get rid of the Query#setParameterList
> variants.  setParameterList was only ever needed so that we could
> understand that the parameter is multivalued - here we'd assume that from
> its context as the IN predicate value.
>
> Continuing to support parameters-lists in any form does not really
> address point
> (1) above; but that's ok - the user really could , But each of the
> alternatives does help with the other problems currently stemming from
> parameter-list support.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From andrea at hibernate.org  Fri Sep  9 09:03:06 2016
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 9 Sep 2016 15:03:06 +0200
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
Message-ID: <CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>

I am also not able to figure out another use case than the IN predicate so
I am for always considering IN predicates as multi-valued.

On 9 September 2016 at 14:20, Steve Ebersole <steve at hibernate.org> wrote:

> To be clear, this is the feature that lets you define a query like:
>
> select ... from Person p where p.name in (:names)
>
> And then bind varied multiple values into that single parameter holder:
>
> query.setParameterList( "names", new String[] { "Larry", "Curly", "Moe" }
> );
> query.setParameterList( "names", new String[] { "John", "Jane" } );
>
> Which magically transforms to the following (rough) SQL:
>
> select ... from PERSON p where p.name in (?, ?, ?)
> select ... from PERSON p where p.name in (?, ?)
>
> Effectively parameter lists allow expansion of the HQL statement - they
> literally are handled by altering the HQL on the fly as we prepare to
> execute the query.  What that means is that we can really not cache these
> queries, at least not until the parameters are bound (which kind of defeats
> the purpose).
>
> I'd like to discuss dropping support for parameter lists.  There are quite
> a few reasons I would like to drop this support:
>
>    1. This is the main culprit that leads to the ever-resurrecting
>    discussion about DB limits on IN clauses.  The one valid use case I saw
> for
>    that lead me to add multi-load support in 5.1.
>    2. In terms of a QueryPlan cache, this support means we can never
>    effectively cache the plans for these queries because the SQL is
> different
>    every time we execute the query.  The problem though is that we do not
> know
>    this until well after the point that we'd resolve the QueryPlan.
>     chicken-egg.
>    3. This is more an internal detail, but handling the parameter bindings
>    for these differently gets quite complicated.
>    4. An additional internal detail is that re-writing the HQL on the fly
>    is problematic.  And some of that leaks to the user in terms of result
>    caching and stats (which HQL do we use?).
>
> I get that this can be a useful feature for apps that dynamically build
> HQL, although really for dynamic query building I think a criteria approach
> is more appropriate.  It is not so much supporting this feature that bugs
> me, it's how we expose it.  So an alternative to dropping this support
> would be to support it in a different way.  The main issue is that I would
> like to *syntactically* understanding that a parameter placeholder will be
> used for multi-valued parameter from the query itself.  This is a
> beyond-JPA feature, so we definitely have some leeway here to define this
> however we want.
>
> I am open to suggestions as to the best syntax to declare that.
>
> An alternative would be to make some assumptions.  Specifically, the only
> time I can think this is used is inside an IN predicate.  Am I missing
> others?  If that is the case, we could simply assume that a IN predicate
> with a single parameter placeholder is going to be a multivalued
> parameter.  That assumption holds valid even if just a single value is
> bound.  The main win there is that we can get rid of the
> Query#setParameterList
> variants.  setParameterList was only ever needed so that we could
> understand that the parameter is multivalued - here we'd assume that from
> its context as the IN predicate value.
>
> Continuing to support parameters-lists in any form does not really
> address point
> (1) above; but that's ok - the user really could , But each of the
> alternatives does help with the other problems currently stemming from
> parameter-list support.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Fri Sep  9 09:20:22 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 9 Sep 2016 16:20:22 +0300
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
Message-ID: <CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>

Hi,

I don't think we should deprecate such a feature.

First, the JPA specs says the follows:

"All input parameters must be single-valued, except in IN expressions (see
section 4.6.9), which support
the use of collection-valued input parameters."

So, we kinda need to support it one way or another.

Also, the JPA specs says that:

"Note that use of a collection-valued input parameter will mean that a
static query cannot be precompiled."

So, it's expected to have such a behavior.

I don't think that multi-load support can replace paremeterList since the
former cannot use any property from a given entity.
Also, the IN predicate with parameter list applies to DTO projections or
native queries, so it's useful to have it.

Vlad

On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero <andrea at hibernate.org> wrote:

> I am also not able to figure out another use case than the IN predicate so
> I am for always considering IN predicates as multi-valued.
>
> On 9 September 2016 at 14:20, Steve Ebersole <steve at hibernate.org> wrote:
>
> > To be clear, this is the feature that lets you define a query like:
> >
> > select ... from Person p where p.name in (:names)
> >
> > And then bind varied multiple values into that single parameter holder:
> >
> > query.setParameterList( "names", new String[] { "Larry", "Curly", "Moe" }
> > );
> > query.setParameterList( "names", new String[] { "John", "Jane" } );
> >
> > Which magically transforms to the following (rough) SQL:
> >
> > select ... from PERSON p where p.name in (?, ?, ?)
> > select ... from PERSON p where p.name in (?, ?)
> >
> > Effectively parameter lists allow expansion of the HQL statement - they
> > literally are handled by altering the HQL on the fly as we prepare to
> > execute the query.  What that means is that we can really not cache these
> > queries, at least not until the parameters are bound (which kind of
> defeats
> > the purpose).
> >
> > I'd like to discuss dropping support for parameter lists.  There are
> quite
> > a few reasons I would like to drop this support:
> >
> >    1. This is the main culprit that leads to the ever-resurrecting
> >    discussion about DB limits on IN clauses.  The one valid use case I
> saw
> > for
> >    that lead me to add multi-load support in 5.1.
> >    2. In terms of a QueryPlan cache, this support means we can never
> >    effectively cache the plans for these queries because the SQL is
> > different
> >    every time we execute the query.  The problem though is that we do not
> > know
> >    this until well after the point that we'd resolve the QueryPlan.
> >     chicken-egg.
> >    3. This is more an internal detail, but handling the parameter
> bindings
> >    for these differently gets quite complicated.
> >    4. An additional internal detail is that re-writing the HQL on the fly
> >    is problematic.  And some of that leaks to the user in terms of result
> >    caching and stats (which HQL do we use?).
> >
> > I get that this can be a useful feature for apps that dynamically build
> > HQL, although really for dynamic query building I think a criteria
> approach
> > is more appropriate.  It is not so much supporting this feature that bugs
> > me, it's how we expose it.  So an alternative to dropping this support
> > would be to support it in a different way.  The main issue is that I
> would
> > like to *syntactically* understanding that a parameter placeholder will
> be
> > used for multi-valued parameter from the query itself.  This is a
> > beyond-JPA feature, so we definitely have some leeway here to define this
> > however we want.
> >
> > I am open to suggestions as to the best syntax to declare that.
> >
> > An alternative would be to make some assumptions.  Specifically, the only
> > time I can think this is used is inside an IN predicate.  Am I missing
> > others?  If that is the case, we could simply assume that a IN predicate
> > with a single parameter placeholder is going to be a multivalued
> > parameter.  That assumption holds valid even if just a single value is
> > bound.  The main win there is that we can get rid of the
> > Query#setParameterList
> > variants.  setParameterList was only ever needed so that we could
> > understand that the parameter is multivalued - here we'd assume that from
> > its context as the IN predicate value.
> >
> > Continuing to support parameters-lists in any form does not really
> > address point
> > (1) above; but that's ok - the user really could , But each of the
> > alternatives does help with the other problems currently stemming from
> > parameter-list support.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Sep  9 16:26:16 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 09 Sep 2016 20:26:16 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
Message-ID: <CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>

WRT the "collection_valued_input_parameter" bit, that is limited in the
spec to IN clauses.  And more specifically in fact the spec specifically
limits this in *exactly* the way I suggested :)

<quote>
in_expression ::=
        {state_valued_path_expression | type_discriminator} [ NOT ] IN
            { ( in_item { , in_item}* ) | ( subquery ) |
collection_valued_input_parameter }

in_item ::= literal | single_valued_input_parameter
</quote>

(see "4.6.9 In Expressions" or "4.14 BNF")

In other words, the "values" of an IN expression may be *one of* the
following:

   1. an explicit list of "in-items", which in turn are specifically single
   values
   2. a subquery
   3. a *single* multivalued param (one placeholder to rule them all)


As I said in my original email:

<quote>
 we could simply assume that a IN predicate with a single parameter
placeholder is going to be a multivalued parameter
</quote>

That's what JPA supports for multi-valued parameters.  Hibernate has long
supported a broader definition of "collection_valued_input_parameter".  I
am simply suggesting that we align with the limitation JPA already has in
place.

Really, the only thing I am really asking about is the overloaded forms of
Query#setParameterList.  We have to support multi-valued parameters *in
this very limited* case.  Sure.  The problem with our existing
broader/open-ended multi-valued param support is that we do not know that a
parameter is multi-valued *from the query* itself.  Specifically we have to
wait and see if #setParameter or #setParameterList is called, on any of the
parameters.

Again, the "win" is that we could then know *up front* that a query is not
cacheable (precompile-able), whereas today we have to wait until just
before the execution (so that #setParameter and #setParameterList have all
been called).


@Vlad It depends what "query cannot be precompiled" *means* which is of
course open to interpretation.  Heck what compilation of a query means at
all is outside the scope of the spec.  Any "compilation" of the query that
resolves to SQL of course has to wait.  But "compilation" to a semantic
form (aka, SQM) does not need to wait.  In fact the SQM is the exact place
you'd look to know whether the query (plan) is cacheable.



On Fri, Sep 9, 2016 at 8:20 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I don't think we should deprecate such a feature.
>
> First, the JPA specs says the follows:
>
> "All input parameters must be single-valued, except in IN expressions (see
> section 4.6.9), which support
> the use of collection-valued input parameters."
>
> So, we kinda need to support it one way or another.
>
> Also, the JPA specs says that:
>
> "Note that use of a collection-valued input parameter will mean that a
> static query cannot be precompiled."
>
> So, it's expected to have such a behavior.
>
> I don't think that multi-load support can replace paremeterList since the
> former cannot use any property from a given entity.
> Also, the IN predicate with parameter list applies to DTO projections or
> native queries, so it's useful to have it.
>
> Vlad
>
> On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero <andrea at hibernate.org>
> wrote:
>
>> I am also not able to figure out another use case than the IN predicate so
>> I am for always considering IN predicates as multi-valued.
>>
>> On 9 September 2016 at 14:20, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> > To be clear, this is the feature that lets you define a query like:
>> >
>> > select ... from Person p where p.name in (:names)
>> >
>> > And then bind varied multiple values into that single parameter holder:
>> >
>> > query.setParameterList( "names", new String[] { "Larry", "Curly", "Moe"
>> }
>> > );
>> > query.setParameterList( "names", new String[] { "John", "Jane" } );
>> >
>> > Which magically transforms to the following (rough) SQL:
>> >
>> > select ... from PERSON p where p.name in (?, ?, ?)
>> > select ... from PERSON p where p.name in (?, ?)
>> >
>> > Effectively parameter lists allow expansion of the HQL statement - they
>> > literally are handled by altering the HQL on the fly as we prepare to
>> > execute the query.  What that means is that we can really not cache
>> these
>> > queries, at least not until the parameters are bound (which kind of
>> defeats
>> > the purpose).
>> >
>> > I'd like to discuss dropping support for parameter lists.  There are
>> quite
>> > a few reasons I would like to drop this support:
>> >
>> >    1. This is the main culprit that leads to the ever-resurrecting
>> >    discussion about DB limits on IN clauses.  The one valid use case I
>> saw
>> > for
>> >    that lead me to add multi-load support in 5.1.
>> >    2. In terms of a QueryPlan cache, this support means we can never
>> >    effectively cache the plans for these queries because the SQL is
>> > different
>> >    every time we execute the query.  The problem though is that we do
>> not
>> > know
>> >    this until well after the point that we'd resolve the QueryPlan.
>> >     chicken-egg.
>> >    3. This is more an internal detail, but handling the parameter
>> bindings
>> >    for these differently gets quite complicated.
>> >    4. An additional internal detail is that re-writing the HQL on the
>> fly
>> >    is problematic.  And some of that leaks to the user in terms of
>> result
>> >    caching and stats (which HQL do we use?).
>> >
>> > I get that this can be a useful feature for apps that dynamically build
>> > HQL, although really for dynamic query building I think a criteria
>> approach
>> > is more appropriate.  It is not so much supporting this feature that
>> bugs
>> > me, it's how we expose it.  So an alternative to dropping this support
>> > would be to support it in a different way.  The main issue is that I
>> would
>> > like to *syntactically* understanding that a parameter placeholder will
>> be
>> > used for multi-valued parameter from the query itself.  This is a
>> > beyond-JPA feature, so we definitely have some leeway here to define
>> this
>> > however we want.
>> >
>> > I am open to suggestions as to the best syntax to declare that.
>> >
>> > An alternative would be to make some assumptions.  Specifically, the
>> only
>> > time I can think this is used is inside an IN predicate.  Am I missing
>> > others?  If that is the case, we could simply assume that a IN predicate
>> > with a single parameter placeholder is going to be a multivalued
>> > parameter.  That assumption holds valid even if just a single value is
>> > bound.  The main win there is that we can get rid of the
>> > Query#setParameterList
>> > variants.  setParameterList was only ever needed so that we could
>> > understand that the parameter is multivalued - here we'd assume that
>> from
>> > its context as the IN predicate value.
>> >
>> > Continuing to support parameters-lists in any form does not really
>> > address point
>> > (1) above; but that's ok - the user really could , But each of the
>> > alternatives does help with the other problems currently stemming from
>> > parameter-list support.
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Fri Sep  9 16:30:43 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 09 Sep 2016 20:30:43 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
Message-ID: <CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>

BTW, JPA really requires that we support accepting multi-valued bindings
for parameters through #setParameter.  Yet another reason to do away with
#setParameterList.


On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole <steve at hibernate.org> wrote:

> WRT the "collection_valued_input_parameter" bit, that is limited in the
> spec to IN clauses.  And more specifically in fact the spec specifically
> limits this in *exactly* the way I suggested :)
>
> <quote>
> in_expression ::=
>         {state_valued_path_expression | type_discriminator} [ NOT ] IN
>             { ( in_item { , in_item}* ) | ( subquery ) |
> collection_valued_input_parameter }
>
> in_item ::= literal | single_valued_input_parameter
> </quote>
>
> (see "4.6.9 In Expressions" or "4.14 BNF")
>
> In other words, the "values" of an IN expression may be *one of* the
> following:
>
>    1. an explicit list of "in-items", which in turn are specifically
>    single values
>    2. a subquery
>    3. a *single* multivalued param (one placeholder to rule them all)
>
>
> As I said in my original email:
>
> <quote>
>  we could simply assume that a IN predicate with a single parameter
> placeholder is going to be a multivalued parameter
> </quote>
>
> That's what JPA supports for multi-valued parameters.  Hibernate has long
> supported a broader definition of "collection_valued_input_parameter".  I
> am simply suggesting that we align with the limitation JPA already has in
> place.
>
> Really, the only thing I am really asking about is the overloaded forms of
> Query#setParameterList.  We have to support multi-valued parameters *in
> this very limited* case.  Sure.  The problem with our existing
> broader/open-ended multi-valued param support is that we do not know that a
> parameter is multi-valued *from the query* itself.  Specifically we have
> to wait and see if #setParameter or #setParameterList is called, on any of
> the parameters.
>
> Again, the "win" is that we could then know *up front* that a query is not
> cacheable (precompile-able), whereas today we have to wait until just
> before the execution (so that #setParameter and #setParameterList have all
> been called).
>
>
> @Vlad It depends what "query cannot be precompiled" *means* which is of
> course open to interpretation.  Heck what compilation of a query means at
> all is outside the scope of the spec.  Any "compilation" of the query that
> resolves to SQL of course has to wait.  But "compilation" to a semantic
> form (aka, SQM) does not need to wait.  In fact the SQM is the exact place
> you'd look to know whether the query (plan) is cacheable.
>
>
>
> On Fri, Sep 9, 2016 at 8:20 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> I don't think we should deprecate such a feature.
>>
>> First, the JPA specs says the follows:
>>
>> "All input parameters must be single-valued, except in IN expressions
>> (see section 4.6.9), which support
>> the use of collection-valued input parameters."
>>
>> So, we kinda need to support it one way or another.
>>
>> Also, the JPA specs says that:
>>
>> "Note that use of a collection-valued input parameter will mean that a
>> static query cannot be precompiled."
>>
>> So, it's expected to have such a behavior.
>>
>> I don't think that multi-load support can replace paremeterList since the
>> former cannot use any property from a given entity.
>> Also, the IN predicate with parameter list applies to DTO projections or
>> native queries, so it's useful to have it.
>>
>> Vlad
>>
>> On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero <andrea at hibernate.org>
>> wrote:
>>
>>> I am also not able to figure out another use case than the IN predicate
>>> so
>>> I am for always considering IN predicates as multi-valued.
>>>
>>> On 9 September 2016 at 14:20, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>> > To be clear, this is the feature that lets you define a query like:
>>> >
>>> > select ... from Person p where p.name in (:names)
>>> >
>>> > And then bind varied multiple values into that single parameter holder:
>>> >
>>> > query.setParameterList( "names", new String[] { "Larry", "Curly",
>>> "Moe" }
>>> > );
>>> > query.setParameterList( "names", new String[] { "John", "Jane" } );
>>> >
>>> > Which magically transforms to the following (rough) SQL:
>>> >
>>> > select ... from PERSON p where p.name in (?, ?, ?)
>>> > select ... from PERSON p where p.name in (?, ?)
>>> >
>>> > Effectively parameter lists allow expansion of the HQL statement - they
>>> > literally are handled by altering the HQL on the fly as we prepare to
>>> > execute the query.  What that means is that we can really not cache
>>> these
>>> > queries, at least not until the parameters are bound (which kind of
>>> defeats
>>> > the purpose).
>>> >
>>> > I'd like to discuss dropping support for parameter lists.  There are
>>> quite
>>> > a few reasons I would like to drop this support:
>>> >
>>> >    1. This is the main culprit that leads to the ever-resurrecting
>>> >    discussion about DB limits on IN clauses.  The one valid use case I
>>> saw
>>> > for
>>> >    that lead me to add multi-load support in 5.1.
>>> >    2. In terms of a QueryPlan cache, this support means we can never
>>> >    effectively cache the plans for these queries because the SQL is
>>> > different
>>> >    every time we execute the query.  The problem though is that we do
>>> not
>>> > know
>>> >    this until well after the point that we'd resolve the QueryPlan.
>>> >     chicken-egg.
>>> >    3. This is more an internal detail, but handling the parameter
>>> bindings
>>> >    for these differently gets quite complicated.
>>> >    4. An additional internal detail is that re-writing the HQL on the
>>> fly
>>> >    is problematic.  And some of that leaks to the user in terms of
>>> result
>>> >    caching and stats (which HQL do we use?).
>>> >
>>> > I get that this can be a useful feature for apps that dynamically build
>>> > HQL, although really for dynamic query building I think a criteria
>>> approach
>>> > is more appropriate.  It is not so much supporting this feature that
>>> bugs
>>> > me, it's how we expose it.  So an alternative to dropping this support
>>> > would be to support it in a different way.  The main issue is that I
>>> would
>>> > like to *syntactically* understanding that a parameter placeholder
>>> will be
>>> > used for multi-valued parameter from the query itself.  This is a
>>> > beyond-JPA feature, so we definitely have some leeway here to define
>>> this
>>> > however we want.
>>> >
>>> > I am open to suggestions as to the best syntax to declare that.
>>> >
>>> > An alternative would be to make some assumptions.  Specifically, the
>>> only
>>> > time I can think this is used is inside an IN predicate.  Am I missing
>>> > others?  If that is the case, we could simply assume that a IN
>>> predicate
>>> > with a single parameter placeholder is going to be a multivalued
>>> > parameter.  That assumption holds valid even if just a single value is
>>> > bound.  The main win there is that we can get rid of the
>>> > Query#setParameterList
>>> > variants.  setParameterList was only ever needed so that we could
>>> > understand that the parameter is multivalued - here we'd assume that
>>> from
>>> > its context as the IN predicate value.
>>> >
>>> > Continuing to support parameters-lists in any form does not really
>>> > address point
>>> > (1) above; but that's ok - the user really could , But each of the
>>> > alternatives does help with the other problems currently stemming from
>>> > parameter-list support.
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>

From christian.beikov at gmail.com  Fri Sep  9 17:12:56 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 9 Sep 2016 23:12:56 +0200
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
Message-ID: <df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>

Ah ok, I thought you wanted to drop parameter lists in general ^^
I suppose you are discussing this because of 
https://hibernate.atlassian.net/browse/HHH-10502?

I personally don't have a use case for a general parameter list 
expansion like the reporter of that issue and I also don't think that 
people are directly writing that kind of stuff into a query, but a 
wrapper does. All in all, I think people will be able to workaround if 
you remove the parameter list expansion for other places. Is this such a 
problem to keep around that feature?

Would be interesting to see how other people make use of that feature. 
If everyone uses such collection valued parameters at least for an IN 
predicate and maybe additionally for something else like that FIELD 
function, you would have to wait for the parameter list anyway.

Query caching can generally be handled if you introduce a configuration 
parameter for a fixed expansion size, but that would probably be even 
more work because then you would have to exectue the query multiple times.

I just don't think that removing this feature will bring any benefits.

Regards,
Christian

Am 09.09.2016 um 22:30 schrieb Steve Ebersole:
> BTW, JPA really requires that we support accepting multi-valued bindings
> for parameters through #setParameter.  Yet another reason to do away with
> #setParameterList.
>
>
> On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> WRT the "collection_valued_input_parameter" bit, that is limited in the
>> spec to IN clauses.  And more specifically in fact the spec specifically
>> limits this in *exactly* the way I suggested :)
>>
>> <quote>
>> in_expression ::=
>>          {state_valued_path_expression | type_discriminator} [ NOT ] IN
>>              { ( in_item { , in_item}* ) | ( subquery ) |
>> collection_valued_input_parameter }
>>
>> in_item ::= literal | single_valued_input_parameter
>> </quote>
>>
>> (see "4.6.9 In Expressions" or "4.14 BNF")
>>
>> In other words, the "values" of an IN expression may be *one of* the
>> following:
>>
>>     1. an explicit list of "in-items", which in turn are specifically
>>     single values
>>     2. a subquery
>>     3. a *single* multivalued param (one placeholder to rule them all)
>>
>>
>> As I said in my original email:
>>
>> <quote>
>>   we could simply assume that a IN predicate with a single parameter
>> placeholder is going to be a multivalued parameter
>> </quote>
>>
>> That's what JPA supports for multi-valued parameters.  Hibernate has long
>> supported a broader definition of "collection_valued_input_parameter".  I
>> am simply suggesting that we align with the limitation JPA already has in
>> place.
>>
>> Really, the only thing I am really asking about is the overloaded forms of
>> Query#setParameterList.  We have to support multi-valued parameters *in
>> this very limited* case.  Sure.  The problem with our existing
>> broader/open-ended multi-valued param support is that we do not know that a
>> parameter is multi-valued *from the query* itself.  Specifically we have
>> to wait and see if #setParameter or #setParameterList is called, on any of
>> the parameters.
>>
>> Again, the "win" is that we could then know *up front* that a query is not
>> cacheable (precompile-able), whereas today we have to wait until just
>> before the execution (so that #setParameter and #setParameterList have all
>> been called).
>>
>>
>> @Vlad It depends what "query cannot be precompiled" *means* which is of
>> course open to interpretation.  Heck what compilation of a query means at
>> all is outside the scope of the spec.  Any "compilation" of the query that
>> resolves to SQL of course has to wait.  But "compilation" to a semantic
>> form (aka, SQM) does not need to wait.  In fact the SQM is the exact place
>> you'd look to know whether the query (plan) is cacheable.
>>
>>
>>
>> On Fri, Sep 9, 2016 at 8:20 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I don't think we should deprecate such a feature.
>>>
>>> First, the JPA specs says the follows:
>>>
>>> "All input parameters must be single-valued, except in IN expressions
>>> (see section 4.6.9), which support
>>> the use of collection-valued input parameters."
>>>
>>> So, we kinda need to support it one way or another.
>>>
>>> Also, the JPA specs says that:
>>>
>>> "Note that use of a collection-valued input parameter will mean that a
>>> static query cannot be precompiled."
>>>
>>> So, it's expected to have such a behavior.
>>>
>>> I don't think that multi-load support can replace paremeterList since the
>>> former cannot use any property from a given entity.
>>> Also, the IN predicate with parameter list applies to DTO projections or
>>> native queries, so it's useful to have it.
>>>
>>> Vlad
>>>
>>> On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero <andrea at hibernate.org>
>>> wrote:
>>>
>>>> I am also not able to figure out another use case than the IN predicate
>>>> so
>>>> I am for always considering IN predicates as multi-valued.
>>>>
>>>> On 9 September 2016 at 14:20, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> To be clear, this is the feature that lets you define a query like:
>>>>>
>>>>> select ... from Person p where p.name in (:names)
>>>>>
>>>>> And then bind varied multiple values into that single parameter holder:
>>>>>
>>>>> query.setParameterList( "names", new String[] { "Larry", "Curly",
>>>> "Moe" }
>>>>> );
>>>>> query.setParameterList( "names", new String[] { "John", "Jane" } );
>>>>>
>>>>> Which magically transforms to the following (rough) SQL:
>>>>>
>>>>> select ... from PERSON p where p.name in (?, ?, ?)
>>>>> select ... from PERSON p where p.name in (?, ?)
>>>>>
>>>>> Effectively parameter lists allow expansion of the HQL statement - they
>>>>> literally are handled by altering the HQL on the fly as we prepare to
>>>>> execute the query.  What that means is that we can really not cache
>>>> these
>>>>> queries, at least not until the parameters are bound (which kind of
>>>> defeats
>>>>> the purpose).
>>>>>
>>>>> I'd like to discuss dropping support for parameter lists.  There are
>>>> quite
>>>>> a few reasons I would like to drop this support:
>>>>>
>>>>>     1. This is the main culprit that leads to the ever-resurrecting
>>>>>     discussion about DB limits on IN clauses.  The one valid use case I
>>>> saw
>>>>> for
>>>>>     that lead me to add multi-load support in 5.1.
>>>>>     2. In terms of a QueryPlan cache, this support means we can never
>>>>>     effectively cache the plans for these queries because the SQL is
>>>>> different
>>>>>     every time we execute the query.  The problem though is that we do
>>>> not
>>>>> know
>>>>>     this until well after the point that we'd resolve the QueryPlan.
>>>>>      chicken-egg.
>>>>>     3. This is more an internal detail, but handling the parameter
>>>> bindings
>>>>>     for these differently gets quite complicated.
>>>>>     4. An additional internal detail is that re-writing the HQL on the
>>>> fly
>>>>>     is problematic.  And some of that leaks to the user in terms of
>>>> result
>>>>>     caching and stats (which HQL do we use?).
>>>>>
>>>>> I get that this can be a useful feature for apps that dynamically build
>>>>> HQL, although really for dynamic query building I think a criteria
>>>> approach
>>>>> is more appropriate.  It is not so much supporting this feature that
>>>> bugs
>>>>> me, it's how we expose it.  So an alternative to dropping this support
>>>>> would be to support it in a different way.  The main issue is that I
>>>> would
>>>>> like to *syntactically* understanding that a parameter placeholder
>>>> will be
>>>>> used for multi-valued parameter from the query itself.  This is a
>>>>> beyond-JPA feature, so we definitely have some leeway here to define
>>>> this
>>>>> however we want.
>>>>>
>>>>> I am open to suggestions as to the best syntax to declare that.
>>>>>
>>>>> An alternative would be to make some assumptions.  Specifically, the
>>>> only
>>>>> time I can think this is used is inside an IN predicate.  Am I missing
>>>>> others?  If that is the case, we could simply assume that a IN
>>>> predicate
>>>>> with a single parameter placeholder is going to be a multivalued
>>>>> parameter.  That assumption holds valid even if just a single value is
>>>>> bound.  The main win there is that we can get rid of the
>>>>> Query#setParameterList
>>>>> variants.  setParameterList was only ever needed so that we could
>>>>> understand that the parameter is multivalued - here we'd assume that
>>>> from
>>>>> its context as the IN predicate value.
>>>>>
>>>>> Continuing to support parameters-lists in any form does not really
>>>>> address point
>>>>> (1) above; but that's ok - the user really could , But each of the
>>>>> alternatives does help with the other problems currently stemming from
>>>>> parameter-list support.
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Fri Sep  9 17:35:50 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 09 Sep 2016 21:35:50 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
Message-ID: <CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>

Not any particular reason, HHH-10502 or otherwise.  Its more a general
question as I am integrating SQM and the new query translators upstream.

Again, I think y'all are missing the point.  The concern is not whether a
query is cacheable or not.  The concern is *when* I know whether it is
cacheable.

Consider some psuedo-code.  First, the ideal case:

SessionImpl#createQuery(...) {
    ...

    // interpret the query into SQM
    SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);

    QueryPlan queryPlan;
    if ( isCacheable( sqm ) ) {
        queryPlan = queryPlanCache.get( ... );
        if ( queryPlan == null ) {
            queryPlan = new QueryPlan( ... );
            queryPlanCache.put( ..., queryPlan );
        }
    }
    else {
        queryPlan = new QueryPlan( ... );
    }

    return new QueryImpl( sqm, queryPlan, this );
}

versus:

SessionImpl#createQuery(...) {
    ...

    // interpret the query into SQM
    SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);

    // now we have to delay creation of the QueryPlan until later
    // because we do not know if the query is cacheable, because
    // we do not know yet whether it contains any multi-valued
    // parameters.

    return new QueryImpl( sqm, this );
}



On Fri, Sep 9, 2016 at 4:17 PM Christian Beikov <christian.beikov at gmail.com>
wrote:

> Ah ok, I thought you wanted to drop parameter lists in general ^^
> I suppose you are discussing this because of
> https://hibernate.atlassian.net/browse/HHH-10502?
>
> I personally don't have a use case for a general parameter list
> expansion like the reporter of that issue and I also don't think that
> people are directly writing that kind of stuff into a query, but a
> wrapper does. All in all, I think people will be able to workaround if
> you remove the parameter list expansion for other places. Is this such a
> problem to keep around that feature?
>
> Would be interesting to see how other people make use of that feature.
> If everyone uses such collection valued parameters at least for an IN
> predicate and maybe additionally for something else like that FIELD
> function, you would have to wait for the parameter list anyway.
>
> Query caching can generally be handled if you introduce a configuration
> parameter for a fixed expansion size, but that would probably be even
> more work because then you would have to exectue the query multiple times.
>
> I just don't think that removing this feature will bring any benefits.
>
> Regards,
> Christian
>
> Am 09.09.2016 um 22:30 schrieb Steve Ebersole:
> > BTW, JPA really requires that we support accepting multi-valued bindings
> > for parameters through #setParameter.  Yet another reason to do away with
> > #setParameterList.
> >
> >
> > On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> WRT the "collection_valued_input_parameter" bit, that is limited in the
> >> spec to IN clauses.  And more specifically in fact the spec specifically
> >> limits this in *exactly* the way I suggested :)
> >>
> >> <quote>
> >> in_expression ::=
> >>          {state_valued_path_expression | type_discriminator} [ NOT ] IN
> >>              { ( in_item { , in_item}* ) | ( subquery ) |
> >> collection_valued_input_parameter }
> >>
> >> in_item ::= literal | single_valued_input_parameter
> >> </quote>
> >>
> >> (see "4.6.9 In Expressions" or "4.14 BNF")
> >>
> >> In other words, the "values" of an IN expression may be *one of* the
> >> following:
> >>
> >>     1. an explicit list of "in-items", which in turn are specifically
> >>     single values
> >>     2. a subquery
> >>     3. a *single* multivalued param (one placeholder to rule them all)
> >>
> >>
> >> As I said in my original email:
> >>
> >> <quote>
> >>   we could simply assume that a IN predicate with a single parameter
> >> placeholder is going to be a multivalued parameter
> >> </quote>
> >>
> >> That's what JPA supports for multi-valued parameters.  Hibernate has
> long
> >> supported a broader definition of "collection_valued_input_parameter".
> I
> >> am simply suggesting that we align with the limitation JPA already has
> in
> >> place.
> >>
> >> Really, the only thing I am really asking about is the overloaded forms
> of
> >> Query#setParameterList.  We have to support multi-valued parameters *in
> >> this very limited* case.  Sure.  The problem with our existing
> >> broader/open-ended multi-valued param support is that we do not know
> that a
> >> parameter is multi-valued *from the query* itself.  Specifically we have
> >> to wait and see if #setParameter or #setParameterList is called, on any
> of
> >> the parameters.
> >>
> >> Again, the "win" is that we could then know *up front* that a query is
> not
> >> cacheable (precompile-able), whereas today we have to wait until just
> >> before the execution (so that #setParameter and #setParameterList have
> all
> >> been called).
> >>
> >>
> >> @Vlad It depends what "query cannot be precompiled" *means* which is of
> >> course open to interpretation.  Heck what compilation of a query means
> at
> >> all is outside the scope of the spec.  Any "compilation" of the query
> that
> >> resolves to SQL of course has to wait.  But "compilation" to a semantic
> >> form (aka, SQM) does not need to wait.  In fact the SQM is the exact
> place
> >> you'd look to know whether the query (plan) is cacheable.
> >>
> >>
> >>
> >> On Fri, Sep 9, 2016 at 8:20 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> I don't think we should deprecate such a feature.
> >>>
> >>> First, the JPA specs says the follows:
> >>>
> >>> "All input parameters must be single-valued, except in IN expressions
> >>> (see section 4.6.9), which support
> >>> the use of collection-valued input parameters."
> >>>
> >>> So, we kinda need to support it one way or another.
> >>>
> >>> Also, the JPA specs says that:
> >>>
> >>> "Note that use of a collection-valued input parameter will mean that a
> >>> static query cannot be precompiled."
> >>>
> >>> So, it's expected to have such a behavior.
> >>>
> >>> I don't think that multi-load support can replace paremeterList since
> the
> >>> former cannot use any property from a given entity.
> >>> Also, the IN predicate with parameter list applies to DTO projections
> or
> >>> native queries, so it's useful to have it.
> >>>
> >>> Vlad
> >>>
> >>> On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero <andrea at hibernate.org>
> >>> wrote:
> >>>
> >>>> I am also not able to figure out another use case than the IN
> predicate
> >>>> so
> >>>> I am for always considering IN predicates as multi-valued.
> >>>>
> >>>> On 9 September 2016 at 14:20, Steve Ebersole <steve at hibernate.org>
> >>>> wrote:
> >>>>
> >>>>> To be clear, this is the feature that lets you define a query like:
> >>>>>
> >>>>> select ... from Person p where p.name in (:names)
> >>>>>
> >>>>> And then bind varied multiple values into that single parameter
> holder:
> >>>>>
> >>>>> query.setParameterList( "names", new String[] { "Larry", "Curly",
> >>>> "Moe" }
> >>>>> );
> >>>>> query.setParameterList( "names", new String[] { "John", "Jane" } );
> >>>>>
> >>>>> Which magically transforms to the following (rough) SQL:
> >>>>>
> >>>>> select ... from PERSON p where p.name in (?, ?, ?)
> >>>>> select ... from PERSON p where p.name in (?, ?)
> >>>>>
> >>>>> Effectively parameter lists allow expansion of the HQL statement -
> they
> >>>>> literally are handled by altering the HQL on the fly as we prepare to
> >>>>> execute the query.  What that means is that we can really not cache
> >>>> these
> >>>>> queries, at least not until the parameters are bound (which kind of
> >>>> defeats
> >>>>> the purpose).
> >>>>>
> >>>>> I'd like to discuss dropping support for parameter lists.  There are
> >>>> quite
> >>>>> a few reasons I would like to drop this support:
> >>>>>
> >>>>>     1. This is the main culprit that leads to the ever-resurrecting
> >>>>>     discussion about DB limits on IN clauses.  The one valid use
> case I
> >>>> saw
> >>>>> for
> >>>>>     that lead me to add multi-load support in 5.1.
> >>>>>     2. In terms of a QueryPlan cache, this support means we can never
> >>>>>     effectively cache the plans for these queries because the SQL is
> >>>>> different
> >>>>>     every time we execute the query.  The problem though is that we
> do
> >>>> not
> >>>>> know
> >>>>>     this until well after the point that we'd resolve the QueryPlan.
> >>>>>      chicken-egg.
> >>>>>     3. This is more an internal detail, but handling the parameter
> >>>> bindings
> >>>>>     for these differently gets quite complicated.
> >>>>>     4. An additional internal detail is that re-writing the HQL on
> the
> >>>> fly
> >>>>>     is problematic.  And some of that leaks to the user in terms of
> >>>> result
> >>>>>     caching and stats (which HQL do we use?).
> >>>>>
> >>>>> I get that this can be a useful feature for apps that dynamically
> build
> >>>>> HQL, although really for dynamic query building I think a criteria
> >>>> approach
> >>>>> is more appropriate.  It is not so much supporting this feature that
> >>>> bugs
> >>>>> me, it's how we expose it.  So an alternative to dropping this
> support
> >>>>> would be to support it in a different way.  The main issue is that I
> >>>> would
> >>>>> like to *syntactically* understanding that a parameter placeholder
> >>>> will be
> >>>>> used for multi-valued parameter from the query itself.  This is a
> >>>>> beyond-JPA feature, so we definitely have some leeway here to define
> >>>> this
> >>>>> however we want.
> >>>>>
> >>>>> I am open to suggestions as to the best syntax to declare that.
> >>>>>
> >>>>> An alternative would be to make some assumptions.  Specifically, the
> >>>> only
> >>>>> time I can think this is used is inside an IN predicate.  Am I
> missing
> >>>>> others?  If that is the case, we could simply assume that a IN
> >>>> predicate
> >>>>> with a single parameter placeholder is going to be a multivalued
> >>>>> parameter.  That assumption holds valid even if just a single value
> is
> >>>>> bound.  The main win there is that we can get rid of the
> >>>>> Query#setParameterList
> >>>>> variants.  setParameterList was only ever needed so that we could
> >>>>> understand that the parameter is multivalued - here we'd assume that
> >>>> from
> >>>>> its context as the IN predicate value.
> >>>>>
> >>>>> Continuing to support parameters-lists in any form does not really
> >>>>> address point
> >>>>> (1) above; but that's ok - the user really could , But each of the
> >>>>> alternatives does help with the other problems currently stemming
> from
> >>>>> parameter-list support.
> >>>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Sep  9 17:39:30 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 09 Sep 2016 21:39:30 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
Message-ID: <CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>

Although, thinking about it some more, SQM itself already exposes some of
the things QueryPlan does today.  So maybe this is not such a big issue.

I personally am just not a fan of not understanding the semantic of a query
up front.  Good translation in part comes down to good design of the
language so that as much semantic as possible is available statically (from
the Query itself, and from Session/SessionFactory).


On Fri, Sep 9, 2016 at 4:35 PM Steve Ebersole <steve at hibernate.org> wrote:

> Not any particular reason, HHH-10502 or otherwise.  Its more a general
> question as I am integrating SQM and the new query translators upstream.
>
> Again, I think y'all are missing the point.  The concern is not whether a
> query is cacheable or not.  The concern is *when* I know whether it is
> cacheable.
>
> Consider some psuedo-code.  First, the ideal case:
>
> SessionImpl#createQuery(...) {
>     ...
>
>     // interpret the query into SQM
>     SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);
>
>     QueryPlan queryPlan;
>     if ( isCacheable( sqm ) ) {
>         queryPlan = queryPlanCache.get( ... );
>         if ( queryPlan == null ) {
>             queryPlan = new QueryPlan( ... );
>             queryPlanCache.put( ..., queryPlan );
>         }
>     }
>     else {
>         queryPlan = new QueryPlan( ... );
>     }
>
>     return new QueryImpl( sqm, queryPlan, this );
> }
>
> versus:
>
> SessionImpl#createQuery(...) {
>     ...
>
>     // interpret the query into SQM
>     SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);
>
>     // now we have to delay creation of the QueryPlan until later
>     // because we do not know if the query is cacheable, because
>     // we do not know yet whether it contains any multi-valued
>     // parameters.
>
>     return new QueryImpl( sqm, this );
> }
>
>
>
> On Fri, Sep 9, 2016 at 4:17 PM Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
>> Ah ok, I thought you wanted to drop parameter lists in general ^^
>> I suppose you are discussing this because of
>> https://hibernate.atlassian.net/browse/HHH-10502?
>>
>> I personally don't have a use case for a general parameter list
>> expansion like the reporter of that issue and I also don't think that
>> people are directly writing that kind of stuff into a query, but a
>> wrapper does. All in all, I think people will be able to workaround if
>> you remove the parameter list expansion for other places. Is this such a
>> problem to keep around that feature?
>>
>> Would be interesting to see how other people make use of that feature.
>> If everyone uses such collection valued parameters at least for an IN
>> predicate and maybe additionally for something else like that FIELD
>> function, you would have to wait for the parameter list anyway.
>>
>> Query caching can generally be handled if you introduce a configuration
>> parameter for a fixed expansion size, but that would probably be even
>> more work because then you would have to exectue the query multiple times.
>>
>> I just don't think that removing this feature will bring any benefits.
>>
>> Regards,
>> Christian
>>
>> Am 09.09.2016 um 22:30 schrieb Steve Ebersole:
>> > BTW, JPA really requires that we support accepting multi-valued bindings
>> > for parameters through #setParameter.  Yet another reason to do away
>> with
>> > #setParameterList.
>> >
>> >
>> > On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> WRT the "collection_valued_input_parameter" bit, that is limited in the
>> >> spec to IN clauses.  And more specifically in fact the spec
>> specifically
>> >> limits this in *exactly* the way I suggested :)
>> >>
>> >> <quote>
>> >> in_expression ::=
>> >>          {state_valued_path_expression | type_discriminator} [ NOT ] IN
>> >>              { ( in_item { , in_item}* ) | ( subquery ) |
>> >> collection_valued_input_parameter }
>> >>
>> >> in_item ::= literal | single_valued_input_parameter
>> >> </quote>
>> >>
>> >> (see "4.6.9 In Expressions" or "4.14 BNF")
>> >>
>> >> In other words, the "values" of an IN expression may be *one of* the
>> >> following:
>> >>
>> >>     1. an explicit list of "in-items", which in turn are specifically
>> >>     single values
>> >>     2. a subquery
>> >>     3. a *single* multivalued param (one placeholder to rule them all)
>> >>
>> >>
>> >> As I said in my original email:
>> >>
>> >> <quote>
>> >>   we could simply assume that a IN predicate with a single parameter
>> >> placeholder is going to be a multivalued parameter
>> >> </quote>
>> >>
>> >> That's what JPA supports for multi-valued parameters.  Hibernate has
>> long
>> >> supported a broader definition of
>> "collection_valued_input_parameter".  I
>> >> am simply suggesting that we align with the limitation JPA already has
>> in
>> >> place.
>> >>
>> >> Really, the only thing I am really asking about is the overloaded
>> forms of
>> >> Query#setParameterList.  We have to support multi-valued parameters *in
>> >> this very limited* case.  Sure.  The problem with our existing
>> >> broader/open-ended multi-valued param support is that we do not know
>> that a
>> >> parameter is multi-valued *from the query* itself.  Specifically we
>> have
>> >> to wait and see if #setParameter or #setParameterList is called, on
>> any of
>> >> the parameters.
>> >>
>> >> Again, the "win" is that we could then know *up front* that a query is
>> not
>> >> cacheable (precompile-able), whereas today we have to wait until just
>> >> before the execution (so that #setParameter and #setParameterList have
>> all
>> >> been called).
>> >>
>> >>
>> >> @Vlad It depends what "query cannot be precompiled" *means* which is of
>> >> course open to interpretation.  Heck what compilation of a query means
>> at
>> >> all is outside the scope of the spec.  Any "compilation" of the query
>> that
>> >> resolves to SQL of course has to wait.  But "compilation" to a semantic
>> >> form (aka, SQM) does not need to wait.  In fact the SQM is the exact
>> place
>> >> you'd look to know whether the query (plan) is cacheable.
>> >>
>> >>
>> >>
>> >> On Fri, Sep 9, 2016 at 8:20 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> >> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I don't think we should deprecate such a feature.
>> >>>
>> >>> First, the JPA specs says the follows:
>> >>>
>> >>> "All input parameters must be single-valued, except in IN expressions
>> >>> (see section 4.6.9), which support
>> >>> the use of collection-valued input parameters."
>> >>>
>> >>> So, we kinda need to support it one way or another.
>> >>>
>> >>> Also, the JPA specs says that:
>> >>>
>> >>> "Note that use of a collection-valued input parameter will mean that a
>> >>> static query cannot be precompiled."
>> >>>
>> >>> So, it's expected to have such a behavior.
>> >>>
>> >>> I don't think that multi-load support can replace paremeterList since
>> the
>> >>> former cannot use any property from a given entity.
>> >>> Also, the IN predicate with parameter list applies to DTO projections
>> or
>> >>> native queries, so it's useful to have it.
>> >>>
>> >>> Vlad
>> >>>
>> >>> On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero <andrea at hibernate.org>
>> >>> wrote:
>> >>>
>> >>>> I am also not able to figure out another use case than the IN
>> predicate
>> >>>> so
>> >>>> I am for always considering IN predicates as multi-valued.
>> >>>>
>> >>>> On 9 September 2016 at 14:20, Steve Ebersole <steve at hibernate.org>
>> >>>> wrote:
>> >>>>
>> >>>>> To be clear, this is the feature that lets you define a query like:
>> >>>>>
>> >>>>> select ... from Person p where p.name in (:names)
>> >>>>>
>> >>>>> And then bind varied multiple values into that single parameter
>> holder:
>> >>>>>
>> >>>>> query.setParameterList( "names", new String[] { "Larry", "Curly",
>> >>>> "Moe" }
>> >>>>> );
>> >>>>> query.setParameterList( "names", new String[] { "John", "Jane" } );
>> >>>>>
>> >>>>> Which magically transforms to the following (rough) SQL:
>> >>>>>
>> >>>>> select ... from PERSON p where p.name in (?, ?, ?)
>> >>>>> select ... from PERSON p where p.name in (?, ?)
>> >>>>>
>> >>>>> Effectively parameter lists allow expansion of the HQL statement -
>> they
>> >>>>> literally are handled by altering the HQL on the fly as we prepare
>> to
>> >>>>> execute the query.  What that means is that we can really not cache
>> >>>> these
>> >>>>> queries, at least not until the parameters are bound (which kind of
>> >>>> defeats
>> >>>>> the purpose).
>> >>>>>
>> >>>>> I'd like to discuss dropping support for parameter lists.  There are
>> >>>> quite
>> >>>>> a few reasons I would like to drop this support:
>> >>>>>
>> >>>>>     1. This is the main culprit that leads to the ever-resurrecting
>> >>>>>     discussion about DB limits on IN clauses.  The one valid use
>> case I
>> >>>> saw
>> >>>>> for
>> >>>>>     that lead me to add multi-load support in 5.1.
>> >>>>>     2. In terms of a QueryPlan cache, this support means we can
>> never
>> >>>>>     effectively cache the plans for these queries because the SQL is
>> >>>>> different
>> >>>>>     every time we execute the query.  The problem though is that we
>> do
>> >>>> not
>> >>>>> know
>> >>>>>     this until well after the point that we'd resolve the QueryPlan.
>> >>>>>      chicken-egg.
>> >>>>>     3. This is more an internal detail, but handling the parameter
>> >>>> bindings
>> >>>>>     for these differently gets quite complicated.
>> >>>>>     4. An additional internal detail is that re-writing the HQL on
>> the
>> >>>> fly
>> >>>>>     is problematic.  And some of that leaks to the user in terms of
>> >>>> result
>> >>>>>     caching and stats (which HQL do we use?).
>> >>>>>
>> >>>>> I get that this can be a useful feature for apps that dynamically
>> build
>> >>>>> HQL, although really for dynamic query building I think a criteria
>> >>>> approach
>> >>>>> is more appropriate.  It is not so much supporting this feature that
>> >>>> bugs
>> >>>>> me, it's how we expose it.  So an alternative to dropping this
>> support
>> >>>>> would be to support it in a different way.  The main issue is that I
>> >>>> would
>> >>>>> like to *syntactically* understanding that a parameter placeholder
>> >>>> will be
>> >>>>> used for multi-valued parameter from the query itself.  This is a
>> >>>>> beyond-JPA feature, so we definitely have some leeway here to define
>> >>>> this
>> >>>>> however we want.
>> >>>>>
>> >>>>> I am open to suggestions as to the best syntax to declare that.
>> >>>>>
>> >>>>> An alternative would be to make some assumptions.  Specifically, the
>> >>>> only
>> >>>>> time I can think this is used is inside an IN predicate.  Am I
>> missing
>> >>>>> others?  If that is the case, we could simply assume that a IN
>> >>>> predicate
>> >>>>> with a single parameter placeholder is going to be a multivalued
>> >>>>> parameter.  That assumption holds valid even if just a single value
>> is
>> >>>>> bound.  The main win there is that we can get rid of the
>> >>>>> Query#setParameterList
>> >>>>> variants.  setParameterList was only ever needed so that we could
>> >>>>> understand that the parameter is multivalued - here we'd assume that
>> >>>> from
>> >>>>> its context as the IN predicate value.
>> >>>>>
>> >>>>> Continuing to support parameters-lists in any form does not really
>> >>>>> address point
>> >>>>> (1) above; but that's ok - the user really could , But each of the
>> >>>>> alternatives does help with the other problems currently stemming
>> from
>> >>>>> parameter-list support.
>> >>>>> _______________________________________________
>> >>>>> hibernate-dev mailing list
>> >>>>> hibernate-dev at lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>>
>> >>>> _______________________________________________
>> >>>> hibernate-dev mailing list
>> >>>> hibernate-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>
>> >>>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From christian.beikov at gmail.com  Fri Sep  9 17:45:03 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 9 Sep 2016 23:45:03 +0200
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
Message-ID: <20d8af87-c78e-11fa-4a09-ad0a75fd7977@gmail.com>

Hmm I think I understand what you mean now. How would you do parameter 
expansion in SQM? Or will the result after a parameter expansion not be 
cached?

Am 09.09.2016 um 23:35 schrieb Steve Ebersole:
> Not any particular reason, HHH-10502 or otherwise. Its more a general 
> question as I am integrating SQM and the new query translators upstream.
>
> Again, I think y'all are missing the point.  The concern is not 
> whether a query is cacheable or not.  The concern is *when* I know 
> whether it is cacheable.
>
> Consider some psuedo-code.  First, the ideal case:
>
> SessionImpl#createQuery(...) {
>     ...
>
>     // interpret the query into SQM
>     SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);
>
>     QueryPlan queryPlan;
>     if ( isCacheable( sqm ) ) {
>         queryPlan = queryPlanCache.get( ... );
>         if ( queryPlan == null ) {
>             queryPlan = new QueryPlan( ... );
> queryPlanCache.put( ..., queryPlan );
>         }
>     }
>     else {
> queryPlan = new QueryPlan( ... );
>   }
>
>   return new QueryImpl( sqm, queryPlan, this );
> }
>
> versus:
>
> SessionImpl#createQuery(...) {
>     ...
>
>     // interpret the query into SQM
>     SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);
>
>     // now we have to delay creation of the QueryPlan until later
>     // because we do not know if the query is cacheable, because
>     // we do not know yet whether it contains any multi-valued
>     // parameters.
>
>   return new QueryImpl( sqm, this );
> }
>
>
>
> On Fri, Sep 9, 2016 at 4:17 PM Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Ah ok, I thought you wanted to drop parameter lists in general ^^
>     I suppose you are discussing this because of
>     https://hibernate.atlassian.net/browse/HHH-10502?
>
>     I personally don't have a use case for a general parameter list
>     expansion like the reporter of that issue and I also don't think that
>     people are directly writing that kind of stuff into a query, but a
>     wrapper does. All in all, I think people will be able to workaround if
>     you remove the parameter list expansion for other places. Is this
>     such a
>     problem to keep around that feature?
>
>     Would be interesting to see how other people make use of that feature.
>     If everyone uses such collection valued parameters at least for an IN
>     predicate and maybe additionally for something else like that FIELD
>     function, you would have to wait for the parameter list anyway.
>
>     Query caching can generally be handled if you introduce a
>     configuration
>     parameter for a fixed expansion size, but that would probably be even
>     more work because then you would have to exectue the query
>     multiple times.
>
>     I just don't think that removing this feature will bring any benefits.
>
>     Regards,
>     Christian
>
>     Am 09.09.2016 um 22:30 schrieb Steve Ebersole:
>     > BTW, JPA really requires that we support accepting multi-valued
>     bindings
>     > for parameters through #setParameter.  Yet another reason to do
>     away with
>     > #setParameterList.
>     >
>     >
>     > On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>     >
>     >> WRT the "collection_valued_input_parameter" bit, that is
>     limited in the
>     >> spec to IN clauses.  And more specifically in fact the spec
>     specifically
>     >> limits this in *exactly* the way I suggested :)
>     >>
>     >> <quote>
>     >> in_expression ::=
>     >>          {state_valued_path_expression | type_discriminator} [
>     NOT ] IN
>     >>              { ( in_item { , in_item}* ) | ( subquery ) |
>     >> collection_valued_input_parameter }
>     >>
>     >> in_item ::= literal | single_valued_input_parameter
>     >> </quote>
>     >>
>     >> (see "4.6.9 In Expressions" or "4.14 BNF")
>     >>
>     >> In other words, the "values" of an IN expression may be *one
>     of* the
>     >> following:
>     >>
>     >>     1. an explicit list of "in-items", which in turn are
>     specifically
>     >>     single values
>     >>     2. a subquery
>     >>     3. a *single* multivalued param (one placeholder to rule
>     them all)
>     >>
>     >>
>     >> As I said in my original email:
>     >>
>     >> <quote>
>     >>   we could simply assume that a IN predicate with a single
>     parameter
>     >> placeholder is going to be a multivalued parameter
>     >> </quote>
>     >>
>     >> That's what JPA supports for multi-valued parameters. 
>     Hibernate has long
>     >> supported a broader definition of
>     "collection_valued_input_parameter".  I
>     >> am simply suggesting that we align with the limitation JPA
>     already has in
>     >> place.
>     >>
>     >> Really, the only thing I am really asking about is the
>     overloaded forms of
>     >> Query#setParameterList.  We have to support multi-valued
>     parameters *in
>     >> this very limited* case.  Sure.  The problem with our existing
>     >> broader/open-ended multi-valued param support is that we do not
>     know that a
>     >> parameter is multi-valued *from the query* itself. Specifically
>     we have
>     >> to wait and see if #setParameter or #setParameterList is
>     called, on any of
>     >> the parameters.
>     >>
>     >> Again, the "win" is that we could then know *up front* that a
>     query is not
>     >> cacheable (precompile-able), whereas today we have to wait
>     until just
>     >> before the execution (so that #setParameter and
>     #setParameterList have all
>     >> been called).
>     >>
>     >>
>     >> @Vlad It depends what "query cannot be precompiled" *means*
>     which is of
>     >> course open to interpretation.  Heck what compilation of a
>     query means at
>     >> all is outside the scope of the spec.  Any "compilation" of the
>     query that
>     >> resolves to SQL of course has to wait.  But "compilation" to a
>     semantic
>     >> form (aka, SQM) does not need to wait.  In fact the SQM is the
>     exact place
>     >> you'd look to know whether the query (plan) is cacheable.
>     >>
>     >>
>     >>
>     >> On Fri, Sep 9, 2016 at 8:20 AM Vlad Mihalcea
>     <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>     >> wrote:
>     >>
>     >>> Hi,
>     >>>
>     >>> I don't think we should deprecate such a feature.
>     >>>
>     >>> First, the JPA specs says the follows:
>     >>>
>     >>> "All input parameters must be single-valued, except in IN
>     expressions
>     >>> (see section 4.6.9), which support
>     >>> the use of collection-valued input parameters."
>     >>>
>     >>> So, we kinda need to support it one way or another.
>     >>>
>     >>> Also, the JPA specs says that:
>     >>>
>     >>> "Note that use of a collection-valued input parameter will
>     mean that a
>     >>> static query cannot be precompiled."
>     >>>
>     >>> So, it's expected to have such a behavior.
>     >>>
>     >>> I don't think that multi-load support can replace
>     paremeterList since the
>     >>> former cannot use any property from a given entity.
>     >>> Also, the IN predicate with parameter list applies to DTO
>     projections or
>     >>> native queries, so it's useful to have it.
>     >>>
>     >>> Vlad
>     >>>
>     >>> On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero
>     <andrea at hibernate.org <mailto:andrea at hibernate.org>>
>     >>> wrote:
>     >>>
>     >>>> I am also not able to figure out another use case than the IN
>     predicate
>     >>>> so
>     >>>> I am for always considering IN predicates as multi-valued.
>     >>>>
>     >>>> On 9 September 2016 at 14:20, Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>>
>     >>>> wrote:
>     >>>>
>     >>>>> To be clear, this is the feature that lets you define a
>     query like:
>     >>>>>
>     >>>>> select ... from Person p where p.name <http://p.name> in
>     (:names)
>     >>>>>
>     >>>>> And then bind varied multiple values into that single
>     parameter holder:
>     >>>>>
>     >>>>> query.setParameterList( "names", new String[] { "Larry",
>     "Curly",
>     >>>> "Moe" }
>     >>>>> );
>     >>>>> query.setParameterList( "names", new String[] { "John",
>     "Jane" } );
>     >>>>>
>     >>>>> Which magically transforms to the following (rough) SQL:
>     >>>>>
>     >>>>> select ... from PERSON p where p.name <http://p.name> in (?,
>     ?, ?)
>     >>>>> select ... from PERSON p where p.name <http://p.name> in (?, ?)
>     >>>>>
>     >>>>> Effectively parameter lists allow expansion of the HQL
>     statement - they
>     >>>>> literally are handled by altering the HQL on the fly as we
>     prepare to
>     >>>>> execute the query.  What that means is that we can really
>     not cache
>     >>>> these
>     >>>>> queries, at least not until the parameters are bound (which
>     kind of
>     >>>> defeats
>     >>>>> the purpose).
>     >>>>>
>     >>>>> I'd like to discuss dropping support for parameter lists. 
>     There are
>     >>>> quite
>     >>>>> a few reasons I would like to drop this support:
>     >>>>>
>     >>>>>     1. This is the main culprit that leads to the
>     ever-resurrecting
>     >>>>>     discussion about DB limits on IN clauses.  The one valid
>     use case I
>     >>>> saw
>     >>>>> for
>     >>>>>     that lead me to add multi-load support in 5.1.
>     >>>>>     2. In terms of a QueryPlan cache, this support means we
>     can never
>     >>>>>     effectively cache the plans for these queries because
>     the SQL is
>     >>>>> different
>     >>>>>     every time we execute the query.  The problem though is
>     that we do
>     >>>> not
>     >>>>> know
>     >>>>>     this until well after the point that we'd resolve the
>     QueryPlan.
>     >>>>>      chicken-egg.
>     >>>>>     3. This is more an internal detail, but handling the
>     parameter
>     >>>> bindings
>     >>>>>     for these differently gets quite complicated.
>     >>>>>     4. An additional internal detail is that re-writing the
>     HQL on the
>     >>>> fly
>     >>>>>     is problematic.  And some of that leaks to the user in
>     terms of
>     >>>> result
>     >>>>>     caching and stats (which HQL do we use?).
>     >>>>>
>     >>>>> I get that this can be a useful feature for apps that
>     dynamically build
>     >>>>> HQL, although really for dynamic query building I think a
>     criteria
>     >>>> approach
>     >>>>> is more appropriate.  It is not so much supporting this
>     feature that
>     >>>> bugs
>     >>>>> me, it's how we expose it.  So an alternative to dropping
>     this support
>     >>>>> would be to support it in a different way.  The main issue
>     is that I
>     >>>> would
>     >>>>> like to *syntactically* understanding that a parameter
>     placeholder
>     >>>> will be
>     >>>>> used for multi-valued parameter from the query itself.  This
>     is a
>     >>>>> beyond-JPA feature, so we definitely have some leeway here
>     to define
>     >>>> this
>     >>>>> however we want.
>     >>>>>
>     >>>>> I am open to suggestions as to the best syntax to declare that.
>     >>>>>
>     >>>>> An alternative would be to make some assumptions. 
>     Specifically, the
>     >>>> only
>     >>>>> time I can think this is used is inside an IN predicate.  Am
>     I missing
>     >>>>> others?  If that is the case, we could simply assume that a IN
>     >>>> predicate
>     >>>>> with a single parameter placeholder is going to be a multivalued
>     >>>>> parameter.  That assumption holds valid even if just a
>     single value is
>     >>>>> bound.  The main win there is that we can get rid of the
>     >>>>> Query#setParameterList
>     >>>>> variants.  setParameterList was only ever needed so that we
>     could
>     >>>>> understand that the parameter is multivalued - here we'd
>     assume that
>     >>>> from
>     >>>>> its context as the IN predicate value.
>     >>>>>
>     >>>>> Continuing to support parameters-lists in any form does not
>     really
>     >>>>> address point
>     >>>>> (1) above; but that's ok - the user really could , But each
>     of the
>     >>>>> alternatives does help with the other problems currently
>     stemming from
>     >>>>> parameter-list support.
>     >>>>> _______________________________________________
>     >>>>> hibernate-dev mailing list
>     >>>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >>>>>
>     >>>> _______________________________________________
>     >>>> hibernate-dev mailing list
>     >>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >>>>
>     >>>
>     > _______________________________________________
>     > hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From steve at hibernate.org  Fri Sep  9 18:11:56 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 09 Sep 2016 22:11:56 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <20d8af87-c78e-11fa-4a09-ad0a75fd7977@gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<20d8af87-c78e-11fa-4a09-ad0a75fd7977@gmail.com>
Message-ID: <CAFdSV9vYsS9M5KbPbXw8oV-sdR2UhvtWrf5VeZgReP2o2dAT4A@mail.gmail.com>

The parameter expansion would happen on the SQM as we translate it to the
"SQL tree" (mutli-step translation).

What we need to know up front (ideally) is:

   1.  "parameter metadata"
   2. "result metadata"

We can glean all that from SQM.  Today that lives on the QueryPlan
(HQLQueryPlan).  The other thing that we keep on QueryPlan is the SQL(s).
That last part would need to change.  So I'd expect to perform "parameter
expansion" over multi-valued params during this SQM -> SQL-tree
conversion.  This is also part of the work that makes sense to cache
(QueryPlanCache) if possible.

What happens once we have the SQM is still being designed/developed,
especially in terms of the role QueryPlan and QueryTranslator used to
play.  Today, even though the current Antlr-based QueryTranslator does a
multi-step translation it does so in a way that expects all steps to happen
at once.  I am looking to improve that design.  I'd like to build the SQM
(like a parse-tree++) up front and leverage that semantic info within the
Query impl.  The other steps/phases can (and should) happen later.

The other concern is that today we have no real validation of when
a collection_valued_input_parameter is allowed versus expecting
a single_valued_input_parameter.  Take HHH-10502 as an example, since you
mentioned it ;)  If we are not going to support multi-valued parameters
there, it sure would be nice to say that in user-friendly terms, right?  A
nice `new QueryException( "Attempt to bind multi-valued parameter when
single-valued binding expected [:ids]" )` or somesuch.  Of course, assuming
we limit this to the JPA support (+1 from me btw).  In fact we don't even
have to wait until they bind the parameter value; in that statement we
know/assume that we have a multi-valued parameter from its use in the IN
expression, but that same parameter is used in a context where a
multi-valued parameter is not allowed - we'd know (asap!) that this is a
bad query.



On Fri, Sep 9, 2016 at 4:45 PM Christian Beikov <christian.beikov at gmail.com>
wrote:

> Hmm I think I understand what you mean now. How would you do parameter
> expansion in SQM? Or will the result after a parameter expansion not be
> cached?
>
>
> Am 09.09.2016 um 23:35 schrieb Steve Ebersole:
>
> Not any particular reason, HHH-10502 or otherwise.  Its more a general
> question as I am integrating SQM and the new query translators upstream.
>
> Again, I think y'all are missing the point.  The concern is not whether a
> query is cacheable or not.  The concern is *when* I know whether it is
> cacheable.
>
> Consider some psuedo-code.  First, the ideal case:
>
> SessionImpl#createQuery(...) {
>     ...
>
>     // interpret the query into SQM
>     SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);
>
>     QueryPlan queryPlan;
>     if ( isCacheable( sqm ) ) {
>         queryPlan = queryPlanCache.get( ... );
>         if ( queryPlan == null ) {
>             queryPlan = new QueryPlan( ... );
>             queryPlanCache.put( ..., queryPlan );
>         }
>     }
>     else {
>         queryPlan = new QueryPlan( ... );
>     }
>
>     return new QueryImpl( sqm, queryPlan, this );
> }
>
> versus:
>
> SessionImpl#createQuery(...) {
>     ...
>
>     // interpret the query into SQM
>     SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);
>
>     // now we have to delay creation of the QueryPlan until later
>     // because we do not know if the query is cacheable, because
>     // we do not know yet whether it contains any multi-valued
>     // parameters.
>
>     return new QueryImpl( sqm, this );
> }
>
>
>
> On Fri, Sep 9, 2016 at 4:17 PM Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
>> Ah ok, I thought you wanted to drop parameter lists in general ^^
>> I suppose you are discussing this because of
>> https://hibernate.atlassian.net/browse/HHH-10502?
>>
>> I personally don't have a use case for a general parameter list
>> expansion like the reporter of that issue and I also don't think that
>> people are directly writing that kind of stuff into a query, but a
>> wrapper does. All in all, I think people will be able to workaround if
>> you remove the parameter list expansion for other places. Is this such a
>> problem to keep around that feature?
>>
>> Would be interesting to see how other people make use of that feature.
>> If everyone uses such collection valued parameters at least for an IN
>> predicate and maybe additionally for something else like that FIELD
>> function, you would have to wait for the parameter list anyway.
>>
>> Query caching can generally be handled if you introduce a configuration
>> parameter for a fixed expansion size, but that would probably be even
>> more work because then you would have to exectue the query multiple times.
>>
>> I just don't think that removing this feature will bring any benefits.
>>
>> Regards,
>> Christian
>>
>> Am 09.09.2016 um 22:30 schrieb Steve Ebersole:
>> > BTW, JPA really requires that we support accepting multi-valued bindings
>> > for parameters through #setParameter.  Yet another reason to do away
>> with
>> > #setParameterList.
>> >
>> >
>> > On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> WRT the "collection_valued_input_parameter" bit, that is limited in the
>> >> spec to IN clauses.  And more specifically in fact the spec
>> specifically
>> >> limits this in *exactly* the way I suggested :)
>> >>
>> >> <quote>
>> >> in_expression ::=
>> >>          {state_valued_path_expression | type_discriminator} [ NOT ] IN
>> >>              { ( in_item { , in_item}* ) | ( subquery ) |
>> >> collection_valued_input_parameter }
>> >>
>> >> in_item ::= literal | single_valued_input_parameter
>> >> </quote>
>> >>
>> >> (see "4.6.9 In Expressions" or "4.14 BNF")
>> >>
>> >> In other words, the "values" of an IN expression may be *one of* the
>> >> following:
>> >>
>> >>     1. an explicit list of "in-items", which in turn are specifically
>> >>     single values
>> >>     2. a subquery
>> >>     3. a *single* multivalued param (one placeholder to rule them all)
>> >>
>> >>
>> >> As I said in my original email:
>> >>
>> >> <quote>
>> >>   we could simply assume that a IN predicate with a single parameter
>> >> placeholder is going to be a multivalued parameter
>> >> </quote>
>> >>
>> >> That's what JPA supports for multi-valued parameters.  Hibernate has
>> long
>> >> supported a broader definition of
>> "collection_valued_input_parameter".  I
>> >> am simply suggesting that we align with the limitation JPA already has
>> in
>> >> place.
>> >>
>> >> Really, the only thing I am really asking about is the overloaded
>> forms of
>> >> Query#setParameterList.  We have to support multi-valued parameters *in
>> >> this very limited* case.  Sure.  The problem with our existing
>> >> broader/open-ended multi-valued param support is that we do not know
>> that a
>> >> parameter is multi-valued *from the query* itself.  Specifically we
>> have
>> >> to wait and see if #setParameter or #setParameterList is called, on
>> any of
>> >> the parameters.
>> >>
>> >> Again, the "win" is that we could then know *up front* that a query is
>> not
>> >> cacheable (precompile-able), whereas today we have to wait until just
>> >> before the execution (so that #setParameter and #setParameterList have
>> all
>> >> been called).
>> >>
>> >>
>> >> @Vlad It depends what "query cannot be precompiled" *means* which is of
>> >> course open to interpretation.  Heck what compilation of a query means
>> at
>> >> all is outside the scope of the spec.  Any "compilation" of the query
>> that
>> >> resolves to SQL of course has to wait.  But "compilation" to a semantic
>> >> form (aka, SQM) does not need to wait.  In fact the SQM is the exact
>> place
>> >> you'd look to know whether the query (plan) is cacheable.
>> >>
>> >>
>> >>
>> >> On Fri, Sep 9, 2016 at 8:20 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> >> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I don't think we should deprecate such a feature.
>> >>>
>> >>> First, the JPA specs says the follows:
>> >>>
>> >>> "All input parameters must be single-valued, except in IN expressions
>> >>> (see section 4.6.9), which support
>> >>> the use of collection-valued input parameters."
>> >>>
>> >>> So, we kinda need to support it one way or another.
>> >>>
>> >>> Also, the JPA specs says that:
>> >>>
>> >>> "Note that use of a collection-valued input parameter will mean that a
>> >>> static query cannot be precompiled."
>> >>>
>> >>> So, it's expected to have such a behavior.
>> >>>
>> >>> I don't think that multi-load support can replace paremeterList since
>> the
>> >>> former cannot use any property from a given entity.
>> >>> Also, the IN predicate with parameter list applies to DTO projections
>> or
>> >>> native queries, so it's useful to have it.
>> >>>
>> >>> Vlad
>> >>>
>> >>> On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero <andrea at hibernate.org>
>> >>> wrote:
>> >>>
>> >>>> I am also not able to figure out another use case than the IN
>> predicate
>> >>>> so
>> >>>> I am for always considering IN predicates as multi-valued.
>> >>>>
>> >>>> On 9 September 2016 at 14:20, Steve Ebersole <steve at hibernate.org>
>> >>>> wrote:
>> >>>>
>> >>>>> To be clear, this is the feature that lets you define a query like:
>> >>>>>
>> >>>>> select ... from Person p where p.name in (:names)
>> >>>>>
>> >>>>> And then bind varied multiple values into that single parameter
>> holder:
>> >>>>>
>> >>>>> query.setParameterList( "names", new String[] { "Larry", "Curly",
>> >>>> "Moe" }
>> >>>>> );
>> >>>>> query.setParameterList( "names", new String[] { "John", "Jane" } );
>> >>>>>
>> >>>>> Which magically transforms to the following (rough) SQL:
>> >>>>>
>> >>>>> select ... from PERSON p where p.name in (?, ?, ?)
>> >>>>> select ... from PERSON p where p.name in (?, ?)
>> >>>>>
>> >>>>> Effectively parameter lists allow expansion of the HQL statement -
>> they
>> >>>>> literally are handled by altering the HQL on the fly as we prepare
>> to
>> >>>>> execute the query.  What that means is that we can really not cache
>> >>>> these
>> >>>>> queries, at least not until the parameters are bound (which kind of
>> >>>> defeats
>> >>>>> the purpose).
>> >>>>>
>> >>>>> I'd like to discuss dropping support for parameter lists.  There are
>> >>>> quite
>> >>>>> a few reasons I would like to drop this support:
>> >>>>>
>> >>>>>     1. This is the main culprit that leads to the ever-resurrecting
>> >>>>>     discussion about DB limits on IN clauses.  The one valid use
>> case I
>> >>>> saw
>> >>>>> for
>> >>>>>     that lead me to add multi-load support in 5.1.
>> >>>>>     2. In terms of a QueryPlan cache, this support means we can
>> never
>> >>>>>     effectively cache the plans for these queries because the SQL is
>> >>>>> different
>> >>>>>     every time we execute the query.  The problem though is that we
>> do
>> >>>> not
>> >>>>> know
>> >>>>>     this until well after the point that we'd resolve the QueryPlan.
>> >>>>>      chicken-egg.
>> >>>>>     3. This is more an internal detail, but handling the parameter
>> >>>> bindings
>> >>>>>     for these differently gets quite complicated.
>> >>>>>     4. An additional internal detail is that re-writing the HQL on
>> the
>> >>>> fly
>> >>>>>     is problematic.  And some of that leaks to the user in terms of
>> >>>> result
>> >>>>>     caching and stats (which HQL do we use?).
>> >>>>>
>> >>>>> I get that this can be a useful feature for apps that dynamically
>> build
>> >>>>> HQL, although really for dynamic query building I think a criteria
>> >>>> approach
>> >>>>> is more appropriate.  It is not so much supporting this feature that
>> >>>> bugs
>> >>>>> me, it's how we expose it.  So an alternative to dropping this
>> support
>> >>>>> would be to support it in a different way.  The main issue is that I
>> >>>> would
>> >>>>> like to *syntactically* understanding that a parameter placeholder
>> >>>> will be
>> >>>>> used for multi-valued parameter from the query itself.  This is a
>> >>>>> beyond-JPA feature, so we definitely have some leeway here to define
>> >>>> this
>> >>>>> however we want.
>> >>>>>
>> >>>>> I am open to suggestions as to the best syntax to declare that.
>> >>>>>
>> >>>>> An alternative would be to make some assumptions.  Specifically, the
>> >>>> only
>> >>>>> time I can think this is used is inside an IN predicate.  Am I
>> missing
>> >>>>> others?  If that is the case, we could simply assume that a IN
>> >>>> predicate
>> >>>>> with a single parameter placeholder is going to be a multivalued
>> >>>>> parameter.  That assumption holds valid even if just a single value
>> is
>> >>>>> bound.  The main win there is that we can get rid of the
>> >>>>> Query#setParameterList
>> >>>>> variants.  setParameterList was only ever needed so that we could
>> >>>>> understand that the parameter is multivalued - here we'd assume that
>> >>>> from
>> >>>>> its context as the IN predicate value.
>> >>>>>
>> >>>>> Continuing to support parameters-lists in any form does not really
>> >>>>> address point
>> >>>>> (1) above; but that's ok - the user really could , But each of the
>> >>>>> alternatives does help with the other problems currently stemming
>> from
>> >>>>> parameter-list support.
>> >>>>> _______________________________________________
>> >>>>> hibernate-dev mailing list
>> >>>>> hibernate-dev at lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>>
>> >>>> _______________________________________________
>> >>>> hibernate-dev mailing list
>> >>>> hibernate-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>
>> >>>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From christian.beikov at gmail.com  Sat Sep 10 08:31:05 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 10 Sep 2016 14:31:05 +0200
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
Message-ID: <cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>

May I ask how the semantics of a query could change in case of parameter 
expansion in different places than IN predicate?
Since such collection valued parameters only make sense on some sort of 
varg-args accepting thingy like IN or a SQLFunction, I don't really see 
how this is an issue.

You could have 2 caches e.g.

  * SQMCache<HQL, SQMQuery>
  * SQLCache<SQMQuery, Cache<ParameterMetadata, SQLString>>

Can you please elaborate what you think is problematic about something 
like that?

Am 09.09.2016 um 23:39 schrieb Steve Ebersole:
> Although, thinking about it some more, SQM itself already exposes some 
> of the things QueryPlan does today.  So maybe this is not such a big 
> issue.
>
> I personally am just not a fan of not understanding the semantic of a 
> query up front.  Good translation in part comes down to good design of 
> the language so that as much semantic as possible is available 
> statically (from the Query itself, and from Session/SessionFactory).
>
>
> On Fri, Sep 9, 2016 at 4:35 PM Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
>
>     Not any particular reason, HHH-10502 or otherwise.  Its more a
>     general question as I am integrating SQM and the new query
>     translators upstream.
>
>     Again, I think y'all are missing the point.  The concern is not
>     whether a query is cacheable or not.  The concern is *when* I know
>     whether it is cacheable.
>
>     Consider some psuedo-code.  First, the ideal case:
>
>     SessionImpl#createQuery(...) {
>         ...
>
>         // interpret the query into SQM
>         SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);
>
>         QueryPlan queryPlan;
>         if ( isCacheable( sqm ) ) {
>             queryPlan = queryPlanCache.get( ... );
>             if ( queryPlan == null ) {
>                 queryPlan = new QueryPlan( ... );
>     queryPlanCache.put( ..., queryPlan );
>             }
>         }
>         else {
>     queryPlan = new QueryPlan( ... );
>       }
>
>       return new QueryImpl( sqm, queryPlan, this );
>     }
>
>     versus:
>
>     SessionImpl#createQuery(...) {
>         ...
>
>         // interpret the query into SQM
>     SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);
>
>         // now we have to delay creation of the QueryPlan until later
>         // because we do not know if the query is cacheable, because
>         // we do not know yet whether it contains any multi-valued
>         // parameters.
>
>       return new QueryImpl( sqm, this );
>     }
>
>
>
>     On Fri, Sep 9, 2016 at 4:17 PM Christian Beikov
>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>     wrote:
>
>         Ah ok, I thought you wanted to drop parameter lists in general ^^
>         I suppose you are discussing this because of
>         https://hibernate.atlassian.net/browse/HHH-10502?
>
>         I personally don't have a use case for a general parameter list
>         expansion like the reporter of that issue and I also don't
>         think that
>         people are directly writing that kind of stuff into a query, but a
>         wrapper does. All in all, I think people will be able to
>         workaround if
>         you remove the parameter list expansion for other places. Is
>         this such a
>         problem to keep around that feature?
>
>         Would be interesting to see how other people make use of that
>         feature.
>         If everyone uses such collection valued parameters at least
>         for an IN
>         predicate and maybe additionally for something else like that
>         FIELD
>         function, you would have to wait for the parameter list anyway.
>
>         Query caching can generally be handled if you introduce a
>         configuration
>         parameter for a fixed expansion size, but that would probably
>         be even
>         more work because then you would have to exectue the query
>         multiple times.
>
>         I just don't think that removing this feature will bring any
>         benefits.
>
>         Regards,
>         Christian
>
>         Am 09.09.2016 um 22:30 schrieb Steve Ebersole:
>         > BTW, JPA really requires that we support accepting
>         multi-valued bindings
>         > for parameters through #setParameter.  Yet another reason to
>         do away with
>         > #setParameterList.
>         >
>         >
>         > On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole
>         <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>         >
>         >> WRT the "collection_valued_input_parameter" bit, that is
>         limited in the
>         >> spec to IN clauses.  And more specifically in fact the spec
>         specifically
>         >> limits this in *exactly* the way I suggested :)
>         >>
>         >> <quote>
>         >> in_expression ::=
>         >>          {state_valued_path_expression |
>         type_discriminator} [ NOT ] IN
>         >>              { ( in_item { , in_item}* ) | ( subquery ) |
>         >> collection_valued_input_parameter }
>         >>
>         >> in_item ::= literal | single_valued_input_parameter
>         >> </quote>
>         >>
>         >> (see "4.6.9 In Expressions" or "4.14 BNF")
>         >>
>         >> In other words, the "values" of an IN expression may be
>         *one of* the
>         >> following:
>         >>
>         >>     1. an explicit list of "in-items", which in turn are
>         specifically
>         >>     single values
>         >>     2. a subquery
>         >>     3. a *single* multivalued param (one placeholder to
>         rule them all)
>         >>
>         >>
>         >> As I said in my original email:
>         >>
>         >> <quote>
>         >>   we could simply assume that a IN predicate with a single
>         parameter
>         >> placeholder is going to be a multivalued parameter
>         >> </quote>
>         >>
>         >> That's what JPA supports for multi-valued parameters. 
>         Hibernate has long
>         >> supported a broader definition of
>         "collection_valued_input_parameter".  I
>         >> am simply suggesting that we align with the limitation JPA
>         already has in
>         >> place.
>         >>
>         >> Really, the only thing I am really asking about is the
>         overloaded forms of
>         >> Query#setParameterList.  We have to support multi-valued
>         parameters *in
>         >> this very limited* case.  Sure.  The problem with our existing
>         >> broader/open-ended multi-valued param support is that we do
>         not know that a
>         >> parameter is multi-valued *from the query* itself. 
>         Specifically we have
>         >> to wait and see if #setParameter or #setParameterList is
>         called, on any of
>         >> the parameters.
>         >>
>         >> Again, the "win" is that we could then know *up front* that
>         a query is not
>         >> cacheable (precompile-able), whereas today we have to wait
>         until just
>         >> before the execution (so that #setParameter and
>         #setParameterList have all
>         >> been called).
>         >>
>         >>
>         >> @Vlad It depends what "query cannot be precompiled" *means*
>         which is of
>         >> course open to interpretation.  Heck what compilation of a
>         query means at
>         >> all is outside the scope of the spec.  Any "compilation" of
>         the query that
>         >> resolves to SQL of course has to wait.  But "compilation"
>         to a semantic
>         >> form (aka, SQM) does not need to wait.  In fact the SQM is
>         the exact place
>         >> you'd look to know whether the query (plan) is cacheable.
>         >>
>         >>
>         >>
>         >> On Fri, Sep 9, 2016 at 8:20 AM Vlad Mihalcea
>         <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>         >> wrote:
>         >>
>         >>> Hi,
>         >>>
>         >>> I don't think we should deprecate such a feature.
>         >>>
>         >>> First, the JPA specs says the follows:
>         >>>
>         >>> "All input parameters must be single-valued, except in IN
>         expressions
>         >>> (see section 4.6.9), which support
>         >>> the use of collection-valued input parameters."
>         >>>
>         >>> So, we kinda need to support it one way or another.
>         >>>
>         >>> Also, the JPA specs says that:
>         >>>
>         >>> "Note that use of a collection-valued input parameter will
>         mean that a
>         >>> static query cannot be precompiled."
>         >>>
>         >>> So, it's expected to have such a behavior.
>         >>>
>         >>> I don't think that multi-load support can replace
>         paremeterList since the
>         >>> former cannot use any property from a given entity.
>         >>> Also, the IN predicate with parameter list applies to DTO
>         projections or
>         >>> native queries, so it's useful to have it.
>         >>>
>         >>> Vlad
>         >>>
>         >>> On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero
>         <andrea at hibernate.org <mailto:andrea at hibernate.org>>
>         >>> wrote:
>         >>>
>         >>>> I am also not able to figure out another use case than
>         the IN predicate
>         >>>> so
>         >>>> I am for always considering IN predicates as multi-valued.
>         >>>>
>         >>>> On 9 September 2016 at 14:20, Steve Ebersole
>         <steve at hibernate.org <mailto:steve at hibernate.org>>
>         >>>> wrote:
>         >>>>
>         >>>>> To be clear, this is the feature that lets you define a
>         query like:
>         >>>>>
>         >>>>> select ... from Person p where p.name <http://p.name> in
>         (:names)
>         >>>>>
>         >>>>> And then bind varied multiple values into that single
>         parameter holder:
>         >>>>>
>         >>>>> query.setParameterList( "names", new String[] { "Larry",
>         "Curly",
>         >>>> "Moe" }
>         >>>>> );
>         >>>>> query.setParameterList( "names", new String[] { "John",
>         "Jane" } );
>         >>>>>
>         >>>>> Which magically transforms to the following (rough) SQL:
>         >>>>>
>         >>>>> select ... from PERSON p where p.name <http://p.name> in
>         (?, ?, ?)
>         >>>>> select ... from PERSON p where p.name <http://p.name> in
>         (?, ?)
>         >>>>>
>         >>>>> Effectively parameter lists allow expansion of the HQL
>         statement - they
>         >>>>> literally are handled by altering the HQL on the fly as
>         we prepare to
>         >>>>> execute the query.  What that means is that we can
>         really not cache
>         >>>> these
>         >>>>> queries, at least not until the parameters are bound
>         (which kind of
>         >>>> defeats
>         >>>>> the purpose).
>         >>>>>
>         >>>>> I'd like to discuss dropping support for parameter
>         lists.  There are
>         >>>> quite
>         >>>>> a few reasons I would like to drop this support:
>         >>>>>
>         >>>>>     1. This is the main culprit that leads to the
>         ever-resurrecting
>         >>>>>     discussion about DB limits on IN clauses.  The one
>         valid use case I
>         >>>> saw
>         >>>>> for
>         >>>>>     that lead me to add multi-load support in 5.1.
>         >>>>>     2. In terms of a QueryPlan cache, this support means
>         we can never
>         >>>>>     effectively cache the plans for these queries
>         because the SQL is
>         >>>>> different
>         >>>>>     every time we execute the query. The problem though
>         is that we do
>         >>>> not
>         >>>>> know
>         >>>>>     this until well after the point that we'd resolve
>         the QueryPlan.
>         >>>>>      chicken-egg.
>         >>>>>     3. This is more an internal detail, but handling the
>         parameter
>         >>>> bindings
>         >>>>>     for these differently gets quite complicated.
>         >>>>>     4. An additional internal detail is that re-writing
>         the HQL on the
>         >>>> fly
>         >>>>>     is problematic.  And some of that leaks to the user
>         in terms of
>         >>>> result
>         >>>>>     caching and stats (which HQL do we use?).
>         >>>>>
>         >>>>> I get that this can be a useful feature for apps that
>         dynamically build
>         >>>>> HQL, although really for dynamic query building I think
>         a criteria
>         >>>> approach
>         >>>>> is more appropriate.  It is not so much supporting this
>         feature that
>         >>>> bugs
>         >>>>> me, it's how we expose it.  So an alternative to
>         dropping this support
>         >>>>> would be to support it in a different way.  The main
>         issue is that I
>         >>>> would
>         >>>>> like to *syntactically* understanding that a parameter
>         placeholder
>         >>>> will be
>         >>>>> used for multi-valued parameter from the query itself. 
>         This is a
>         >>>>> beyond-JPA feature, so we definitely have some leeway
>         here to define
>         >>>> this
>         >>>>> however we want.
>         >>>>>
>         >>>>> I am open to suggestions as to the best syntax to
>         declare that.
>         >>>>>
>         >>>>> An alternative would be to make some assumptions. 
>         Specifically, the
>         >>>> only
>         >>>>> time I can think this is used is inside an IN
>         predicate.  Am I missing
>         >>>>> others?  If that is the case, we could simply assume
>         that a IN
>         >>>> predicate
>         >>>>> with a single parameter placeholder is going to be a
>         multivalued
>         >>>>> parameter.  That assumption holds valid even if just a
>         single value is
>         >>>>> bound.  The main win there is that we can get rid of the
>         >>>>> Query#setParameterList
>         >>>>> variants.  setParameterList was only ever needed so that
>         we could
>         >>>>> understand that the parameter is multivalued - here we'd
>         assume that
>         >>>> from
>         >>>>> its context as the IN predicate value.
>         >>>>>
>         >>>>> Continuing to support parameters-lists in any form does
>         not really
>         >>>>> address point
>         >>>>> (1) above; but that's ok - the user really could , But
>         each of the
>         >>>>> alternatives does help with the other problems currently
>         stemming from
>         >>>>> parameter-list support.
>         >>>>> _______________________________________________
>         >>>>> hibernate-dev mailing list
>         >>>>> hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>
>         >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>         >>>>>
>         >>>> _______________________________________________
>         >>>> hibernate-dev mailing list
>         >>>> hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>
>         >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>         >>>>
>         >>>
>         > _______________________________________________
>         > hibernate-dev mailing list
>         > hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>
>         > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>         _______________________________________________
>         hibernate-dev mailing list
>         hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From steve at hibernate.org  Sat Sep 10 09:30:13 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 10 Sep 2016 13:30:13 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
	<cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>
Message-ID: <CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>

Semantic means the "meaning" of something, but also the "intent".  Here,
specifically, the intent is "is this param placeholder representing a
single- or multi-valued parameter?  So I'll ask you... Given a query:

"from Something order by field( id, :param )"

Does ":param" represent a single- or multi-valued parameter?  Because that
is part of the semantic of the query... the ability to answer such
questions...


On Sat, Sep 10, 2016 at 7:34 AM Christian Beikov <christian.beikov at gmail.com>
wrote:

> May I ask how the semantics of a query could change in case of parameter
> expansion in different places than IN predicate?
> Since such collection valued parameters only make sense on some sort of
> varg-args accepting thingy like IN or a SQLFunction, I don't really see
> how this is an issue.
>
> You could have 2 caches e.g.
>
>   * SQMCache<HQL, SQMQuery>
>   * SQLCache<SQMQuery, Cache<ParameterMetadata, SQLString>>
>
> Can you please elaborate what you think is problematic about something
> like that?
>
> Am 09.09.2016 um 23:39 schrieb Steve Ebersole:
> > Although, thinking about it some more, SQM itself already exposes some
> > of the things QueryPlan does today.  So maybe this is not such a big
> > issue.
> >
> > I personally am just not a fan of not understanding the semantic of a
> > query up front.  Good translation in part comes down to good design of
> > the language so that as much semantic as possible is available
> > statically (from the Query itself, and from Session/SessionFactory).
> >
> >
> > On Fri, Sep 9, 2016 at 4:35 PM Steve Ebersole <steve at hibernate.org
> > <mailto:steve at hibernate.org>> wrote:
> >
> >     Not any particular reason, HHH-10502 or otherwise.  Its more a
> >     general question as I am integrating SQM and the new query
> >     translators upstream.
> >
> >     Again, I think y'all are missing the point.  The concern is not
> >     whether a query is cacheable or not.  The concern is *when* I know
> >     whether it is cacheable.
> >
> >     Consider some psuedo-code.  First, the ideal case:
> >
> >     SessionImpl#createQuery(...) {
> >         ...
> >
> >         // interpret the query into SQM
> >         SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);
> >
> >         QueryPlan queryPlan;
> >         if ( isCacheable( sqm ) ) {
> >             queryPlan = queryPlanCache.get( ... );
> >             if ( queryPlan == null ) {
> >                 queryPlan = new QueryPlan( ... );
> >     queryPlanCache.put( ..., queryPlan );
> >             }
> >         }
> >         else {
> >     queryPlan = new QueryPlan( ... );
> >       }
> >
> >       return new QueryImpl( sqm, queryPlan, this );
> >     }
> >
> >     versus:
> >
> >     SessionImpl#createQuery(...) {
> >         ...
> >
> >         // interpret the query into SQM
> >     SqmStatementSelect sqm = SemanticQueryInterpreter.interpret(...);
> >
> >         // now we have to delay creation of the QueryPlan until later
> >         // because we do not know if the query is cacheable, because
> >         // we do not know yet whether it contains any multi-valued
> >         // parameters.
> >
> >       return new QueryImpl( sqm, this );
> >     }
> >
> >
> >
> >     On Fri, Sep 9, 2016 at 4:17 PM Christian Beikov
> >     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
> >     wrote:
> >
> >         Ah ok, I thought you wanted to drop parameter lists in general ^^
> >         I suppose you are discussing this because of
> >         https://hibernate.atlassian.net/browse/HHH-10502?
> >
> >         I personally don't have a use case for a general parameter list
> >         expansion like the reporter of that issue and I also don't
> >         think that
> >         people are directly writing that kind of stuff into a query, but
> a
> >         wrapper does. All in all, I think people will be able to
> >         workaround if
> >         you remove the parameter list expansion for other places. Is
> >         this such a
> >         problem to keep around that feature?
> >
> >         Would be interesting to see how other people make use of that
> >         feature.
> >         If everyone uses such collection valued parameters at least
> >         for an IN
> >         predicate and maybe additionally for something else like that
> >         FIELD
> >         function, you would have to wait for the parameter list anyway.
> >
> >         Query caching can generally be handled if you introduce a
> >         configuration
> >         parameter for a fixed expansion size, but that would probably
> >         be even
> >         more work because then you would have to exectue the query
> >         multiple times.
> >
> >         I just don't think that removing this feature will bring any
> >         benefits.
> >
> >         Regards,
> >         Christian
> >
> >         Am 09.09.2016 um 22:30 schrieb Steve Ebersole:
> >         > BTW, JPA really requires that we support accepting
> >         multi-valued bindings
> >         > for parameters through #setParameter.  Yet another reason to
> >         do away with
> >         > #setParameterList.
> >         >
> >         >
> >         > On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole
> >         <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
> >         >
> >         >> WRT the "collection_valued_input_parameter" bit, that is
> >         limited in the
> >         >> spec to IN clauses.  And more specifically in fact the spec
> >         specifically
> >         >> limits this in *exactly* the way I suggested :)
> >         >>
> >         >> <quote>
> >         >> in_expression ::=
> >         >>          {state_valued_path_expression |
> >         type_discriminator} [ NOT ] IN
> >         >>              { ( in_item { , in_item}* ) | ( subquery ) |
> >         >> collection_valued_input_parameter }
> >         >>
> >         >> in_item ::= literal | single_valued_input_parameter
> >         >> </quote>
> >         >>
> >         >> (see "4.6.9 In Expressions" or "4.14 BNF")
> >         >>
> >         >> In other words, the "values" of an IN expression may be
> >         *one of* the
> >         >> following:
> >         >>
> >         >>     1. an explicit list of "in-items", which in turn are
> >         specifically
> >         >>     single values
> >         >>     2. a subquery
> >         >>     3. a *single* multivalued param (one placeholder to
> >         rule them all)
> >         >>
> >         >>
> >         >> As I said in my original email:
> >         >>
> >         >> <quote>
> >         >>   we could simply assume that a IN predicate with a single
> >         parameter
> >         >> placeholder is going to be a multivalued parameter
> >         >> </quote>
> >         >>
> >         >> That's what JPA supports for multi-valued parameters.
> >         Hibernate has long
> >         >> supported a broader definition of
> >         "collection_valued_input_parameter".  I
> >         >> am simply suggesting that we align with the limitation JPA
> >         already has in
> >         >> place.
> >         >>
> >         >> Really, the only thing I am really asking about is the
> >         overloaded forms of
> >         >> Query#setParameterList.  We have to support multi-valued
> >         parameters *in
> >         >> this very limited* case.  Sure.  The problem with our existing
> >         >> broader/open-ended multi-valued param support is that we do
> >         not know that a
> >         >> parameter is multi-valued *from the query* itself.
> >         Specifically we have
> >         >> to wait and see if #setParameter or #setParameterList is
> >         called, on any of
> >         >> the parameters.
> >         >>
> >         >> Again, the "win" is that we could then know *up front* that
> >         a query is not
> >         >> cacheable (precompile-able), whereas today we have to wait
> >         until just
> >         >> before the execution (so that #setParameter and
> >         #setParameterList have all
> >         >> been called).
> >         >>
> >         >>
> >         >> @Vlad It depends what "query cannot be precompiled" *means*
> >         which is of
> >         >> course open to interpretation.  Heck what compilation of a
> >         query means at
> >         >> all is outside the scope of the spec.  Any "compilation" of
> >         the query that
> >         >> resolves to SQL of course has to wait.  But "compilation"
> >         to a semantic
> >         >> form (aka, SQM) does not need to wait.  In fact the SQM is
> >         the exact place
> >         >> you'd look to know whether the query (plan) is cacheable.
> >         >>
> >         >>
> >         >>
> >         >> On Fri, Sep 9, 2016 at 8:20 AM Vlad Mihalcea
> >         <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
> >         >> wrote:
> >         >>
> >         >>> Hi,
> >         >>>
> >         >>> I don't think we should deprecate such a feature.
> >         >>>
> >         >>> First, the JPA specs says the follows:
> >         >>>
> >         >>> "All input parameters must be single-valued, except in IN
> >         expressions
> >         >>> (see section 4.6.9), which support
> >         >>> the use of collection-valued input parameters."
> >         >>>
> >         >>> So, we kinda need to support it one way or another.
> >         >>>
> >         >>> Also, the JPA specs says that:
> >         >>>
> >         >>> "Note that use of a collection-valued input parameter will
> >         mean that a
> >         >>> static query cannot be precompiled."
> >         >>>
> >         >>> So, it's expected to have such a behavior.
> >         >>>
> >         >>> I don't think that multi-load support can replace
> >         paremeterList since the
> >         >>> former cannot use any property from a given entity.
> >         >>> Also, the IN predicate with parameter list applies to DTO
> >         projections or
> >         >>> native queries, so it's useful to have it.
> >         >>>
> >         >>> Vlad
> >         >>>
> >         >>> On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero
> >         <andrea at hibernate.org <mailto:andrea at hibernate.org>>
> >         >>> wrote:
> >         >>>
> >         >>>> I am also not able to figure out another use case than
> >         the IN predicate
> >         >>>> so
> >         >>>> I am for always considering IN predicates as multi-valued.
> >         >>>>
> >         >>>> On 9 September 2016 at 14:20, Steve Ebersole
> >         <steve at hibernate.org <mailto:steve at hibernate.org>>
> >         >>>> wrote:
> >         >>>>
> >         >>>>> To be clear, this is the feature that lets you define a
> >         query like:
> >         >>>>>
> >         >>>>> select ... from Person p where p.name <http://p.name> in
> >         (:names)
> >         >>>>>
> >         >>>>> And then bind varied multiple values into that single
> >         parameter holder:
> >         >>>>>
> >         >>>>> query.setParameterList( "names", new String[] { "Larry",
> >         "Curly",
> >         >>>> "Moe" }
> >         >>>>> );
> >         >>>>> query.setParameterList( "names", new String[] { "John",
> >         "Jane" } );
> >         >>>>>
> >         >>>>> Which magically transforms to the following (rough) SQL:
> >         >>>>>
> >         >>>>> select ... from PERSON p where p.name <http://p.name> in
> >         (?, ?, ?)
> >         >>>>> select ... from PERSON p where p.name <http://p.name> in
> >         (?, ?)
> >         >>>>>
> >         >>>>> Effectively parameter lists allow expansion of the HQL
> >         statement - they
> >         >>>>> literally are handled by altering the HQL on the fly as
> >         we prepare to
> >         >>>>> execute the query.  What that means is that we can
> >         really not cache
> >         >>>> these
> >         >>>>> queries, at least not until the parameters are bound
> >         (which kind of
> >         >>>> defeats
> >         >>>>> the purpose).
> >         >>>>>
> >         >>>>> I'd like to discuss dropping support for parameter
> >         lists.  There are
> >         >>>> quite
> >         >>>>> a few reasons I would like to drop this support:
> >         >>>>>
> >         >>>>>     1. This is the main culprit that leads to the
> >         ever-resurrecting
> >         >>>>>     discussion about DB limits on IN clauses.  The one
> >         valid use case I
> >         >>>> saw
> >         >>>>> for
> >         >>>>>     that lead me to add multi-load support in 5.1.
> >         >>>>>     2. In terms of a QueryPlan cache, this support means
> >         we can never
> >         >>>>>     effectively cache the plans for these queries
> >         because the SQL is
> >         >>>>> different
> >         >>>>>     every time we execute the query. The problem though
> >         is that we do
> >         >>>> not
> >         >>>>> know
> >         >>>>>     this until well after the point that we'd resolve
> >         the QueryPlan.
> >         >>>>>      chicken-egg.
> >         >>>>>     3. This is more an internal detail, but handling the
> >         parameter
> >         >>>> bindings
> >         >>>>>     for these differently gets quite complicated.
> >         >>>>>     4. An additional internal detail is that re-writing
> >         the HQL on the
> >         >>>> fly
> >         >>>>>     is problematic.  And some of that leaks to the user
> >         in terms of
> >         >>>> result
> >         >>>>>     caching and stats (which HQL do we use?).
> >         >>>>>
> >         >>>>> I get that this can be a useful feature for apps that
> >         dynamically build
> >         >>>>> HQL, although really for dynamic query building I think
> >         a criteria
> >         >>>> approach
> >         >>>>> is more appropriate.  It is not so much supporting this
> >         feature that
> >         >>>> bugs
> >         >>>>> me, it's how we expose it.  So an alternative to
> >         dropping this support
> >         >>>>> would be to support it in a different way.  The main
> >         issue is that I
> >         >>>> would
> >         >>>>> like to *syntactically* understanding that a parameter
> >         placeholder
> >         >>>> will be
> >         >>>>> used for multi-valued parameter from the query itself.
> >         This is a
> >         >>>>> beyond-JPA feature, so we definitely have some leeway
> >         here to define
> >         >>>> this
> >         >>>>> however we want.
> >         >>>>>
> >         >>>>> I am open to suggestions as to the best syntax to
> >         declare that.
> >         >>>>>
> >         >>>>> An alternative would be to make some assumptions.
> >         Specifically, the
> >         >>>> only
> >         >>>>> time I can think this is used is inside an IN
> >         predicate.  Am I missing
> >         >>>>> others?  If that is the case, we could simply assume
> >         that a IN
> >         >>>> predicate
> >         >>>>> with a single parameter placeholder is going to be a
> >         multivalued
> >         >>>>> parameter.  That assumption holds valid even if just a
> >         single value is
> >         >>>>> bound.  The main win there is that we can get rid of the
> >         >>>>> Query#setParameterList
> >         >>>>> variants.  setParameterList was only ever needed so that
> >         we could
> >         >>>>> understand that the parameter is multivalued - here we'd
> >         assume that
> >         >>>> from
> >         >>>>> its context as the IN predicate value.
> >         >>>>>
> >         >>>>> Continuing to support parameters-lists in any form does
> >         not really
> >         >>>>> address point
> >         >>>>> (1) above; but that's ok - the user really could , But
> >         each of the
> >         >>>>> alternatives does help with the other problems currently
> >         stemming from
> >         >>>>> parameter-list support.
> >         >>>>> _______________________________________________
> >         >>>>> hibernate-dev mailing list
> >         >>>>> hibernate-dev at lists.jboss.org
> >         <mailto:hibernate-dev at lists.jboss.org>
> >         >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >         >>>>>
> >         >>>> _______________________________________________
> >         >>>> hibernate-dev mailing list
> >         >>>> hibernate-dev at lists.jboss.org
> >         <mailto:hibernate-dev at lists.jboss.org>
> >         >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >         >>>>
> >         >>>
> >         > _______________________________________________
> >         > hibernate-dev mailing list
> >         > hibernate-dev at lists.jboss.org
> >         <mailto:hibernate-dev at lists.jboss.org>
> >         > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >         _______________________________________________
> >         hibernate-dev mailing list
> >         hibernate-dev at lists.jboss.org
> >         <mailto:hibernate-dev at lists.jboss.org>
> >         https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From christian.beikov at gmail.com  Sat Sep 10 09:57:59 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 10 Sep 2016 15:57:59 +0200
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
	<cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>
	<CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>
Message-ID: <2c763076-ad9c-da77-9fe4-428968b0a0a3@gmail.com>

Will there be a way in SQM to specify the argument types of a function? 
If so, then you could introduce the concept of var-args and then a 
parameter will only be a multi-valued parameter if the function argument 
it is used for is a var-arg parameter.
If not, then you probably need a custom syntax. Maybe something like 
":param...", ":...param", ":*param" or ":param*"?

Am 10.09.2016 um 15:30 schrieb Steve Ebersole:
> Semantic means the "meaning" of something, but also the "intent".  
> Here, specifically, the intent is "is this param placeholder 
> representing a single- or multi-valued parameter? So I'll ask you... 
> Given a query:
>
> "from Something order by field( id, :param )"
>
> Does ":param" represent a single- or multi-valued parameter?  Because 
> that is part of the semantic of the query... the ability to answer 
> such questions...
>
>
> On Sat, Sep 10, 2016 at 7:34 AM Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     May I ask how the semantics of a query could change in case of
>     parameter
>     expansion in different places than IN predicate?
>     Since such collection valued parameters only make sense on some
>     sort of
>     varg-args accepting thingy like IN or a SQLFunction, I don't
>     really see
>     how this is an issue.
>
>     You could have 2 caches e.g.
>
>       * SQMCache<HQL, SQMQuery>
>       * SQLCache<SQMQuery, Cache<ParameterMetadata, SQLString>>
>
>     Can you please elaborate what you think is problematic about something
>     like that?
>
>     Am 09.09.2016 um 23:39 schrieb Steve Ebersole:
>     > Although, thinking about it some more, SQM itself already
>     exposes some
>     > of the things QueryPlan does today.  So maybe this is not such a big
>     > issue.
>     >
>     > I personally am just not a fan of not understanding the semantic
>     of a
>     > query up front.  Good translation in part comes down to good
>     design of
>     > the language so that as much semantic as possible is available
>     > statically (from the Query itself, and from Session/SessionFactory).
>     >
>     >
>     > On Fri, Sep 9, 2016 at 4:35 PM Steve Ebersole
>     <steve at hibernate.org <mailto:steve at hibernate.org>
>     > <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>> wrote:
>     >
>     >     Not any particular reason, HHH-10502 or otherwise. Its more a
>     >     general question as I am integrating SQM and the new query
>     >     translators upstream.
>     >
>     >     Again, I think y'all are missing the point.  The concern is not
>     >     whether a query is cacheable or not.  The concern is *when*
>     I know
>     >     whether it is cacheable.
>     >
>     >     Consider some psuedo-code.  First, the ideal case:
>     >
>     >     SessionImpl#createQuery(...) {
>     >         ...
>     >
>     >         // interpret the query into SQM
>     >         SqmStatementSelect sqm =
>     SemanticQueryInterpreter.interpret(...);
>     >
>     >         QueryPlan queryPlan;
>     >         if ( isCacheable( sqm ) ) {
>     >             queryPlan = queryPlanCache.get( ... );
>     >             if ( queryPlan == null ) {
>     >                 queryPlan = new QueryPlan( ... );
>     >     queryPlanCache.put( ..., queryPlan );
>     >             }
>     >         }
>     >         else {
>     >     queryPlan = new QueryPlan( ... );
>     >       }
>     >
>     >       return new QueryImpl( sqm, queryPlan, this );
>     >     }
>     >
>     >     versus:
>     >
>     >     SessionImpl#createQuery(...) {
>     >         ...
>     >
>     >         // interpret the query into SQM
>     >     SqmStatementSelect sqm =
>     SemanticQueryInterpreter.interpret(...);
>     >
>     >         // now we have to delay creation of the QueryPlan until
>     later
>     >         // because we do not know if the query is cacheable, because
>     >         // we do not know yet whether it contains any multi-valued
>     >         // parameters.
>     >
>     >       return new QueryImpl( sqm, this );
>     >     }
>     >
>     >
>     >
>     >     On Fri, Sep 9, 2016 at 4:17 PM Christian Beikov
>     >     <christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>
>     <mailto:christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>>>
>     >     wrote:
>     >
>     >         Ah ok, I thought you wanted to drop parameter lists in
>     general ^^
>     >         I suppose you are discussing this because of
>     > https://hibernate.atlassian.net/browse/HHH-10502?
>     >
>     >         I personally don't have a use case for a general
>     parameter list
>     >         expansion like the reporter of that issue and I also don't
>     >         think that
>     >         people are directly writing that kind of stuff into a
>     query, but a
>     >         wrapper does. All in all, I think people will be able to
>     >         workaround if
>     >         you remove the parameter list expansion for other places. Is
>     >         this such a
>     >         problem to keep around that feature?
>     >
>     >         Would be interesting to see how other people make use of
>     that
>     >         feature.
>     >         If everyone uses such collection valued parameters at least
>     >         for an IN
>     >         predicate and maybe additionally for something else like
>     that
>     >         FIELD
>     >         function, you would have to wait for the parameter list
>     anyway.
>     >
>     >         Query caching can generally be handled if you introduce a
>     >         configuration
>     >         parameter for a fixed expansion size, but that would
>     probably
>     >         be even
>     >         more work because then you would have to exectue the query
>     >         multiple times.
>     >
>     >         I just don't think that removing this feature will bring any
>     >         benefits.
>     >
>     >         Regards,
>     >         Christian
>     >
>     >         Am 09.09.2016 um 22:30 schrieb Steve Ebersole:
>     >         > BTW, JPA really requires that we support accepting
>     >         multi-valued bindings
>     >         > for parameters through #setParameter.  Yet another
>     reason to
>     >         do away with
>     >         > #setParameterList.
>     >         >
>     >         >
>     >         > On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole
>     >         <steve at hibernate.org <mailto:steve at hibernate.org>
>     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>> wrote:
>     >         >
>     >         >> WRT the "collection_valued_input_parameter" bit, that is
>     >         limited in the
>     >         >> spec to IN clauses.  And more specifically in fact
>     the spec
>     >         specifically
>     >         >> limits this in *exactly* the way I suggested :)
>     >         >>
>     >         >> <quote>
>     >         >> in_expression ::=
>     >         >>          {state_valued_path_expression |
>     >         type_discriminator} [ NOT ] IN
>     >         >>              { ( in_item { , in_item}* ) | ( subquery ) |
>     >         >> collection_valued_input_parameter }
>     >         >>
>     >         >> in_item ::= literal | single_valued_input_parameter
>     >         >> </quote>
>     >         >>
>     >         >> (see "4.6.9 In Expressions" or "4.14 BNF")
>     >         >>
>     >         >> In other words, the "values" of an IN expression may be
>     >         *one of* the
>     >         >> following:
>     >         >>
>     >         >>     1. an explicit list of "in-items", which in turn are
>     >         specifically
>     >         >>     single values
>     >         >>     2. a subquery
>     >         >>     3. a *single* multivalued param (one placeholder to
>     >         rule them all)
>     >         >>
>     >         >>
>     >         >> As I said in my original email:
>     >         >>
>     >         >> <quote>
>     >         >>   we could simply assume that a IN predicate with a
>     single
>     >         parameter
>     >         >> placeholder is going to be a multivalued parameter
>     >         >> </quote>
>     >         >>
>     >         >> That's what JPA supports for multi-valued parameters.
>     >         Hibernate has long
>     >         >> supported a broader definition of
>     >         "collection_valued_input_parameter".  I
>     >         >> am simply suggesting that we align with the
>     limitation JPA
>     >         already has in
>     >         >> place.
>     >         >>
>     >         >> Really, the only thing I am really asking about is the
>     >         overloaded forms of
>     >         >> Query#setParameterList.  We have to support multi-valued
>     >         parameters *in
>     >         >> this very limited* case.  Sure.  The problem with our
>     existing
>     >         >> broader/open-ended multi-valued param support is that
>     we do
>     >         not know that a
>     >         >> parameter is multi-valued *from the query* itself.
>     >         Specifically we have
>     >         >> to wait and see if #setParameter or #setParameterList is
>     >         called, on any of
>     >         >> the parameters.
>     >         >>
>     >         >> Again, the "win" is that we could then know *up
>     front* that
>     >         a query is not
>     >         >> cacheable (precompile-able), whereas today we have to
>     wait
>     >         until just
>     >         >> before the execution (so that #setParameter and
>     >         #setParameterList have all
>     >         >> been called).
>     >         >>
>     >         >>
>     >         >> @Vlad It depends what "query cannot be precompiled"
>     *means*
>     >         which is of
>     >         >> course open to interpretation.  Heck what compilation
>     of a
>     >         query means at
>     >         >> all is outside the scope of the spec. Any
>     "compilation" of
>     >         the query that
>     >         >> resolves to SQL of course has to wait. But "compilation"
>     >         to a semantic
>     >         >> form (aka, SQM) does not need to wait. In fact the SQM is
>     >         the exact place
>     >         >> you'd look to know whether the query (plan) is cacheable.
>     >         >>
>     >         >>
>     >         >>
>     >         >> On Fri, Sep 9, 2016 at 8:20 AM Vlad Mihalcea
>     >         <mihalcea.vlad at gmail.com
>     <mailto:mihalcea.vlad at gmail.com> <mailto:mihalcea.vlad at gmail.com
>     <mailto:mihalcea.vlad at gmail.com>>>
>     >         >> wrote:
>     >         >>
>     >         >>> Hi,
>     >         >>>
>     >         >>> I don't think we should deprecate such a feature.
>     >         >>>
>     >         >>> First, the JPA specs says the follows:
>     >         >>>
>     >         >>> "All input parameters must be single-valued, except
>     in IN
>     >         expressions
>     >         >>> (see section 4.6.9), which support
>     >         >>> the use of collection-valued input parameters."
>     >         >>>
>     >         >>> So, we kinda need to support it one way or another.
>     >         >>>
>     >         >>> Also, the JPA specs says that:
>     >         >>>
>     >         >>> "Note that use of a collection-valued input
>     parameter will
>     >         mean that a
>     >         >>> static query cannot be precompiled."
>     >         >>>
>     >         >>> So, it's expected to have such a behavior.
>     >         >>>
>     >         >>> I don't think that multi-load support can replace
>     >         paremeterList since the
>     >         >>> former cannot use any property from a given entity.
>     >         >>> Also, the IN predicate with parameter list applies
>     to DTO
>     >         projections or
>     >         >>> native queries, so it's useful to have it.
>     >         >>>
>     >         >>> Vlad
>     >         >>>
>     >         >>> On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero
>     >         <andrea at hibernate.org <mailto:andrea at hibernate.org>
>     <mailto:andrea at hibernate.org <mailto:andrea at hibernate.org>>>
>     >         >>> wrote:
>     >         >>>
>     >         >>>> I am also not able to figure out another use case than
>     >         the IN predicate
>     >         >>>> so
>     >         >>>> I am for always considering IN predicates as
>     multi-valued.
>     >         >>>>
>     >         >>>> On 9 September 2016 at 14:20, Steve Ebersole
>     >         <steve at hibernate.org <mailto:steve at hibernate.org>
>     <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>>
>     >         >>>> wrote:
>     >         >>>>
>     >         >>>>> To be clear, this is the feature that lets you
>     define a
>     >         query like:
>     >         >>>>>
>     >         >>>>> select ... from Person p where p.name
>     <http://p.name> <http://p.name> in
>     >         (:names)
>     >         >>>>>
>     >         >>>>> And then bind varied multiple values into that single
>     >         parameter holder:
>     >         >>>>>
>     >         >>>>> query.setParameterList( "names", new String[] {
>     "Larry",
>     >         "Curly",
>     >         >>>> "Moe" }
>     >         >>>>> );
>     >         >>>>> query.setParameterList( "names", new String[] {
>     "John",
>     >         "Jane" } );
>     >         >>>>>
>     >         >>>>> Which magically transforms to the following
>     (rough) SQL:
>     >         >>>>>
>     >         >>>>> select ... from PERSON p where p.name
>     <http://p.name> <http://p.name> in
>     >         (?, ?, ?)
>     >         >>>>> select ... from PERSON p where p.name
>     <http://p.name> <http://p.name> in
>     >         (?, ?)
>     >         >>>>>
>     >         >>>>> Effectively parameter lists allow expansion of the HQL
>     >         statement - they
>     >         >>>>> literally are handled by altering the HQL on the
>     fly as
>     >         we prepare to
>     >         >>>>> execute the query.  What that means is that we can
>     >         really not cache
>     >         >>>> these
>     >         >>>>> queries, at least not until the parameters are bound
>     >         (which kind of
>     >         >>>> defeats
>     >         >>>>> the purpose).
>     >         >>>>>
>     >         >>>>> I'd like to discuss dropping support for parameter
>     >         lists.  There are
>     >         >>>> quite
>     >         >>>>> a few reasons I would like to drop this support:
>     >         >>>>>
>     >         >>>>>     1. This is the main culprit that leads to the
>     >         ever-resurrecting
>     >         >>>>>     discussion about DB limits on IN clauses.  The one
>     >         valid use case I
>     >         >>>> saw
>     >         >>>>> for
>     >         >>>>>     that lead me to add multi-load support in 5.1.
>     >         >>>>>     2. In terms of a QueryPlan cache, this support
>     means
>     >         we can never
>     >         >>>>>     effectively cache the plans for these queries
>     >         because the SQL is
>     >         >>>>> different
>     >         >>>>>     every time we execute the query. The problem
>     though
>     >         is that we do
>     >         >>>> not
>     >         >>>>> know
>     >         >>>>>     this until well after the point that we'd resolve
>     >         the QueryPlan.
>     >         >>>>>      chicken-egg.
>     >         >>>>>     3. This is more an internal detail, but
>     handling the
>     >         parameter
>     >         >>>> bindings
>     >         >>>>>     for these differently gets quite complicated.
>     >         >>>>>     4. An additional internal detail is that
>     re-writing
>     >         the HQL on the
>     >         >>>> fly
>     >         >>>>>     is problematic.  And some of that leaks to the
>     user
>     >         in terms of
>     >         >>>> result
>     >         >>>>>     caching and stats (which HQL do we use?).
>     >         >>>>>
>     >         >>>>> I get that this can be a useful feature for apps that
>     >         dynamically build
>     >         >>>>> HQL, although really for dynamic query building I
>     think
>     >         a criteria
>     >         >>>> approach
>     >         >>>>> is more appropriate.  It is not so much supporting
>     this
>     >         feature that
>     >         >>>> bugs
>     >         >>>>> me, it's how we expose it. So an alternative to
>     >         dropping this support
>     >         >>>>> would be to support it in a different way.  The main
>     >         issue is that I
>     >         >>>> would
>     >         >>>>> like to *syntactically* understanding that a parameter
>     >         placeholder
>     >         >>>> will be
>     >         >>>>> used for multi-valued parameter from the query itself.
>     >         This is a
>     >         >>>>> beyond-JPA feature, so we definitely have some leeway
>     >         here to define
>     >         >>>> this
>     >         >>>>> however we want.
>     >         >>>>>
>     >         >>>>> I am open to suggestions as to the best syntax to
>     >         declare that.
>     >         >>>>>
>     >         >>>>> An alternative would be to make some assumptions.
>     >         Specifically, the
>     >         >>>> only
>     >         >>>>> time I can think this is used is inside an IN
>     >         predicate.  Am I missing
>     >         >>>>> others?  If that is the case, we could simply assume
>     >         that a IN
>     >         >>>> predicate
>     >         >>>>> with a single parameter placeholder is going to be a
>     >         multivalued
>     >         >>>>> parameter.  That assumption holds valid even if just a
>     >         single value is
>     >         >>>>> bound.  The main win there is that we can get rid
>     of the
>     >         >>>>> Query#setParameterList
>     >         >>>>> variants.  setParameterList was only ever needed
>     so that
>     >         we could
>     >         >>>>> understand that the parameter is multivalued -
>     here we'd
>     >         assume that
>     >         >>>> from
>     >         >>>>> its context as the IN predicate value.
>     >         >>>>>
>     >         >>>>> Continuing to support parameters-lists in any form
>     does
>     >         not really
>     >         >>>>> address point
>     >         >>>>> (1) above; but that's ok - the user really could , But
>     >         each of the
>     >         >>>>> alternatives does help with the other problems
>     currently
>     >         stemming from
>     >         >>>>> parameter-list support.
>     >         >>>>> _______________________________________________
>     >         >>>>> hibernate-dev mailing list
>     >         >>>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >         <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     >         >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >         >>>>>
>     >         >>>> _______________________________________________
>     >         >>>> hibernate-dev mailing list
>     >         >>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >         <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     >         >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >         >>>>
>     >         >>>
>     >         > _______________________________________________
>     >         > hibernate-dev mailing list
>     >         > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >         <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     >         > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >
>     >         _______________________________________________
>     >         hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     >         <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From steve at hibernate.org  Sat Sep 10 10:10:18 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 10 Sep 2016 14:10:18 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
	<cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>
	<CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>
Message-ID: <CAFdSV9s4bSK9uzySPEmkR_GVqbB0ZiimVkccO0a3Vn8Ak0Tg9g@mail.gmail.com>

WRT the "double caches"... yes there will be a few caches.

I'm not understanding what that has to do with defining a clear semantic
for a particular language element.

----

Look, to me this whole thing boils down to the fact that JPA defines
specific/limited support for this "collection valued input parameter"
language element.  It does that btw because the ideal in language design is
to be able to wholly understand the semantic of a part of a query based
only on the syntax[1].  Further, JPA requires that we handle a user binding
a  "collection valued input parameter" directly through #setParameter.

So all told we have a set of overloaded methods (#setParameterList) that
are not really providing any value[2], but that are needed because that
provides the only indication we ever get that a particular parameter
placeholder identifies a "collection valued input parameter" rather
than a "single
valued input parameter".  For all the reasons discussed[1], thats not the
ideal language design because it is not deterministic from the grammar.

Think of it this way...  It would be nice++ to be able to say "this
parameter is allowing multi-valued input" or "this parameter is expecting
single-valued input (multi-value input disallowed)", right?  Its the whole
reason JPA defines its grammar (BNF) the way it does, so that we can
properly validate the incoming parameter input.  Today I can do something
like this:

s.createQuery( "from Zoo z where z.name = :name" )
      .setParameterList( "name", new String[] { "San Antonio Zoo",
"Waco Zoo" } )
      .list();

That is a completely "valid" query.  Its not going to return anything
useful, but syntactically it is valid because we cannot understand the
proper semantic.   And we do not understand the proper semantic because it
is not deterministic wrt the grammar/syntax.  Ideally you'd want to throw
an exception back to the user here as soon as they try to call
#setParameterList for a parameter we conceptually *know* should not accept
"collection valued input parameters"

----

[1] This gets into language and grammar design, but there are a few reasons
you want to encode as much semantic understanding into the syntax as
possible.  There are a few reasons for this; the 2 main ones for us:

   1. validation - again, here if I understand that a parameter placeholder
   should or should-not allow "collection valued input parameter" I can
   apply better validation up front (the sooner this type of feedback can
   happen the better)
   2. performance - anytime the query itself is not clear as to its
   semantic there is going to be a performance aspect to resolving that
   unclarity.

[2] I can see the argument of #setParameterList providing a better API for
passing the multi-value bind value in terms of type signature.  But
ultimately IMO both  "collection valued input parameter" and  "single
valued input parameter" ought to be stored in one structure.  Today they
are not, can't because we need to know that #setParameterList was called
instead of #setParameter because that is our only understanding of the
semantic - that this is a "collection valued input parameter", not a "single
valued input parameter".

From steve at hibernate.org  Sat Sep 10 10:27:34 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 10 Sep 2016 14:27:34 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <2c763076-ad9c-da77-9fe4-428968b0a0a3@gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
	<cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>
	<CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>
	<2c763076-ad9c-da77-9fe4-428968b0a0a3@gmail.com>
Message-ID: <CAFdSV9vn3T5bofSQw7es5v0-f=AJJ0pTx6nCUSpRnXYAxRyTKA@mail.gmail.com>

On Sat, Sep 10, 2016 at 9:08 AM Christian Beikov <christian.beikov at gmail.com>
wrote:

> Will there be a way in SQM to specify the argument types of a function?
>

We have that today.  Not so much the "varargs" aspect, but if the user
registered that function as a SQLFunction then we would understand the
type(s) of arguments it accepts.



> If so, then you could introduce the concept of var-args and then a
> parameter will only be a multi-valued parameter if the function argument
> it is used for is a var-arg parameter.
>

Right, that would mean adjusting SQLFunction to report whether the
arguments are "varargs".  I plan on looking to change the SQLFunction
contract quite a bit already actually.  Today we render these (into the
SQL) via the method `String render(Type argumentType, List args,
SessionFactoryImplementor factory)` where the `args` is List<String>.  I'd
prefer that to be more OO than String.  In terms of SQM and SQL-tree, I'd
like that to be something like List<SqlTreeExpression>.  Heck I'd love for
these SQLFunctions themselves to implement SqlTreeExpression themselves and
embed them directly into the SQL-tree



> If not, then you probably need a custom syntax. Maybe something like
> ":param...", ":...param", ":*param" or ":param*"?
>

Yep, like I mentioned back in the original email.  This is an alternative
mean to making the question of "collection valued input parameter" versus
"single valued input parameter" deterministic from the grammar.  I
personally am not a fan of this, but just mentioned it for completeness.

HHH-10502 is an example of a "corner case".  The placeholder is reused, and
one is already deterministic to accept "collection valued input
parameter".  So we could understand that across both usages.  We have to be
clear that this this non-compliant JPA usage, however.

Either way, if we are going to allow a "collection valued input parameter"
in contexts not allowed strictly under JPA then this needs to be hooked in
with org.hibernate.sqm.ConsumerContext#useStrictJpaCompliance
and org.hibernate.sqm.StrictJpaComplianceViolation

From christian.beikov at gmail.com  Sat Sep 10 10:40:07 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 10 Sep 2016 16:40:07 +0200
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9s4bSK9uzySPEmkR_GVqbB0ZiimVkccO0a3Vn8Ak0Tg9g@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
	<cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>
	<CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>
	<CAFdSV9s4bSK9uzySPEmkR_GVqbB0ZiimVkccO0a3Vn8Ak0Tg9g@mail.gmail.com>
Message-ID: <4523a12b-fb1f-e77f-620c-61ad8f3e1664@gmail.com>

My idea was to allow a parameter to be a collection valued parameter 
only in two cases

 1. When used with the IN predicate
 2. When used as last argument for a function and the parameter is a
    var-arg parameter

That way the query can be validated upfront when knowing the registered 
functions and their argument types, but it's obviously not clear from 
just looking at the query string if a parameter is multi-valued or not. 
If you want to make the semantics independent of the functions, then you 
must introduce a syntax of course. I was just trying to suggest 
something that is mostly compatible to the way it is right now.

Am 10.09.2016 um 16:10 schrieb Steve Ebersole:
> WRT the "double caches"... yes there will be a few caches.
>
> I'm not understanding what that has to do with defining a clear 
> semantic for a particular language element.
>
> ----
>
> Look, to me this whole thing boils down to the fact that JPA defines 
> specific/limited support for this "collection valued input parameter" 
> language element.  It does that btw because the ideal in language 
> design is to be able to wholly understand the semantic of a part of a 
> query based only on the syntax[1]. Further, JPA requires that we 
> handle a user binding a "collection valued input parameter" directly 
> through #setParameter.
>
> So all told we have a set of overloaded methods (#setParameterList) 
> that are not really providing any value[2], but that are needed 
> because that provides the only indication we ever get that a 
> particular parameter placeholder identifies a "collection valued input 
> parameter" rather than a"single valued input parameter". For all the 
> reasons discussed[1], thats not the ideal language design because it 
> is not deterministic from the grammar.
>
> Think of it this way...  It would be nice++ to be able to say "this 
> parameter is allowing multi-valued input" or "this parameter is 
> expecting single-valued input (multi-value input disallowed)", right? 
> Its the whole reason JPA defines its grammar (BNF) the way it does, so 
> that we can properly validate the incoming parameter input.  Today I 
> can do something like this:
>
> s.createQuery("from Zoo z where z.name <http://z.name> = :name" )
>        .setParameterList("name",new String[] {"San Antonio Zoo","Waco Zoo" } )
>        .list();
> That is a completely "valid" query.  Its not going to return anything 
> useful, but syntactically it is valid because we cannot understand the 
> proper semantic.   And we do not understand the proper semantic 
> because it is not deterministic wrt the grammar/syntax. Ideally you'd 
> want to throw an exception back to the user here as soon as they try 
> to call #setParameterList for a parameter we conceptually *know* 
> should not accept "collection valued input parameters"
>
> ----
>
> [1] This gets into language and grammar design, but there are a few 
> reasons you want to encode as much semantic understanding into the 
> syntax as possible.  There are a few reasons for this; the 2 main ones 
> for us:
>
>  1. validation - again, here if I understand that a parameter
>     placeholder should or should-not allow "collection valued input
>     parameter" I can apply better validation up front (the sooner this
>     type of feedback can happen the better)
>  2. performance - anytime the query itself is not clear as to its
>     semantic there is going to be a performance aspect to resolving
>     that unclarity.
>
> [2] I can see the argument of #setParameterList providing a better API 
> for passing the multi-value bind value in terms of type signature.  
> But ultimately IMO both "collection valued input parameter" and 
> "single valued input parameter" ought to be stored in one structure.  
> Today they are not, can't because we need to know that 
> #setParameterList was called instead of #setParameter because that is 
> our only understanding of the semantic - that this is a "collection 
> valued input parameter", not a"single valued input parameter".
>
>


From steve at hibernate.org  Sat Sep 10 10:42:38 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 10 Sep 2016 14:42:38 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9vn3T5bofSQw7es5v0-f=AJJ0pTx6nCUSpRnXYAxRyTKA@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
	<cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>
	<CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>
	<2c763076-ad9c-da77-9fe4-428968b0a0a3@gmail.com>
	<CAFdSV9vn3T5bofSQw7es5v0-f=AJJ0pTx6nCUSpRnXYAxRyTKA@mail.gmail.com>
Message-ID: <CAFdSV9v-BLGB1E_WqixqfbThP2+42djRduwnjfknuuvm11nLDQ@mail.gmail.com>

Just to follow up on something I said below...

On Sat, Sep 10, 2016 at 9:27 AM Steve Ebersole <steve at hibernate.org> wrote:

> Right, that would mean adjusting SQLFunction to report whether the
> arguments are "varargs".  I plan on looking to change the SQLFunction
> contract quite a bit already actually.  Today we render these (into the
> SQL) via the method `String render(Type argumentType, List args,
> SessionFactoryImplementor factory)` where the `args` is List<String>.  I'd
> prefer that to be more OO than String.  In terms of SQM and SQL-tree, I'd
> like that to be something like List<SqlTreeExpression>.  Heck I'd love for
> these SQLFunctions themselves to implement SqlTreeExpression themselves and
> embed them directly into the SQL-tree
>

This whole discussion about the SQLFunction contract change is not really
related to this discussion.  I was just pointing out that I already have
some changes in mind for that contract.  So changing the contract for this
is not a "hardship".

I forget the details atm, I just know that I have been in situations when
writing a SQLFunction impl where it would have been nice to know some more
details about a particular argument - especially when you start thinking
about nested function calls.

From steve at hibernate.org  Sat Sep 10 10:53:30 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 10 Sep 2016 14:53:30 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <4523a12b-fb1f-e77f-620c-61ad8f3e1664@gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
	<cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>
	<CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>
	<CAFdSV9s4bSK9uzySPEmkR_GVqbB0ZiimVkccO0a3Vn8Ak0Tg9g@mail.gmail.com>
	<4523a12b-fb1f-e77f-620c-61ad8f3e1664@gmail.com>
Message-ID: <CAFdSV9uQmyn2puxDRRH1ed24NRestzJffkzLCd-PGAu8--0hwg@mail.gmail.com>

We are actually getting close to being able to wholly determine FUNCTION
syntactically.  So adding support for "collection valued input parameters"
as function arg should be pretty straight forward.

And validation-wise I think it still works out nicely.  Basically that
leaves us 3 conditions:

   1. "collection valued input parameters" as IN expression value -
   supported by HQL and JPQL
   2. "collection valued input parameters" as (final) function argument -
   supported by HQL but not JPQL strictly
   3. "collection valued input parameters" anywhere else - not supported in
   HQL or JPQL




On Sat, Sep 10, 2016 at 9:43 AM Christian Beikov <christian.beikov at gmail.com>
wrote:

> My idea was to allow a parameter to be a collection valued parameter
> only in two cases
>
>  1. When used with the IN predicate
>  2. When used as last argument for a function and the parameter is a
>     var-arg parameter
>
> That way the query can be validated upfront when knowing the registered
> functions and their argument types, but it's obviously not clear from
> just looking at the query string if a parameter is multi-valued or not.
> If you want to make the semantics independent of the functions, then you
> must introduce a syntax of course. I was just trying to suggest
> something that is mostly compatible to the way it is right now.
>
> Am 10.09.2016 um 16:10 schrieb Steve Ebersole:
> > WRT the "double caches"... yes there will be a few caches.
> >
> > I'm not understanding what that has to do with defining a clear
> > semantic for a particular language element.
> >
> > ----
> >
> > Look, to me this whole thing boils down to the fact that JPA defines
> > specific/limited support for this "collection valued input parameter"
> > language element.  It does that btw because the ideal in language
> > design is to be able to wholly understand the semantic of a part of a
> > query based only on the syntax[1]. Further, JPA requires that we
> > handle a user binding a "collection valued input parameter" directly
> > through #setParameter.
> >
> > So all told we have a set of overloaded methods (#setParameterList)
> > that are not really providing any value[2], but that are needed
> > because that provides the only indication we ever get that a
> > particular parameter placeholder identifies a "collection valued input
> > parameter" rather than a"single valued input parameter". For all the
> > reasons discussed[1], thats not the ideal language design because it
> > is not deterministic from the grammar.
> >
> > Think of it this way...  It would be nice++ to be able to say "this
> > parameter is allowing multi-valued input" or "this parameter is
> > expecting single-valued input (multi-value input disallowed)", right?
> > Its the whole reason JPA defines its grammar (BNF) the way it does, so
> > that we can properly validate the incoming parameter input.  Today I
> > can do something like this:
> >
> > s.createQuery("from Zoo z where z.name <http://z.name> = :name" )
> >        .setParameterList("name",new String[] {"San Antonio Zoo","Waco
> Zoo" } )
> >        .list();
> > That is a completely "valid" query.  Its not going to return anything
> > useful, but syntactically it is valid because we cannot understand the
> > proper semantic.   And we do not understand the proper semantic
> > because it is not deterministic wrt the grammar/syntax. Ideally you'd
> > want to throw an exception back to the user here as soon as they try
> > to call #setParameterList for a parameter we conceptually *know*
> > should not accept "collection valued input parameters"
> >
> > ----
> >
> > [1] This gets into language and grammar design, but there are a few
> > reasons you want to encode as much semantic understanding into the
> > syntax as possible.  There are a few reasons for this; the 2 main ones
> > for us:
> >
> >  1. validation - again, here if I understand that a parameter
> >     placeholder should or should-not allow "collection valued input
> >     parameter" I can apply better validation up front (the sooner this
> >     type of feedback can happen the better)
> >  2. performance - anytime the query itself is not clear as to its
> >     semantic there is going to be a performance aspect to resolving
> >     that unclarity.
> >
> > [2] I can see the argument of #setParameterList providing a better API
> > for passing the multi-value bind value in terms of type signature.
> > But ultimately IMO both "collection valued input parameter" and
> > "single valued input parameter" ought to be stored in one structure.
> > Today they are not, can't because we need to know that
> > #setParameterList was called instead of #setParameter because that is
> > our only understanding of the semantic - that this is a "collection
> > valued input parameter", not a"single valued input parameter".
> >
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sat Sep 10 11:02:14 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 10 Sep 2016 15:02:14 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9uQmyn2puxDRRH1ed24NRestzJffkzLCd-PGAu8--0hwg@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
	<cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>
	<CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>
	<CAFdSV9s4bSK9uzySPEmkR_GVqbB0ZiimVkccO0a3Vn8Ak0Tg9g@mail.gmail.com>
	<4523a12b-fb1f-e77f-620c-61ad8f3e1664@gmail.com>
	<CAFdSV9uQmyn2puxDRRH1ed24NRestzJffkzLCd-PGAu8--0hwg@mail.gmail.com>
Message-ID: <CAFdSV9tNRMpk+8qeaV7ouyhmBHHMydupN8WpTNHL8GvP+nFK2g@mail.gmail.com>

BTW... the question is not necessarily whether that parameter *is*
multi-valued.  The question is whether it *can be* multi-valued.

So from the initial SQM build we'd understand that a particular parameter
is used in a way that indicated that its binding might be multi-valued.
When we resolve that to a SQLFunction, e.g., we'd be able to ask the
SQLFunction if it accepts varargs and:

if ( sqmFunctionArgumentParameter.allowsMultiValues() ) {
    if ( !sqlFunction.acceptsVarargs() ) {
        log.debug( "SQLFunction [%s] does not accept varargs, adjusting
SqmParameterExpression [%s] used as argument to not allow multi-values, ..
);
        sqmFunctionArgumentParameter.allowMultiValues( false );
    }
}

On Sat, Sep 10, 2016 at 9:53 AM Steve Ebersole <steve at hibernate.org> wrote:

> We are actually getting close to being able to wholly determine FUNCTION
> syntactically.  So adding support for "collection valued input
> parameters" as function arg should be pretty straight forward.
>
> And validation-wise I think it still works out nicely.  Basically that
> leaves us 3 conditions:
>
>    1. "collection valued input parameters" as IN expression value -
>    supported by HQL and JPQL
>    2. "collection valued input parameters" as (final) function argument -
>    supported by HQL but not JPQL strictly
>    3. "collection valued input parameters" anywhere else - not supported
>    in HQL or JPQL
>
>
>
>
> On Sat, Sep 10, 2016 at 9:43 AM Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
>> My idea was to allow a parameter to be a collection valued parameter
>> only in two cases
>>
>>  1. When used with the IN predicate
>>  2. When used as last argument for a function and the parameter is a
>>     var-arg parameter
>>
>> That way the query can be validated upfront when knowing the registered
>> functions and their argument types, but it's obviously not clear from
>> just looking at the query string if a parameter is multi-valued or not.
>> If you want to make the semantics independent of the functions, then you
>> must introduce a syntax of course. I was just trying to suggest
>> something that is mostly compatible to the way it is right now.
>>
>> Am 10.09.2016 um 16:10 schrieb Steve Ebersole:
>> > WRT the "double caches"... yes there will be a few caches.
>> >
>> > I'm not understanding what that has to do with defining a clear
>> > semantic for a particular language element.
>> >
>> > ----
>> >
>> > Look, to me this whole thing boils down to the fact that JPA defines
>> > specific/limited support for this "collection valued input parameter"
>> > language element.  It does that btw because the ideal in language
>> > design is to be able to wholly understand the semantic of a part of a
>> > query based only on the syntax[1]. Further, JPA requires that we
>> > handle a user binding a "collection valued input parameter" directly
>> > through #setParameter.
>> >
>> > So all told we have a set of overloaded methods (#setParameterList)
>> > that are not really providing any value[2], but that are needed
>> > because that provides the only indication we ever get that a
>> > particular parameter placeholder identifies a "collection valued input
>> > parameter" rather than a"single valued input parameter". For all the
>> > reasons discussed[1], thats not the ideal language design because it
>> > is not deterministic from the grammar.
>> >
>> > Think of it this way...  It would be nice++ to be able to say "this
>> > parameter is allowing multi-valued input" or "this parameter is
>> > expecting single-valued input (multi-value input disallowed)", right?
>> > Its the whole reason JPA defines its grammar (BNF) the way it does, so
>> > that we can properly validate the incoming parameter input.  Today I
>> > can do something like this:
>> >
>> > s.createQuery("from Zoo z where z.name <http://z.name> = :name" )
>> >        .setParameterList("name",new String[] {"San Antonio Zoo","Waco
>> Zoo" } )
>> >        .list();
>> > That is a completely "valid" query.  Its not going to return anything
>> > useful, but syntactically it is valid because we cannot understand the
>> > proper semantic.   And we do not understand the proper semantic
>> > because it is not deterministic wrt the grammar/syntax. Ideally you'd
>> > want to throw an exception back to the user here as soon as they try
>> > to call #setParameterList for a parameter we conceptually *know*
>> > should not accept "collection valued input parameters"
>> >
>> > ----
>> >
>> > [1] This gets into language and grammar design, but there are a few
>> > reasons you want to encode as much semantic understanding into the
>> > syntax as possible.  There are a few reasons for this; the 2 main ones
>> > for us:
>> >
>> >  1. validation - again, here if I understand that a parameter
>> >     placeholder should or should-not allow "collection valued input
>> >     parameter" I can apply better validation up front (the sooner this
>> >     type of feedback can happen the better)
>> >  2. performance - anytime the query itself is not clear as to its
>> >     semantic there is going to be a performance aspect to resolving
>> >     that unclarity.
>> >
>> > [2] I can see the argument of #setParameterList providing a better API
>> > for passing the multi-value bind value in terms of type signature.
>> > But ultimately IMO both "collection valued input parameter" and
>> > "single valued input parameter" ought to be stored in one structure.
>> > Today they are not, can't because we need to know that
>> > #setParameterList was called instead of #setParameter because that is
>> > our only understanding of the semantic - that this is a "collection
>> > valued input parameter", not a"single valued input parameter".
>> >
>> >
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Sun Sep 11 09:48:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 11 Sep 2016 13:48:47 +0000
Subject: [hibernate-dev] Continue "parameter list" support?
In-Reply-To: <CAFdSV9tNRMpk+8qeaV7ouyhmBHHMydupN8WpTNHL8GvP+nFK2g@mail.gmail.com>
References: <CAFdSV9s0j96fLhmVn04AROJs_B+=pjAoLs7ypLU_fJgXzogR0Q@mail.gmail.com>
	<CAL00eSTK66+w-wv1cYYrPBJ64iPG=yDjszA9beBG0ksuV3suYA@mail.gmail.com>
	<CA+gWKMAHcY_FWRTjTV7BHpaAbOOvJfiEGpy8toBVQguVB7nkzw@mail.gmail.com>
	<CAFdSV9v+SQmb4gtqzyngx9YCYjRKasYYjB0zqFc=+RkiaWxo7Q@mail.gmail.com>
	<CAFdSV9u4AUUA_jmfhfeO0qddx29cqg8iP7HqgdtO53V4QcwNEg@mail.gmail.com>
	<df07a619-d40c-8078-88d5-6f1b44edf6cd@gmail.com>
	<CAFdSV9svDc7Ln4g-5Az8MhgeNVu_P_9f7m_BaW8T7wVN=38eyA@mail.gmail.com>
	<CAFdSV9tGNPDUH_OGZ8UzW4hu9ZBhsFaRfsjMAcFdv=brbycTpw@mail.gmail.com>
	<cb0d7284-6a4d-04d8-a060-b5c914d579af@gmail.com>
	<CAFdSV9tcQMdfP==1oAfb4j+zw+w7XBzR9ayOqK7xxKsSN2KVzg@mail.gmail.com>
	<CAFdSV9s4bSK9uzySPEmkR_GVqbB0ZiimVkccO0a3Vn8Ak0Tg9g@mail.gmail.com>
	<4523a12b-fb1f-e77f-620c-61ad8f3e1664@gmail.com>
	<CAFdSV9uQmyn2puxDRRH1ed24NRestzJffkzLCd-PGAu8--0hwg@mail.gmail.com>
	<CAFdSV9tNRMpk+8qeaV7ouyhmBHHMydupN8WpTNHL8GvP+nFK2g@mail.gmail.com>
Message-ID: <CAFdSV9uVkXT79OowHDmg_ZPbu0+m6E5QrgxDzmVPUNi4z1XT_A@mail.gmail.com>

The direction I went for now was to push collection of the parameters to
SQM itself and expose that from SqmStatement#getQueryParameters.
Additionally I have SQM validate the positional parameters per JPA spec
(1-based, contiguous).

I added org.hibernate.sqm.query.Parameter#allowsMultiValuedBinding which
gets set based on the parameters context.  We can leverage that in ORM.
The one caveat to that is the function stuff because atm SQM has no "object
view" of a function (SQLFunction or otherwise) so it has no idea if a
function allows "varargs"... we will have to either:

   1. validate that on the ORM side
   2. provide some "object view" of a function to SQM (via ConsumerContext)
   to check that.

(2) is nice because it would also allow us to understand the result-type of
a function also.


On Sat, Sep 10, 2016 at 10:02 AM Steve Ebersole <steve at hibernate.org> wrote:

> BTW... the question is not necessarily whether that parameter *is*
> multi-valued.  The question is whether it *can be* multi-valued.
>
> So from the initial SQM build we'd understand that a particular parameter
> is used in a way that indicated that its binding might be multi-valued.
> When we resolve that to a SQLFunction, e.g., we'd be able to ask the
> SQLFunction if it accepts varargs and:
>
> if ( sqmFunctionArgumentParameter.allowsMultiValues() ) {
>     if ( !sqlFunction.acceptsVarargs() ) {
>         log.debug( "SQLFunction [%s] does not accept varargs, adjusting
> SqmParameterExpression [%s] used as argument to not allow multi-values, ..
> );
>         sqmFunctionArgumentParameter.allowMultiValues( false );
>     }
> }
>
> On Sat, Sep 10, 2016 at 9:53 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> We are actually getting close to being able to wholly determine FUNCTION
>> syntactically.  So adding support for "collection valued input
>> parameters" as function arg should be pretty straight forward.
>>
>> And validation-wise I think it still works out nicely.  Basically that
>> leaves us 3 conditions:
>>
>>    1. "collection valued input parameters" as IN expression value -
>>    supported by HQL and JPQL
>>    2. "collection valued input parameters" as (final) function argument
>>    - supported by HQL but not JPQL strictly
>>    3. "collection valued input parameters" anywhere else - not supported
>>    in HQL or JPQL
>>
>>
>>
>>
>> On Sat, Sep 10, 2016 at 9:43 AM Christian Beikov <
>> christian.beikov at gmail.com> wrote:
>>
>>> My idea was to allow a parameter to be a collection valued parameter
>>> only in two cases
>>>
>>>  1. When used with the IN predicate
>>>  2. When used as last argument for a function and the parameter is a
>>>     var-arg parameter
>>>
>>> That way the query can be validated upfront when knowing the registered
>>> functions and their argument types, but it's obviously not clear from
>>> just looking at the query string if a parameter is multi-valued or not.
>>> If you want to make the semantics independent of the functions, then you
>>> must introduce a syntax of course. I was just trying to suggest
>>> something that is mostly compatible to the way it is right now.
>>>
>>> Am 10.09.2016 um 16:10 schrieb Steve Ebersole:
>>> > WRT the "double caches"... yes there will be a few caches.
>>> >
>>> > I'm not understanding what that has to do with defining a clear
>>> > semantic for a particular language element.
>>> >
>>> > ----
>>> >
>>> > Look, to me this whole thing boils down to the fact that JPA defines
>>> > specific/limited support for this "collection valued input parameter"
>>> > language element.  It does that btw because the ideal in language
>>> > design is to be able to wholly understand the semantic of a part of a
>>> > query based only on the syntax[1]. Further, JPA requires that we
>>> > handle a user binding a "collection valued input parameter" directly
>>> > through #setParameter.
>>> >
>>> > So all told we have a set of overloaded methods (#setParameterList)
>>> > that are not really providing any value[2], but that are needed
>>> > because that provides the only indication we ever get that a
>>> > particular parameter placeholder identifies a "collection valued input
>>> > parameter" rather than a"single valued input parameter". For all the
>>> > reasons discussed[1], thats not the ideal language design because it
>>> > is not deterministic from the grammar.
>>> >
>>> > Think of it this way...  It would be nice++ to be able to say "this
>>> > parameter is allowing multi-valued input" or "this parameter is
>>> > expecting single-valued input (multi-value input disallowed)", right?
>>> > Its the whole reason JPA defines its grammar (BNF) the way it does, so
>>> > that we can properly validate the incoming parameter input.  Today I
>>> > can do something like this:
>>> >
>>> > s.createQuery("from Zoo z where z.name <http://z.name> = :name" )
>>> >        .setParameterList("name",new String[] {"San Antonio Zoo","Waco
>>> Zoo" } )
>>> >        .list();
>>> > That is a completely "valid" query.  Its not going to return anything
>>> > useful, but syntactically it is valid because we cannot understand the
>>> > proper semantic.   And we do not understand the proper semantic
>>> > because it is not deterministic wrt the grammar/syntax. Ideally you'd
>>> > want to throw an exception back to the user here as soon as they try
>>> > to call #setParameterList for a parameter we conceptually *know*
>>> > should not accept "collection valued input parameters"
>>> >
>>> > ----
>>> >
>>> > [1] This gets into language and grammar design, but there are a few
>>> > reasons you want to encode as much semantic understanding into the
>>> > syntax as possible.  There are a few reasons for this; the 2 main ones
>>> > for us:
>>> >
>>> >  1. validation - again, here if I understand that a parameter
>>> >     placeholder should or should-not allow "collection valued input
>>> >     parameter" I can apply better validation up front (the sooner this
>>> >     type of feedback can happen the better)
>>> >  2. performance - anytime the query itself is not clear as to its
>>> >     semantic there is going to be a performance aspect to resolving
>>> >     that unclarity.
>>> >
>>> > [2] I can see the argument of #setParameterList providing a better API
>>> > for passing the multi-value bind value in terms of type signature.
>>> > But ultimately IMO both "collection valued input parameter" and
>>> > "single valued input parameter" ought to be stored in one structure.
>>> > Today they are not, can't because we need to know that
>>> > #setParameterList was called instead of #setParameter because that is
>>> > our only understanding of the semantic - that this is a "collection
>>> > valued input parameter", not a"single valued input parameter".
>>> >
>>> >
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From steve at hibernate.org  Sun Sep 11 22:49:45 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 12 Sep 2016 02:49:45 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
Message-ID: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>

Another legacy concept I'd like to revisit as we move to 6.0 is the
Hibernate ResultTransformer.  I'd argue that ResultTransformer is no longer
needed, especially in it's current form.

Specifically, ResultTransformer defines 2 distinct ways to transform the
results of a query:

   1. `#transformTuple` - this method operates on each "row" of the result,
   allowing the user to transform the Object[] into some other structure.
   This is specifically the one I see no value in moving forward.  Between
   dynamic-instantiation, Tuple-handling, etc I think users have the needed
   capabilities to transform the query result tuples.
   2. `#transformList` - this one operates on the query result as a whole
   (unless scroll/iterate are used).  This method at least adds something that
   cannot be done in another way.   But I'd still personally question its
   overall usefulness.

Does anyone have an argument for continuing to support either of these?
Personally, I propose just dropping the ResultTransformer support
altogether.

From steve at hibernate.org  Sun Sep 11 23:02:15 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 12 Sep 2016 03:02:15 +0000
Subject: [hibernate-dev] 6.0 - Session#createFilter
Message-ID: <CAFdSV9tfsfGFiQ4seuN30bzEPSA80qHr+KdGosLhoTj1shLK_w@mail.gmail.com>

Another method I'd like to drop is Session#createFilter.  This is method is
easy enough to replace with a call to createQuery instead.  Longer term I
can also see Stream or DSL support from our persistent collections to
provide the similar capabilities.  But for now its just no real benefit for
the cost of overly-complicating the grammars.

From mihalcea.vlad at gmail.com  Mon Sep 12 01:38:44 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 12 Sep 2016 08:38:44 +0300
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
Message-ID: <CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>

Hi,

We definitely need to address the ResultTranformer.
Only the former method is what we should be exposing, the latter being used
only in one particular use case, so that should be addressed by a different
contract.

This way we could provide a ResultTransformer using a lambda, which is not
possible today.

Vlad

On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Another legacy concept I'd like to revisit as we move to 6.0 is the
> Hibernate ResultTransformer.  I'd argue that ResultTransformer is no longer
> needed, especially in it's current form.
>
> Specifically, ResultTransformer defines 2 distinct ways to transform the
> results of a query:
>
>    1. `#transformTuple` - this method operates on each "row" of the result,
>    allowing the user to transform the Object[] into some other structure.
>    This is specifically the one I see no value in moving forward.  Between
>    dynamic-instantiation, Tuple-handling, etc I think users have the needed
>    capabilities to transform the query result tuples.
>    2. `#transformList` - this one operates on the query result as a whole
>    (unless scroll/iterate are used).  This method at least adds something
> that
>    cannot be done in another way.   But I'd still personally question its
>    overall usefulness.
>
> Does anyone have an argument for continuing to support either of these?
> Personally, I propose just dropping the ResultTransformer support
> altogether.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Mon Sep 12 01:41:21 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 12 Sep 2016 08:41:21 +0300
Subject: [hibernate-dev] 6.0 - Session#createFilter
In-Reply-To: <CAFdSV9tfsfGFiQ4seuN30bzEPSA80qHr+KdGosLhoTj1shLK_w@mail.gmail.com>
References: <CAFdSV9tfsfGFiQ4seuN30bzEPSA80qHr+KdGosLhoTj1shLK_w@mail.gmail.com>
Message-ID: <CA+gWKMAeh+Rp3w2+A4HOj7Az4qNphmo4qs17H30iR6VNxafNKw@mail.gmail.com>

I agree. The createFilter can be moved to the Query, so we don't require
this to be in the Session interface.

I haven't seen many questions about this functionality, so I guess we
shouldn't worry to much about this change.

Vlad

On Mon, Sep 12, 2016 at 6:02 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Another method I'd like to drop is Session#createFilter.  This is method is
> easy enough to replace with a call to createQuery instead.  Longer term I
> can also see Stream or DSL support from our persistent collections to
> provide the similar capabilities.  But for now its just no real benefit for
> the cost of overly-complicating the grammars.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Sep 12 06:58:18 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 12 Sep 2016 10:58:18 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
Message-ID: <CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>

The former though is specifically what I see no use for.  Do you have a
specific use case in mind that cannot be addressed by other mechanisms
(Tuple, dynamic-instantiation,  etc)?

On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> We definitely need to address the ResultTranformer.
> Only the former method is what we should be exposing, the latter being
> used only in one particular use case, so that should be addressed by a
> different contract.
>
> This way we could provide a ResultTransformer using a lambda, which is not
> possible today.
>
> Vlad
>
> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Another legacy concept I'd like to revisit as we move to 6.0 is the
>> Hibernate ResultTransformer.  I'd argue that ResultTransformer is no
>> longer
>> needed, especially in it's current form.
>>
>> Specifically, ResultTransformer defines 2 distinct ways to transform the
>> results of a query:
>>
>>    1. `#transformTuple` - this method operates on each "row" of the
>> result,
>
>
>>    allowing the user to transform the Object[] into some other structure.
>>    This is specifically the one I see no value in moving forward.  Between
>>    dynamic-instantiation, Tuple-handling, etc I think users have the
>> needed
>>    capabilities to transform the query result tuples.
>>
>    2. `#transformList` - this one operates on the query result as a whole
>
>
>>    (unless scroll/iterate are used).  This method at least adds something
>> that
>>    cannot be done in another way.   But I'd still personally question its
>>    overall usefulness.
>>
>> Does anyone have an argument for continuing to support either of these?
>> Personally, I propose just dropping the ResultTransformer support
>> altogether.
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From mihalcea.vlad at gmail.com  Mon Sep 12 07:09:14 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 12 Sep 2016 14:09:14 +0300
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
Message-ID: <CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>

Sure. I've used it recently to group a tree-like structure as follows:

public class PostCommentScoreResultTransformer
    implements ResultTransformer {

    private Map<Long, PostCommentScore> postCommentScoreMap = new
HashMap<>();

    private List<PostCommentScore> roots = new ArrayList<>();

    @Override
    public Object transformTuple(Object[] tuple, String[] aliases) {
        PostCommentScore commentScore = (PostCommentScore) tuple[0];
        Long parentId = commentScore.getParentId();
        if (parentId == null) {
            roots.add(commentScore);
        } else {
            PostCommentScore parent = postCommentScoreMap.get(parentId);
            if (parent != null) {
                parent.addChild(commentScore);
            }
        }
        postCommentScoreMap.putIfAbsent(commentScore.getId(), commentScore);
        return commentScore;
    }

    @Override
    public List transformList(List collection) {
        return roots;
    }
}

The results were fetched using a Recursive CTE and I wanted the results to
be assembled back in a N-level hierarchy, starting from a Root node.

On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve at hibernate.org> wrote:

> The former though is specifically what I see no use for.  Do you have a
> specific use case in mind that cannot be addressed by other mechanisms
> (Tuple, dynamic-instantiation,  etc)?
>
> On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> We definitely need to address the ResultTranformer.
>> Only the former method is what we should be exposing, the latter being
>> used only in one particular use case, so that should be addressed by a
>> different contract.
>>
>> This way we could provide a ResultTransformer using a lambda, which is
>> not possible today.
>>
>> Vlad
>>
>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Another legacy concept I'd like to revisit as we move to 6.0 is the
>>> Hibernate ResultTransformer.  I'd argue that ResultTransformer is no
>>> longer
>>> needed, especially in it's current form.
>>>
>>> Specifically, ResultTransformer defines 2 distinct ways to transform the
>>> results of a query:
>>>
>>>    1. `#transformTuple` - this method operates on each "row" of the
>>> result,
>>
>>
>>>    allowing the user to transform the Object[] into some other structure.
>>>    This is specifically the one I see no value in moving forward.
>>> Between
>>>    dynamic-instantiation, Tuple-handling, etc I think users have the
>>> needed
>>>    capabilities to transform the query result tuples.
>>>
>>    2. `#transformList` - this one operates on the query result as a whole
>>
>>
>>>    (unless scroll/iterate are used).  This method at least adds
>>> something that
>>>    cannot be done in another way.   But I'd still personally question its
>>>    overall usefulness.
>>>
>>> Does anyone have an argument for continuing to support either of these?
>>> Personally, I propose just dropping the ResultTransformer support
>>> altogether.
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>

From yrodiere at redhat.com  Mon Sep 12 07:19:25 2016
From: yrodiere at redhat.com (Yoann Rodiere)
Date: Mon, 12 Sep 2016 13:19:25 +0200
Subject: [hibernate-dev] Add entity with InheritanceType.JOINED to
	native query
In-Reply-To: <A25A791B-6F09-4910-ABC9-2CC3EDA52F99@youngmediaexperts.nl>
References: <A25A791B-6F09-4910-ABC9-2CC3EDA52F99@youngmediaexperts.nl>
Message-ID: <CAEqagpqnnxnUP_Y8r9kHRDSYy1X2CNqODHVymv9DHLBmDGC1wQ@mail.gmail.com>

Hi,

I'll let it to actual Hibernate ORM developers (which I'm not) to give you
a proper answer (if they have one), but this seems like a bug to me. You
best course of action may be to provide a test case and provide it as part
of a ticket on JIRA: https://hibernate.atlassian.net/ .

If you really are in a hurry and can't wait for this to be fixed...
My previous team had to work this around in one of our projects once, and
we ultimately resorted to some ugly hack that would rely on the fact that
Hibernate generates semi-deterministic aliases for JOINed tables. I don't
remember the specifics, but this definitely involved guessing
Hibernate-generated aliases.
For instance, if "s" is your main table alias, Hibernate will use something
like "s_1_" for the table mapped to the first child class, "s_2_" for the
second child class, and so on. You can then try guessing the aliases and
make use of them in your JOIN clause instead of your custom alias ("{a}"),
being careful to remove the braces. The order seems to be stable for each
subsequent execution, but has been seen to change when doing major code
updates (though I couldn't say which).
As I said, this is ugly. It may do for non-essential, well-tested code that
won't have to evolve much, but this isn't necessarily your case.

Yoann

On 7 September 2016 at 03:41, Jan-Willem Gmelig Meyling <
jan-willem at youngmediaexperts.nl> wrote:

> Hi Hibernate developers,
>
> I stumbled upon an issue today and I am wondering whether the following
> would be possible using Hibernate, and if not, whether such could actually
> be implemented, or if I actually hit a boundary of the alias injection.
>
> My problem has to do with trying to map the result set of a native query
> to an entity that uses the JOINED InheritanceType. After adding the enitity
> to my NativeQuery as follows, the aliases for the tables of the subclasses
> are not set properly (obviously). My question is, though, would it be
> possible to set these as well? As I can?t figure this out from the current
> documentation (that only states that all columns should be present in the
> result set, which I assume to apply to a InheritanceType.SINGLE_TABLE
> primarily).
>
> The code I am currently using to construct the query is as follows:
>
>
> session
>    .createNativeQuery("SELECT {s.*} FROM my_super {s} LEFT JOIN my_sub_a
> {a} USING (id)")
>    .addEntity("s", MySuper.class)
>    .getSingleResult();
>
> Additional code is available on Github gist: https://gist.github.com/
> JWGmeligMeyling/51e8a305f3c268eda473511e202f76e8
>
> And my question is also posted on Stackoverflow (to gain some extra
> credits for the answer ;-) ):
> http://stackoverflow.com/questions/39359924/add-entity-
> with-inheritancetype-joined-to-native-query
>
> Thanks in advance,
>
> Jan-Willem
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Sep 12 07:29:38 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 12 Sep 2016 11:29:38 +0000
Subject: [hibernate-dev] 6.0 - Session#createFilter
In-Reply-To: <CA+gWKMAeh+Rp3w2+A4HOj7Az4qNphmo4qs17H30iR6VNxafNKw@mail.gmail.com>
References: <CAFdSV9tfsfGFiQ4seuN30bzEPSA80qHr+KdGosLhoTj1shLK_w@mail.gmail.com>
	<CA+gWKMAeh+Rp3w2+A4HOj7Az4qNphmo4qs17H30iR6VNxafNKw@mail.gmail.com>
Message-ID: <CAFdSV9tvmKeMEYqo31RAcRrA6sPosP4V3eKOwaykUmHtU_ngzg@mail.gmail.com>

To be clear, I do not mean moving the method from Session to Query.  More
as a user you would convert the call from Session#createFilter to
Session#createQuery

The "intent" of this #createFilter call is better served design-wise as a
stream/filter on the collection.


On Mon, Sep 12, 2016 at 12:41 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I agree. The createFilter can be moved to the Query, so we don't require
> this to be in the Session interface.
>
> I haven't seen many questions about this functionality, so I guess we
> shouldn't worry to much about this change.
>
> Vlad
>
> On Mon, Sep 12, 2016 at 6:02 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Another method I'd like to drop is Session#createFilter.  This is method
>> is
>> easy enough to replace with a call to createQuery instead.  Longer term I
>> can also see Stream or DSL support from our persistent collections to
>> provide the similar capabilities.  But for now its just no real benefit
>> for
>> the cost of overly-complicating the grammars.
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Mon Sep 12 07:36:53 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 12 Sep 2016 11:36:53 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
Message-ID: <CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>

So your example actually leverages both methods...  Well technically it
only really needs the latter method (#transformList); you could have done
all that work there - the elements of the passed collection would be the
individual tuples.




On Mon, Sep 12, 2016 at 6:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Sure. I've used it recently to group a tree-like structure as follows:
>
> public class PostCommentScoreResultTransformer
>     implements ResultTransformer {
>
>     private Map<Long, PostCommentScore> postCommentScoreMap = new
> HashMap<>();
>
>     private List<PostCommentScore> roots = new ArrayList<>();
>
>     @Override
>     public Object transformTuple(Object[] tuple, String[] aliases) {
>         PostCommentScore commentScore = (PostCommentScore) tuple[0];
>         Long parentId = commentScore.getParentId();
>         if (parentId == null) {
>             roots.add(commentScore);
>         } else {
>             PostCommentScore parent = postCommentScoreMap.get(parentId);
>             if (parent != null) {
>                 parent.addChild(commentScore);
>             }
>         }
>         postCommentScoreMap.putIfAbsent(commentScore.getId(),
> commentScore);
>         return commentScore;
>     }
>
>     @Override
>     public List transformList(List collection) {
>         return roots;
>     }
> }
>
> The results were fetched using a Recursive CTE and I wanted the results to
> be assembled back in a N-level hierarchy, starting from a Root node.
>
> On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> The former though is specifically what I see no use for.  Do you have a
>> specific use case in mind that cannot be addressed by other mechanisms
>> (Tuple, dynamic-instantiation,  etc)?
>>
>> On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> We definitely need to address the ResultTranformer.
>>> Only the former method is what we should be exposing, the latter being
>>> used only in one particular use case, so that should be addressed by a
>>> different contract.
>>>
>>> This way we could provide a ResultTransformer using a lambda, which is
>>> not possible today.
>>>
>>> Vlad
>>>
>>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> Another legacy concept I'd like to revisit as we move to 6.0 is the
>>>> Hibernate ResultTransformer.  I'd argue that ResultTransformer is no
>>>> longer
>>>> needed, especially in it's current form.
>>>>
>>>> Specifically, ResultTransformer defines 2 distinct ways to transform the
>>>> results of a query:
>>>>
>>>>    1. `#transformTuple` - this method operates on each "row" of the
>>>> result,
>>>
>>>
>>>>    allowing the user to transform the Object[] into some other
>>>> structure.
>>>>    This is specifically the one I see no value in moving forward.
>>>> Between
>>>>    dynamic-instantiation, Tuple-handling, etc I think users have the
>>>> needed
>>>>    capabilities to transform the query result tuples.
>>>>
>>>    2. `#transformList` - this one operates on the query result as a whole
>>>
>>>
>>>>    (unless scroll/iterate are used).  This method at least adds
>>>> something that
>>>>    cannot be done in another way.   But I'd still personally question
>>>> its
>>>>    overall usefulness.
>>>>
>>>> Does anyone have an argument for continuing to support either of these?
>>>> Personally, I propose just dropping the ResultTransformer support
>>>> altogether.
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>

From guillaume.smet at gmail.com  Mon Sep 12 10:08:22 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 12 Sep 2016 16:08:22 +0200
Subject: [hibernate-dev] NoORM team meeting minutes
Message-ID: <CALt0+o9_QVT_t=6UaOBoVeBqwUyQZCurZ9va+HXb0ZS6uJtz0g@mail.gmail.com>

Hi all,

It just occurred to me this morning that I forgot to send the minutes
of the last NoORM team meeting.

So, here they are:

http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-30-13.00.html
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-30-13.00.txt
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-30-13.00.log.html

As for the grouping discussion and concerning the issue with
properties generated by the datastore, the issue is that we need to
flush the pending changes and get the generated values from the
datastore before processing the generated properties (and potentially
putting the entity in the cache).

The 2 proposals to get it working were:
1. when one does a tuple or association read, we check the cache of
operations and flush it if the entity has generated values
2. we call an explicit GridDialect new method when we refresh the
entry to read the generated value

IMHO, 2. was the best option (it's easier to control when the
operations are really executed) so that's what I implemented in the PR
I just posted.

-- 
Guillaume

From steve at hibernate.org  Mon Sep 12 10:17:48 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 12 Sep 2016 14:17:48 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
Message-ID: <CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>

Gail, IIRC one of these methods causes problems with regards to query
result caching.  Do I remember that correctly?  And if so, do you remember
which one?  I'd guess #transformTuples, but I forget the details.


On Mon, Sep 12, 2016 at 6:36 AM Steve Ebersole <steve at hibernate.org> wrote:

> So your example actually leverages both methods...  Well technically it
> only really needs the latter method (#transformList); you could have done
> all that work there - the elements of the passed collection would be the
> individual tuples.
>
>
>
>
> On Mon, Sep 12, 2016 at 6:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Sure. I've used it recently to group a tree-like structure as follows:
>>
>> public class PostCommentScoreResultTransformer
>>     implements ResultTransformer {
>>
>>     private Map<Long, PostCommentScore> postCommentScoreMap = new
>> HashMap<>();
>>
>>     private List<PostCommentScore> roots = new ArrayList<>();
>>
>>     @Override
>>     public Object transformTuple(Object[] tuple, String[] aliases) {
>>         PostCommentScore commentScore = (PostCommentScore) tuple[0];
>>         Long parentId = commentScore.getParentId();
>>         if (parentId == null) {
>>             roots.add(commentScore);
>>         } else {
>>             PostCommentScore parent = postCommentScoreMap.get(parentId);
>>             if (parent != null) {
>>                 parent.addChild(commentScore);
>>             }
>>         }
>>         postCommentScoreMap.putIfAbsent(commentScore.getId(),
>> commentScore);
>>         return commentScore;
>>     }
>>
>>     @Override
>>     public List transformList(List collection) {
>>         return roots;
>>     }
>> }
>>
>> The results were fetched using a Recursive CTE and I wanted the results
>> to be assembled back in a N-level hierarchy, starting from a Root node.
>>
>> On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> The former though is specifically what I see no use for.  Do you have a
>>> specific use case in mind that cannot be addressed by other mechanisms
>>> (Tuple, dynamic-instantiation,  etc)?
>>>
>>> On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> We definitely need to address the ResultTranformer.
>>>> Only the former method is what we should be exposing, the latter being
>>>> used only in one particular use case, so that should be addressed by a
>>>> different contract.
>>>>
>>>> This way we could provide a ResultTransformer using a lambda, which is
>>>> not possible today.
>>>>
>>>> Vlad
>>>>
>>>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> Another legacy concept I'd like to revisit as we move to 6.0 is the
>>>>> Hibernate ResultTransformer.  I'd argue that ResultTransformer is no
>>>>> longer
>>>>> needed, especially in it's current form.
>>>>>
>>>>> Specifically, ResultTransformer defines 2 distinct ways to transform
>>>>> the
>>>>> results of a query:
>>>>>
>>>>>    1. `#transformTuple` - this method operates on each "row" of the
>>>>> result,
>>>>
>>>>
>>>>>    allowing the user to transform the Object[] into some other
>>>>> structure.
>>>>>    This is specifically the one I see no value in moving forward.
>>>>> Between
>>>>>    dynamic-instantiation, Tuple-handling, etc I think users have the
>>>>> needed
>>>>>    capabilities to transform the query result tuples.
>>>>>
>>>>    2. `#transformList` - this one operates on the query result as a
>>>>> whole
>>>>
>>>>
>>>>>    (unless scroll/iterate are used).  This method at least adds
>>>>> something that
>>>>>    cannot be done in another way.   But I'd still personally question
>>>>> its
>>>>>    overall usefulness.
>>>>>
>>>>> Does anyone have an argument for continuing to support either of these?
>>>>> Personally, I propose just dropping the ResultTransformer support
>>>>> altogether.
>>>>>
>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>

From guillaume.smet at gmail.com  Mon Sep 12 11:31:23 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 12 Sep 2016 17:31:23 +0200
Subject: [hibernate-dev] [OGM] Issue with a test and the new operation
	grouping infrastructure
Message-ID: <CALt0+o8c2uNii-P7O30HP=3WnE3ccy6jVwMk5BLW7e5ROBVg5A@mail.gmail.com>

Hi,

This is a follow-up of https://github.com/hibernate/hibernate-ogm/pull/767 .

So, in the PR, I commented the following test:
ManyToOneGlobalTest>ManyToOneTest.testRemovalOfTransientEntityWithAssociation
(the "ManyToOneGlobalTest>" part is important)

The test is a Redis one but the issue is a general one.

When running under the ManyToOneGlobalTest umbrella, the associations
are created as separate documents.

The behavior of the test is the following:

========================

=== Creation phase

Create a SalesForce with 2 SalesGuys associated.

The association is managed by SalesGuy.

It creates 4 documents:
SalesForce1
SalesGuy1
SalesGuy2
SalesForce1_SalesGuy navigational information

=== Let's delete the SalesForce1 entity

It removes the SalesForce1 document (note that SalesGuy.salesForce has
a @NotFound(action = NotFoundAction.IGNORE) annotation).

So we end up with having:
SalesGuy1
SalesGuy2
SalesForce1_SalesGuy navigational information [1]

=== Then we delete the 2 SalesGuy

SalesGuys1 removed
-> SalesForce_SalesGuy navigational information updated
SalesGuy2 removed
-> SalesForce1_SalesGuy navigational information removed as it is empty [2]

========================

In [1], we still have the navigational information for SalesForce1 <->
SalesGuys.

With the new grouping infrastructure, I don't save every operation to
the datastore as it's currently done. I have to store the Association
object somewhere to keep track of the association state so I store it
in OgmEntityEntryState in a Map<String, Association>, the key being
the role of the association, just next to the Tuple which has the same
purpose. It works perfectly well except that when we arrive at [2],
the OgmEntityEntryState for SalesForce1 is gone as the entity has been
removed in [1] so I can't access the OgmEntityEntryState of the entity
and so the association document is not removed (and thus the test
fails as it checks there isn't any entity/association left).

Gunnar proposed the idea of storing the inverse Associations in the
OgmEntityEntryState of the association owner. It's indeed one way to
solve the issue.

The issue with this approach is that we need to have the association
owner when we create the AssociationPersister and, while it's not a
problem for most of the cases, I don't see how I can do it in
OgmLoader#getResultSet. I posted a WIP patch here:
https://gist.github.com/gsmet/e18ccb7d3f3494bb334647e540d0d4d0.

Opinions, thoughts?

-- 
Guillaume

From steve at hibernate.org  Mon Sep 12 19:33:11 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 12 Sep 2016 23:33:11 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
Message-ID: <CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>

If we are going to support #transformTuple (in whatever form) we need to
decide on a precedence between that, resultClass, dynamic-instantiation, etc

Specifically, what is the meaning of:

session.createQuery( "select new DTO(...) ...", DTO.class )
        .setTupleTransformer( () -> ... )
        ...

And what if they dont match necessarily, like:

session.createQuery( "select new DTO(...) ...", Tuple.class )
        .setTupleTransformer( () -> ... )



On Mon, Sep 12, 2016 at 9:17 AM Steve Ebersole <steve at hibernate.org> wrote:

> Gail, IIRC one of these methods causes problems with regards to query
> result caching.  Do I remember that correctly?  And if so, do you remember
> which one?  I'd guess #transformTuples, but I forget the details.
>
>
> On Mon, Sep 12, 2016 at 6:36 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> So your example actually leverages both methods...  Well technically it
>> only really needs the latter method (#transformList); you could have done
>> all that work there - the elements of the passed collection would be the
>> individual tuples.
>>
>>
>>
>>
>> On Mon, Sep 12, 2016 at 6:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Sure. I've used it recently to group a tree-like structure as follows:
>>>
>>> public class PostCommentScoreResultTransformer
>>>     implements ResultTransformer {
>>>
>>>     private Map<Long, PostCommentScore> postCommentScoreMap = new
>>> HashMap<>();
>>>
>>>     private List<PostCommentScore> roots = new ArrayList<>();
>>>
>>>     @Override
>>>     public Object transformTuple(Object[] tuple, String[] aliases) {
>>>         PostCommentScore commentScore = (PostCommentScore) tuple[0];
>>>         Long parentId = commentScore.getParentId();
>>>         if (parentId == null) {
>>>             roots.add(commentScore);
>>>         } else {
>>>             PostCommentScore parent = postCommentScoreMap.get(parentId);
>>>             if (parent != null) {
>>>                 parent.addChild(commentScore);
>>>             }
>>>         }
>>>         postCommentScoreMap.putIfAbsent(commentScore.getId(),
>>> commentScore);
>>>         return commentScore;
>>>     }
>>>
>>>     @Override
>>>     public List transformList(List collection) {
>>>         return roots;
>>>     }
>>> }
>>>
>>> The results were fetched using a Recursive CTE and I wanted the results
>>> to be assembled back in a N-level hierarchy, starting from a Root node.
>>>
>>> On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> The former though is specifically what I see no use for.  Do you have a
>>>> specific use case in mind that cannot be addressed by other mechanisms
>>>> (Tuple, dynamic-instantiation,  etc)?
>>>>
>>>> On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We definitely need to address the ResultTranformer.
>>>>> Only the former method is what we should be exposing, the latter being
>>>>> used only in one particular use case, so that should be addressed by a
>>>>> different contract.
>>>>>
>>>>> This way we could provide a ResultTransformer using a lambda, which is
>>>>> not possible today.
>>>>>
>>>>> Vlad
>>>>>
>>>>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> Another legacy concept I'd like to revisit as we move to 6.0 is the
>>>>>> Hibernate ResultTransformer.  I'd argue that ResultTransformer is no
>>>>>> longer
>>>>>> needed, especially in it's current form.
>>>>>>
>>>>>> Specifically, ResultTransformer defines 2 distinct ways to transform
>>>>>> the
>>>>>> results of a query:
>>>>>>
>>>>>>    1. `#transformTuple` - this method operates on each "row" of the
>>>>>> result,
>>>>>
>>>>>
>>>>>>    allowing the user to transform the Object[] into some other
>>>>>> structure.
>>>>>>    This is specifically the one I see no value in moving forward.
>>>>>> Between
>>>>>>    dynamic-instantiation, Tuple-handling, etc I think users have the
>>>>>> needed
>>>>>>    capabilities to transform the query result tuples.
>>>>>>
>>>>>    2. `#transformList` - this one operates on the query result as a
>>>>>> whole
>>>>>
>>>>>
>>>>>>    (unless scroll/iterate are used).  This method at least adds
>>>>>> something that
>>>>>>    cannot be done in another way.   But I'd still personally question
>>>>>> its
>>>>>>    overall usefulness.
>>>>>>
>>>>>> Does anyone have an argument for continuing to support either of
>>>>>> these?
>>>>>> Personally, I propose just dropping the ResultTransformer support
>>>>>> altogether.
>>>>>>
>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>>
>>>

From christian.beikov at gmail.com  Tue Sep 13 03:16:40 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 13 Sep 2016 09:16:40 +0200
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
	<CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
Message-ID: <42848f6f-fa00-4d36-5a7f-fce4d4283f1c@gmail.com>

I'd say one can either use the "new .." syntax, or a 
ResultTransformer/TupleTransformer but not both at the same time.
IMO you can do your DTO stuff in the transformer which is probably also 
one of the few usecases for ResultTransformer.

Am 13.09.2016 um 01:33 schrieb Steve Ebersole:
> If we are going to support #transformTuple (in whatever form) we need to
> decide on a precedence between that, resultClass, dynamic-instantiation, etc
>
> Specifically, what is the meaning of:
>
> session.createQuery( "select new DTO(...) ...", DTO.class )
>          .setTupleTransformer( () -> ... )
>          ...
>
> And what if they dont match necessarily, like:
>
> session.createQuery( "select new DTO(...) ...", Tuple.class )
>          .setTupleTransformer( () -> ... )
>
>
>
> On Mon, Sep 12, 2016 at 9:17 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Gail, IIRC one of these methods causes problems with regards to query
>> result caching.  Do I remember that correctly?  And if so, do you remember
>> which one?  I'd guess #transformTuples, but I forget the details.
>>
>>
>> On Mon, Sep 12, 2016 at 6:36 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> So your example actually leverages both methods...  Well technically it
>>> only really needs the latter method (#transformList); you could have done
>>> all that work there - the elements of the passed collection would be the
>>> individual tuples.
>>>
>>>
>>>
>>>
>>> On Mon, Sep 12, 2016 at 6:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Sure. I've used it recently to group a tree-like structure as follows:
>>>>
>>>> public class PostCommentScoreResultTransformer
>>>>      implements ResultTransformer {
>>>>
>>>>      private Map<Long, PostCommentScore> postCommentScoreMap = new
>>>> HashMap<>();
>>>>
>>>>      private List<PostCommentScore> roots = new ArrayList<>();
>>>>
>>>>      @Override
>>>>      public Object transformTuple(Object[] tuple, String[] aliases) {
>>>>          PostCommentScore commentScore = (PostCommentScore) tuple[0];
>>>>          Long parentId = commentScore.getParentId();
>>>>          if (parentId == null) {
>>>>              roots.add(commentScore);
>>>>          } else {
>>>>              PostCommentScore parent = postCommentScoreMap.get(parentId);
>>>>              if (parent != null) {
>>>>                  parent.addChild(commentScore);
>>>>              }
>>>>          }
>>>>          postCommentScoreMap.putIfAbsent(commentScore.getId(),
>>>> commentScore);
>>>>          return commentScore;
>>>>      }
>>>>
>>>>      @Override
>>>>      public List transformList(List collection) {
>>>>          return roots;
>>>>      }
>>>> }
>>>>
>>>> The results were fetched using a Recursive CTE and I wanted the results
>>>> to be assembled back in a N-level hierarchy, starting from a Root node.
>>>>
>>>> On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> The former though is specifically what I see no use for.  Do you have a
>>>>> specific use case in mind that cannot be addressed by other mechanisms
>>>>> (Tuple, dynamic-instantiation,  etc)?
>>>>>
>>>>> On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We definitely need to address the ResultTranformer.
>>>>>> Only the former method is what we should be exposing, the latter being
>>>>>> used only in one particular use case, so that should be addressed by a
>>>>>> different contract.
>>>>>>
>>>>>> This way we could provide a ResultTransformer using a lambda, which is
>>>>>> not possible today.
>>>>>>
>>>>>> Vlad
>>>>>>
>>>>>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Another legacy concept I'd like to revisit as we move to 6.0 is the
>>>>>>> Hibernate ResultTransformer.  I'd argue that ResultTransformer is no
>>>>>>> longer
>>>>>>> needed, especially in it's current form.
>>>>>>>
>>>>>>> Specifically, ResultTransformer defines 2 distinct ways to transform
>>>>>>> the
>>>>>>> results of a query:
>>>>>>>
>>>>>>>     1. `#transformTuple` - this method operates on each "row" of the
>>>>>>> result,
>>>>>>
>>>>>>>     allowing the user to transform the Object[] into some other
>>>>>>> structure.
>>>>>>>     This is specifically the one I see no value in moving forward.
>>>>>>> Between
>>>>>>>     dynamic-instantiation, Tuple-handling, etc I think users have the
>>>>>>> needed
>>>>>>>     capabilities to transform the query result tuples.
>>>>>>>
>>>>>>     2. `#transformList` - this one operates on the query result as a
>>>>>>> whole
>>>>>>
>>>>>>>     (unless scroll/iterate are used).  This method at least adds
>>>>>>> something that
>>>>>>>     cannot be done in another way.   But I'd still personally question
>>>>>>> its
>>>>>>>     overall usefulness.
>>>>>>>
>>>>>>> Does anyone have an argument for continuing to support either of
>>>>>>> these?
>>>>>>> Personally, I propose just dropping the ResultTransformer support
>>>>>>> altogether.
>>>>>>>
>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gunnar at hibernate.org  Tue Sep 13 03:25:59 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 13 Sep 2016 09:25:59 +0200
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <42848f6f-fa00-4d36-5a7f-fce4d4283f1c@gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
	<CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
	<42848f6f-fa00-4d36-5a7f-fce4d4283f1c@gmail.com>
Message-ID: <CADGJaX9rr1AXkSpMzwdh4JUSJmpj-pNA4U0juw37a8-01JpNpQ@mail.gmail.com>

> Between dynamic-instantiation, Tuple-handling...

To be sure, WDYM by "tuple-handling"?

One use case for result transformers are full-text searches executed
through Hibernate Search's Session extension FullTextSession (see [1]).

For full-text searches we don't use HQL/JPQL, so the "new ..." syntax
cannot be used, but I don't know about tuple-handling.

Either way the solution should be friendly towards Java 8 Lambda style,
i.e. work with functional interfaces (see [2] for a previous discussion of
this very case of result transformers).

--Gunnar

[1] http://in.relation.to/2016/03/02/converting-projection-results-of-full-
text-queries-into-pojos/
[2] http://lists.jboss.org/pipermail/hibernate-dev/2016-March/014409.html





2016-09-13 9:16 GMT+02:00 Christian Beikov <christian.beikov at gmail.com>:

> I'd say one can either use the "new .." syntax, or a
> ResultTransformer/TupleTransformer but not both at the same time.
> IMO you can do your DTO stuff in the transformer which is probably also
> one of the few usecases for ResultTransformer.
>
> Am 13.09.2016 um 01:33 schrieb Steve Ebersole:
> > If we are going to support #transformTuple (in whatever form) we need to
> > decide on a precedence between that, resultClass, dynamic-instantiation,
> etc
> >
> > Specifically, what is the meaning of:
> >
> > session.createQuery( "select new DTO(...) ...", DTO.class )
> >          .setTupleTransformer( () -> ... )
> >          ...
> >
> > And what if they dont match necessarily, like:
> >
> > session.createQuery( "select new DTO(...) ...", Tuple.class )
> >          .setTupleTransformer( () -> ... )
> >
> >
> >
> > On Mon, Sep 12, 2016 at 9:17 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> Gail, IIRC one of these methods causes problems with regards to query
> >> result caching.  Do I remember that correctly?  And if so, do you
> remember
> >> which one?  I'd guess #transformTuples, but I forget the details.
> >>
> >>
> >> On Mon, Sep 12, 2016 at 6:36 AM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> So your example actually leverages both methods...  Well technically it
> >>> only really needs the latter method (#transformList); you could have
> done
> >>> all that work there - the elements of the passed collection would be
> the
> >>> individual tuples.
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Sep 12, 2016 at 6:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com
> >
> >>> wrote:
> >>>
> >>>> Sure. I've used it recently to group a tree-like structure as follows:
> >>>>
> >>>> public class PostCommentScoreResultTransformer
> >>>>      implements ResultTransformer {
> >>>>
> >>>>      private Map<Long, PostCommentScore> postCommentScoreMap = new
> >>>> HashMap<>();
> >>>>
> >>>>      private List<PostCommentScore> roots = new ArrayList<>();
> >>>>
> >>>>      @Override
> >>>>      public Object transformTuple(Object[] tuple, String[] aliases) {
> >>>>          PostCommentScore commentScore = (PostCommentScore) tuple[0];
> >>>>          Long parentId = commentScore.getParentId();
> >>>>          if (parentId == null) {
> >>>>              roots.add(commentScore);
> >>>>          } else {
> >>>>              PostCommentScore parent = postCommentScoreMap.get(parent
> Id);
> >>>>              if (parent != null) {
> >>>>                  parent.addChild(commentScore);
> >>>>              }
> >>>>          }
> >>>>          postCommentScoreMap.putIfAbsent(commentScore.getId(),
> >>>> commentScore);
> >>>>          return commentScore;
> >>>>      }
> >>>>
> >>>>      @Override
> >>>>      public List transformList(List collection) {
> >>>>          return roots;
> >>>>      }
> >>>> }
> >>>>
> >>>> The results were fetched using a Recursive CTE and I wanted the
> results
> >>>> to be assembled back in a N-level hierarchy, starting from a Root
> node.
> >>>>
> >>>> On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve at hibernate.org>
> >>>> wrote:
> >>>>
> >>>>> The former though is specifically what I see no use for.  Do you
> have a
> >>>>> specific use case in mind that cannot be addressed by other
> mechanisms
> >>>>> (Tuple, dynamic-instantiation,  etc)?
> >>>>>
> >>>>> On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> We definitely need to address the ResultTranformer.
> >>>>>> Only the former method is what we should be exposing, the latter
> being
> >>>>>> used only in one particular use case, so that should be addressed
> by a
> >>>>>> different contract.
> >>>>>>
> >>>>>> This way we could provide a ResultTransformer using a lambda, which
> is
> >>>>>> not possible today.
> >>>>>>
> >>>>>> Vlad
> >>>>>>
> >>>>>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <
> steve at hibernate.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Another legacy concept I'd like to revisit as we move to 6.0 is the
> >>>>>>> Hibernate ResultTransformer.  I'd argue that ResultTransformer is
> no
> >>>>>>> longer
> >>>>>>> needed, especially in it's current form.
> >>>>>>>
> >>>>>>> Specifically, ResultTransformer defines 2 distinct ways to
> transform
> >>>>>>> the
> >>>>>>> results of a query:
> >>>>>>>
> >>>>>>>     1. `#transformTuple` - this method operates on each "row" of
> the
> >>>>>>> result,
> >>>>>>
> >>>>>>>     allowing the user to transform the Object[] into some other
> >>>>>>> structure.
> >>>>>>>     This is specifically the one I see no value in moving forward.
> >>>>>>> Between
> >>>>>>>     dynamic-instantiation, Tuple-handling, etc I think users have
> the
> >>>>>>> needed
> >>>>>>>     capabilities to transform the query result tuples.
> >>>>>>>
> >>>>>>     2. `#transformList` - this one operates on the query result as a
> >>>>>>> whole
> >>>>>>
> >>>>>>>     (unless scroll/iterate are used).  This method at least adds
> >>>>>>> something that
> >>>>>>>     cannot be done in another way.   But I'd still personally
> question
> >>>>>>> its
> >>>>>>>     overall usefulness.
> >>>>>>>
> >>>>>>> Does anyone have an argument for continuing to support either of
> >>>>>>> these?
> >>>>>>> Personally, I propose just dropping the ResultTransformer support
> >>>>>>> altogether.
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>>> hibernate-dev mailing list
> >>>>>>> hibernate-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>
> >>>>>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Tue Sep 13 03:54:21 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 13 Sep 2016 09:54:21 +0200
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
	<CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
Message-ID: <20160913075421.GD41558@hibernate.org>

My preference would be to keep some form of resultTransformer around,
especially the first method that is redundant.

And it's mainly because it is very easy to write one and plug. The HQL
based instantiation is fine when you use it but as Gunnar mentioned,
this is not always the case. What is the Tuple handling method BTW?

For ordering, I always thought if result transformers as happening after
the result of a query. Since the query transform things into DTO objects
in your example, the result transformer would receive DTO.

BTW what does happen in this case?
session.createQuery( "select new DTO(...) ...", Tuple.class ).list();

Some exception or is Tuple treated specifically?

Emmanuel

On Mon 2016-09-12 23:33, Steve Ebersole wrote:
>If we are going to support #transformTuple (in whatever form) we need to
>decide on a precedence between that, resultClass, dynamic-instantiation, etc
>
>Specifically, what is the meaning of:
>
>session.createQuery( "select new DTO(...) ...", DTO.class )
>        .setTupleTransformer( () -> ... )
>        ...
>
>And what if they dont match necessarily, like:
>
>session.createQuery( "select new DTO(...) ...", Tuple.class )
>        .setTupleTransformer( () -> ... )
>
>
>
>On Mon, Sep 12, 2016 at 9:17 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Gail, IIRC one of these methods causes problems with regards to query
>> result caching.  Do I remember that correctly?  And if so, do you remember
>> which one?  I'd guess #transformTuples, but I forget the details.
>>
>>
>> On Mon, Sep 12, 2016 at 6:36 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> So your example actually leverages both methods...  Well technically it
>>> only really needs the latter method (#transformList); you could have done
>>> all that work there - the elements of the passed collection would be the
>>> individual tuples.
>>>
>>>
>>>
>>>
>>> On Mon, Sep 12, 2016 at 6:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Sure. I've used it recently to group a tree-like structure as follows:
>>>>
>>>> public class PostCommentScoreResultTransformer
>>>>     implements ResultTransformer {
>>>>
>>>>     private Map<Long, PostCommentScore> postCommentScoreMap = new
>>>> HashMap<>();
>>>>
>>>>     private List<PostCommentScore> roots = new ArrayList<>();
>>>>
>>>>     @Override
>>>>     public Object transformTuple(Object[] tuple, String[] aliases) {
>>>>         PostCommentScore commentScore = (PostCommentScore) tuple[0];
>>>>         Long parentId = commentScore.getParentId();
>>>>         if (parentId == null) {
>>>>             roots.add(commentScore);
>>>>         } else {
>>>>             PostCommentScore parent = postCommentScoreMap.get(parentId);
>>>>             if (parent != null) {
>>>>                 parent.addChild(commentScore);
>>>>             }
>>>>         }
>>>>         postCommentScoreMap.putIfAbsent(commentScore.getId(),
>>>> commentScore);
>>>>         return commentScore;
>>>>     }
>>>>
>>>>     @Override
>>>>     public List transformList(List collection) {
>>>>         return roots;
>>>>     }
>>>> }
>>>>
>>>> The results were fetched using a Recursive CTE and I wanted the results
>>>> to be assembled back in a N-level hierarchy, starting from a Root node.
>>>>
>>>> On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> The former though is specifically what I see no use for.  Do you have a
>>>>> specific use case in mind that cannot be addressed by other mechanisms
>>>>> (Tuple, dynamic-instantiation,  etc)?
>>>>>
>>>>> On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We definitely need to address the ResultTranformer.
>>>>>> Only the former method is what we should be exposing, the latter being
>>>>>> used only in one particular use case, so that should be addressed by a
>>>>>> different contract.
>>>>>>
>>>>>> This way we could provide a ResultTransformer using a lambda, which is
>>>>>> not possible today.
>>>>>>
>>>>>> Vlad
>>>>>>
>>>>>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Another legacy concept I'd like to revisit as we move to 6.0 is the
>>>>>>> Hibernate ResultTransformer.  I'd argue that ResultTransformer is no
>>>>>>> longer
>>>>>>> needed, especially in it's current form.
>>>>>>>
>>>>>>> Specifically, ResultTransformer defines 2 distinct ways to transform
>>>>>>> the
>>>>>>> results of a query:
>>>>>>>
>>>>>>>    1. `#transformTuple` - this method operates on each "row" of the
>>>>>>> result,
>>>>>>
>>>>>>
>>>>>>>    allowing the user to transform the Object[] into some other
>>>>>>> structure.
>>>>>>>    This is specifically the one I see no value in moving forward.
>>>>>>> Between
>>>>>>>    dynamic-instantiation, Tuple-handling, etc I think users have the
>>>>>>> needed
>>>>>>>    capabilities to transform the query result tuples.
>>>>>>>
>>>>>>    2. `#transformList` - this one operates on the query result as a
>>>>>>> whole
>>>>>>
>>>>>>
>>>>>>>    (unless scroll/iterate are used).  This method at least adds
>>>>>>> something that
>>>>>>>    cannot be done in another way.   But I'd still personally question
>>>>>>> its
>>>>>>>    overall usefulness.
>>>>>>>
>>>>>>> Does anyone have an argument for continuing to support either of
>>>>>>> these?
>>>>>>> Personally, I propose just dropping the ResultTransformer support
>>>>>>> altogether.
>>>>>>>
>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>
>_______________________________________________
>hibernate-dev mailing list
>hibernate-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Tue Sep 13 04:19:31 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 13 Sep 2016 10:19:31 +0200
Subject: [hibernate-dev] OpenJDK proposal: JDK 9 modules and reflection
Message-ID: <20160913081931.GE41558@hibernate.org>

Hi all,

Sanne kindly pointed out to me the latest proposal by the OpenJDK team
around JDK 9 module and how they would handle frameworks needing access
to non exported types (Hibernate, dependency injection, etc).

If you are remotely into JDK9, please read it and provide feedback.
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000390.html

It's better than before for sure. It feels to me that most applications
(the core of it) will end up being a weak module for this to work
though. I'm not sure whether it is good or bad, at least a isolation
concious person has the choice.

    export private some.package;

Is essentially equivalent to what you can do for a given package in Java
8.
What I am less clear about is what relation Hibernate * projects really
need with a module containing the entities. Do we still this proposal
still mandates to use

    requires hibernate.entitymanager;
    requires hibernate.core;

in the targeted module?

Or would this be a usable module

    module foo.bar {
        exports private com.foo.bar.model;
        requires javax.jpa;
        // requires hibernate.entitymanager/core; no longer needed thanks to export private?
    }

Mark proposes that in a container (EE or anything controlling module loading
really), the container adds dynamically the addExports to the relevant
framework. But that looks like a solution to limit exports private
implications.

Comments?

Emmanuel

From steve at hibernate.org  Tue Sep 13 09:52:01 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Sep 2016 13:52:01 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CADGJaX9rr1AXkSpMzwdh4JUSJmpj-pNA4U0juw37a8-01JpNpQ@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
	<CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
	<42848f6f-fa00-4d36-5a7f-fce4d4283f1c@gmail.com>
	<CADGJaX9rr1AXkSpMzwdh4JUSJmpj-pNA4U0juw37a8-01JpNpQ@mail.gmail.com>
Message-ID: <CAFdSV9tZGUUbCexiF3kYAA5+RUrT47Q-UK5C6AvF5Yiv1FFmvQ@mail.gmail.com>

On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> > Between dynamic-instantiation, Tuple-handling...
>
> To be sure, WDYM by "tuple-handling"?
>

javax.persistence.Tuple

So I gave just one example earlier of how all of these things do not
necessarily fit together in inherently obvious ways.  Some combinations I
think are ok; others are not.  In sitting here and trying to describe this
to a user from a documentation perspective, it is not a simple explanation.

I'll follow up with a separate reply that covers those combos for
discussion.


One use case for result transformers are full-text searches executed
> through Hibernate Search's Session extension FullTextSession (see [1]).
>
> For full-text searches we don't use HQL/JPQL, so the "new ..." syntax
> cannot be used, but I don't know about tuple-handling.
>

Well for sure you do not allow the user to use HQL/JPQL.  But I'd have to
assume that under the covers you handle resolving that FullTextQuery
yourself from the indexes - which means this is not even a ORM Query at all
and what we do with ResultTransformer in ORM in regards to Query is
completely irrelevant for you.  In other words I would have to think that
Search itself is applying that ResultTransformer in your example, not ORM.
Very different.

From steve at hibernate.org  Tue Sep 13 09:59:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Sep 2016 13:59:47 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <20160913075421.GD41558@hibernate.org>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
	<CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
	<20160913075421.GD41558@hibernate.org>
Message-ID: <CAFdSV9vDGW7doU7nXLchXVk-yKAhwt3SMxOjt3pm09bH4-QC1A@mail.gmail.com>

On Tue, Sep 13, 2016 at 5:23 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> My preference would be to keep some form of resultTransformer around,
> especially the first method that is redundant.
>
> And it's mainly because it is very easy to write one and plug. The HQL
> based instantiation is fine when you use it but as Gunnar mentioned,
> this is not always the case. What is the Tuple handling method BTW?
>

Well if you refer to the Search case Gunnar mentioned, I do not think that
is valid per this discussion (how ResultTransformer plugs into the ORM
Query contract) as I mentioned in my reply to him.


For ordering, I always thought if result transformers as happening after
> the result of a query. Since the query transform things into DTO objects
> in your example, the result transformer would receive DTO.
>

All of these things get applied "after the query".  In fact
dynamic-instantiation and Tuple-handling are today (5.x and prior) handled
by plugging in an implicit ResultTransformer!  You can see part of the
problem :)  Personally I think routing those through ResultTransformer is a
bad idea, and that will change in 6.0.


BTW what does happen in this case?
> session.createQuery( "select new DTO(...) ...", Tuple.class ).list();
>
> Some exception or is Tuple treated specifically?
>

TBH I am not sure.  TIAS. But like I said  dynamic-instantiation and
Tuple-handling are handled internally as ResultTransformers, so my guess is
that the last one wins.

From christian.beikov at gmail.com  Tue Sep 13 10:06:12 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 13 Sep 2016 16:06:12 +0200
Subject: [hibernate-dev] Hibernate 6.0 status?
Message-ID: <2d248bad-ec14-5ddf-2e65-bb2d291dcedc@gmail.com>

Is there a more or less stable version of Hibernate 6 that can be used 
for early testing?
I'd like to provide feedback from an integration point of view.
Are there any Hibernate 6 builds in a Maven repository?

If not, is there a plan for Alpha releases? I'd like to make sure my 
schedule is clear to be able to provide fast feeback.

Regards,
Christian

From steve at hibernate.org  Tue Sep 13 10:19:46 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Sep 2016 14:19:46 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9tZGUUbCexiF3kYAA5+RUrT47Q-UK5C6AvF5Yiv1FFmvQ@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
	<CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
	<42848f6f-fa00-4d36-5a7f-fce4d4283f1c@gmail.com>
	<CADGJaX9rr1AXkSpMzwdh4JUSJmpj-pNA4U0juw37a8-01JpNpQ@mail.gmail.com>
	<CAFdSV9tZGUUbCexiF3kYAA5+RUrT47Q-UK5C6AvF5Yiv1FFmvQ@mail.gmail.com>
Message-ID: <CAFdSV9tQu6h8jzKCfzbx_-BgUZGS8m0AZk6ShY2oZq-UVotrWA@mail.gmail.com>

So again, this all boils down to the interplay with
(Result|Tuple|ResultList)Transformer, dynamic instantiations, and
result-types.

So let's look at some specific cases...

First some cases I think are perfectly valid:

session.createQuery( "select new map(...) ...", Map.class ) - returns a
List<Map<String,?>>
session.createQuery( "select new list(...) ...", List.class ) - returns a
List<List> (rather than List<Object[]>)
session.createQuery( "select new DTO(...), DTO.class ) - returns a List<DTO>

Ok, so I cheated there by not including transformers :)  So let's look at
adding transformers into this mix[1].

session.createQuery( "select new map(...) ...", Map.class )
        .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )

this one is illegal.  It defines the Query resultType as Map, but the
applied TupleTranformer is transforming those to SomeNonMap -> CCE.  This
should be either:

session.createQuery( "select new map(...) ...", SomeNonMap.class )
        .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )

or (non-typed):

session.createQuery( "select new map(...) ..." )
        .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )

In both of those cases, the TupleTranformer is handed a Object[] where the
only element is the Map.

I guess too that defines the blueprint for what is and what is not
supported and how the various pieces apply.


But I am still not sure about the semantic wrt TupleTransformer and/or
dynamic-instantiation in combination with Tuple.  I kind of think those
should just be illegal combos:

session.createQuery( "select ...", Tuple.class )
        .setTupleTransformer( () -> ... )

Unless the TupleTransformer is building a Tuple, I that is a bad combo for
sure.

I thik dynamic-instantiation and TupleTransformer is ok:

session.createQuery( "select new DTO(...) ..." )
        .setTupleTransformer( () -> ... )

Here the TupleTransformer would get Object[] with the long element being
the DTO; the "query result" is whatever the TupleTransformer returns.

Any other specific combos we should clarify?



[1]  I am using the new TupleTransformer and ResultListTransformer
breakdowns I have defined on 6.0 :
https://gist.github.com/sebersole/bc721caa20a5e4a97cbde44567b0b2ea



On Tue, Sep 13, 2016 at 8:52 AM Steve Ebersole <steve at hibernate.org> wrote:

> On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> > Between dynamic-instantiation, Tuple-handling...
>>
>> To be sure, WDYM by "tuple-handling"?
>>
>
> javax.persistence.Tuple
>
> So I gave just one example earlier of how all of these things do not
> necessarily fit together in inherently obvious ways.  Some combinations I
> think are ok; others are not.  In sitting here and trying to describe this
> to a user from a documentation perspective, it is not a simple explanation.
>
> I'll follow up with a separate reply that covers those combos for
> discussion.
>
>
> One use case for result transformers are full-text searches executed
>> through Hibernate Search's Session extension FullTextSession (see [1]).
>>
>> For full-text searches we don't use HQL/JPQL, so the "new ..." syntax
>> cannot be used, but I don't know about tuple-handling.
>>
>
> Well for sure you do not allow the user to use HQL/JPQL.  But I'd have to
> assume that under the covers you handle resolving that FullTextQuery
> yourself from the indexes - which means this is not even a ORM Query at all
> and what we do with ResultTransformer in ORM in regards to Query is
> completely irrelevant for you.  In other words I would have to think that
> Search itself is applying that ResultTransformer in your example, not ORM.
> Very different.
>

From steve at hibernate.org  Tue Sep 13 10:24:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Sep 2016 14:24:47 +0000
Subject: [hibernate-dev] Hibernate 6.0 status?
In-Reply-To: <2d248bad-ec14-5ddf-2e65-bb2d291dcedc@gmail.com>
References: <2d248bad-ec14-5ddf-2e65-bb2d291dcedc@gmail.com>
Message-ID: <CAFdSV9u_wKxqp=d7AeM260_QrcfcaiPTmhjNwzt5qZ=DoRhS=A@mail.gmail.com>

It is still a WIP and is not yet buildable.  But you can follow the
progress: https://github.com/sebersole/hibernate-core/tree/wip/6.0


On Tue, Sep 13, 2016 at 9:10 AM Christian Beikov <christian.beikov at gmail.com>
wrote:

> Is there a more or less stable version of Hibernate 6 that can be used
> for early testing?
> I'd like to provide feedback from an integration point of view.
> Are there any Hibernate 6 builds in a Maven repository?
>
> If not, is there a plan for Alpha releases? I'd like to make sure my
> schedule is clear to be able to provide fast feeback.
>
> Regards,
> Christian
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue Sep 13 10:29:20 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 13 Sep 2016 15:29:20 +0100
Subject: [hibernate-dev] Usage of Session#getTransaction() being banned from
 the Hibernate Search code
Message-ID: <CAFm4XO1L++9=j2TA=euMkwbwXc=GbXPUoSZ398-BVLgypSiBCw@mail.gmail.com>

Since Hibernate ORM 5.2, the method getTransaction() on Session needs
to behave according to EntityManager spec, which implies that it has
to throw an exception in certain circumstances which depend on the
configuration.

Hibernate Search used this method in various places, for example to
integrate with the current transaction's events, or even to control
the transaction explicitly in the case of the MassIndexer.

Since we want Hibernate Search to work fine with Hibernate ORM no
matter what configuration is being used, we need to avoid invoking
this method.
The solution is extremely simple: use its SPI level replacement, which
is SessionImplementor#accessTransaction().

Unfortunately most of our Search/ORM tests happen to run without a
Transaction Manager so if you happen to use the old method, the tests
would pass and everything would seem fine - however your shiny new
feature would not work in certain configurations.

One solution to verify we're not using it, is to ban this method using
the "forbiddenapi" plugin:
 - https://github.com/Sanne/hibernate-search/commit/a980ee5dca0c7a58dd79ba98acd8a354bc5601e6#diff-600376dffeb79835ede4a0b285078036R1036

A more comprehensive integration test would be to re-run all tests
from the Search/ORM using a proper JTA configuration; not rushing to
refactor our testsuite now since we have the forbidden-apis plugin but
opening a JIRA task for 5.7, as this version will support ORM 5.7:
 - https://hibernate.atlassian.net/browse/HSEARCH-2344

Thanks,
Sanne

From guillaume.smet at gmail.com  Tue Sep 13 10:31:46 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 13 Sep 2016 16:31:46 +0200
Subject: [hibernate-dev] NoORM team meeting minutes
Message-ID: <CALt0+o97W_MAh_GFLRMAhvWHzhsCWpD5fUxH6sd_KBXZt3==Ww@mail.gmail.com>

Hi!

As usual, the NoORM team meeting minutes.

16:26 < jbott> Meeting ended Tue Sep 13 14:25:49 2016 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:26 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-13-13.00.html
16:26 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-13-13.00.txt
16:26 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-13-13.00.log.html

Emmanuel, quick summary of what you missed:
- Organization for the review of the OGM PRs:
. Hot Rod: Gunnar
. Operation grouping: Davide, Yoann, Gunnar (for the overall approach)
. Neo4j Bolt: Guillaume
- Java 9 module:
-> moved to the Friday hangout

-- 
Guillaume

From steve at hibernate.org  Tue Sep 13 10:54:48 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Sep 2016 14:54:48 +0000
Subject: [hibernate-dev] Usage of Session#getTransaction() being banned
 from the Hibernate Search code
In-Reply-To: <CAFm4XO1L++9=j2TA=euMkwbwXc=GbXPUoSZ398-BVLgypSiBCw@mail.gmail.com>
References: <CAFm4XO1L++9=j2TA=euMkwbwXc=GbXPUoSZ398-BVLgypSiBCw@mail.gmail.com>
Message-ID: <CAFdSV9uEk2dRC5uhoavpCtXyEuwC=wnAkTPBxSDPbbVgLjGs4Q@mail.gmail.com>

NIce!  I never knew of this plugin, but there is a Gradle plugin for it as
well.

On Tue, Sep 13, 2016 at 9:33 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Since Hibernate ORM 5.2, the method getTransaction() on Session needs
> to behave according to EntityManager spec, which implies that it has
> to throw an exception in certain circumstances which depend on the
> configuration.
>
> Hibernate Search used this method in various places, for example to
> integrate with the current transaction's events, or even to control
> the transaction explicitly in the case of the MassIndexer.
>
> Since we want Hibernate Search to work fine with Hibernate ORM no
> matter what configuration is being used, we need to avoid invoking
> this method.
> The solution is extremely simple: use its SPI level replacement, which
> is SessionImplementor#accessTransaction().
>
> Unfortunately most of our Search/ORM tests happen to run without a
> Transaction Manager so if you happen to use the old method, the tests
> would pass and everything would seem fine - however your shiny new
> feature would not work in certain configurations.
>
> One solution to verify we're not using it, is to ban this method using
> the "forbiddenapi" plugin:
>  -
> https://github.com/Sanne/hibernate-search/commit/a980ee5dca0c7a58dd79ba98acd8a354bc5601e6#diff-600376dffeb79835ede4a0b285078036R1036
>
> A more comprehensive integration test would be to re-run all tests
> from the Search/ORM using a proper JTA configuration; not rushing to
> refactor our testsuite now since we have the forbidden-apis plugin but
> opening a JIRA task for 5.7, as this version will support ORM 5.7:
>  - https://hibernate.atlassian.net/browse/HSEARCH-2344
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Sep 13 19:00:33 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Sep 2016 23:00:33 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9tQu6h8jzKCfzbx_-BgUZGS8m0AZk6ShY2oZq-UVotrWA@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
	<CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
	<42848f6f-fa00-4d36-5a7f-fce4d4283f1c@gmail.com>
	<CADGJaX9rr1AXkSpMzwdh4JUSJmpj-pNA4U0juw37a8-01JpNpQ@mail.gmail.com>
	<CAFdSV9tZGUUbCexiF3kYAA5+RUrT47Q-UK5C6AvF5Yiv1FFmvQ@mail.gmail.com>
	<CAFdSV9tQu6h8jzKCfzbx_-BgUZGS8m0AZk6ShY2oZq-UVotrWA@mail.gmail.com>
Message-ID: <CAFdSV9tMgzAh9uXcCN5d=B4g5Z0CC-E0ia38szjxa86LqicZAw@mail.gmail.com>

So here is the path I am following initially.. It is straightforward to
explain to a user which I like.

In terms of processing each "row" in a result there is the RowTransformer
contract I mentioned earlier, or maybe I mentioned on HipChat.  I added the
capability for RowTransformer to be nested, specifically I defined 2 levels:

   1. an implicit RowTransformer.  This is resolved based on the following
   chart:
      1. If there is a resultType and it is Object[].class we do a "pass
      thru"
      2. If there is a resultType and it is Tuple.class we do use a
      RowTransformer adapter that builds a Tuple
      3. If there is just one selection we transform the Object[] by
      returning just row[0]
   2. a RowTransformer adapter for TupleTransformer, if specified

And just a word on dynamic-instantiation here.. it is actually done prior
to any of this.  In fact, in 6.0 a dynamic-instantiation is no different
that other selectable expressions.



On Tue, Sep 13, 2016 at 9:19 AM Steve Ebersole <steve at hibernate.org> wrote:

> So again, this all boils down to the interplay with
> (Result|Tuple|ResultList)Transformer, dynamic instantiations, and
> result-types.
>
> So let's look at some specific cases...
>
> First some cases I think are perfectly valid:
>
> session.createQuery( "select new map(...) ...", Map.class ) - returns a
> List<Map<String,?>>
> session.createQuery( "select new list(...) ...", List.class ) - returns a
> List<List> (rather than List<Object[]>)
> session.createQuery( "select new DTO(...), DTO.class ) - returns a
> List<DTO>
>
> Ok, so I cheated there by not including transformers :)  So let's look at
> adding transformers into this mix[1].
>
> session.createQuery( "select new map(...) ...", Map.class )
>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
>
> this one is illegal.  It defines the Query resultType as Map, but the
> applied TupleTranformer is transforming those to SomeNonMap -> CCE.  This
> should be either:
>
> session.createQuery( "select new map(...) ...", SomeNonMap.class )
>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
>
> or (non-typed):
>
> session.createQuery( "select new map(...) ..." )
>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
>
> In both of those cases, the TupleTranformer is handed a Object[] where
> the only element is the Map.
>
> I guess too that defines the blueprint for what is and what is not
> supported and how the various pieces apply.
>
>
> But I am still not sure about the semantic wrt TupleTransformer and/or
> dynamic-instantiation in combination with Tuple.  I kind of think those
> should just be illegal combos:
>
> session.createQuery( "select ...", Tuple.class )
>         .setTupleTransformer( () -> ... )
>
> Unless the TupleTransformer is building a Tuple, I that is a bad combo for
> sure.
>
> I thik dynamic-instantiation and TupleTransformer is ok:
>
> session.createQuery( "select new DTO(...) ..." )
>         .setTupleTransformer( () -> ... )
>
> Here the TupleTransformer would get Object[] with the long element being
> the DTO; the "query result" is whatever the TupleTransformer returns.
>
> Any other specific combos we should clarify?
>
>
>
> [1]  I am using the new TupleTransformer and ResultListTransformer
> breakdowns I have defined on 6.0 :
> https://gist.github.com/sebersole/bc721caa20a5e4a97cbde44567b0b2ea
>
>
>
> On Tue, Sep 13, 2016 at 8:52 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> > Between dynamic-instantiation, Tuple-handling...
>>>
>>> To be sure, WDYM by "tuple-handling"?
>>>
>>
>> javax.persistence.Tuple
>>
>> So I gave just one example earlier of how all of these things do not
>> necessarily fit together in inherently obvious ways.  Some combinations
>> I think are ok; others are not.  In sitting here and trying to describe
>> this to a user from a documentation perspective, it is not a simple
>> explanation.
>>
>> I'll follow up with a separate reply that covers those combos for
>> discussion.
>>
>>
>> One use case for result transformers are full-text searches executed
>>> through Hibernate Search's Session extension FullTextSession (see [1]).
>>>
>>> For full-text searches we don't use HQL/JPQL, so the "new ..." syntax
>>> cannot be used, but I don't know about tuple-handling.
>>>
>>
>> Well for sure you do not allow the user to use HQL/JPQL.  But I'd have to
>> assume that under the covers you handle resolving that FullTextQuery
>> yourself from the indexes - which means this is not even a ORM Query at all
>> and what we do with ResultTransformer in ORM in regards to Query is
>> completely irrelevant for you.  In other words I would have to think that
>> Search itself is applying that ResultTransformer in your example, not ORM.
>> Very different.
>>
>

From steve at hibernate.org  Tue Sep 13 20:05:06 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 00:05:06 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9tMgzAh9uXcCN5d=B4g5Z0CC-E0ia38szjxa86LqicZAw@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
	<CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
	<42848f6f-fa00-4d36-5a7f-fce4d4283f1c@gmail.com>
	<CADGJaX9rr1AXkSpMzwdh4JUSJmpj-pNA4U0juw37a8-01JpNpQ@mail.gmail.com>
	<CAFdSV9tZGUUbCexiF3kYAA5+RUrT47Q-UK5C6AvF5Yiv1FFmvQ@mail.gmail.com>
	<CAFdSV9tQu6h8jzKCfzbx_-BgUZGS8m0AZk6ShY2oZq-UVotrWA@mail.gmail.com>
	<CAFdSV9tMgzAh9uXcCN5d=B4g5Z0CC-E0ia38szjxa86LqicZAw@mail.gmail.com>
Message-ID: <CAFdSV9vksQxQ-+bWbG5bp6dmq_Ujh+2nVoZtp_YzQdorArgTSA@mail.gmail.com>

Hmmm there is an interesting aspect to Tuple + TupleTransformer.. both
expect to get the root selection aliases and would naturally expect those
to match in length to the values to transform.  Basically only one can
"consume" the aliases.

I think that because Tuple is a "higher precedence" (it defines the result
type) it ought to win that battle.  But then that is inconsistent for
TupleTransformer.  IMO either we let Tuple consume the aliases or we
disallow this combo.

On Tue, Sep 13, 2016 at 6:00 PM Steve Ebersole <steve at hibernate.org> wrote:

> So here is the path I am following initially.. It is straightforward to
> explain to a user which I like.
>
> In terms of processing each "row" in a result there is the RowTransformer
> contract I mentioned earlier, or maybe I mentioned on HipChat.  I added the
> capability for RowTransformer to be nested, specifically I defined 2
> levels:
>
>    1. an implicit RowTransformer.  This is resolved based on the
>    following chart:
>       1. If there is a resultType and it is Object[].class we do a "pass
>       thru"
>       2. If there is a resultType and it is Tuple.class we do use a
>       RowTransformer adapter that builds a Tuple
>       3. If there is just one selection we transform the Object[] by
>       returning just row[0]
>    2. a RowTransformer adapter for TupleTransformer, if specified
>
> And just a word on dynamic-instantiation here.. it is actually done prior
> to any of this.  In fact, in 6.0 a dynamic-instantiation is no different
> that other selectable expressions.
>
>
>
> On Tue, Sep 13, 2016 at 9:19 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> So again, this all boils down to the interplay with
>> (Result|Tuple|ResultList)Transformer, dynamic instantiations, and
>> result-types.
>>
>> So let's look at some specific cases...
>>
>> First some cases I think are perfectly valid:
>>
>> session.createQuery( "select new map(...) ...", Map.class ) - returns a
>> List<Map<String,?>>
>> session.createQuery( "select new list(...) ...", List.class ) - returns a
>> List<List> (rather than List<Object[]>)
>> session.createQuery( "select new DTO(...), DTO.class ) - returns a
>> List<DTO>
>>
>> Ok, so I cheated there by not including transformers :)  So let's look at
>> adding transformers into this mix[1].
>>
>> session.createQuery( "select new map(...) ...", Map.class )
>>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
>>
>> this one is illegal.  It defines the Query resultType as Map, but the
>> applied TupleTranformer is transforming those to SomeNonMap -> CCE.
>> This should be either:
>>
>> session.createQuery( "select new map(...) ...", SomeNonMap.class )
>>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
>>
>> or (non-typed):
>>
>> session.createQuery( "select new map(...) ..." )
>>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
>>
>> In both of those cases, the TupleTranformer is handed a Object[] where
>> the only element is the Map.
>>
>> I guess too that defines the blueprint for what is and what is not
>> supported and how the various pieces apply.
>>
>>
>> But I am still not sure about the semantic wrt TupleTransformer and/or
>> dynamic-instantiation in combination with Tuple.  I kind of think those
>> should just be illegal combos:
>>
>> session.createQuery( "select ...", Tuple.class )
>>         .setTupleTransformer( () -> ... )
>>
>> Unless the TupleTransformer is building a Tuple, I that is a bad combo
>> for sure.
>>
>> I thik dynamic-instantiation and TupleTransformer is ok:
>>
>> session.createQuery( "select new DTO(...) ..." )
>>         .setTupleTransformer( () -> ... )
>>
>> Here the TupleTransformer would get Object[] with the long element being
>> the DTO; the "query result" is whatever the TupleTransformer returns.
>>
>> Any other specific combos we should clarify?
>>
>>
>>
>> [1]  I am using the new TupleTransformer and ResultListTransformer
>> breakdowns I have defined on 6.0 :
>> https://gist.github.com/sebersole/bc721caa20a5e4a97cbde44567b0b2ea
>>
>>
>>
>> On Tue, Sep 13, 2016 at 8:52 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>>> > Between dynamic-instantiation, Tuple-handling...
>>>>
>>>> To be sure, WDYM by "tuple-handling"?
>>>>
>>>
>>> javax.persistence.Tuple
>>>
>>> So I gave just one example earlier of how all of these things do not
>>> necessarily fit together in inherently obvious ways.  Some combinations
>>> I think are ok; others are not.  In sitting here and trying to describe
>>> this to a user from a documentation perspective, it is not a simple
>>> explanation.
>>>
>>> I'll follow up with a separate reply that covers those combos for
>>> discussion.
>>>
>>>
>>> One use case for result transformers are full-text searches executed
>>>> through Hibernate Search's Session extension FullTextSession (see [1]).
>>>>
>>>> For full-text searches we don't use HQL/JPQL, so the "new ..." syntax
>>>> cannot be used, but I don't know about tuple-handling.
>>>>
>>>
>>> Well for sure you do not allow the user to use HQL/JPQL.  But I'd have
>>> to assume that under the covers you handle resolving that FullTextQuery
>>> yourself from the indexes - which means this is not even a ORM Query at all
>>> and what we do with ResultTransformer in ORM in regards to Query is
>>> completely irrelevant for you.  In other words I would have to think that
>>> Search itself is applying that ResultTransformer in your example, not ORM.
>>> Very different.
>>>
>>

From steve at hibernate.org  Tue Sep 13 20:50:57 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 00:50:57 +0000
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9vksQxQ-+bWbG5bp6dmq_Ujh+2nVoZtp_YzQdorArgTSA@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
	<CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
	<42848f6f-fa00-4d36-5a7f-fce4d4283f1c@gmail.com>
	<CADGJaX9rr1AXkSpMzwdh4JUSJmpj-pNA4U0juw37a8-01JpNpQ@mail.gmail.com>
	<CAFdSV9tZGUUbCexiF3kYAA5+RUrT47Q-UK5C6AvF5Yiv1FFmvQ@mail.gmail.com>
	<CAFdSV9tQu6h8jzKCfzbx_-BgUZGS8m0AZk6ShY2oZq-UVotrWA@mail.gmail.com>
	<CAFdSV9tMgzAh9uXcCN5d=B4g5Z0CC-E0ia38szjxa86LqicZAw@mail.gmail.com>
	<CAFdSV9vksQxQ-+bWbG5bp6dmq_Ujh+2nVoZtp_YzQdorArgTSA@mail.gmail.com>
Message-ID: <CAFdSV9v9ZGhSUD+H1g=WZ5tqWdXAyx=JQvjFqe+m48CwUFPh=A@mail.gmail.com>

BTW... https://hibernate.atlassian.net/browse/HHH-11104

On Tue, Sep 13, 2016 at 7:05 PM Steve Ebersole <steve at hibernate.org> wrote:

> Hmmm there is an interesting aspect to Tuple + TupleTransformer.. both
> expect to get the root selection aliases and would naturally expect those
> to match in length to the values to transform.  Basically only one can
> "consume" the aliases.
>
> I think that because Tuple is a "higher precedence" (it defines the result
> type) it ought to win that battle.  But then that is inconsistent for
> TupleTransformer.  IMO either we let Tuple consume the aliases or we
> disallow this combo.
>
> On Tue, Sep 13, 2016 at 6:00 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> So here is the path I am following initially.. It is straightforward to
>> explain to a user which I like.
>>
>> In terms of processing each "row" in a result there is the RowTransformer
>> contract I mentioned earlier, or maybe I mentioned on HipChat.  I added the
>> capability for RowTransformer to be nested, specifically I defined 2
>> levels:
>>
>>    1. an implicit RowTransformer.  This is resolved based on the
>>    following chart:
>>       1. If there is a resultType and it is Object[].class we do a "pass
>>       thru"
>>       2. If there is a resultType and it is Tuple.class we do use a
>>       RowTransformer adapter that builds a Tuple
>>       3. If there is just one selection we transform the Object[] by
>>       returning just row[0]
>>    2. a RowTransformer adapter for TupleTransformer, if specified
>>
>> And just a word on dynamic-instantiation here.. it is actually done prior
>> to any of this.  In fact, in 6.0 a dynamic-instantiation is no different
>> that other selectable expressions.
>>
>>
>>
>> On Tue, Sep 13, 2016 at 9:19 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> So again, this all boils down to the interplay with
>>> (Result|Tuple|ResultList)Transformer, dynamic instantiations, and
>>> result-types.
>>>
>>> So let's look at some specific cases...
>>>
>>> First some cases I think are perfectly valid:
>>>
>>> session.createQuery( "select new map(...) ...", Map.class ) - returns a
>>> List<Map<String,?>>
>>> session.createQuery( "select new list(...) ...", List.class ) - returns
>>> a List<List> (rather than List<Object[]>)
>>> session.createQuery( "select new DTO(...), DTO.class ) - returns a
>>> List<DTO>
>>>
>>> Ok, so I cheated there by not including transformers :)  So let's look
>>> at adding transformers into this mix[1].
>>>
>>> session.createQuery( "select new map(...) ...", Map.class )
>>>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
>>>
>>> this one is illegal.  It defines the Query resultType as Map, but the
>>> applied TupleTranformer is transforming those to SomeNonMap -> CCE.
>>> This should be either:
>>>
>>> session.createQuery( "select new map(...) ...", SomeNonMap.class )
>>>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
>>>
>>> or (non-typed):
>>>
>>> session.createQuery( "select new map(...) ..." )
>>>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
>>>
>>> In both of those cases, the TupleTranformer is handed a Object[] where
>>> the only element is the Map.
>>>
>>> I guess too that defines the blueprint for what is and what is not
>>> supported and how the various pieces apply.
>>>
>>>
>>> But I am still not sure about the semantic wrt TupleTransformer and/or
>>> dynamic-instantiation in combination with Tuple.  I kind of think those
>>> should just be illegal combos:
>>>
>>> session.createQuery( "select ...", Tuple.class )
>>>         .setTupleTransformer( () -> ... )
>>>
>>> Unless the TupleTransformer is building a Tuple, I that is a bad combo
>>> for sure.
>>>
>>> I thik dynamic-instantiation and TupleTransformer is ok:
>>>
>>> session.createQuery( "select new DTO(...) ..." )
>>>         .setTupleTransformer( () -> ... )
>>>
>>> Here the TupleTransformer would get Object[] with the long element being
>>> the DTO; the "query result" is whatever the TupleTransformer returns.
>>>
>>> Any other specific combos we should clarify?
>>>
>>>
>>>
>>> [1]  I am using the new TupleTransformer and ResultListTransformer
>>> breakdowns I have defined on 6.0 :
>>> https://gist.github.com/sebersole/bc721caa20a5e4a97cbde44567b0b2ea
>>>
>>>
>>>
>>> On Tue, Sep 13, 2016 at 8:52 AM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>>
>>>>> > Between dynamic-instantiation, Tuple-handling...
>>>>>
>>>>> To be sure, WDYM by "tuple-handling"?
>>>>>
>>>>
>>>> javax.persistence.Tuple
>>>>
>>>> So I gave just one example earlier of how all of these things do not
>>>> necessarily fit together in inherently obvious ways.  Some
>>>> combinations I think are ok; others are not.  In sitting here and trying to
>>>> describe this to a user from a documentation perspective, it is not a
>>>> simple explanation.
>>>>
>>>> I'll follow up with a separate reply that covers those combos for
>>>> discussion.
>>>>
>>>>
>>>> One use case for result transformers are full-text searches executed
>>>>> through Hibernate Search's Session extension FullTextSession (see [1]).
>>>>>
>>>>> For full-text searches we don't use HQL/JPQL, so the "new ..." syntax
>>>>> cannot be used, but I don't know about tuple-handling.
>>>>>
>>>>
>>>> Well for sure you do not allow the user to use HQL/JPQL.  But I'd have
>>>> to assume that under the covers you handle resolving that
>>>> FullTextQuery yourself from the indexes - which means this is not even a
>>>> ORM Query at all and what we do with ResultTransformer in ORM in regards to
>>>> Query is completely irrelevant for you.  In other words I would have to
>>>> think that Search itself is applying that ResultTransformer in your
>>>> example, not ORM.  Very different.
>>>>
>>>

From gbadner at redhat.com  Tue Sep 13 22:55:38 2016
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 13 Sep 2016 19:55:38 -0700
Subject: [hibernate-dev] 6.0 - ResultTransformer
In-Reply-To: <CAFdSV9vksQxQ-+bWbG5bp6dmq_Ujh+2nVoZtp_YzQdorArgTSA@mail.gmail.com>
References: <CAFdSV9uz2v-q-GQrP838Ft=4X9yFrA6coiaxQHm0JNnCuK7Y+g@mail.gmail.com>
	<CA+gWKMB7u38qMbbZ+_P+17KpKon4X1gd7Nj2=omvavsD=DBRjg@mail.gmail.com>
	<CAFdSV9urdcXRfaD04RyozC-G2GuLxiCPisa++zdmXpiY8Bi+LQ@mail.gmail.com>
	<CA+gWKMCLr0G7a_vcUUw_r=-dsZBrK=PXuQM9-k4A+Gc4EXZHyA@mail.gmail.com>
	<CAFdSV9t6PNpCNC0Wa9FsSkw_C7TE9S9rAL5GG5HQ8NTXpccO5Q@mail.gmail.com>
	<CAFdSV9u-idURC37QcqVuB3xFJQs=+0V9U_-MSKamk+amfUFLrQ@mail.gmail.com>
	<CAFdSV9u+AgZ+QcF_DeqrRPuMfQfUS=kKVcHYNWLLo--rAQ7xJg@mail.gmail.com>
	<42848f6f-fa00-4d36-5a7f-fce4d4283f1c@gmail.com>
	<CADGJaX9rr1AXkSpMzwdh4JUSJmpj-pNA4U0juw37a8-01JpNpQ@mail.gmail.com>
	<CAFdSV9tZGUUbCexiF3kYAA5+RUrT47Q-UK5C6AvF5Yiv1FFmvQ@mail.gmail.com>
	<CAFdSV9tQu6h8jzKCfzbx_-BgUZGS8m0AZk6ShY2oZq-UVotrWA@mail.gmail.com>
	<CAFdSV9tMgzAh9uXcCN5d=B4g5Z0CC-E0ia38szjxa86LqicZAw@mail.gmail.com>
	<CAFdSV9vksQxQ-+bWbG5bp6dmq_Ujh+2nVoZtp_YzQdorArgTSA@mail.gmail.com>
Message-ID: <CAFDzhiRSArkVZ35TN+u423OnxkgBhhhHdDp0VG_FeLsRDTKCwQ@mail.gmail.com>

Sorry for the late response. I've been looking through the fix for HHH-5163
[1] to jog my memory.

Here are some reasons why CacheableResultTransformer is important when
caching query results:

1) The same SQL can be generated when associations are joined as when
associations are fetched, but what gets cached is different. The cached
results exclude fetched associations. QueryKey needs to contain the proper
CacheableResultTransformer to indicate which tuple elements are cached to
distinguish the differing results.

2) IIRC, the tuple elements that got cached by the legacy Criteria and HQL
were inconsistent, and I believe that in some cases the ResultTransformer
was applied before caching the value, which added to problems assembling
the query results (HHH--2463). CacheableResultTransformer ensured that what
got cached was consistent (excluding fetched values), and ensured that rows
were untransformed (padded with nulls where fetches were) and
re-transformed (if necessary) by a specified transformer as necessary.

I added lots of tests for this change, so I think we will find out quickly
if something gets broken.

Steve, I'm not completely following your discussion. Some pseudocode would
help.

Let me know if you need more details.

[1]
https://github.com/hibernate/hibernate-orm/commit/dc00c4dcde1bae399a9350bd4a13f9a2a449f6c3

On Tue, Sep 13, 2016 at 5:05 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Hmmm there is an interesting aspect to Tuple + TupleTransformer.. both
> expect to get the root selection aliases and would naturally expect those
> to match in length to the values to transform.  Basically only one can
> "consume" the aliases.
>
> I think that because Tuple is a "higher precedence" (it defines the result
> type) it ought to win that battle.  But then that is inconsistent for
> TupleTransformer.  IMO either we let Tuple consume the aliases or we
> disallow this combo.
>
> On Tue, Sep 13, 2016 at 6:00 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > So here is the path I am following initially.. It is straightforward to
> > explain to a user which I like.
> >
> > In terms of processing each "row" in a result there is the RowTransformer
> > contract I mentioned earlier, or maybe I mentioned on HipChat.  I added
> the
> > capability for RowTransformer to be nested, specifically I defined 2
> > levels:
> >
> >    1. an implicit RowTransformer.  This is resolved based on the
> >    following chart:
> >       1. If there is a resultType and it is Object[].class we do a "pass
> >       thru"
> >       2. If there is a resultType and it is Tuple.class we do use a
> >       RowTransformer adapter that builds a Tuple
> >       3. If there is just one selection we transform the Object[] by
> >       returning just row[0]
> >    2. a RowTransformer adapter for TupleTransformer, if specified
> >
> > And just a word on dynamic-instantiation here.. it is actually done prior
> > to any of this.  In fact, in 6.0 a dynamic-instantiation is no different
> > that other selectable expressions.
> >
> >
> >
> > On Tue, Sep 13, 2016 at 9:19 AM Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> >> So again, this all boils down to the interplay with
> >> (Result|Tuple|ResultList)Transformer, dynamic instantiations, and
> >> result-types.
> >>
> >> So let's look at some specific cases...
> >>
> >> First some cases I think are perfectly valid:
> >>
> >> session.createQuery( "select new map(...) ...", Map.class ) - returns a
> >> List<Map<String,?>>
> >> session.createQuery( "select new list(...) ...", List.class ) - returns
> a
> >> List<List> (rather than List<Object[]>)
> >> session.createQuery( "select new DTO(...), DTO.class ) - returns a
> >> List<DTO>
> >>
> >> Ok, so I cheated there by not including transformers :)  So let's look
> at
> >> adding transformers into this mix[1].
> >>
> >> session.createQuery( "select new map(...) ...", Map.class )
> >>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
> >>
> >> this one is illegal.  It defines the Query resultType as Map, but the
> >> applied TupleTranformer is transforming those to SomeNonMap -> CCE.
> >> This should be either:
> >>
> >> session.createQuery( "select new map(...) ...", SomeNonMap.class )
> >>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
> >>
> >> or (non-typed):
> >>
> >> session.createQuery( "select new map(...) ..." )
> >>         .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )
> >>
> >> In both of those cases, the TupleTranformer is handed a Object[] where
> >> the only element is the Map.
> >>
> >> I guess too that defines the blueprint for what is and what is not
> >> supported and how the various pieces apply.
> >>
> >>
> >> But I am still not sure about the semantic wrt TupleTransformer and/or
> >> dynamic-instantiation in combination with Tuple.  I kind of think those
> >> should just be illegal combos:
> >>
> >> session.createQuery( "select ...", Tuple.class )
> >>         .setTupleTransformer( () -> ... )
> >>
> >> Unless the TupleTransformer is building a Tuple, I that is a bad combo
> >> for sure.
> >>
> >> I thik dynamic-instantiation and TupleTransformer is ok:
> >>
> >> session.createQuery( "select new DTO(...) ..." )
> >>         .setTupleTransformer( () -> ... )
> >>
> >> Here the TupleTransformer would get Object[] with the long element being
> >> the DTO; the "query result" is whatever the TupleTransformer returns.
> >>
> >> Any other specific combos we should clarify?
> >>
> >>
> >>
> >> [1]  I am using the new TupleTransformer and ResultListTransformer
> >> breakdowns I have defined on 6.0 :
> >> https://gist.github.com/sebersole/bc721caa20a5e4a97cbde44567b0b2ea
> >>
> >>
> >>
> >> On Tue, Sep 13, 2016 at 8:52 AM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar at hibernate.org>
> >>> wrote:
> >>>
> >>>> > Between dynamic-instantiation, Tuple-handling...
> >>>>
> >>>> To be sure, WDYM by "tuple-handling"?
> >>>>
> >>>
> >>> javax.persistence.Tuple
> >>>
> >>> So I gave just one example earlier of how all of these things do not
> >>> necessarily fit together in inherently obvious ways.  Some combinations
> >>> I think are ok; others are not.  In sitting here and trying to describe
> >>> this to a user from a documentation perspective, it is not a simple
> >>> explanation.
> >>>
> >>> I'll follow up with a separate reply that covers those combos for
> >>> discussion.
> >>>
> >>>
> >>> One use case for result transformers are full-text searches executed
> >>>> through Hibernate Search's Session extension FullTextSession (see
> [1]).
> >>>>
> >>>> For full-text searches we don't use HQL/JPQL, so the "new ..." syntax
> >>>> cannot be used, but I don't know about tuple-handling.
> >>>>
> >>>
> >>> Well for sure you do not allow the user to use HQL/JPQL.  But I'd have
> >>> to assume that under the covers you handle resolving that FullTextQuery
> >>> yourself from the indexes - which means this is not even a ORM Query
> at all
> >>> and what we do with ResultTransformer in ORM in regards to Query is
> >>> completely irrelevant for you.  In other words I would have to think
> that
> >>> Search itself is applying that ResultTransformer in your example, not
> ORM.
> >>> Very different.
> >>>
> >>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Sep 14 11:59:01 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 14 Sep 2016 16:59:01 +0100
Subject: [hibernate-dev] Usage of Session#getTransaction() being banned
 from the Hibernate Search code
In-Reply-To: <CAFdSV9uEk2dRC5uhoavpCtXyEuwC=wnAkTPBxSDPbbVgLjGs4Q@mail.gmail.com>
References: <CAFm4XO1L++9=j2TA=euMkwbwXc=GbXPUoSZ398-BVLgypSiBCw@mail.gmail.com>
	<CAFdSV9uEk2dRC5uhoavpCtXyEuwC=wnAkTPBxSDPbbVgLjGs4Q@mail.gmail.com>
Message-ID: <CAFm4XO3oZR7rwimaCCALJF0K-Lv_p=PirjkD9y=e_SRPYiFKkg@mail.gmail.com>

Hi Steve,
as a follow up of migrating #getTransaction() usage to
session.accessTransaction() I now noticed a difference:

we had previous code like this:

Transaction transaction = session.getTransaction();
transaction.begin();

Which worked fine even though the user is actually using an
EntityManager (the Hibernate Search integration code consistently uses
the underlying Session so that it works in either case..).
It also worked fine in both JTA and other transaction modes; in case
of JTA w'd previously have started the transaction on the
TransactionManager (as well).

But the new code now requires a bit more care:

Transaction transaction = session.accessTransaction();
if ( transaction.isActive() == false ) {
    transaction.begin();
}

as otherwise the transaction.begin() would trigger this IllegalStateException:
 - https://github.com/hibernate/hibernate-orm/blob/cf0fb8d262ec725a4d0692e13d0a56d149d84584/hibernate-core/src/main/java/org/hibernate/engine/transaction/internal/TransactionImpl.java#L50-L53

I'll say that the new behaviour doesn't look unreasonable, but I'd
like to hear from you if this was intentional as you seemed to suggest
over chat that the accessTransaction() method was to be a drop-in
replacement for the previous semantics of getTransaction.

Secondarily, when it comes to the "transaction.commit()" I'm having no
exception and it seems to work fine... should I need to check for the
state?

Thanks,
Sanne


On 13 September 2016 at 15:54, Steve Ebersole <steve at hibernate.org> wrote:
> NIce!  I never knew of this plugin, but there is a Gradle plugin for it as
> well.
>
> On Tue, Sep 13, 2016 at 9:33 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Since Hibernate ORM 5.2, the method getTransaction() on Session needs
>> to behave according to EntityManager spec, which implies that it has
>> to throw an exception in certain circumstances which depend on the
>> configuration.
>>
>> Hibernate Search used this method in various places, for example to
>> integrate with the current transaction's events, or even to control
>> the transaction explicitly in the case of the MassIndexer.
>>
>> Since we want Hibernate Search to work fine with Hibernate ORM no
>> matter what configuration is being used, we need to avoid invoking
>> this method.
>> The solution is extremely simple: use its SPI level replacement, which
>> is SessionImplementor#accessTransaction().
>>
>> Unfortunately most of our Search/ORM tests happen to run without a
>> Transaction Manager so if you happen to use the old method, the tests
>> would pass and everything would seem fine - however your shiny new
>> feature would not work in certain configurations.
>>
>> One solution to verify we're not using it, is to ban this method using
>> the "forbiddenapi" plugin:
>>  -
>> https://github.com/Sanne/hibernate-search/commit/a980ee5dca0c7a58dd79ba98acd8a354bc5601e6#diff-600376dffeb79835ede4a0b285078036R1036
>>
>> A more comprehensive integration test would be to re-run all tests
>> from the Search/ORM using a proper JTA configuration; not rushing to
>> refactor our testsuite now since we have the forbidden-apis plugin but
>> opening a JIRA task for 5.7, as this version will support ORM 5.7:
>>  - https://hibernate.atlassian.net/browse/HSEARCH-2344
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Sep 14 12:15:08 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 16:15:08 +0000
Subject: [hibernate-dev] Usage of Session#getTransaction() being banned
 from the Hibernate Search code
In-Reply-To: <CAFm4XO3oZR7rwimaCCALJF0K-Lv_p=PirjkD9y=e_SRPYiFKkg@mail.gmail.com>
References: <CAFm4XO1L++9=j2TA=euMkwbwXc=GbXPUoSZ398-BVLgypSiBCw@mail.gmail.com>
	<CAFdSV9uEk2dRC5uhoavpCtXyEuwC=wnAkTPBxSDPbbVgLjGs4Q@mail.gmail.com>
	<CAFm4XO3oZR7rwimaCCALJF0K-Lv_p=PirjkD9y=e_SRPYiFKkg@mail.gmail.com>
Message-ID: <CAFdSV9t-OGqgoDS3y16zHqLTvS3jCog4J+d+8TRk2HiYjxuEQg@mail.gmail.com>

Yes, it was intentional.  As you say it is totally reasonable.

The problem is "matching".  Like it was no problem to call begin() before
but what happened if the txn was commited multiple times was wonky.  In
fact JPA explicitly forbids it multiple calls to commit (as well as
multiple calls to begin).

I personally think code like this is just awful:

Session s = ...;
s.accessTransaction().begin();
// do some stuff
// but never end the txn



On Wed, Sep 14, 2016 at 10:59 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi Steve,
> as a follow up of migrating #getTransaction() usage to
> session.accessTransaction() I now noticed a difference:
>
> we had previous code like this:
>
> Transaction transaction = session.getTransaction();
> transaction.begin();
>
> Which worked fine even though the user is actually using an
> EntityManager (the Hibernate Search integration code consistently uses
> the underlying Session so that it works in either case..).
> It also worked fine in both JTA and other transaction modes; in case
> of JTA w'd previously have started the transaction on the
> TransactionManager (as well).
>
> But the new code now requires a bit more care:
>
> Transaction transaction = session.accessTransaction();
> if ( transaction.isActive() == false ) {
>     transaction.begin();
> }
>
> as otherwise the transaction.begin() would trigger this
> IllegalStateException:
>  -
> https://github.com/hibernate/hibernate-orm/blob/cf0fb8d262ec725a4d0692e13d0a56d149d84584/hibernate-core/src/main/java/org/hibernate/engine/transaction/internal/TransactionImpl.java#L50-L53
>
> I'll say that the new behaviour doesn't look unreasonable, but I'd
> like to hear from you if this was intentional as you seemed to suggest
> over chat that the accessTransaction() method was to be a drop-in
> replacement for the previous semantics of getTransaction.
>
> Secondarily, when it comes to the "transaction.commit()" I'm having no
> exception and it seems to work fine... should I need to check for the
> state?
>
> Thanks,
> Sanne
>
>
> On 13 September 2016 at 15:54, Steve Ebersole <steve at hibernate.org> wrote:
> > NIce!  I never knew of this plugin, but there is a Gradle plugin for it
> as
> > well.
> >
> > On Tue, Sep 13, 2016 at 9:33 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> Since Hibernate ORM 5.2, the method getTransaction() on Session needs
> >> to behave according to EntityManager spec, which implies that it has
> >> to throw an exception in certain circumstances which depend on the
> >> configuration.
> >>
> >> Hibernate Search used this method in various places, for example to
> >> integrate with the current transaction's events, or even to control
> >> the transaction explicitly in the case of the MassIndexer.
> >>
> >> Since we want Hibernate Search to work fine with Hibernate ORM no
> >> matter what configuration is being used, we need to avoid invoking
> >> this method.
> >> The solution is extremely simple: use its SPI level replacement, which
> >> is SessionImplementor#accessTransaction().
> >>
> >> Unfortunately most of our Search/ORM tests happen to run without a
> >> Transaction Manager so if you happen to use the old method, the tests
> >> would pass and everything would seem fine - however your shiny new
> >> feature would not work in certain configurations.
> >>
> >> One solution to verify we're not using it, is to ban this method using
> >> the "forbiddenapi" plugin:
> >>  -
> >>
> https://github.com/Sanne/hibernate-search/commit/a980ee5dca0c7a58dd79ba98acd8a354bc5601e6#diff-600376dffeb79835ede4a0b285078036R1036
> >>
> >> A more comprehensive integration test would be to re-run all tests
> >> from the Search/ORM using a proper JTA configuration; not rushing to
> >> refactor our testsuite now since we have the forbidden-apis plugin but
> >> opening a JIRA task for 5.7, as this version will support ORM 5.7:
> >>  - https://hibernate.atlassian.net/browse/HSEARCH-2344
> >>
> >> Thanks,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Sep 14 12:16:30 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 16:16:30 +0000
Subject: [hibernate-dev] Usage of Session#getTransaction() being banned
 from the Hibernate Search code
In-Reply-To: <CAFdSV9t-OGqgoDS3y16zHqLTvS3jCog4J+d+8TRk2HiYjxuEQg@mail.gmail.com>
References: <CAFm4XO1L++9=j2TA=euMkwbwXc=GbXPUoSZ398-BVLgypSiBCw@mail.gmail.com>
	<CAFdSV9uEk2dRC5uhoavpCtXyEuwC=wnAkTPBxSDPbbVgLjGs4Q@mail.gmail.com>
	<CAFm4XO3oZR7rwimaCCALJF0K-Lv_p=PirjkD9y=e_SRPYiFKkg@mail.gmail.com>
	<CAFdSV9t-OGqgoDS3y16zHqLTvS3jCog4J+d+8TRk2HiYjxuEQg@mail.gmail.com>
Message-ID: <CAFdSV9vpCkCreARfix9Fc6TQzzjWcSxMNNf=tako3JsXDRcN1g@mail.gmail.com>

To be clear, I mean "never end the transaction locally".  It's like any
resource handling... if you start/begin/open something you should
stop/end/close it.  IMHO.


On Wed, Sep 14, 2016 at 11:15 AM Steve Ebersole <steve at hibernate.org> wrote:

> Yes, it was intentional.  As you say it is totally reasonable.
>
> The problem is "matching".  Like it was no problem to call begin() before
> but what happened if the txn was commited multiple times was wonky.  In
> fact JPA explicitly forbids it multiple calls to commit (as well as
> multiple calls to begin).
>
> I personally think code like this is just awful:
>
> Session s = ...;
> s.accessTransaction().begin();
> // do some stuff
> // but never end the txn
>
>
>
> On Wed, Sep 14, 2016 at 10:59 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> Hi Steve,
>> as a follow up of migrating #getTransaction() usage to
>> session.accessTransaction() I now noticed a difference:
>>
>> we had previous code like this:
>>
>> Transaction transaction = session.getTransaction();
>> transaction.begin();
>>
>> Which worked fine even though the user is actually using an
>> EntityManager (the Hibernate Search integration code consistently uses
>> the underlying Session so that it works in either case..).
>> It also worked fine in both JTA and other transaction modes; in case
>> of JTA w'd previously have started the transaction on the
>> TransactionManager (as well).
>>
>> But the new code now requires a bit more care:
>>
>> Transaction transaction = session.accessTransaction();
>> if ( transaction.isActive() == false ) {
>>     transaction.begin();
>> }
>>
>> as otherwise the transaction.begin() would trigger this
>> IllegalStateException:
>>  -
>> https://github.com/hibernate/hibernate-orm/blob/cf0fb8d262ec725a4d0692e13d0a56d149d84584/hibernate-core/src/main/java/org/hibernate/engine/transaction/internal/TransactionImpl.java#L50-L53
>>
>> I'll say that the new behaviour doesn't look unreasonable, but I'd
>> like to hear from you if this was intentional as you seemed to suggest
>> over chat that the accessTransaction() method was to be a drop-in
>> replacement for the previous semantics of getTransaction.
>>
>> Secondarily, when it comes to the "transaction.commit()" I'm having no
>> exception and it seems to work fine... should I need to check for the
>> state?
>>
>> Thanks,
>> Sanne
>>
>>
>> On 13 September 2016 at 15:54, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> > NIce!  I never knew of this plugin, but there is a Gradle plugin for it
>> as
>> > well.
>> >
>> > On Tue, Sep 13, 2016 at 9:33 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>> >>
>> >> Since Hibernate ORM 5.2, the method getTransaction() on Session needs
>> >> to behave according to EntityManager spec, which implies that it has
>> >> to throw an exception in certain circumstances which depend on the
>> >> configuration.
>> >>
>> >> Hibernate Search used this method in various places, for example to
>> >> integrate with the current transaction's events, or even to control
>> >> the transaction explicitly in the case of the MassIndexer.
>> >>
>> >> Since we want Hibernate Search to work fine with Hibernate ORM no
>> >> matter what configuration is being used, we need to avoid invoking
>> >> this method.
>> >> The solution is extremely simple: use its SPI level replacement, which
>> >> is SessionImplementor#accessTransaction().
>> >>
>> >> Unfortunately most of our Search/ORM tests happen to run without a
>> >> Transaction Manager so if you happen to use the old method, the tests
>> >> would pass and everything would seem fine - however your shiny new
>> >> feature would not work in certain configurations.
>> >>
>> >> One solution to verify we're not using it, is to ban this method using
>> >> the "forbiddenapi" plugin:
>> >>  -
>> >>
>> https://github.com/Sanne/hibernate-search/commit/a980ee5dca0c7a58dd79ba98acd8a354bc5601e6#diff-600376dffeb79835ede4a0b285078036R1036
>> >>
>> >> A more comprehensive integration test would be to re-run all tests
>> >> from the Search/ORM using a proper JTA configuration; not rushing to
>> >> refactor our testsuite now since we have the forbidden-apis plugin but
>> >> opening a JIRA task for 5.7, as this version will support ORM 5.7:
>> >>  - https://hibernate.atlassian.net/browse/HSEARCH-2344
>> >>
>> >> Thanks,
>> >> Sanne
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From sanne at hibernate.org  Wed Sep 14 12:23:49 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 14 Sep 2016 17:23:49 +0100
Subject: [hibernate-dev] Usage of Session#getTransaction() being banned
 from the Hibernate Search code
In-Reply-To: <CAFdSV9vpCkCreARfix9Fc6TQzzjWcSxMNNf=tako3JsXDRcN1g@mail.gmail.com>
References: <CAFm4XO1L++9=j2TA=euMkwbwXc=GbXPUoSZ398-BVLgypSiBCw@mail.gmail.com>
	<CAFdSV9uEk2dRC5uhoavpCtXyEuwC=wnAkTPBxSDPbbVgLjGs4Q@mail.gmail.com>
	<CAFm4XO3oZR7rwimaCCALJF0K-Lv_p=PirjkD9y=e_SRPYiFKkg@mail.gmail.com>
	<CAFdSV9t-OGqgoDS3y16zHqLTvS3jCog4J+d+8TRk2HiYjxuEQg@mail.gmail.com>
	<CAFdSV9vpCkCreARfix9Fc6TQzzjWcSxMNNf=tako3JsXDRcN1g@mail.gmail.com>
Message-ID: <CAFm4XO2adi2f629oU6fppq5L=L4=WEJt85WSm49E7KzmmS+H+g@mail.gmail.com>

On 14 September 2016 at 17:16, Steve Ebersole <steve at hibernate.org> wrote:
> To be clear, I mean "never end the transaction locally".  It's like any
> resource handling... if you start/begin/open something you should
> stop/end/close it.  IMHO.

Thanks for the clarifications. I agree on the "who opens close"
principle.. I probably shouldn't be doing the commit then, if I skip
the begin?

>
>
> On Wed, Sep 14, 2016 at 11:15 AM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> Yes, it was intentional.  As you say it is totally reasonable.
>>
>> The problem is "matching".  Like it was no problem to call begin() before
>> but what happened if the txn was commited multiple times was wonky.  In fact
>> JPA explicitly forbids it multiple calls to commit (as well as multiple
>> calls to begin).
>>
>> I personally think code like this is just awful:
>>
>> Session s = ...;
>> s.accessTransaction().begin();
>> // do some stuff
>> // but never end the txn
>>
>>
>>
>> On Wed, Sep 14, 2016 at 10:59 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>> Hi Steve,
>>> as a follow up of migrating #getTransaction() usage to
>>> session.accessTransaction() I now noticed a difference:
>>>
>>> we had previous code like this:
>>>
>>> Transaction transaction = session.getTransaction();
>>> transaction.begin();
>>>
>>> Which worked fine even though the user is actually using an
>>> EntityManager (the Hibernate Search integration code consistently uses
>>> the underlying Session so that it works in either case..).
>>> It also worked fine in both JTA and other transaction modes; in case
>>> of JTA w'd previously have started the transaction on the
>>> TransactionManager (as well).
>>>
>>> But the new code now requires a bit more care:
>>>
>>> Transaction transaction = session.accessTransaction();
>>> if ( transaction.isActive() == false ) {
>>>     transaction.begin();
>>> }
>>>
>>> as otherwise the transaction.begin() would trigger this
>>> IllegalStateException:
>>>  -
>>> https://github.com/hibernate/hibernate-orm/blob/cf0fb8d262ec725a4d0692e13d0a56d149d84584/hibernate-core/src/main/java/org/hibernate/engine/transaction/internal/TransactionImpl.java#L50-L53
>>>
>>> I'll say that the new behaviour doesn't look unreasonable, but I'd
>>> like to hear from you if this was intentional as you seemed to suggest
>>> over chat that the accessTransaction() method was to be a drop-in
>>> replacement for the previous semantics of getTransaction.
>>>
>>> Secondarily, when it comes to the "transaction.commit()" I'm having no
>>> exception and it seems to work fine... should I need to check for the
>>> state?
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> On 13 September 2016 at 15:54, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> > NIce!  I never knew of this plugin, but there is a Gradle plugin for it
>>> > as
>>> > well.
>>> >
>>> > On Tue, Sep 13, 2016 at 9:33 AM Sanne Grinovero <sanne at hibernate.org>
>>> > wrote:
>>> >>
>>> >> Since Hibernate ORM 5.2, the method getTransaction() on Session needs
>>> >> to behave according to EntityManager spec, which implies that it has
>>> >> to throw an exception in certain circumstances which depend on the
>>> >> configuration.
>>> >>
>>> >> Hibernate Search used this method in various places, for example to
>>> >> integrate with the current transaction's events, or even to control
>>> >> the transaction explicitly in the case of the MassIndexer.
>>> >>
>>> >> Since we want Hibernate Search to work fine with Hibernate ORM no
>>> >> matter what configuration is being used, we need to avoid invoking
>>> >> this method.
>>> >> The solution is extremely simple: use its SPI level replacement, which
>>> >> is SessionImplementor#accessTransaction().
>>> >>
>>> >> Unfortunately most of our Search/ORM tests happen to run without a
>>> >> Transaction Manager so if you happen to use the old method, the tests
>>> >> would pass and everything would seem fine - however your shiny new
>>> >> feature would not work in certain configurations.
>>> >>
>>> >> One solution to verify we're not using it, is to ban this method using
>>> >> the "forbiddenapi" plugin:
>>> >>  -
>>> >>
>>> >> https://github.com/Sanne/hibernate-search/commit/a980ee5dca0c7a58dd79ba98acd8a354bc5601e6#diff-600376dffeb79835ede4a0b285078036R1036
>>> >>
>>> >> A more comprehensive integration test would be to re-run all tests
>>> >> from the Search/ORM using a proper JTA configuration; not rushing to
>>> >> refactor our testsuite now since we have the forbidden-apis plugin but
>>> >> opening a JIRA task for 5.7, as this version will support ORM 5.7:
>>> >>  - https://hibernate.atlassian.net/browse/HSEARCH-2344
>>> >>
>>> >> Thanks,
>>> >> Sanne
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Sep 14 12:42:11 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 16:42:11 +0000
Subject: [hibernate-dev] Usage of Session#getTransaction() being banned
 from the Hibernate Search code
In-Reply-To: <CAFm4XO2adi2f629oU6fppq5L=L4=WEJt85WSm49E7KzmmS+H+g@mail.gmail.com>
References: <CAFm4XO1L++9=j2TA=euMkwbwXc=GbXPUoSZ398-BVLgypSiBCw@mail.gmail.com>
	<CAFdSV9uEk2dRC5uhoavpCtXyEuwC=wnAkTPBxSDPbbVgLjGs4Q@mail.gmail.com>
	<CAFm4XO3oZR7rwimaCCALJF0K-Lv_p=PirjkD9y=e_SRPYiFKkg@mail.gmail.com>
	<CAFdSV9t-OGqgoDS3y16zHqLTvS3jCog4J+d+8TRk2HiYjxuEQg@mail.gmail.com>
	<CAFdSV9vpCkCreARfix9Fc6TQzzjWcSxMNNf=tako3JsXDRcN1g@mail.gmail.com>
	<CAFm4XO2adi2f629oU6fppq5L=L4=WEJt85WSm49E7KzmmS+H+g@mail.gmail.com>
Message-ID: <CAFdSV9vrLd=MY27tD1LZrW93c6TdPezAfMCODKFhSDE8hB8LwQ@mail.gmail.com>

That would be my personal opinion.


On Wed, Sep 14, 2016 at 11:24 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 14 September 2016 at 17:16, Steve Ebersole <steve at hibernate.org> wrote:
> > To be clear, I mean "never end the transaction locally".  It's like any
> > resource handling... if you start/begin/open something you should
> > stop/end/close it.  IMHO.
>
> Thanks for the clarifications. I agree on the "who opens close"
> principle.. I probably shouldn't be doing the commit then, if I skip
> the begin?
>
> >
> >
> > On Wed, Sep 14, 2016 at 11:15 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> Yes, it was intentional.  As you say it is totally reasonable.
> >>
> >> The problem is "matching".  Like it was no problem to call begin()
> before
> >> but what happened if the txn was commited multiple times was wonky.  In
> fact
> >> JPA explicitly forbids it multiple calls to commit (as well as multiple
> >> calls to begin).
> >>
> >> I personally think code like this is just awful:
> >>
> >> Session s = ...;
> >> s.accessTransaction().begin();
> >> // do some stuff
> >> // but never end the txn
> >>
> >>
> >>
> >> On Wed, Sep 14, 2016 at 10:59 AM Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>>
> >>> Hi Steve,
> >>> as a follow up of migrating #getTransaction() usage to
> >>> session.accessTransaction() I now noticed a difference:
> >>>
> >>> we had previous code like this:
> >>>
> >>> Transaction transaction = session.getTransaction();
> >>> transaction.begin();
> >>>
> >>> Which worked fine even though the user is actually using an
> >>> EntityManager (the Hibernate Search integration code consistently uses
> >>> the underlying Session so that it works in either case..).
> >>> It also worked fine in both JTA and other transaction modes; in case
> >>> of JTA w'd previously have started the transaction on the
> >>> TransactionManager (as well).
> >>>
> >>> But the new code now requires a bit more care:
> >>>
> >>> Transaction transaction = session.accessTransaction();
> >>> if ( transaction.isActive() == false ) {
> >>>     transaction.begin();
> >>> }
> >>>
> >>> as otherwise the transaction.begin() would trigger this
> >>> IllegalStateException:
> >>>  -
> >>>
> https://github.com/hibernate/hibernate-orm/blob/cf0fb8d262ec725a4d0692e13d0a56d149d84584/hibernate-core/src/main/java/org/hibernate/engine/transaction/internal/TransactionImpl.java#L50-L53
> >>>
> >>> I'll say that the new behaviour doesn't look unreasonable, but I'd
> >>> like to hear from you if this was intentional as you seemed to suggest
> >>> over chat that the accessTransaction() method was to be a drop-in
> >>> replacement for the previous semantics of getTransaction.
> >>>
> >>> Secondarily, when it comes to the "transaction.commit()" I'm having no
> >>> exception and it seems to work fine... should I need to check for the
> >>> state?
> >>>
> >>> Thanks,
> >>> Sanne
> >>>
> >>>
> >>> On 13 September 2016 at 15:54, Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>> > NIce!  I never knew of this plugin, but there is a Gradle plugin for
> it
> >>> > as
> >>> > well.
> >>> >
> >>> > On Tue, Sep 13, 2016 at 9:33 AM Sanne Grinovero <sanne at hibernate.org
> >
> >>> > wrote:
> >>> >>
> >>> >> Since Hibernate ORM 5.2, the method getTransaction() on Session
> needs
> >>> >> to behave according to EntityManager spec, which implies that it has
> >>> >> to throw an exception in certain circumstances which depend on the
> >>> >> configuration.
> >>> >>
> >>> >> Hibernate Search used this method in various places, for example to
> >>> >> integrate with the current transaction's events, or even to control
> >>> >> the transaction explicitly in the case of the MassIndexer.
> >>> >>
> >>> >> Since we want Hibernate Search to work fine with Hibernate ORM no
> >>> >> matter what configuration is being used, we need to avoid invoking
> >>> >> this method.
> >>> >> The solution is extremely simple: use its SPI level replacement,
> which
> >>> >> is SessionImplementor#accessTransaction().
> >>> >>
> >>> >> Unfortunately most of our Search/ORM tests happen to run without a
> >>> >> Transaction Manager so if you happen to use the old method, the
> tests
> >>> >> would pass and everything would seem fine - however your shiny new
> >>> >> feature would not work in certain configurations.
> >>> >>
> >>> >> One solution to verify we're not using it, is to ban this method
> using
> >>> >> the "forbiddenapi" plugin:
> >>> >>  -
> >>> >>
> >>> >>
> https://github.com/Sanne/hibernate-search/commit/a980ee5dca0c7a58dd79ba98acd8a354bc5601e6#diff-600376dffeb79835ede4a0b285078036R1036
> >>> >>
> >>> >> A more comprehensive integration test would be to re-run all tests
> >>> >> from the Search/ORM using a proper JTA configuration; not rushing to
> >>> >> refactor our testsuite now since we have the forbidden-apis plugin
> but
> >>> >> opening a JIRA task for 5.7, as this version will support ORM 5.7:
> >>> >>  - https://hibernate.atlassian.net/browse/HSEARCH-2344
> >>> >>
> >>> >> Thanks,
> >>> >> Sanne
> >>> >> _______________________________________________
> >>> >> hibernate-dev mailing list
> >>> >> hibernate-dev at lists.jboss.org
> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Sep 14 14:35:51 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 14 Sep 2016 19:35:51 +0100
Subject: [hibernate-dev] Lambda usage to run a code block in an isolated
	transaction
Message-ID: <CAFm4XO2GA3AfkN3KMK5Q8pAhGhGeC7rCL+c93V-SGGGo3Mn7Bw@mail.gmail.com>

Today porting some benchmark code to Hibernate ORM 5.2 I had several
difficulties around the fact that the code now needs to be different
depending on transactions being container managed or not.

My goal was to have a single benchmark test which I could compile once
and run in either JavaSE or CMT; with some help from Steve I figured
the necessary incantations out but ... it looks very unpractical.

One way is to use an isolation delegate, which looks like this:

final SessionImplementor session = (SessionImplementor) s;
session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
   new WorkExecutorVisitable() {
      @ Override
      public Object accept(WorkExecutor executor, Connection
connection) throws SQLException {
         /// Some work with PreparedStatement on Connection..
      }
}, true );

This worked fine for some raw SQL used for the benchmark
initialization, but in another case I'd prefer to use the Session API
rather than dealing with PreparedStatements and native connections;
it looks like we don't have an equivalent "run code in isolation" for
the Session ?

It would be great if I could just pass a lambda to a Session and have
this executed on a "child Session" in the scope of a "child
Transaction", or just start and commit a transaction if there isn't
one.

s.executeInIsolation( session -> session.save(...) );

So I'd expect that details like how to begin the transaction, how it
should be committed (or rolled back in case of exceptions), how to
lookup a TransactionManager, and especially how to not leak resources
should be handled for the user.

Obviously the inner Session instance is a different one than the
outer, so any data returned by this block should be considered
detached; maybe this limitation would be clearer if the method was
hosted on SessionFactory or StatelessSession instead?
Although it wouldn't necessarily have the limitations of a
StalessSession, and it would be nice to have the inner transaction
behave as a nested one when there's already one in the host Session.

Looking forward for comments and improvement ideas :)

Thanks,
Sanne

From steve at hibernate.org  Wed Sep 14 15:32:11 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 19:32:11 +0000
Subject: [hibernate-dev] Lambda usage to run a code block in an isolated
	transaction
In-Reply-To: <CAFm4XO2GA3AfkN3KMK5Q8pAhGhGeC7rCL+c93V-SGGGo3Mn7Bw@mail.gmail.com>
References: <CAFm4XO2GA3AfkN3KMK5Q8pAhGhGeC7rCL+c93V-SGGGo3Mn7Bw@mail.gmail.com>
Message-ID: <CAFdSV9v7oVM-eOuAS0UstvT5tAVFsJAiUwV5UDgNEffP8t9Y1A@mail.gmail.com>

The problem with "execute in isolation" here is that the "isolation" aspect
refers to being isolated from any current transaction.  It says nothing
about whether that stuff-to-execute should itself be transacted.  This is
why, for example, you see IsolationDelegate accept a `transacted` boolean
argument.

How would you propose we pass such a flag in this case?  Or are you
proposing that this always start a (new) transaction?

On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Today porting some benchmark code to Hibernate ORM 5.2 I had several
> difficulties around the fact that the code now needs to be different
> depending on transactions being container managed or not.
>
> My goal was to have a single benchmark test which I could compile once
> and run in either JavaSE or CMT; with some help from Steve I figured
> the necessary incantations out but ... it looks very unpractical.
>
> One way is to use an isolation delegate, which looks like this:
>
> final SessionImplementor session = (SessionImplementor) s;
> session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
>    new WorkExecutorVisitable() {
>       @ Override
>       public Object accept(WorkExecutor executor, Connection
> connection) throws SQLException {
>          /// Some work with PreparedStatement on Connection..
>       }
> }, true );
>
> This worked fine for some raw SQL used for the benchmark
> initialization, but in another case I'd prefer to use the Session API
> rather than dealing with PreparedStatements and native connections;
> it looks like we don't have an equivalent "run code in isolation" for
> the Session ?
>
> It would be great if I could just pass a lambda to a Session and have
> this executed on a "child Session" in the scope of a "child
> Transaction", or just start and commit a transaction if there isn't
> one.
>
> s.executeInIsolation( session -> session.save(...) );
>
> So I'd expect that details like how to begin the transaction, how it
> should be committed (or rolled back in case of exceptions), how to
> lookup a TransactionManager, and especially how to not leak resources
> should be handled for the user.
>
> Obviously the inner Session instance is a different one than the
> outer, so any data returned by this block should be considered
> detached; maybe this limitation would be clearer if the method was
> hosted on SessionFactory or StatelessSession instead?
> Although it wouldn't necessarily have the limitations of a
> StalessSession, and it would be nice to have the inner transaction
> behave as a nested one when there's already one in the host Session.
>
> Looking forward for comments and improvement ideas :)
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Sep 14 15:59:33 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 14 Sep 2016 20:59:33 +0100
Subject: [hibernate-dev] Lambda usage to run a code block in an isolated
	transaction
In-Reply-To: <CAFdSV9v7oVM-eOuAS0UstvT5tAVFsJAiUwV5UDgNEffP8t9Y1A@mail.gmail.com>
References: <CAFm4XO2GA3AfkN3KMK5Q8pAhGhGeC7rCL+c93V-SGGGo3Mn7Bw@mail.gmail.com>
	<CAFdSV9v7oVM-eOuAS0UstvT5tAVFsJAiUwV5UDgNEffP8t9Y1A@mail.gmail.com>
Message-ID: <CAFm4XO05rqJqLRJfnAK9M58mrXegiJO+n-CmFdtEB8P=XrMvqQ@mail.gmail.com>

On 14 September 2016 at 20:32, Steve Ebersole <steve at hibernate.org> wrote:
> The problem with "execute in isolation" here is that the "isolation" aspect
> refers to being isolated from any current transaction.  It says nothing
> about whether that stuff-to-execute should itself be transacted.  This is
> why, for example, you see IsolationDelegate accept a `transacted` boolean
> argument.
>
> How would you propose we pass such a flag in this case?  Or are you
> proposing that this always start a (new) transaction?

I had only the (new) transaction case in mind, but sure you could add
a `transacted` boolean parameter.

Or we make it explicit with a better method name:

s.executeInSubtransaction( session -> session.save(...) );

Thanks,
Sanne


>
> On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Today porting some benchmark code to Hibernate ORM 5.2 I had several
>> difficulties around the fact that the code now needs to be different
>> depending on transactions being container managed or not.
>>
>> My goal was to have a single benchmark test which I could compile once
>> and run in either JavaSE or CMT; with some help from Steve I figured
>> the necessary incantations out but ... it looks very unpractical.
>>
>> One way is to use an isolation delegate, which looks like this:
>>
>> final SessionImplementor session = (SessionImplementor) s;
>>
>> session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
>>    new WorkExecutorVisitable() {
>>       @ Override
>>       public Object accept(WorkExecutor executor, Connection
>> connection) throws SQLException {
>>          /// Some work with PreparedStatement on Connection..
>>       }
>> }, true );
>>
>> This worked fine for some raw SQL used for the benchmark
>> initialization, but in another case I'd prefer to use the Session API
>> rather than dealing with PreparedStatements and native connections;
>> it looks like we don't have an equivalent "run code in isolation" for
>> the Session ?
>>
>> It would be great if I could just pass a lambda to a Session and have
>> this executed on a "child Session" in the scope of a "child
>> Transaction", or just start and commit a transaction if there isn't
>> one.
>>
>> s.executeInIsolation( session -> session.save(...) );
>>
>> So I'd expect that details like how to begin the transaction, how it
>> should be committed (or rolled back in case of exceptions), how to
>> lookup a TransactionManager, and especially how to not leak resources
>> should be handled for the user.
>>
>> Obviously the inner Session instance is a different one than the
>> outer, so any data returned by this block should be considered
>> detached; maybe this limitation would be clearer if the method was
>> hosted on SessionFactory or StatelessSession instead?
>> Although it wouldn't necessarily have the limitations of a
>> StalessSession, and it would be nice to have the inner transaction
>> behave as a nested one when there's already one in the host Session.
>>
>> Looking forward for comments and improvement ideas :)
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Sep 14 15:59:53 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 19:59:53 +0000
Subject: [hibernate-dev] Lambda usage to run a code block in an isolated
	transaction
In-Reply-To: <CAFdSV9v7oVM-eOuAS0UstvT5tAVFsJAiUwV5UDgNEffP8t9Y1A@mail.gmail.com>
References: <CAFm4XO2GA3AfkN3KMK5Q8pAhGhGeC7rCL+c93V-SGGGo3Mn7Bw@mail.gmail.com>
	<CAFdSV9v7oVM-eOuAS0UstvT5tAVFsJAiUwV5UDgNEffP8t9Y1A@mail.gmail.com>
Message-ID: <CAFdSV9uC92_q94t1LN-TaY6QtV8ws3tewY=CBQ4n8Hrzt4JKeg@mail.gmail.com>

As another option we could define something like this on SF:

<T> T doInIsolatedSession(BiFunction<Session,Boolean,T> work);
<T> T doInIsolatedSession(Function<Session,T> work);

The spec here would be to make sure any current transaction is suspended
(JTA), a new Session opened, the function performed and the suspended
transaction is resumed (JTA).  In between the Boolean would dictate whether
a new Transaction is started.

I also considered just the second form and having the function manage the
new transaction as needed.  The "difficulty" with that is back to the same
#getTransaction (API) versus #accessTransaction (SPI) issue you already
discovered.  Perhaps it could be reasonable to either expect the function
to cast to SessionImplementor or to define this based on SessionImplementor
rather than Session; dunno.



On Wed, Sep 14, 2016 at 2:32 PM Steve Ebersole <steve at hibernate.org> wrote:

> The problem with "execute in isolation" here is that the "isolation"
> aspect refers to being isolated from any current transaction.  It says
> nothing about whether that stuff-to-execute should itself be transacted.
> This is why, for example, you see IsolationDelegate accept a `transacted`
> boolean argument.
>
> How would you propose we pass such a flag in this case?  Or are you
> proposing that this always start a (new) transaction?
>
> On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> Today porting some benchmark code to Hibernate ORM 5.2 I had several
>> difficulties around the fact that the code now needs to be different
>> depending on transactions being container managed or not.
>>
>> My goal was to have a single benchmark test which I could compile once
>> and run in either JavaSE or CMT; with some help from Steve I figured
>> the necessary incantations out but ... it looks very unpractical.
>>
>> One way is to use an isolation delegate, which looks like this:
>>
>> final SessionImplementor session = (SessionImplementor) s;
>>
>> session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
>>    new WorkExecutorVisitable() {
>>       @ Override
>>       public Object accept(WorkExecutor executor, Connection
>> connection) throws SQLException {
>>          /// Some work with PreparedStatement on Connection..
>>       }
>> }, true );
>>
>> This worked fine for some raw SQL used for the benchmark
>> initialization, but in another case I'd prefer to use the Session API
>> rather than dealing with PreparedStatements and native connections;
>> it looks like we don't have an equivalent "run code in isolation" for
>> the Session ?
>>
>> It would be great if I could just pass a lambda to a Session and have
>> this executed on a "child Session" in the scope of a "child
>> Transaction", or just start and commit a transaction if there isn't
>> one.
>>
>> s.executeInIsolation( session -> session.save(...) );
>>
>> So I'd expect that details like how to begin the transaction, how it
>> should be committed (or rolled back in case of exceptions), how to
>> lookup a TransactionManager, and especially how to not leak resources
>> should be handled for the user.
>>
>> Obviously the inner Session instance is a different one than the
>> outer, so any data returned by this block should be considered
>> detached; maybe this limitation would be clearer if the method was
>> hosted on SessionFactory or StatelessSession instead?
>> Although it wouldn't necessarily have the limitations of a
>> StalessSession, and it would be nice to have the inner transaction
>> behave as a nested one when there's already one in the host Session.
>>
>> Looking forward for comments and improvement ideas :)
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed Sep 14 16:01:26 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 20:01:26 +0000
Subject: [hibernate-dev] Lambda usage to run a code block in an isolated
	transaction
In-Reply-To: <CAFm4XO05rqJqLRJfnAK9M58mrXegiJO+n-CmFdtEB8P=XrMvqQ@mail.gmail.com>
References: <CAFm4XO2GA3AfkN3KMK5Q8pAhGhGeC7rCL+c93V-SGGGo3Mn7Bw@mail.gmail.com>
	<CAFdSV9v7oVM-eOuAS0UstvT5tAVFsJAiUwV5UDgNEffP8t9Y1A@mail.gmail.com>
	<CAFm4XO05rqJqLRJfnAK9M58mrXegiJO+n-CmFdtEB8P=XrMvqQ@mail.gmail.com>
Message-ID: <CAFdSV9sFwgGBfUiz+ucvybFSrBwZ=VPX0zZV_y3XJANpXTxEvg@mail.gmail.com>

"Better" according to whom? ;)

I personally very much dislike the kind of API explosion this kind of thing
leads to.


On Wed, Sep 14, 2016 at 2:59 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 14 September 2016 at 20:32, Steve Ebersole <steve at hibernate.org> wrote:
> > The problem with "execute in isolation" here is that the "isolation"
> aspect
> > refers to being isolated from any current transaction.  It says nothing
> > about whether that stuff-to-execute should itself be transacted.  This is
> > why, for example, you see IsolationDelegate accept a `transacted` boolean
> > argument.
> >
> > How would you propose we pass such a flag in this case?  Or are you
> > proposing that this always start a (new) transaction?
>
> I had only the (new) transaction case in mind, but sure you could add
> a `transacted` boolean parameter.
>
> Or we make it explicit with a better method name:
>
> s.executeInSubtransaction( session -> session.save(...) );
>
> Thanks,
> Sanne
>
>
> >
> > On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> Today porting some benchmark code to Hibernate ORM 5.2 I had several
> >> difficulties around the fact that the code now needs to be different
> >> depending on transactions being container managed or not.
> >>
> >> My goal was to have a single benchmark test which I could compile once
> >> and run in either JavaSE or CMT; with some help from Steve I figured
> >> the necessary incantations out but ... it looks very unpractical.
> >>
> >> One way is to use an isolation delegate, which looks like this:
> >>
> >> final SessionImplementor session = (SessionImplementor) s;
> >>
> >>
> session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
> >>    new WorkExecutorVisitable() {
> >>       @ Override
> >>       public Object accept(WorkExecutor executor, Connection
> >> connection) throws SQLException {
> >>          /// Some work with PreparedStatement on Connection..
> >>       }
> >> }, true );
> >>
> >> This worked fine for some raw SQL used for the benchmark
> >> initialization, but in another case I'd prefer to use the Session API
> >> rather than dealing with PreparedStatements and native connections;
> >> it looks like we don't have an equivalent "run code in isolation" for
> >> the Session ?
> >>
> >> It would be great if I could just pass a lambda to a Session and have
> >> this executed on a "child Session" in the scope of a "child
> >> Transaction", or just start and commit a transaction if there isn't
> >> one.
> >>
> >> s.executeInIsolation( session -> session.save(...) );
> >>
> >> So I'd expect that details like how to begin the transaction, how it
> >> should be committed (or rolled back in case of exceptions), how to
> >> lookup a TransactionManager, and especially how to not leak resources
> >> should be handled for the user.
> >>
> >> Obviously the inner Session instance is a different one than the
> >> outer, so any data returned by this block should be considered
> >> detached; maybe this limitation would be clearer if the method was
> >> hosted on SessionFactory or StatelessSession instead?
> >> Although it wouldn't necessarily have the limitations of a
> >> StalessSession, and it would be nice to have the inner transaction
> >> behave as a nested one when there's already one in the host Session.
> >>
> >> Looking forward for comments and improvement ideas :)
> >>
> >> Thanks,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Sep 14 16:02:18 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 20:02:18 +0000
Subject: [hibernate-dev] Lambda usage to run a code block in an isolated
	transaction
In-Reply-To: <CAFdSV9sFwgGBfUiz+ucvybFSrBwZ=VPX0zZV_y3XJANpXTxEvg@mail.gmail.com>
References: <CAFm4XO2GA3AfkN3KMK5Q8pAhGhGeC7rCL+c93V-SGGGo3Mn7Bw@mail.gmail.com>
	<CAFdSV9v7oVM-eOuAS0UstvT5tAVFsJAiUwV5UDgNEffP8t9Y1A@mail.gmail.com>
	<CAFm4XO05rqJqLRJfnAK9M58mrXegiJO+n-CmFdtEB8P=XrMvqQ@mail.gmail.com>
	<CAFdSV9sFwgGBfUiz+ucvybFSrBwZ=VPX0zZV_y3XJANpXTxEvg@mail.gmail.com>
Message-ID: <CAFdSV9uN6sO95KBLVx+TwXRWAxJrArxC5OFLqOzEn3AwBgufFg@mail.gmail.com>

Also, why do you keep defining this in terms of Session, rather than
SessionFactory?


On Wed, Sep 14, 2016 at 3:01 PM Steve Ebersole <steve at hibernate.org> wrote:

> "Better" according to whom? ;)
>
> I personally very much dislike the kind of API explosion this kind of
> thing leads to.
>
>
> On Wed, Sep 14, 2016 at 2:59 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 14 September 2016 at 20:32, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> > The problem with "execute in isolation" here is that the "isolation"
>> aspect
>> > refers to being isolated from any current transaction.  It says nothing
>> > about whether that stuff-to-execute should itself be transacted.  This
>> is
>> > why, for example, you see IsolationDelegate accept a `transacted`
>> boolean
>> > argument.
>> >
>> > How would you propose we pass such a flag in this case?  Or are you
>> > proposing that this always start a (new) transaction?
>>
>> I had only the (new) transaction case in mind, but sure you could add
>> a `transacted` boolean parameter.
>>
>> Or we make it explicit with a better method name:
>>
>> s.executeInSubtransaction( session -> session.save(...) );
>>
>> Thanks,
>> Sanne
>>
>>
>> >
>> > On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>> >>
>> >> Today porting some benchmark code to Hibernate ORM 5.2 I had several
>> >> difficulties around the fact that the code now needs to be different
>> >> depending on transactions being container managed or not.
>> >>
>> >> My goal was to have a single benchmark test which I could compile once
>> >> and run in either JavaSE or CMT; with some help from Steve I figured
>> >> the necessary incantations out but ... it looks very unpractical.
>> >>
>> >> One way is to use an isolation delegate, which looks like this:
>> >>
>> >> final SessionImplementor session = (SessionImplementor) s;
>> >>
>> >>
>> session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
>> >>    new WorkExecutorVisitable() {
>> >>       @ Override
>> >>       public Object accept(WorkExecutor executor, Connection
>> >> connection) throws SQLException {
>> >>          /// Some work with PreparedStatement on Connection..
>> >>       }
>> >> }, true );
>> >>
>> >> This worked fine for some raw SQL used for the benchmark
>> >> initialization, but in another case I'd prefer to use the Session API
>> >> rather than dealing with PreparedStatements and native connections;
>> >> it looks like we don't have an equivalent "run code in isolation" for
>> >> the Session ?
>> >>
>> >> It would be great if I could just pass a lambda to a Session and have
>> >> this executed on a "child Session" in the scope of a "child
>> >> Transaction", or just start and commit a transaction if there isn't
>> >> one.
>> >>
>> >> s.executeInIsolation( session -> session.save(...) );
>> >>
>> >> So I'd expect that details like how to begin the transaction, how it
>> >> should be committed (or rolled back in case of exceptions), how to
>> >> lookup a TransactionManager, and especially how to not leak resources
>> >> should be handled for the user.
>> >>
>> >> Obviously the inner Session instance is a different one than the
>> >> outer, so any data returned by this block should be considered
>> >> detached; maybe this limitation would be clearer if the method was
>> >> hosted on SessionFactory or StatelessSession instead?
>> >> Although it wouldn't necessarily have the limitations of a
>> >> StalessSession, and it would be nice to have the inner transaction
>> >> behave as a nested one when there's already one in the host Session.
>> >>
>> >> Looking forward for comments and improvement ideas :)
>> >>
>> >> Thanks,
>> >> Sanne
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From sanne at hibernate.org  Wed Sep 14 16:13:00 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 14 Sep 2016 21:13:00 +0100
Subject: [hibernate-dev] Lambda usage to run a code block in an isolated
	transaction
In-Reply-To: <CAFdSV9uN6sO95KBLVx+TwXRWAxJrArxC5OFLqOzEn3AwBgufFg@mail.gmail.com>
References: <CAFm4XO2GA3AfkN3KMK5Q8pAhGhGeC7rCL+c93V-SGGGo3Mn7Bw@mail.gmail.com>
	<CAFdSV9v7oVM-eOuAS0UstvT5tAVFsJAiUwV5UDgNEffP8t9Y1A@mail.gmail.com>
	<CAFm4XO05rqJqLRJfnAK9M58mrXegiJO+n-CmFdtEB8P=XrMvqQ@mail.gmail.com>
	<CAFdSV9sFwgGBfUiz+ucvybFSrBwZ=VPX0zZV_y3XJANpXTxEvg@mail.gmail.com>
	<CAFdSV9uN6sO95KBLVx+TwXRWAxJrArxC5OFLqOzEn3AwBgufFg@mail.gmail.com>
Message-ID: <CAFm4XO25yoD3Km137cjO+qAhb+RYwWviYioNp_wtVJFYy_jTgw@mail.gmail.com>

On 14 September 2016 at 21:02, Steve Ebersole <steve at hibernate.org> wrote:
> Also, why do you keep defining this in terms of Session, rather than
> SessionFactory?

I mentioned that same doubt in my first email of this thread.
I think I prefer Session as that's what people interact with most of
the time, and it's a better choice if we opt to make this a nested
transaction of the current one; if it's meant to be totally
independent yes then we should probably consider the SF.

>
>
> On Wed, Sep 14, 2016 at 3:01 PM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> "Better" according to whom? ;)
>>
>> I personally very much dislike the kind of API explosion this kind of
>> thing leads to.
>>
>>
>> On Wed, Sep 14, 2016 at 2:59 PM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>> On 14 September 2016 at 20:32, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> > The problem with "execute in isolation" here is that the "isolation"
>>> > aspect
>>> > refers to being isolated from any current transaction.  It says nothing
>>> > about whether that stuff-to-execute should itself be transacted.  This
>>> > is
>>> > why, for example, you see IsolationDelegate accept a `transacted`
>>> > boolean
>>> > argument.
>>> >
>>> > How would you propose we pass such a flag in this case?  Or are you
>>> > proposing that this always start a (new) transaction?
>>>
>>> I had only the (new) transaction case in mind, but sure you could add
>>> a `transacted` boolean parameter.
>>>
>>> Or we make it explicit with a better method name:
>>>
>>> s.executeInSubtransaction( session -> session.save(...) );
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> >
>>> > On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <sanne at hibernate.org>
>>> > wrote:
>>> >>
>>> >> Today porting some benchmark code to Hibernate ORM 5.2 I had several
>>> >> difficulties around the fact that the code now needs to be different
>>> >> depending on transactions being container managed or not.
>>> >>
>>> >> My goal was to have a single benchmark test which I could compile once
>>> >> and run in either JavaSE or CMT; with some help from Steve I figured
>>> >> the necessary incantations out but ... it looks very unpractical.
>>> >>
>>> >> One way is to use an isolation delegate, which looks like this:
>>> >>
>>> >> final SessionImplementor session = (SessionImplementor) s;
>>> >>
>>> >>
>>> >> session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
>>> >>    new WorkExecutorVisitable() {
>>> >>       @ Override
>>> >>       public Object accept(WorkExecutor executor, Connection
>>> >> connection) throws SQLException {
>>> >>          /// Some work with PreparedStatement on Connection..
>>> >>       }
>>> >> }, true );
>>> >>
>>> >> This worked fine for some raw SQL used for the benchmark
>>> >> initialization, but in another case I'd prefer to use the Session API
>>> >> rather than dealing with PreparedStatements and native connections;
>>> >> it looks like we don't have an equivalent "run code in isolation" for
>>> >> the Session ?
>>> >>
>>> >> It would be great if I could just pass a lambda to a Session and have
>>> >> this executed on a "child Session" in the scope of a "child
>>> >> Transaction", or just start and commit a transaction if there isn't
>>> >> one.
>>> >>
>>> >> s.executeInIsolation( session -> session.save(...) );
>>> >>
>>> >> So I'd expect that details like how to begin the transaction, how it
>>> >> should be committed (or rolled back in case of exceptions), how to
>>> >> lookup a TransactionManager, and especially how to not leak resources
>>> >> should be handled for the user.
>>> >>
>>> >> Obviously the inner Session instance is a different one than the
>>> >> outer, so any data returned by this block should be considered
>>> >> detached; maybe this limitation would be clearer if the method was
>>> >> hosted on SessionFactory or StatelessSession instead?
>>> >> Although it wouldn't necessarily have the limitations of a
>>> >> StalessSession, and it would be nice to have the inner transaction
>>> >> behave as a nested one when there's already one in the host Session.
>>> >>
>>> >> Looking forward for comments and improvement ideas :)
>>> >>
>>> >> Thanks,
>>> >> Sanne
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Sep 14 16:17:09 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 20:17:09 +0000
Subject: [hibernate-dev] Lambda usage to run a code block in an isolated
	transaction
In-Reply-To: <CAFm4XO25yoD3Km137cjO+qAhb+RYwWviYioNp_wtVJFYy_jTgw@mail.gmail.com>
References: <CAFm4XO2GA3AfkN3KMK5Q8pAhGhGeC7rCL+c93V-SGGGo3Mn7Bw@mail.gmail.com>
	<CAFdSV9v7oVM-eOuAS0UstvT5tAVFsJAiUwV5UDgNEffP8t9Y1A@mail.gmail.com>
	<CAFm4XO05rqJqLRJfnAK9M58mrXegiJO+n-CmFdtEB8P=XrMvqQ@mail.gmail.com>
	<CAFdSV9sFwgGBfUiz+ucvybFSrBwZ=VPX0zZV_y3XJANpXTxEvg@mail.gmail.com>
	<CAFdSV9uN6sO95KBLVx+TwXRWAxJrArxC5OFLqOzEn3AwBgufFg@mail.gmail.com>
	<CAFm4XO25yoD3Km137cjO+qAhb+RYwWviYioNp_wtVJFYy_jTgw@mail.gmail.com>
Message-ID: <CAFdSV9tkMDt_COkj1qqEwgznB8RUo9vH61avJm-ZwJPAR+FD8g@mail.gmail.com>

Most transaction systems do not support nested transactions


On Wed, Sep 14, 2016 at 3:13 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 14 September 2016 at 21:02, Steve Ebersole <steve at hibernate.org> wrote:
> > Also, why do you keep defining this in terms of Session, rather than
> > SessionFactory?
>
> I mentioned that same doubt in my first email of this thread.
> I think I prefer Session as that's what people interact with most of
> the time, and it's a better choice if we opt to make this a nested
> transaction of the current one; if it's meant to be totally
> independent yes then we should probably consider the SF.
>
> >
> >
> > On Wed, Sep 14, 2016 at 3:01 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> "Better" according to whom? ;)
> >>
> >> I personally very much dislike the kind of API explosion this kind of
> >> thing leads to.
> >>
> >>
> >> On Wed, Sep 14, 2016 at 2:59 PM Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>>
> >>> On 14 September 2016 at 20:32, Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>> > The problem with "execute in isolation" here is that the "isolation"
> >>> > aspect
> >>> > refers to being isolated from any current transaction.  It says
> nothing
> >>> > about whether that stuff-to-execute should itself be transacted.
> This
> >>> > is
> >>> > why, for example, you see IsolationDelegate accept a `transacted`
> >>> > boolean
> >>> > argument.
> >>> >
> >>> > How would you propose we pass such a flag in this case?  Or are you
> >>> > proposing that this always start a (new) transaction?
> >>>
> >>> I had only the (new) transaction case in mind, but sure you could add
> >>> a `transacted` boolean parameter.
> >>>
> >>> Or we make it explicit with a better method name:
> >>>
> >>> s.executeInSubtransaction( session -> session.save(...) );
> >>>
> >>> Thanks,
> >>> Sanne
> >>>
> >>>
> >>> >
> >>> > On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <sanne at hibernate.org
> >
> >>> > wrote:
> >>> >>
> >>> >> Today porting some benchmark code to Hibernate ORM 5.2 I had several
> >>> >> difficulties around the fact that the code now needs to be different
> >>> >> depending on transactions being container managed or not.
> >>> >>
> >>> >> My goal was to have a single benchmark test which I could compile
> once
> >>> >> and run in either JavaSE or CMT; with some help from Steve I figured
> >>> >> the necessary incantations out but ... it looks very unpractical.
> >>> >>
> >>> >> One way is to use an isolation delegate, which looks like this:
> >>> >>
> >>> >> final SessionImplementor session = (SessionImplementor) s;
> >>> >>
> >>> >>
> >>> >>
> session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
> >>> >>    new WorkExecutorVisitable() {
> >>> >>       @ Override
> >>> >>       public Object accept(WorkExecutor executor, Connection
> >>> >> connection) throws SQLException {
> >>> >>          /// Some work with PreparedStatement on Connection..
> >>> >>       }
> >>> >> }, true );
> >>> >>
> >>> >> This worked fine for some raw SQL used for the benchmark
> >>> >> initialization, but in another case I'd prefer to use the Session
> API
> >>> >> rather than dealing with PreparedStatements and native connections;
> >>> >> it looks like we don't have an equivalent "run code in isolation"
> for
> >>> >> the Session ?
> >>> >>
> >>> >> It would be great if I could just pass a lambda to a Session and
> have
> >>> >> this executed on a "child Session" in the scope of a "child
> >>> >> Transaction", or just start and commit a transaction if there isn't
> >>> >> one.
> >>> >>
> >>> >> s.executeInIsolation( session -> session.save(...) );
> >>> >>
> >>> >> So I'd expect that details like how to begin the transaction, how it
> >>> >> should be committed (or rolled back in case of exceptions), how to
> >>> >> lookup a TransactionManager, and especially how to not leak
> resources
> >>> >> should be handled for the user.
> >>> >>
> >>> >> Obviously the inner Session instance is a different one than the
> >>> >> outer, so any data returned by this block should be considered
> >>> >> detached; maybe this limitation would be clearer if the method was
> >>> >> hosted on SessionFactory or StatelessSession instead?
> >>> >> Although it wouldn't necessarily have the limitations of a
> >>> >> StalessSession, and it would be nice to have the inner transaction
> >>> >> behave as a nested one when there's already one in the host Session.
> >>> >>
> >>> >> Looking forward for comments and improvement ideas :)
> >>> >>
> >>> >> Thanks,
> >>> >> Sanne
> >>> >> _______________________________________________
> >>> >> hibernate-dev mailing list
> >>> >> hibernate-dev at lists.jboss.org
> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Sep 14 16:35:53 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Sep 2016 20:35:53 +0000
Subject: [hibernate-dev] Lambda usage to run a code block in an isolated
	transaction
In-Reply-To: <CAFdSV9tkMDt_COkj1qqEwgznB8RUo9vH61avJm-ZwJPAR+FD8g@mail.gmail.com>
References: <CAFm4XO2GA3AfkN3KMK5Q8pAhGhGeC7rCL+c93V-SGGGo3Mn7Bw@mail.gmail.com>
	<CAFdSV9v7oVM-eOuAS0UstvT5tAVFsJAiUwV5UDgNEffP8t9Y1A@mail.gmail.com>
	<CAFm4XO05rqJqLRJfnAK9M58mrXegiJO+n-CmFdtEB8P=XrMvqQ@mail.gmail.com>
	<CAFdSV9sFwgGBfUiz+ucvybFSrBwZ=VPX0zZV_y3XJANpXTxEvg@mail.gmail.com>
	<CAFdSV9uN6sO95KBLVx+TwXRWAxJrArxC5OFLqOzEn3AwBgufFg@mail.gmail.com>
	<CAFm4XO25yoD3Km137cjO+qAhb+RYwWviYioNp_wtVJFYy_jTgw@mail.gmail.com>
	<CAFdSV9tkMDt_COkj1qqEwgznB8RUo9vH61avJm-ZwJPAR+FD8g@mail.gmail.com>
Message-ID: <CAFdSV9vAoZ_A4vDkfbs0Ai1M7YegTA+Zf=mddicC-mTSAeEwhg@mail.gmail.com>

Naming aside, my favorite approach is to have an "executor" available from
SessionFactory for accepting this functional-interface (lambda).  The
executor would be configured with whether to isolate the work and whether
to transact it.  Something like:

Executor getExecutor(boolean isolated, boolean transacted);

And then, Executor defines:

<T> T doInSession(Function<Session,T> work)

so all-told:

factory.getExecutor( true, true ).doInSession( session -> ... )

As Sanne says though we need a better name for Executor

On Wed, Sep 14, 2016 at 3:17 PM Steve Ebersole <steve at hibernate.org> wrote:

> Most transaction systems do not support nested transactions
>
>
> On Wed, Sep 14, 2016 at 3:13 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 14 September 2016 at 21:02, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> > Also, why do you keep defining this in terms of Session, rather than
>> > SessionFactory?
>>
>> I mentioned that same doubt in my first email of this thread.
>> I think I prefer Session as that's what people interact with most of
>> the time, and it's a better choice if we opt to make this a nested
>> transaction of the current one; if it's meant to be totally
>> independent yes then we should probably consider the SF.
>>
>> >
>> >
>> > On Wed, Sep 14, 2016 at 3:01 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >>
>> >> "Better" according to whom? ;)
>> >>
>> >> I personally very much dislike the kind of API explosion this kind of
>> >> thing leads to.
>> >>
>> >>
>> >> On Wed, Sep 14, 2016 at 2:59 PM Sanne Grinovero <sanne at hibernate.org>
>> >> wrote:
>> >>>
>> >>> On 14 September 2016 at 20:32, Steve Ebersole <steve at hibernate.org>
>> >>> wrote:
>> >>> > The problem with "execute in isolation" here is that the "isolation"
>> >>> > aspect
>> >>> > refers to being isolated from any current transaction.  It says
>> nothing
>> >>> > about whether that stuff-to-execute should itself be transacted.
>> This
>> >>> > is
>> >>> > why, for example, you see IsolationDelegate accept a `transacted`
>> >>> > boolean
>> >>> > argument.
>> >>> >
>> >>> > How would you propose we pass such a flag in this case?  Or are you
>> >>> > proposing that this always start a (new) transaction?
>> >>>
>> >>> I had only the (new) transaction case in mind, but sure you could add
>> >>> a `transacted` boolean parameter.
>> >>>
>> >>> Or we make it explicit with a better method name:
>> >>>
>> >>> s.executeInSubtransaction( session -> session.save(...) );
>> >>>
>> >>> Thanks,
>> >>> Sanne
>> >>>
>> >>>
>> >>> >
>> >>> > On Wed, Sep 14, 2016 at 1:39 PM Sanne Grinovero <
>> sanne at hibernate.org>
>> >>> > wrote:
>> >>> >>
>> >>> >> Today porting some benchmark code to Hibernate ORM 5.2 I had
>> several
>> >>> >> difficulties around the fact that the code now needs to be
>> different
>> >>> >> depending on transactions being container managed or not.
>> >>> >>
>> >>> >> My goal was to have a single benchmark test which I could compile
>> once
>> >>> >> and run in either JavaSE or CMT; with some help from Steve I
>> figured
>> >>> >> the necessary incantations out but ... it looks very unpractical.
>> >>> >>
>> >>> >> One way is to use an isolation delegate, which looks like this:
>> >>> >>
>> >>> >> final SessionImplementor session = (SessionImplementor) s;
>> >>> >>
>> >>> >>
>> >>> >>
>> session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
>> >>> >>    new WorkExecutorVisitable() {
>> >>> >>       @ Override
>> >>> >>       public Object accept(WorkExecutor executor, Connection
>> >>> >> connection) throws SQLException {
>> >>> >>          /// Some work with PreparedStatement on Connection..
>> >>> >>       }
>> >>> >> }, true );
>> >>> >>
>> >>> >> This worked fine for some raw SQL used for the benchmark
>> >>> >> initialization, but in another case I'd prefer to use the Session
>> API
>> >>> >> rather than dealing with PreparedStatements and native connections;
>> >>> >> it looks like we don't have an equivalent "run code in isolation"
>> for
>> >>> >> the Session ?
>> >>> >>
>> >>> >> It would be great if I could just pass a lambda to a Session and
>> have
>> >>> >> this executed on a "child Session" in the scope of a "child
>> >>> >> Transaction", or just start and commit a transaction if there isn't
>> >>> >> one.
>> >>> >>
>> >>> >> s.executeInIsolation( session -> session.save(...) );
>> >>> >>
>> >>> >> So I'd expect that details like how to begin the transaction, how
>> it
>> >>> >> should be committed (or rolled back in case of exceptions), how to
>> >>> >> lookup a TransactionManager, and especially how to not leak
>> resources
>> >>> >> should be handled for the user.
>> >>> >>
>> >>> >> Obviously the inner Session instance is a different one than the
>> >>> >> outer, so any data returned by this block should be considered
>> >>> >> detached; maybe this limitation would be clearer if the method was
>> >>> >> hosted on SessionFactory or StatelessSession instead?
>> >>> >> Although it wouldn't necessarily have the limitations of a
>> >>> >> StalessSession, and it would be nice to have the inner transaction
>> >>> >> behave as a nested one when there's already one in the host
>> Session.
>> >>> >>
>> >>> >> Looking forward for comments and improvement ideas :)
>> >>> >>
>> >>> >> Thanks,
>> >>> >> Sanne
>> >>> >> _______________________________________________
>> >>> >> hibernate-dev mailing list
>> >>> >> hibernate-dev at lists.jboss.org
>> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From sanne at hibernate.org  Wed Sep 14 18:33:37 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 14 Sep 2016 23:33:37 +0100
Subject: [hibernate-dev] People need an Hibernate Search release to
 match ORM 5.2
In-Reply-To: <CADGJaX8NJ=n21LreH_Sf598+z3f_Xb_-oapNcJp-ENgTud1LjQ@mail.gmail.com>
References: <CAFm4XO0x7Th=9woeOe7qn_c=YmW7z8khszF2o150YGQox+H3fA@mail.gmail.com>
	<CALt0+o9HKpCXxZt5MYX54vkrkd0CKoZy_H8+PHXagmcfe+fUMw@mail.gmail.com>
	<CAFm4XO2b8Q3Y1H5d-LMjDfWOXtj5DhU5svqtUOiKGtczDGZtsw@mail.gmail.com>
	<CADGJaX8NJ=n21LreH_Sf598+z3f_Xb_-oapNcJp-ENgTud1LjQ@mail.gmail.com>
Message-ID: <CAFm4XO3M4v4Ntu-kvSJEv=r=NS0eDnxdYCfSC-=dxApdK3jbag@mail.gmail.com>

Sorry for the late follow up on this one.

Even after pruning JIRA of non-important issues targeted for 5.6 there
are still several ones open and I suspect it would take more than two
weeks. So while I would generally agree with Gunnar's suggestion to
try hard to not overlap work on active branches, in this specific case
this can't wait longer as we're holding back many users.

The migration to Hibernate ORM 5.2 was a bit more tricky than usual;
I'd appreciate an additional pair of eyes on my preview PR:
 - https://github.com/hibernate/hibernate-search/pull/1160

I didn't branch to 5.7 yet but I'll do it as soon as we think that PR
is in good shape:
it's still missing a couple of non-essential steps which I'll track in
the PR description,
however I expect this to work already and deployed a 5.7.0-SNAPSHOT
from my branch.

Thanks,
Sanne



On 11 August 2016 at 18:07, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> What's still missing from releasing 5.6 (compatible with ORM 5.0/5.1),
> labelling the ES support as a "tech preview"?
>
> I'd hope we could do such release rather quickly after you re-focus from OGM
> to HSEARCH? Calling the ES support a "tech preview" will allow us to release
> something a bit less polished than we'd usually do it (e.g. we can omit some
> corner cases as not supported yet for the time being), thus saving some
> time. It has been a while since I last looked at the ES bits, but I'd expect
> it to be ready for that in rather short time?
>
> Then we can do a ORM-5.2-compatible Alpha release of HSEARCH 5.7 quickly
> afterwards, while continuing to improve the ES support, based on user's
> feedback (which I expect to come in more frequently once 5.6 is Final rather
> than Beta). I'd prefer to avoid parallel branches of development as far as
> possible, as the required merging drains energy we better could spend
> otherwise.
>
> --Gunnar
>
>
> 2016-08-11 15:52 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 11 August 2016 at 14:36, Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>> > Hi Sanne,
>> >
>> > I had the same thought a few days ago. At Open Wide, we used to follow
>> > the ORM versions very closely and we usually had a corresponding
>> > Search version very soon.
>> >
>> > I agree we need to release something compatible with ORM 5.2 sooner
>> > rather than later.
>> >
>> > I understand your concern about bringing Elasticsearch to WildFly
>> > users but it feels quite weird for a "product" version to be the
>> > reference for our community work.
>> >
>> > IMHO, it would make more sense to have our main development efforts on
>> > a community release backed by 5.2 and eventually backport the
>> > Elasticsearch work to 5.6 and make a 5.6 release if it ends up to be
>> > useful for product.
>>
>> I'm not sure why you refer to it as "product", that's not my intent at
>> all.
>>
>> WildFly is a community OSS project, so:
>>  - we have several users who are stuck to whatever is compatible with WF
>>  - several other users stuck on older versions of ORM
>>  - some people eager to try latest ORM
>>
>> My goal here is just to try satisfy all of them; not least it would be
>> nice to
>> have the next WF version to include the Hibernate Search/Elasticsearch
>> integration out of the box.
>>
>> Red Hat's supported products might take some of these things onboard in
>> future,
>> but that's much further in time and they will definitely only take on
>> combinations
>> which have proven themselves in freely available distributions first.. so
>> yes
>> in a way you're right to consider this a pre-requisite, but it's not
>> sufficient
>> and it's affecting a very different timeline and audience.
>>
>> So back to timelines, if I upgrade 5.6 today to use ORM 5.2 already then
>> we'll
>> prevent all people using ORM 5.0 and 5.1, and also all people running on
>> WF
>> from benefiting of the Elasticsearch features.
>>
>> Vice-versa, if we release 5.6 with Elasticsearch support and then follow
>> up
>> quickly with a very similar 5.7 which just introduces the changes to catch
>> up with ORM 5.2, then we have something good for everyone.
>>
>> Thanks,
>> Sanne
>>
>> >
>> > --
>> > Guillaume
>> >
>> > On Thu, Aug 11, 2016 at 3:11 PM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >> Hi all,
>> >> as you might be aware, ORM 5.2 made some rather radical internal work,
>> >> and the latest Hibernate Search releases aren't compatible.
>> >>
>> >> So far, business as usual: we typically simply catch up on the next
>> >> minor.
>> >>
>> >> The problem is that normally Hibernate Search releases are time-boxed
>> >> - with us only merging new features when they are ready - so that we
>> >> can trigger a release as needed, as contingency required.
>> >>
>> >> However currently we switched temporarily to a less desirable "we ship
>> >> when it's ready" as the Elasticsearch integration couldn't possibly be
>> >> developed by a single person in a feature branch, so in short we're
>> >> not in a position to "just release" it, as it's not ready and this
>> >> will take another month (optimistically). This would position
>> >> Hibernate Search 5.6 in September.
>> >>
>> >> We'd also want to have WildFly users have a chance to use this new
>> >> Elasticsearch feature, which ties us to make this release compatible
>> >> with ORM 5.0 and 5.1.
>> >>
>> >> So Hibernate ORM 5.2 users who need Hibernate Search will need to wait
>> >> for Search version 5.7, which in timelines would mean this fall.. way
>> >> too far ahead.
>> >>
>> >> (I tried to figure out a way to make Search master compatible with
>> >> both, but that's just not possible: it's either/or, barring an
>> >> outrageous amount of work which I'd rather spend in finishing 5.6 and
>> >> move on do do the migration properly..)
>> >>
>> >> On HSEARCH-2296 [1] James proposed we could already publish a 5.7
>> >> SNAPSHOT.
>> >>
>> >> Assuming we can set the right expectations, what would you think of
>> >> this idea to branch a 5.7 already even though 5.6 isn't done?
>> >> We could even call it Alpha1 and tag appropriately. The goal is of
>> >> course to make sure people have at least something they can test with
>> >> and make progress while we put our stuff together.
>> >>
>> >> The downside is of course that all remaining work on 5.6 will have to
>> >> be regularly rebased and applied to 5.7 too. Considering we won't do
>> >> any other changes on 5.7 I don't expect this to hurt too much.
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >> 1 - https://hibernate.atlassian.net/browse/HSEARCH-2296
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From emmanuel at hibernate.org  Fri Sep 16 13:27:21 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 16 Sep 2016 19:27:21 +0200
Subject: [hibernate-dev] OpenJDK proposal: JDK 9 modules and reflection
In-Reply-To: <20160913081931.GE41558@hibernate.org>
References: <20160913081931.GE41558@hibernate.org>
Message-ID: <67C126C1-A528-40B9-B671-3442C43DEBDB@hibernate.org>

No one ?

> On 13 Sep 2016, at 10:19, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> Hi all,
> 
> Sanne kindly pointed out to me the latest proposal by the OpenJDK team
> around JDK 9 module and how they would handle frameworks needing access
> to non exported types (Hibernate, dependency injection, etc).
> 
> If you are remotely into JDK9, please read it and provide feedback.
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000390.html
> 
> It's better than before for sure. It feels to me that most applications
> (the core of it) will end up being a weak module for this to work
> though. I'm not sure whether it is good or bad, at least a isolation
> concious person has the choice.
> 
>    export private some.package;
> 
> Is essentially equivalent to what you can do for a given package in Java
> 8.
> What I am less clear about is what relation Hibernate * projects really
> need with a module containing the entities. Do we still this proposal
> still mandates to use
> 
>    requires hibernate.entitymanager;
>    requires hibernate.core;
> 
> in the targeted module?
> 
> Or would this be a usable module
> 
>    module foo.bar {
>        exports private com.foo.bar.model;
>        requires javax.jpa;
>        // requires hibernate.entitymanager/core; no longer needed thanks to export private?
>    }
> 
> Mark proposes that in a container (EE or anything controlling module loading
> really), the container adds dynamically the addExports to the relevant
> framework. But that looks like a solution to limit exports private
> implications.
> 
> Comments?
> 
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Sun Sep 18 19:31:03 2016
From: gbadner at redhat.com (Gail Badner)
Date: Sun, 18 Sep 2016 16:31:03 -0700
Subject: [hibernate-dev] Preparing to release 5.0.11 and 5.1.2
Message-ID: <CAFDzhiQcB_wFwbcY0hXu2qZWu=+Hwru9W_A-t1ZfMh9M3pg56w@mail.gmail.com>

Please do not push anything to 5.1 or 5.0 branches as I am preparing to
release  5.0.11 and 5.1.2.

Thanks,
Gail

From gbadner at redhat.com  Mon Sep 19 06:07:59 2016
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 19 Sep 2016 03:07:59 -0700
Subject: [hibernate-dev] Preparing to release 5.0.11 and 5.1.2
In-Reply-To: <CAFDzhiQcB_wFwbcY0hXu2qZWu=+Hwru9W_A-t1ZfMh9M3pg56w@mail.gmail.com>
References: <CAFDzhiQcB_wFwbcY0hXu2qZWu=+Hwru9W_A-t1ZfMh9M3pg56w@mail.gmail.com>
Message-ID: <CAFDzhiRg9yYVmGY37yK_dX_pAP3A84yCKDb1vHV=dKy0So7GnA@mail.gmail.com>

I am having some trouble publishing the distributions for 5.0.11. I've
finished everything else except for announcements. I'll get everything
finished up later today.

On Sun, Sep 18, 2016 at 4:31 PM, Gail Badner <gbadner at redhat.com> wrote:

> Please do not push anything to 5.1 or 5.0 branches as I am preparing to
> release  5.0.11 and 5.1.2.
>
> Thanks,
> Gail
>

From yoann at hibernate.org  Mon Sep 19 08:24:28 2016
From: yoann at hibernate.org (Yoann Rodiere)
Date: Mon, 19 Sep 2016 14:24:28 +0200
Subject: [hibernate-dev] OpenJDK proposal: JDK 9 modules and reflection
In-Reply-To: <67C126C1-A528-40B9-B671-3442C43DEBDB@hibernate.org>
References: <20160913081931.GE41558@hibernate.org>
	<67C126C1-A528-40B9-B671-3442C43DEBDB@hibernate.org>
Message-ID: <CAEqagpp8tYZUsmHrnjB8uyw6XfNU5hwQHdnepqCH47w=d5w3Lg@mail.gmail.com>

I'll try to jump in. I'm mainly providing an external point of view though,
since I didn't seriously follow the progress of Java 9.

If I understood correctly, modules containing entities would not need to be
weak; they *could* be, as a quick solution to migrating to Java 9, but
ultimately the clean way of (re-)writing them would be:

    module foo.bar {
        exports private com.foo.bar.model; // Exports to anyone, including
hibernate.*
        requires javax.jpa;
    }

(Assuming all classes needed by Hibernate are in `com.foo.bar.model`)

Then public classes of package `com.foo.bar.model` would be exported to any
module, and additionally package-protected classes from this package could
be made accessible by anyone using `AccessibleObject::setAccessible`. Which
seems to solve the issue at least in principle.

What I'm not sure about is if it couldn't be even stricter by using a
qualified export :

    module foo.bar {
        exports private com.foo.bar.model to hibernate.entitymanager;
        exports private com.foo.bar.model to hibernate.core;
        requires javax.jpa;
    }

It has the advantage of not disclosing private code to the entire world,
but the disadvantage of referring to the JPA implementation explicitely,
which is a shame.

In an ideal world, it would be awesome to be able to not reference
Hibernate at all (as below) and still reduce the visibility of the
"private" package to only a select few modules. It doesn't seem to be
possible, and I guess the syntax below is wrong for many reasons. Not the
least being that there's no way for the JVM to connect the dots between JPA
and Hibernate.

    module foo.bar {
        exports private com.foo.bar.model to javax.jpa; // Won't work
        requires javax.jpa;
    }

In the end, isn't the issue also about the lack of a concept of "module
interface", which "implementation modules" may implement? I mean, here, a
developer may not want to say "I'm using Hibernate", just "I'm using JPA",
and let the consumer of the module choose the actual JPA implementation. It
would be a bit like the `uses` and `provides` keywords, except we would be
referring to entire modules instead of classes.
I guess that, of course, the full definition of such a feature might get
quite complex depending on what it provides exactly.

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

On 16 September 2016 at 19:27, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> No one ?
>
> > On 13 Sep 2016, at 10:19, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >
> > Hi all,
> >
> > Sanne kindly pointed out to me the latest proposal by the OpenJDK team
> > around JDK 9 module and how they would handle frameworks needing access
> > to non exported types (Hibernate, dependency injection, etc).
> >
> > If you are remotely into JDK9, please read it and provide feedback.
> > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/
> 2016-September/000390.html
> >
> > It's better than before for sure. It feels to me that most applications
> > (the core of it) will end up being a weak module for this to work
> > though. I'm not sure whether it is good or bad, at least a isolation
> > concious person has the choice.
> >
> >    export private some.package;
> >
> > Is essentially equivalent to what you can do for a given package in Java
> > 8.
> > What I am less clear about is what relation Hibernate * projects really
> > need with a module containing the entities. Do we still this proposal
> > still mandates to use
> >
> >    requires hibernate.entitymanager;
> >    requires hibernate.core;
> >
> > in the targeted module?
> >
> > Or would this be a usable module
> >
> >    module foo.bar {
> >        exports private com.foo.bar.model;
> >        requires javax.jpa;
> >        // requires hibernate.entitymanager/core; no longer needed thanks
> to export private?
> >    }
> >
> > Mark proposes that in a container (EE or anything controlling module
> loading
> > really), the container adds dynamically the addExports to the relevant
> > framework. But that looks like a solution to limit exports private
> > implications.
> >
> > Comments?
> >
> > Emmanuel
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From christian.beikov at gmail.com  Mon Sep 19 10:50:59 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 19 Sep 2016 16:50:59 +0200
Subject: [hibernate-dev] Question regarding HHH-10229
Message-ID: <5e7446f1-f46b-0834-c6fb-b1e0ffda976c@gmail.com>

Hey everyone,

I'd like to get HHH-10229 fixed as I can't workaround it. I prepared the 
fix and a test(https://github.com/hibernate/hibernate-orm/pull/1558), 
but I am not sure if that's the best way to do it.

Basically what I did is to check if an IdentNode is an alias to an 
element collection and if so, resolve it to the element type when 
requested from the select clause. This is very similar to what is 
happening when a MapValueNode is used, in fact some of the code is copied.
When I later encounter that a map or index function is around it, I 
resolve it as alias again.

Any comments?

Regards,
Christian Beikov

From mihalcea.vlad at gmail.com  Mon Sep 19 11:10:58 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 19 Sep 2016 18:10:58 +0300
Subject: [hibernate-dev] Question regarding HHH-10229
In-Reply-To: <5e7446f1-f46b-0834-c6fb-b1e0ffda976c@gmail.com>
References: <5e7446f1-f46b-0834-c6fb-b1e0ffda976c@gmail.com>
Message-ID: <CA+gWKMBELji+H8tq594Mhnoky714WJJcKaW9bm-GbfgCd07f-A@mail.gmail.com>

I can take a look on it tomorrow and let you know.

Vlad

On Mon, Sep 19, 2016 at 5:50 PM, Christian Beikov <
christian.beikov at gmail.com> wrote:

> Hey everyone,
>
> I'd like to get HHH-10229 fixed as I can't workaround it. I prepared the
> fix and a test(https://github.com/hibernate/hibernate-orm/pull/1558),
> but I am not sure if that's the best way to do it.
>
> Basically what I did is to check if an IdentNode is an alias to an
> element collection and if so, resolve it to the element type when
> requested from the select clause. This is very similar to what is
> happening when a MapValueNode is used, in fact some of the code is copied.
> When I later encounter that a map or index function is around it, I
> resolve it as alias again.
>
> Any comments?
>
> Regards,
> Christian Beikov
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From christian.beikov at gmail.com  Mon Sep 19 13:48:47 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 19 Sep 2016 19:48:47 +0200
Subject: [hibernate-dev] Question regarding HHH-10229
In-Reply-To: <CA+gWKMBELji+H8tq594Mhnoky714WJJcKaW9bm-GbfgCd07f-A@mail.gmail.com>
References: <5e7446f1-f46b-0834-c6fb-b1e0ffda976c@gmail.com>
	<CA+gWKMBELji+H8tq594Mhnoky714WJJcKaW9bm-GbfgCd07f-A@mail.gmail.com>
Message-ID: <6130bbae-d98b-d3ee-57ae-0328883dd47b@gmail.com>

Thanks Vlad,

and for what it's worth, the tests for H2 run through.

Am 19.09.2016 um 17:10 schrieb Vlad Mihalcea:
> I can take a look on it tomorrow and let you know.
>
> Vlad
>
> On Mon, Sep 19, 2016 at 5:50 PM, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Hey everyone,
>
>     I'd like to get HHH-10229 fixed as I can't workaround it. I
>     prepared the
>     fix and a
>     test(https://github.com/hibernate/hibernate-orm/pull/1558
>     <https://github.com/hibernate/hibernate-orm/pull/1558>),
>     but I am not sure if that's the best way to do it.
>
>     Basically what I did is to check if an IdentNode is an alias to an
>     element collection and if so, resolve it to the element type when
>     requested from the select clause. This is very similar to what is
>     happening when a MapValueNode is used, in fact some of the code is
>     copied.
>     When I later encounter that a map or index function is around it, I
>     resolve it as alias again.
>
>     Any comments?
>
>     Regards,
>     Christian Beikov
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>


From gbadner at redhat.com  Mon Sep 19 20:10:40 2016
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 19 Sep 2016 17:10:40 -0700
Subject: [hibernate-dev] Hibernate ORM 5.0.11.Final and 5.1.2.Final have
	been released
Message-ID: <CAFDzhiRPDC-P=Au_qS=t7QsaweHrXtFq8SNtrw8BvS9PZzFQ6Q@mail.gmail.com>

For details:
http://in.relation.to/2016/09/19/hibernate-orm-5011-final-and-512-final-release/

From yoann at hibernate.org  Tue Sep 20 03:56:41 2016
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 20 Sep 2016 09:56:41 +0200
Subject: [hibernate-dev] [OGM] Issue with a test and the new operation
 grouping infrastructure
In-Reply-To: <CALt0+o8c2uNii-P7O30HP=3WnE3ccy6jVwMk5BLW7e5ROBVg5A@mail.gmail.com>
References: <CALt0+o8c2uNii-P7O30HP=3WnE3ccy6jVwMk5BLW7e5ROBVg5A@mail.gmail.com>
Message-ID: <CAEqagpp=XBTTmMsAVry3Chu-KHn=XLybkQELRRKVMwcMfbWpgg@mail.gmail.com>

(Don't know what's the status of this, since it's been discussed on IRC,
but jumping in just in case)

I tend to agree with Gunnar that storing the association on the owning side
of the association seems like a good idea. At least with an external point
of view, it seems like the right choice, but I may be missing some details.

As for the specifics of the implementation, I just stumbled upon
`org.hibernate.ogm.persister.impl.BiDirectionalAssociationHelper`.
`getInverseCollectionPersister(OgmCollectionPersister)` and
`getInverseAssociationKeyMetadata(OgmEntityPersister, int)` may help... ?
All these methods suffer from a limitation: the current implementation will
only work with non-inverse collection persisters. **But** I wonder if it's
a limitation of the current implementation (we can't do more) or an
arbitrary limitation added on purpose (we don't want to do more).
For instance, in `getInverseCollectionPersister(OgmCollectionPersister)`,
we might think that the element persister used to get the reverse side is
null for inverse association. But from what I see in
`org.hibernate.persister.collection.AbstractCollectionPersister.AbstractCollectionPersister(Collection,
CollectionRegionAccessStrategy, PersisterCreationContext)` (line 315), the
element persister is always non-null regardless of whether the collection
persister is on the owning or the inverse side, provided it's not an
`@ElementCollection`.
Anyway, what I'm trying to say is:
`org.hibernate.ogm.persister.impl.BiDirectionalAssociationHelper` might not
help as it is now, but it's probably a good starting point.


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

On 12 September 2016 at 17:31, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> This is a follow-up of https://github.com/hibernate/hibernate-ogm/pull/767
> .
>
> So, in the PR, I commented the following test:
> ManyToOneGlobalTest>ManyToOneTest.testRemovalOfTransientEntityWi
> thAssociation
> (the "ManyToOneGlobalTest>" part is important)
>
> The test is a Redis one but the issue is a general one.
>
> When running under the ManyToOneGlobalTest umbrella, the associations
> are created as separate documents.
>
> The behavior of the test is the following:
>
> ========================
>
> === Creation phase
>
> Create a SalesForce with 2 SalesGuys associated.
>
> The association is managed by SalesGuy.
>
> It creates 4 documents:
> SalesForce1
> SalesGuy1
> SalesGuy2
> SalesForce1_SalesGuy navigational information
>
> === Let's delete the SalesForce1 entity
>
> It removes the SalesForce1 document (note that SalesGuy.salesForce has
> a @NotFound(action = NotFoundAction.IGNORE) annotation).
>
> So we end up with having:
> SalesGuy1
> SalesGuy2
> SalesForce1_SalesGuy navigational information [1]
>
> === Then we delete the 2 SalesGuy
>
> SalesGuys1 removed
> -> SalesForce_SalesGuy navigational information updated
> SalesGuy2 removed
> -> SalesForce1_SalesGuy navigational information removed as it is empty [2]
>
> ========================
>
> In [1], we still have the navigational information for SalesForce1 <->
> SalesGuys.
>
> With the new grouping infrastructure, I don't save every operation to
> the datastore as it's currently done. I have to store the Association
> object somewhere to keep track of the association state so I store it
> in OgmEntityEntryState in a Map<String, Association>, the key being
> the role of the association, just next to the Tuple which has the same
> purpose. It works perfectly well except that when we arrive at [2],
> the OgmEntityEntryState for SalesForce1 is gone as the entity has been
> removed in [1] so I can't access the OgmEntityEntryState of the entity
> and so the association document is not removed (and thus the test
> fails as it checks there isn't any entity/association left).
>
> Gunnar proposed the idea of storing the inverse Associations in the
> OgmEntityEntryState of the association owner. It's indeed one way to
> solve the issue.
>
> The issue with this approach is that we need to have the association
> owner when we create the AssociationPersister and, while it's not a
> problem for most of the cases, I don't see how I can do it in
> OgmLoader#getResultSet. I posted a WIP patch here:
> https://gist.github.com/gsmet/e18ccb7d3f3494bb334647e540d0d4d0.
>
> Opinions, thoughts?
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From christian.beikov at gmail.com  Tue Sep 20 13:38:39 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 20 Sep 2016 19:38:39 +0200
Subject: [hibernate-dev] HHH-9329
Message-ID: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>

Hey again,

I implemented the approach that I proposed in the issue and a test in 
https://github.com/hibernate/hibernate-orm/pull/1561

It detects left joins with join tables that use the target table alias. 
The join table is replaced with a subquery and the WITH clause is moved 
to the join of the subquery.

Any comments?

Regards,
Christian

From mihalcea.vlad at gmail.com  Tue Sep 20 13:51:35 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 20 Sep 2016 20:51:35 +0300
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
Message-ID: <CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>

Thanks,

I'm going to review it tomorrow.

Vlad

On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
christian.beikov at gmail.com> wrote:

> Hey again,
>
> I implemented the approach that I proposed in the issue and a test in
> https://github.com/hibernate/hibernate-orm/pull/1561
>
> It detects left joins with join tables that use the target table alias.
> The join table is replaced with a subquery and the WITH clause is moved
> to the join of the subquery.
>
> Any comments?
>
> Regards,
> Christian
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Sep 20 17:05:48 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 20 Sep 2016 21:05:48 +0000
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
Message-ID: <CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>

I took a quick look.  I'd prefer to see better solution as we migrate to
SQM; but for 5.x, given how Hibernate generates SQL there, I am not sure
how else you would possibly do this


On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Thanks,
>
> I'm going to review it tomorrow.
>
> Vlad
>
> On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
> > Hey again,
> >
> > I implemented the approach that I proposed in the issue and a test in
> > https://github.com/hibernate/hibernate-orm/pull/1561
> >
> > It detects left joins with join tables that use the target table alias.
> > The join table is replaced with a subquery and the WITH clause is moved
> > to the join of the subquery.
> >
> > Any comments?
> >
> > Regards,
> > Christian
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Sep 20 20:59:03 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 00:59:03 +0000
Subject: [hibernate-dev] NativeQuery and parameters
Message-ID: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>

In the interest of questioning everything, just to make sure we are all on
the same page, Hibernate's support for native SQL queries currently
recognizes named parameters, positional parameters as well as JDBC-style
parameters.

JPA only defines support for "JDBC-style parameters" as valid for native
SQL queries:
{quote}
It is assumed that for native queries the parameters themselves use the SQL
syntax (i.e., ???, rather than ??1?).
{quote}

Furthermore Hibernate does not support a native query using both positional
parameters and JDBC-style parameters in the same query because it causes a
non-determinism wrt the positions.

I assume we want to continue to support that full complement of parameter
types, with the positional/JDBC-style caveat.

Further I assume we will hook up the use of any non-JDBC-style parameters
in with the "strict JPA compliance" checking and throw an error when
indicated.

Anyone have objections to any of that?

From brett at hibernate.org  Tue Sep 20 21:51:42 2016
From: brett at hibernate.org (Brett Meyer)
Date: Tue, 20 Sep 2016 21:51:42 -0400
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
Message-ID: <13cf8fb7-2a50-d75d-e695-7365fda8bce5@hibernate.org>

+1 across the board.


On 09/20/2016 08:59 PM, Steve Ebersole wrote:
> In the interest of questioning everything, just to make sure we are all on
> the same page, Hibernate's support for native SQL queries currently
> recognizes named parameters, positional parameters as well as JDBC-style
> parameters.
>
> JPA only defines support for "JDBC-style parameters" as valid for native
> SQL queries:
> {quote}
> It is assumed that for native queries the parameters themselves use the SQL
> syntax (i.e., ???, rather than ??1?).
> {quote}
>
> Furthermore Hibernate does not support a native query using both positional
> parameters and JDBC-style parameters in the same query because it causes a
> non-determinism wrt the positions.
>
> I assume we want to continue to support that full complement of parameter
> types, with the positional/JDBC-style caveat.
>
> Further I assume we will hook up the use of any non-JDBC-style parameters
> in with the "strict JPA compliance" checking and throw an error when
> indicated.
>
> Anyone have objections to any of that?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From coladict at gmail.com  Wed Sep 21 00:44:53 2016
From: coladict at gmail.com (Jordan Gigov)
Date: Wed, 21 Sep 2016 07:44:53 +0300
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
Message-ID: <CA+nBocCxQkmohn3JogaMfoNCKs=hS4a_MwWo4t_gdp2ZRAL9Cg@mail.gmail.com>

Actually JPA defines it as "Only positional parameter binding and
positional access to result items may be portably used for native queries".
I believe "portably" means the providers are only required to support
positional, but not forbidden from supporting other.

2016-09-21 3:59 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> In the interest of questioning everything, just to make sure we are all on
> the same page, Hibernate's support for native SQL queries currently
> recognizes named parameters, positional parameters as well as JDBC-style
> parameters.
>
> JPA only defines support for "JDBC-style parameters" as valid for native
> SQL queries:
> {quote}
> It is assumed that for native queries the parameters themselves use the SQL
> syntax (i.e., ???, rather than ??1?).
> {quote}
>
> Furthermore Hibernate does not support a native query using both positional
> parameters and JDBC-style parameters in the same query because it causes a
> non-determinism wrt the positions.
>
> I assume we want to continue to support that full complement of parameter
> types, with the positional/JDBC-style caveat.
>
> Further I assume we will hook up the use of any non-JDBC-style parameters
> in with the "strict JPA compliance" checking and throw an error when
> indicated.
>
> Anyone have objections to any of that?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Wed Sep 21 01:20:27 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 21 Sep 2016 08:20:27 +0300
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
Message-ID: <CA+gWKMD26vmzEct3O7A0qVTOmDNGnx4Bu84LShfLMj4yayDJ7A@mail.gmail.com>

+1

On Wed, Sep 21, 2016 at 3:59 AM, Steve Ebersole <steve at hibernate.org> wrote:

> In the interest of questioning everything, just to make sure we are all on
> the same page, Hibernate's support for native SQL queries currently
> recognizes named parameters, positional parameters as well as JDBC-style
> parameters.
>
> JPA only defines support for "JDBC-style parameters" as valid for native
> SQL queries:
> {quote}
> It is assumed that for native queries the parameters themselves use the SQL
> syntax (i.e., ???, rather than ??1?).
> {quote}
>
> Furthermore Hibernate does not support a native query using both positional
> parameters and JDBC-style parameters in the same query because it causes a
> non-determinism wrt the positions.
>
> I assume we want to continue to support that full complement of parameter
> types, with the positional/JDBC-style caveat.
>
> Further I assume we will hook up the use of any non-JDBC-style parameters
> in with the "strict JPA compliance" checking and throw an error when
> indicated.
>
> Anyone have objections to any of that?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Sep 21 02:12:36 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 21 Sep 2016 08:12:36 +0200
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
Message-ID: <CADGJaX8uAqY4-bg2w+awEP4ux74G6hVkeVpj34pRqST1X7+YGg@mail.gmail.com>

+1 Sounds good.

2016-09-21 2:59 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> In the interest of questioning everything, just to make sure we are all on
> the same page, Hibernate's support for native SQL queries currently
> recognizes named parameters, positional parameters as well as JDBC-style
> parameters.
>
> JPA only defines support for "JDBC-style parameters" as valid for native
> SQL queries:
> {quote}
> It is assumed that for native queries the parameters themselves use the SQL
> syntax (i.e., ???, rather than ??1?).
> {quote}
>
> Furthermore Hibernate does not support a native query using both positional
> parameters and JDBC-style parameters in the same query because it causes a
> non-determinism wrt the positions.
>
> I assume we want to continue to support that full complement of parameter
> types, with the positional/JDBC-style caveat.
>
> Further I assume we will hook up the use of any non-JDBC-style parameters
> in with the "strict JPA compliance" checking and throw an error when
> indicated.
>
> Anyone have objections to any of that?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From christian.beikov at gmail.com  Wed Sep 21 03:14:12 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 21 Sep 2016 09:14:12 +0200
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
Message-ID: <1bbae282-698f-8617-52fa-c0e194567762@gmail.com>

Thanks, I know that it's a beauty ^^
Hope this can get into all 5.x branches?

Regards,
Christian
Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
> I took a quick look.  I'd prefer to see better solution as we migrate 
> to SQM; but for 5.x, given how Hibernate generates SQL there, I am not 
> sure how else you would possibly do this
>
>
> On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea 
> <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>> wrote:
>
>     Thanks,
>
>     I'm going to review it tomorrow.
>
>     Vlad
>
>     On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
>     christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     > Hey again,
>     >
>     > I implemented the approach that I proposed in the issue and a
>     test in
>     > https://github.com/hibernate/hibernate-orm/pull/1561
>     >
>     > It detects left joins with join tables that use the target table
>     alias.
>     > The join table is replaced with a subquery and the WITH clause
>     is moved
>     > to the join of the subquery.
>     >
>     > Any comments?
>     >
>     > Regards,
>     > Christian
>     > _______________________________________________
>     > hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From andrea at hibernate.org  Wed Sep 21 05:20:01 2016
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 21 Sep 2016 10:20:01 +0100
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
Message-ID: <CAL00eSRS8pFKdzRQ0Kyr5+iQnr9p69FR8PEjEWr5cFXdUQhB6Q@mail.gmail.com>

+1

On 21 Sep 2016 02:00, "Steve Ebersole" <steve at hibernate.org> wrote:

> In the interest of questioning everything, just to make sure we are all on
> the same page, Hibernate's support for native SQL queries currently
> recognizes named parameters, positional parameters as well as JDBC-style
> parameters.
>
> JPA only defines support for "JDBC-style parameters" as valid for native
> SQL queries:
> {quote}
> It is assumed that for native queries the parameters themselves use the SQL
> syntax (i.e., ???, rather than ??1?).
> {quote}
>
> Furthermore Hibernate does not support a native query using both positional
> parameters and JDBC-style parameters in the same query because it causes a
> non-determinism wrt the positions.
>
> I assume we want to continue to support that full complement of parameter
> types, with the positional/JDBC-style caveat.
>
> Further I assume we will hook up the use of any non-JDBC-style parameters
> in with the "strict JPA compliance" checking and throw an error when
> indicated.
>
> Anyone have objections to any of that?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Wed Sep 21 05:50:32 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 21 Sep 2016 10:50:32 +0100
Subject: [hibernate-dev] Build time downloads of ORM itself during an ORM
	clean build?
Message-ID: <CAFm4XO32UpeQbH9Cxo7mUmm1XgsNEYT29N10-TQhkMRQ2zaHOw@mail.gmail.com>

Hi all,

I just happened to build Hibernate ORM's latest "master" on a clean
machine and this is how the build log looks like:

No compatible daemons found:
  - an idle daemon with different JVM constraints can't run this build
Starting a new Gradle Daemon for this build: subsequent builds will be faster
:buildSrc:clean UP-TO-DATE
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes
:buildSrc:jar
:buildSrc:assemble
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build
Download http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-core/5.2.3-SNAPSHOT/hibernate-core-5.2.3-20160920.201550-53.jar
[...]

I'm not having any specific failure, but it seems very suspicious that
the build is needing to download hibernate-core at the very beginning
of the build?

I'm not familiar enough with ORM's build scripts to investigate myself
but I suspect some dependency order needs to be cleaned up, or you
might be including some side-effects from previous builds.

Thanks,
Sanne

From gunnar at hibernate.org  Wed Sep 21 08:02:40 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 21 Sep 2016 14:02:40 +0200
Subject: [hibernate-dev] Limited history in HipChat
Message-ID: <CADGJaX_ckq5ra9bZML7fkVciv_WFO1YiY+NktZy51LoZO+e-7g@mail.gmail.com>

Steve, all,

Is there any way we can get HipChat Plus licenses for the team from
Atlassian?

The free client provides access only to a limited part of the chat history,
making it impossible to search for discussions discussed more than a few
weeks ago.

That's starting to be a real problem now that we've been using HipChat for
a while and early discussions begin to fall below the threshold of being
available in the free version.

I don't know whom to reach out to at Atlassian, otherwise I'd do it myself.
I'd hope they are supportive given that we can use JIRA at all for free,
too.

Thanks,

--Gunnar

From sanne at hibernate.org  Wed Sep 21 08:11:12 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 21 Sep 2016 13:11:12 +0100
Subject: [hibernate-dev] [Action needed!] Java 9 preview updated on CI -
	build options changed syntax
Message-ID: <CAFm4XO3omaZ2-2VqY+NP9XkLE7qCpcXTgYjeV-D7__hfSoXHgQ@mail.gmail.com>

Hi all,
I've updated the Java 9 preview build on our ci.hibernate.org build
servers to version 9-ea+136.

There's a catch: the build option which we've been using "-addmods"
has been renamed "--add-modules".

We need to update all build scripts; I'm taking care of Search and
OGM, I hope others can do the same on the other projects?

It's trivial; for example:
 - https://github.com/hibernate/hibernate-search/commit/cbc8694f342159e262d578cc218b8e30c5354274

Thanks,
Sanne

From crancran at gmail.com  Wed Sep 21 09:08:04 2016
From: crancran at gmail.com (Chris Cranford)
Date: Wed, 21 Sep 2016 09:08:04 -0400
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
Message-ID: <c12d8135-4bfe-637b-acea-23de274a648f@gmail.com>

+1


On 09/20/2016 08:59 PM, Steve Ebersole wrote:
> In the interest of questioning everything, just to make sure we are all on
> the same page, Hibernate's support for native SQL queries currently
> recognizes named parameters, positional parameters as well as JDBC-style
> parameters.
>
> JPA only defines support for "JDBC-style parameters" as valid for native
> SQL queries:
> {quote}
> It is assumed that for native queries the parameters themselves use the SQL
> syntax (i.e., ???, rather than ??1?).
> {quote}
>
> Furthermore Hibernate does not support a native query using both positional
> parameters and JDBC-style parameters in the same query because it causes a
> non-determinism wrt the positions.
>
> I assume we want to continue to support that full complement of parameter
> types, with the positional/JDBC-style caveat.
>
> Further I assume we will hook up the use of any non-JDBC-style parameters
> in with the "strict JPA compliance" checking and throw an error when
> indicated.
>
> Anyone have objections to any of that?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From mihalcea.vlad at gmail.com  Wed Sep 21 09:08:38 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 21 Sep 2016 16:08:38 +0300
Subject: [hibernate-dev] AvailableSettings.DISCARD_PC_ON_CLOSE and
	Transaction status
Message-ID: <CA+gWKMA5Nr+UcDQGvLA5o9EXBm1Ju-80NLW4NQ=_o0HQ0RWXxQ@mail.gmail.com>

Hi,

While reviewing and adding a test case for
https://hibernate.atlassian.net/browse/HHH-11120,
I realized that if we enable the AvailableSettings.DISCARD_PC_ON_CLOSE
property,
the database connection gets closed when the EntityManager is closed, while
the EntityTransaction status remains ACTIVE.

I noticed that in the call:

currentHibernateTransaction.invalidate();

But this method is no-op and deprecated as well.

Is this behavior intended? If the database connection was closed, at least
for RESOURCE_LOCAL, on most RDBMS engines, the underlying transaction gets
rolled back as well.
For JTA, the connection might still be open and allocated to the current
user since the TM controls when the resources are to be released.

Should we leave this behavior like that?

Vlad

From steve at hibernate.org  Wed Sep 21 09:20:30 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 13:20:30 +0000
Subject: [hibernate-dev] Limited history in HipChat
In-Reply-To: <CADGJaX_ckq5ra9bZML7fkVciv_WFO1YiY+NktZy51LoZO+e-7g@mail.gmail.com>
References: <CADGJaX_ckq5ra9bZML7fkVciv_WFO1YiY+NktZy51LoZO+e-7g@mail.gmail.com>
Message-ID: <CAFdSV9vqtsaQ_hk5xZ4d+cuOicFEnfyYBxBG0bxoqJFZym9CXg@mail.gmail.com>

I thought we had some sort of non-basic license already.  Isn't that why we
need to explicitly invite people to be non-Guest?

Anyway, I agree wrt HipChat being more or less useless.  I've been saying
that for a while now.  Yes the GitHub and Jira and social integrations *can
be* nice (they can also be annoying).

Ayway, I am not the one who set up HipChat for Hibernate.  Sanne maybe?
Anyway I am looking around for a way.

On Wed, Sep 21, 2016 at 7:05 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Steve, all,
>
> Is there any way we can get HipChat Plus licenses for the team from
> Atlassian?
>
> The free client provides access only to a limited part of the chat history,
> making it impossible to search for discussions discussed more than a few
> weeks ago.
>
> That's starting to be a real problem now that we've been using HipChat for
> a while and early discussions begin to fall below the threshold of being
> available in the free version.
>
> I don't know whom to reach out to at Atlassian, otherwise I'd do it myself.
> I'd hope they are supportive given that we can use JIRA at all for free,
> too.
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Sep 21 09:29:57 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 13:29:57 +0000
Subject: [hibernate-dev] AvailableSettings.DISCARD_PC_ON_CLOSE and
 Transaction status
In-Reply-To: <CA+gWKMA5Nr+UcDQGvLA5o9EXBm1Ju-80NLW4NQ=_o0HQ0RWXxQ@mail.gmail.com>
References: <CA+gWKMA5Nr+UcDQGvLA5o9EXBm1Ju-80NLW4NQ=_o0HQ0RWXxQ@mail.gmail.com>
Message-ID: <CAFdSV9usTNZQ=A5RyMFR3tTn99vQik0OR4Dirg_4=K_O4xkfVg@mail.gmail.com>

DISCARD_PC_ON_CLOSE, as a concept, is only valid for JTA iirc.

On Wed, Sep 21, 2016 at 8:11 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> While reviewing and adding a test case for
> https://hibernate.atlassian.net/browse/HHH-11120,
> I realized that if we enable the AvailableSettings.DISCARD_PC_ON_CLOSE
> property,
> the database connection gets closed when the EntityManager is closed, while
> the EntityTransaction status remains ACTIVE.
>
> I noticed that in the call:
>
> currentHibernateTransaction.invalidate();
>
> But this method is no-op and deprecated as well.
>
> Is this behavior intended? If the database connection was closed, at least
> for RESOURCE_LOCAL, on most RDBMS engines, the underlying transaction gets
> rolled back as well.
> For JTA, the connection might still be open and allocated to the current
> user since the TM controls when the resources are to be released.
>
> Should we leave this behavior like that?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Sep 21 09:30:33 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 13:30:33 +0000
Subject: [hibernate-dev] AvailableSettings.DISCARD_PC_ON_CLOSE and
 Transaction status
In-Reply-To: <CAFdSV9usTNZQ=A5RyMFR3tTn99vQik0OR4Dirg_4=K_O4xkfVg@mail.gmail.com>
References: <CA+gWKMA5Nr+UcDQGvLA5o9EXBm1Ju-80NLW4NQ=_o0HQ0RWXxQ@mail.gmail.com>
	<CAFdSV9usTNZQ=A5RyMFR3tTn99vQik0OR4Dirg_4=K_O4xkfVg@mail.gmail.com>
Message-ID: <CAFdSV9v7oNnsdcOE6CvPQ3avwxd62ZetWeN6D1rqW1PwFGUa-w@mail.gmail.com>

Sorry, *was* only valid for JTA.  As you mentioned we handle this
differently today.


On Wed, Sep 21, 2016 at 8:29 AM Steve Ebersole <steve at hibernate.org> wrote:

> DISCARD_PC_ON_CLOSE, as a concept, is only valid for JTA iirc.
>
> On Wed, Sep 21, 2016 at 8:11 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> While reviewing and adding a test case for
>> https://hibernate.atlassian.net/browse/HHH-11120,
>> I realized that if we enable the AvailableSettings.DISCARD_PC_ON_CLOSE
>> property,
>> the database connection gets closed when the EntityManager is closed,
>> while
>> the EntityTransaction status remains ACTIVE.
>>
>> I noticed that in the call:
>>
>> currentHibernateTransaction.invalidate();
>>
>> But this method is no-op and deprecated as well.
>>
>> Is this behavior intended? If the database connection was closed, at least
>> for RESOURCE_LOCAL, on most RDBMS engines, the underlying transaction gets
>> rolled back as well.
>> For JTA, the connection might still be open and allocated to the current
>> user since the TM controls when the resources are to be released.
>>
>> Should we leave this behavior like that?
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From mihalcea.vlad at gmail.com  Wed Sep 21 09:33:13 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 21 Sep 2016 16:33:13 +0300
Subject: [hibernate-dev] AvailableSettings.DISCARD_PC_ON_CLOSE and
 Transaction status
In-Reply-To: <CAFdSV9v7oNnsdcOE6CvPQ3avwxd62ZetWeN6D1rqW1PwFGUa-w@mail.gmail.com>
References: <CA+gWKMA5Nr+UcDQGvLA5o9EXBm1Ju-80NLW4NQ=_o0HQ0RWXxQ@mail.gmail.com>
	<CAFdSV9usTNZQ=A5RyMFR3tTn99vQik0OR4Dirg_4=K_O4xkfVg@mail.gmail.com>
	<CAFdSV9v7oNnsdcOE6CvPQ3avwxd62ZetWeN6D1rqW1PwFGUa-w@mail.gmail.com>
Message-ID: <CA+gWKMAJk-QWFLpOEFt3=5MJNUCDPMyP4xA6n+E7QYd7iD0sKQ@mail.gmail.com>

I could make use of it in a non-JTA environment. I guess we need to think
what should we do with the transaction status because now it's still
active, but if we try to rollback, we'll get an exception because the
connection was closed.

Vlad

On Wed, Sep 21, 2016 at 4:30 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Sorry, *was* only valid for JTA.  As you mentioned we handle this
> differently today.
>
>
> On Wed, Sep 21, 2016 at 8:29 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> DISCARD_PC_ON_CLOSE, as a concept, is only valid for JTA iirc.
>>
>> On Wed, Sep 21, 2016 at 8:11 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> While reviewing and adding a test case for
>>> https://hibernate.atlassian.net/browse/HHH-11120,
>>> I realized that if we enable the AvailableSettings.DISCARD_PC_ON_CLOSE
>>> property,
>>> the database connection gets closed when the EntityManager is closed,
>>> while
>>> the EntityTransaction status remains ACTIVE.
>>>
>>> I noticed that in the call:
>>>
>>> currentHibernateTransaction.invalidate();
>>>
>>> But this method is no-op and deprecated as well.
>>>
>>> Is this behavior intended? If the database connection was closed, at
>>> least
>>> for RESOURCE_LOCAL, on most RDBMS engines, the underlying transaction
>>> gets
>>> rolled back as well.
>>> For JTA, the connection might still be open and allocated to the current
>>> user since the TM controls when the resources are to be released.
>>>
>>> Should we leave this behavior like that?
>>>
>>> Vlad
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From steve at hibernate.org  Wed Sep 21 09:48:41 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 13:48:41 +0000
Subject: [hibernate-dev] AvailableSettings.DISCARD_PC_ON_CLOSE and
 Transaction status
In-Reply-To: <CA+gWKMAJk-QWFLpOEFt3=5MJNUCDPMyP4xA6n+E7QYd7iD0sKQ@mail.gmail.com>
References: <CA+gWKMA5Nr+UcDQGvLA5o9EXBm1Ju-80NLW4NQ=_o0HQ0RWXxQ@mail.gmail.com>
	<CAFdSV9usTNZQ=A5RyMFR3tTn99vQik0OR4Dirg_4=K_O4xkfVg@mail.gmail.com>
	<CAFdSV9v7oNnsdcOE6CvPQ3avwxd62ZetWeN6D1rqW1PwFGUa-w@mail.gmail.com>
	<CA+gWKMAJk-QWFLpOEFt3=5MJNUCDPMyP4xA6n+E7QYd7iD0sKQ@mail.gmail.com>
Message-ID: <CAFdSV9t7ZHdPuE-z94WiR_BM8=kkRR6b41tS8XXAQnNDePegiA@mail.gmail.com>

I have no idea what "I could make use of it" means in this context.  Make
use of what?  That setting?  That setting has zero effect today, unless I
missed something.

On Wed, Sep 21, 2016 at 8:33 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I could make use of it in a non-JTA environment. I guess we need to think
> what should we do with the transaction status because now it's still
> active, but if we try to rollback, we'll get an exception because the
> connection was closed.
>
> Vlad
>
> On Wed, Sep 21, 2016 at 4:30 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Sorry, *was* only valid for JTA.  As you mentioned we handle this
>> differently today.
>>
>>
>> On Wed, Sep 21, 2016 at 8:29 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> DISCARD_PC_ON_CLOSE, as a concept, is only valid for JTA iirc.
>>>
>>> On Wed, Sep 21, 2016 at 8:11 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> While reviewing and adding a test case for
>>>> https://hibernate.atlassian.net/browse/HHH-11120,
>>>> I realized that if we enable the AvailableSettings.DISCARD_PC_ON_CLOSE
>>>> property,
>>>> the database connection gets closed when the EntityManager is closed,
>>>> while
>>>> the EntityTransaction status remains ACTIVE.
>>>>
>>>> I noticed that in the call:
>>>>
>>>> currentHibernateTransaction.invalidate();
>>>>
>>>> But this method is no-op and deprecated as well.
>>>>
>>>> Is this behavior intended? If the database connection was closed, at
>>>> least
>>>> for RESOURCE_LOCAL, on most RDBMS engines, the underlying transaction
>>>> gets
>>>> rolled back as well.
>>>> For JTA, the connection might still be open and allocated to the current
>>>> user since the TM controls when the resources are to be released.
>>>>
>>>> Should we leave this behavior like that?
>>>>
>>>> Vlad
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>

From emmanuel at hibernate.org  Wed Sep 21 09:53:38 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 21 Sep 2016 15:53:38 +0200
Subject: [hibernate-dev] Limited history in HipChat
In-Reply-To: <CAFdSV9vqtsaQ_hk5xZ4d+cuOicFEnfyYBxBG0bxoqJFZym9CXg@mail.gmail.com>
References: <CADGJaX_ckq5ra9bZML7fkVciv_WFO1YiY+NktZy51LoZO+e-7g@mail.gmail.com>
	<CAFdSV9vqtsaQ_hk5xZ4d+cuOicFEnfyYBxBG0bxoqJFZym9CXg@mail.gmail.com>
Message-ID: <FDC59BD4-D868-425F-8FEE-69928BBF645F@hibernate.org>

At least on the NoORM side, we do like what it provides and we do exchange a lot in it. It doesn?t have to be everyone?s best tool of course.
The multi client including phone is an awesome feature for my flow for example.

I?ve contacted Samuel and he offered options to give it a shot.

Emmanuel


> On 21 Sep 2016, at 15:20, Steve Ebersole <steve at hibernate.org> wrote:
> 
> I thought we had some sort of non-basic license already.  Isn't that why we
> need to explicitly invite people to be non-Guest?
> 
> Anyway, I agree wrt HipChat being more or less useless.  I've been saying
> that for a while now.  Yes the GitHub and Jira and social integrations *can
> be* nice (they can also be annoying).
> 
> Ayway, I am not the one who set up HipChat for Hibernate.  Sanne maybe?
> Anyway I am looking around for a way.
> 
> On Wed, Sep 21, 2016 at 7:05 AM Gunnar Morling <gunnar at hibernate.org> wrote:
> 
>> Steve, all,
>> 
>> Is there any way we can get HipChat Plus licenses for the team from
>> Atlassian?
>> 
>> The free client provides access only to a limited part of the chat history,
>> making it impossible to search for discussions discussed more than a few
>> weeks ago.
>> 
>> That's starting to be a real problem now that we've been using HipChat for
>> a while and early discussions begin to fall below the threshold of being
>> available in the free version.
>> 
>> I don't know whom to reach out to at Atlassian, otherwise I'd do it myself.
>> I'd hope they are supportive given that we can use JIRA at all for free,
>> too.
>> 
>> Thanks,
>> 
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From mihalcea.vlad at gmail.com  Wed Sep 21 09:55:50 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 21 Sep 2016 16:55:50 +0300
Subject: [hibernate-dev] AvailableSettings.DISCARD_PC_ON_CLOSE and
 Transaction status
In-Reply-To: <CAFdSV9t7ZHdPuE-z94WiR_BM8=kkRR6b41tS8XXAQnNDePegiA@mail.gmail.com>
References: <CA+gWKMA5Nr+UcDQGvLA5o9EXBm1Ju-80NLW4NQ=_o0HQ0RWXxQ@mail.gmail.com>
	<CAFdSV9usTNZQ=A5RyMFR3tTn99vQik0OR4Dirg_4=K_O4xkfVg@mail.gmail.com>
	<CAFdSV9v7oNnsdcOE6CvPQ3avwxd62ZetWeN6D1rqW1PwFGUa-w@mail.gmail.com>
	<CA+gWKMAJk-QWFLpOEFt3=5MJNUCDPMyP4xA6n+E7QYd7iD0sKQ@mail.gmail.com>
	<CAFdSV9t7ZHdPuE-z94WiR_BM8=kkRR6b41tS8XXAQnNDePegiA@mail.gmail.com>
Message-ID: <CA+gWKMDSdZhrbyFE0z66d4igmi0ZHrO5TyhW4bw8N+9PbF8vAA@mail.gmail.com>

Check out this Jira issue that I integrated today:

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

If we enable this property, all the underlying resources are released right
away.
Otherwise (the default option), resources are released when the transaction
is ended (commit/rollback).

If this fix was a mistake and we should not support this property, then we
should deprecate it and remove it in a future release, right?

Vlad

On Wed, Sep 21, 2016 at 4:48 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I have no idea what "I could make use of it" means in this context.  Make
> use of what?  That setting?  That setting has zero effect today, unless I
> missed something.
>
> On Wed, Sep 21, 2016 at 8:33 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I could make use of it in a non-JTA environment. I guess we need to think
>> what should we do with the transaction status because now it's still
>> active, but if we try to rollback, we'll get an exception because the
>> connection was closed.
>>
>> Vlad
>>
>> On Wed, Sep 21, 2016 at 4:30 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Sorry, *was* only valid for JTA.  As you mentioned we handle this
>>> differently today.
>>>
>>>
>>> On Wed, Sep 21, 2016 at 8:29 AM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> DISCARD_PC_ON_CLOSE, as a concept, is only valid for JTA iirc.
>>>>
>>>> On Wed, Sep 21, 2016 at 8:11 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> While reviewing and adding a test case for
>>>>> https://hibernate.atlassian.net/browse/HHH-11120,
>>>>> I realized that if we enable the AvailableSettings.DISCARD_PC_ON_CLOSE
>>>>> property,
>>>>> the database connection gets closed when the EntityManager is closed,
>>>>> while
>>>>> the EntityTransaction status remains ACTIVE.
>>>>>
>>>>> I noticed that in the call:
>>>>>
>>>>> currentHibernateTransaction.invalidate();
>>>>>
>>>>> But this method is no-op and deprecated as well.
>>>>>
>>>>> Is this behavior intended? If the database connection was closed, at
>>>>> least
>>>>> for RESOURCE_LOCAL, on most RDBMS engines, the underlying transaction
>>>>> gets
>>>>> rolled back as well.
>>>>> For JTA, the connection might still be open and allocated to the
>>>>> current
>>>>> user since the TM controls when the resources are to be released.
>>>>>
>>>>> Should we leave this behavior like that?
>>>>>
>>>>> Vlad
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>

From paranoiabla at gmail.com  Wed Sep 21 10:00:20 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 21 Sep 2016 17:00:20 +0300
Subject: [hibernate-dev] Cannot build branch 5.1
Message-ID: <CAKnbemWFuhR_AUtB2ZcX4R+T7bmOFPmoYZGV9t7NgoAm=yPbEQ@mail.gmail.com>

Hi guys,

I'm trying to build the 5.1 branch with "./gradlew publishToMavenLocal" but
I get the following error:

:hibernate-ehcache:generatePomFileForMavenJavaPublication
:hibernate-ehcache:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Starting AnimalSniffer checks using [java16-1.0.signature] against
[sourceSets.main]
/home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
Undefined reference:
net.sf.ehcache.config.TerracottaConfiguration.ValueMode[]
net.sf.ehcache.config.TerracottaConfiguration.ValueMode.values()
/home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
Undefined reference:
net.sf.ehcache.config.TerracottaConfiguration.ValueMode
net.sf.ehcache.config.TerracottaConfiguration.ValueMode.IDENTITY
/home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
Undefined reference: int
net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
/home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
Undefined reference:
net.sf.ehcache.config.TerracottaConfiguration.ValueMode
net.sf.ehcache.config.TerracottaConfiguration.ValueMode.SERIALIZATION
/home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
Undefined reference: int
net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
:hibernate-ehcache:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':hibernate-ehcache:compileJava'.
> Signature errors found for SourceSet main against java16-1.0.signature.
Verify errors and ignore them with the proper annotation if needed.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.

BUILD FAILED

Total time: 23.979 secs


Can you please help me?

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Wed Sep 21 10:17:29 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 14:17:29 +0000
Subject: [hibernate-dev] Cannot build branch 5.1
In-Reply-To: <CAKnbemWFuhR_AUtB2ZcX4R+T7bmOFPmoYZGV9t7NgoAm=yPbEQ@mail.gmail.com>
References: <CAKnbemWFuhR_AUtB2ZcX4R+T7bmOFPmoYZGV9t7NgoAm=yPbEQ@mail.gmail.com>
Message-ID: <CAFdSV9sQ28HaoC4O+D-VukJBaQWbv2W18tav7mUxsQUSNDTH_Q@mail.gmail.com>

Strange.  It is working in CI:
http://ci.hibernate.org/view/ORM/job/hibernate-orm-5.1-h2/


On Wed, Sep 21, 2016 at 9:03 AM Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Hi guys,
>
> I'm trying to build the 5.1 branch with "./gradlew publishToMavenLocal" but
> I get the following error:
>
> :hibernate-ehcache:generatePomFileForMavenJavaPublication
> :hibernate-ehcache:compileJava
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
>
> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
> Undefined reference:
> net.sf.ehcache.config.TerracottaConfiguration.ValueMode[]
> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.values()
>
> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
> Undefined reference:
> net.sf.ehcache.config.TerracottaConfiguration.ValueMode
> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.IDENTITY
>
> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
> Undefined reference: int
> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
>
> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
> Undefined reference:
> net.sf.ehcache.config.TerracottaConfiguration.ValueMode
> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.SERIALIZATION
>
> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
> Undefined reference: int
> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
> :hibernate-ehcache:compileJava FAILED
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':hibernate-ehcache:compileJava'.
> > Signature errors found for SourceSet main against java16-1.0.signature.
> Verify errors and ignore them with the proper annotation if needed.
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output.
>
> BUILD FAILED
>
> Total time: 23.979 secs
>
>
> Can you please help me?
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From paranoiabla at gmail.com  Wed Sep 21 10:23:36 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 21 Sep 2016 17:23:36 +0300
Subject: [hibernate-dev] Cannot build branch 5.1
In-Reply-To: <CAFdSV9sQ28HaoC4O+D-VukJBaQWbv2W18tav7mUxsQUSNDTH_Q@mail.gmail.com>
References: <CAKnbemWFuhR_AUtB2ZcX4R+T7bmOFPmoYZGV9t7NgoAm=yPbEQ@mail.gmail.com>
	<CAFdSV9sQ28HaoC4O+D-VukJBaQWbv2W18tav7mUxsQUSNDTH_Q@mail.gmail.com>
Message-ID: <CAKnbemW+9sPbR6vPnkgADcP=wcRzykMJAZ3FpwzoU-=f__3jDw@mail.gmail.com>

Yeah really strange - branch 5.0 and master (5.2.3) I can build without a
problem, but 5.1 shows that error.

2016-09-21 17:17 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> Strange.  It is working in CI: http://ci.hibernate.org/
> view/ORM/job/hibernate-orm-5.1-h2/
>
>
> On Wed, Sep 21, 2016 at 9:03 AM Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Hi guys,
>>
>> I'm trying to build the 5.1 branch with "./gradlew publishToMavenLocal"
>> but
>> I get the following error:
>>
>> :hibernate-ehcache:generatePomFileForMavenJavaPublication
>> :hibernate-ehcache:compileJava
>> Note: Some input files use or override a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> Starting AnimalSniffer checks using [java16-1.0.signature] against
>> [sourceSets.main]
>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/
>> hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>> Undefined reference:
>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode[]
>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.values()
>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/
>> hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>> Undefined reference:
>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode
>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.IDENTITY
>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/
>> hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>> Undefined reference: int
>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/
>> hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>> Undefined reference:
>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode
>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.SERIALIZATION
>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/
>> hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>> Undefined reference: int
>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
>> :hibernate-ehcache:compileJava FAILED
>>
>> FAILURE: Build failed with an exception.
>>
>> * What went wrong:
>> Execution failed for task ':hibernate-ehcache:compileJava'.
>> > Signature errors found for SourceSet main against java16-1.0.signature.
>> Verify errors and ignore them with the proper annotation if needed.
>>
>> * Try:
>> Run with --stacktrace option to get the stack trace. Run with --info or
>> --debug option to get more log output.
>>
>> BUILD FAILED
>>
>> Total time: 23.979 secs
>>
>>
>> Can you please help me?
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Wed Sep 21 10:28:21 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 14:28:21 +0000
Subject: [hibernate-dev] Cannot build branch 5.1
In-Reply-To: <CAKnbemW+9sPbR6vPnkgADcP=wcRzykMJAZ3FpwzoU-=f__3jDw@mail.gmail.com>
References: <CAKnbemWFuhR_AUtB2ZcX4R+T7bmOFPmoYZGV9t7NgoAm=yPbEQ@mail.gmail.com>
	<CAFdSV9sQ28HaoC4O+D-VukJBaQWbv2W18tav7mUxsQUSNDTH_Q@mail.gmail.com>
	<CAKnbemW+9sPbR6vPnkgADcP=wcRzykMJAZ3FpwzoU-=f__3jDw@mail.gmail.com>
Message-ID: <CAFdSV9vqNtChNKQHUHuYKmJUhqK6nQ14br1Qo6vTYY89ruV=ig@mail.gmail.com>

Try a clean?


On Wed, Sep 21, 2016 at 9:23 AM Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Yeah really strange - branch 5.0 and master (5.2.3) I can build without a
> problem, but 5.1 shows that error.
>
> 2016-09-21 17:17 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> Strange.  It is working in CI:
>> http://ci.hibernate.org/view/ORM/job/hibernate-orm-5.1-h2/
>>
>>
>> On Wed, Sep 21, 2016 at 9:03 AM Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Hi guys,
>>>
>>> I'm trying to build the 5.1 branch with "./gradlew publishToMavenLocal"
>>> but
>>> I get the following error:
>>>
>>> :hibernate-ehcache:generatePomFileForMavenJavaPublication
>>> :hibernate-ehcache:compileJava
>>> Note: Some input files use or override a deprecated API.
>>> Note: Recompile with -Xlint:deprecation for details.
>>> Starting AnimalSniffer checks using [java16-1.0.signature] against
>>> [sourceSets.main]
>>>
>>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>>> Undefined reference:
>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode[]
>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.values()
>>>
>>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>>> Undefined reference:
>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode
>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.IDENTITY
>>>
>>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>>> Undefined reference: int
>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
>>>
>>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>>> Undefined reference:
>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode
>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.SERIALIZATION
>>>
>>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>>> Undefined reference: int
>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
>>> :hibernate-ehcache:compileJava FAILED
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> * What went wrong:
>>> Execution failed for task ':hibernate-ehcache:compileJava'.
>>> > Signature errors found for SourceSet main against java16-1.0.signature.
>>> Verify errors and ignore them with the proper annotation if needed.
>>>
>>> * Try:
>>> Run with --stacktrace option to get the stack trace. Run with --info or
>>> --debug option to get more log output.
>>>
>>> BUILD FAILED
>>>
>>> Total time: 23.979 secs
>>>
>>>
>>> Can you please help me?
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From paranoiabla at gmail.com  Wed Sep 21 10:31:51 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 21 Sep 2016 17:31:51 +0300
Subject: [hibernate-dev] Cannot build branch 5.1
In-Reply-To: <CAFdSV9vqNtChNKQHUHuYKmJUhqK6nQ14br1Qo6vTYY89ruV=ig@mail.gmail.com>
References: <CAKnbemWFuhR_AUtB2ZcX4R+T7bmOFPmoYZGV9t7NgoAm=yPbEQ@mail.gmail.com>
	<CAFdSV9sQ28HaoC4O+D-VukJBaQWbv2W18tav7mUxsQUSNDTH_Q@mail.gmail.com>
	<CAKnbemW+9sPbR6vPnkgADcP=wcRzykMJAZ3FpwzoU-=f__3jDw@mail.gmail.com>
	<CAFdSV9vqNtChNKQHUHuYKmJUhqK6nQ14br1Qo6vTYY89ruV=ig@mail.gmail.com>
Message-ID: <CAKnbemUP6Zm+L0420MBY+m+qbE4pp+M1wj+ZV-dRpV-6e0G_WA@mail.gmail.com>

Yes, clean worked. Thank you Steve and sorry about the noise - I'm not very
familiar with gradle.

2016-09-21 17:28 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> Try a clean?
>
>
> On Wed, Sep 21, 2016 at 9:23 AM Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Yeah really strange - branch 5.0 and master (5.2.3) I can build without a
>> problem, but 5.1 shows that error.
>>
>> 2016-09-21 17:17 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> Strange.  It is working in CI: http://ci.hibernate.org/
>>> view/ORM/job/hibernate-orm-5.1-h2/
>>>
>>>
>>> On Wed, Sep 21, 2016 at 9:03 AM Petar Tahchiev <paranoiabla at gmail.com>
>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I'm trying to build the 5.1 branch with "./gradlew publishToMavenLocal"
>>>> but
>>>> I get the following error:
>>>>
>>>> :hibernate-ehcache:generatePomFileForMavenJavaPublication
>>>> :hibernate-ehcache:compileJava
>>>> Note: Some input files use or override a deprecated API.
>>>> Note: Recompile with -Xlint:deprecation for details.
>>>> Starting AnimalSniffer checks using [java16-1.0.signature] against
>>>> [sourceSets.main]
>>>> /home/petar/workspace/hibernate-orm/hibernate-
>>>> ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/
>>>> HibernateEhcacheUtils.java:104:
>>>> Undefined reference:
>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode[]
>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.values()
>>>> /home/petar/workspace/hibernate-orm/hibernate-
>>>> ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/
>>>> HibernateEhcacheUtils.java:104:
>>>> Undefined reference:
>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode
>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.IDENTITY
>>>> /home/petar/workspace/hibernate-orm/hibernate-
>>>> ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/
>>>> HibernateEhcacheUtils.java:104:
>>>> Undefined reference: int
>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
>>>> /home/petar/workspace/hibernate-orm/hibernate-
>>>> ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/
>>>> HibernateEhcacheUtils.java:104:
>>>> Undefined reference:
>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode
>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.SERIALIZATION
>>>> /home/petar/workspace/hibernate-orm/hibernate-
>>>> ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/
>>>> HibernateEhcacheUtils.java:104:
>>>> Undefined reference: int
>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
>>>> :hibernate-ehcache:compileJava FAILED
>>>>
>>>> FAILURE: Build failed with an exception.
>>>>
>>>> * What went wrong:
>>>> Execution failed for task ':hibernate-ehcache:compileJava'.
>>>> > Signature errors found for SourceSet main against
>>>> java16-1.0.signature.
>>>> Verify errors and ignore them with the proper annotation if needed.
>>>>
>>>> * Try:
>>>> Run with --stacktrace option to get the stack trace. Run with --info or
>>>> --debug option to get more log output.
>>>>
>>>> BUILD FAILED
>>>>
>>>> Total time: 23.979 secs
>>>>
>>>>
>>>> Can you please help me?
>>>>
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> ---
>>>> Public PGP Key at:
>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=
>> 0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Wed Sep 21 10:33:46 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 14:33:46 +0000
Subject: [hibernate-dev] Cannot build branch 5.1
In-Reply-To: <CAKnbemUP6Zm+L0420MBY+m+qbE4pp+M1wj+ZV-dRpV-6e0G_WA@mail.gmail.com>
References: <CAKnbemWFuhR_AUtB2ZcX4R+T7bmOFPmoYZGV9t7NgoAm=yPbEQ@mail.gmail.com>
	<CAFdSV9sQ28HaoC4O+D-VukJBaQWbv2W18tav7mUxsQUSNDTH_Q@mail.gmail.com>
	<CAKnbemW+9sPbR6vPnkgADcP=wcRzykMJAZ3FpwzoU-=f__3jDw@mail.gmail.com>
	<CAFdSV9vqNtChNKQHUHuYKmJUhqK6nQ14br1Qo6vTYY89ruV=ig@mail.gmail.com>
	<CAKnbemUP6Zm+L0420MBY+m+qbE4pp+M1wj+ZV-dRpV-6e0G_WA@mail.gmail.com>
Message-ID: <CAFdSV9tmJgLOA0CNtvDcETLRCuBrLkduSdde2-=s+-yDnaCcsg@mail.gmail.com>

Well the only way I can see that happening is if you used different JDKs
between the runs.  That is always a trigger to me (regardless of build
tool) that I have to clean first.  Otherwise, I have no idea what might
have caused you to see that.


On Wed, Sep 21, 2016 at 9:31 AM Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Yes, clean worked. Thank you Steve and sorry about the noise - I'm not
> very familiar with gradle.
>
> 2016-09-21 17:28 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> Try a clean?
>>
>>
>> On Wed, Sep 21, 2016 at 9:23 AM Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Yeah really strange - branch 5.0 and master (5.2.3) I can build without
>>> a problem, but 5.1 shows that error.
>>>
>>> 2016-09-21 17:17 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> Strange.  It is working in CI:
>>>> http://ci.hibernate.org/view/ORM/job/hibernate-orm-5.1-h2/
>>>>
>>>>
>>>> On Wed, Sep 21, 2016 at 9:03 AM Petar Tahchiev <paranoiabla at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I'm trying to build the 5.1 branch with "./gradlew
>>>>> publishToMavenLocal" but
>>>>> I get the following error:
>>>>>
>>>>> :hibernate-ehcache:generatePomFileForMavenJavaPublication
>>>>> :hibernate-ehcache:compileJava
>>>>> Note: Some input files use or override a deprecated API.
>>>>> Note: Recompile with -Xlint:deprecation for details.
>>>>> Starting AnimalSniffer checks using [java16-1.0.signature] against
>>>>> [sourceSets.main]
>>>>>
>>>>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>>>>> Undefined reference:
>>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode[]
>>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.values()
>>>>>
>>>>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>>>>> Undefined reference:
>>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode
>>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.IDENTITY
>>>>>
>>>>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>>>>> Undefined reference: int
>>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
>>>>>
>>>>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>>>>> Undefined reference:
>>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode
>>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.SERIALIZATION
>>>>>
>>>>> /home/petar/workspace/hibernate-orm/hibernate-ehcache/src/main/java/org/hibernate/cache/ehcache/internal/util/HibernateEhcacheUtils.java:104:
>>>>> Undefined reference: int
>>>>> net.sf.ehcache.config.TerracottaConfiguration.ValueMode.ordinal()
>>>>> :hibernate-ehcache:compileJava FAILED
>>>>>
>>>>> FAILURE: Build failed with an exception.
>>>>>
>>>>> * What went wrong:
>>>>> Execution failed for task ':hibernate-ehcache:compileJava'.
>>>>> > Signature errors found for SourceSet main against
>>>>> java16-1.0.signature.
>>>>> Verify errors and ignore them with the proper annotation if needed.
>>>>>
>>>>> * Try:
>>>>> Run with --stacktrace option to get the stack trace. Run with --info or
>>>>> --debug option to get more log output.
>>>>>
>>>>> BUILD FAILED
>>>>>
>>>>> Total time: 23.979 secs
>>>>>
>>>>>
>>>>> Can you please help me?
>>>>>
>>>>> --
>>>>> Regards, Petar!
>>>>> Karlovo, Bulgaria.
>>>>> ---
>>>>> Public PGP Key at:
>>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From coladict at gmail.com  Wed Sep 21 10:43:59 2016
From: coladict at gmail.com (Jordan Gigov)
Date: Wed, 21 Sep 2016 17:43:59 +0300
Subject: [hibernate-dev] Build time downloads of ORM itself during an
 ORM clean build?
In-Reply-To: <CAFm4XO32UpeQbH9Cxo7mUmm1XgsNEYT29N10-TQhkMRQ2zaHOw@mail.gmail.com>
References: <CAFm4XO32UpeQbH9Cxo7mUmm1XgsNEYT29N10-TQhkMRQ2zaHOw@mail.gmail.com>
Message-ID: <CA+nBocAY0TShFZA_8PYzn3kKL1DMHJSsLC7i=uJndav9oy9DaQ@mail.gmail.com>

Well, the CI would generally have a local snapshot to use, instead of
downloading it.
The problem is that the package buildscripts depend on
'hibernate-gradle-plugin',but it depends on 'hibernate-core'.

I just cleared my ~/.gradle/caches and ~/.m2/repository/org/hibernate/,
switched to the '5.1' branch and it didn't download the core snapshot as it
does in 'master'.

As far as I can determine, this plugin enhances entity classes after
they're built, which I suppose is meant to speed-up the tests slightly.

2016-09-21 12:50 GMT+03:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi all,
>
> I just happened to build Hibernate ORM's latest "master" on a clean
> machine and this is how the build log looks like:
>
> No compatible daemons found:
>   - an idle daemon with different JVM constraints can't run this build
> Starting a new Gradle Daemon for this build: subsequent builds will be
> faster
> :buildSrc:clean UP-TO-DATE
> :buildSrc:compileJava UP-TO-DATE
> :buildSrc:compileGroovy
> :buildSrc:processResources UP-TO-DATE
> :buildSrc:classes
> :buildSrc:jar
> :buildSrc:assemble
> :buildSrc:compileTestJava UP-TO-DATE
> :buildSrc:compileTestGroovy UP-TO-DATE
> :buildSrc:processTestResources UP-TO-DATE
> :buildSrc:testClasses UP-TO-DATE
> :buildSrc:test UP-TO-DATE
> :buildSrc:check UP-TO-DATE
> :buildSrc:build
> Download http://repository.jboss.org/nexus/content/groups/public/
> org/hibernate/hibernate-core/5.2.3-SNAPSHOT/hibernate-core-
> 5.2.3-20160920.201550-53.jar
> [...]
>
> I'm not having any specific failure, but it seems very suspicious that
> the build is needing to download hibernate-core at the very beginning
> of the build?
>
> I'm not familiar enough with ORM's build scripts to investigate myself
> but I suspect some dependency order needs to be cleaned up, or you
> might be including some side-effects from previous builds.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Sep 21 10:59:58 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 14:59:58 +0000
Subject: [hibernate-dev] Build time downloads of ORM itself during an
 ORM clean build?
In-Reply-To: <CA+nBocAY0TShFZA_8PYzn3kKL1DMHJSsLC7i=uJndav9oy9DaQ@mail.gmail.com>
References: <CAFm4XO32UpeQbH9Cxo7mUmm1XgsNEYT29N10-TQhkMRQ2zaHOw@mail.gmail.com>
	<CA+nBocAY0TShFZA_8PYzn3kKL1DMHJSsLC7i=uJndav9oy9DaQ@mail.gmail.com>
Message-ID: <CAFdSV9uDKspYPdUbV-8F2_G81j4Fw768C38DmNNPwg_73RL8_Q@mail.gmail.com>

By "package buildscripts" do you mean the buildSrc module?  That should not
be the case.

If not, what do yo mean by "package buildscripts"?



On Wed, Sep 21, 2016 at 9:47 AM Jordan Gigov <coladict at gmail.com> wrote:

> Well, the CI would generally have a local snapshot to use, instead of
> downloading it.
> The problem is that the package buildscripts depend on
> 'hibernate-gradle-plugin',but it depends on 'hibernate-core'.
>
> I just cleared my ~/.gradle/caches and ~/.m2/repository/org/hibernate/,
> switched to the '5.1' branch and it didn't download the core snapshot as it
> does in 'master'.
>
> As far as I can determine, this plugin enhances entity classes after
> they're built, which I suppose is meant to speed-up the tests slightly.
>
> 2016-09-21 12:50 GMT+03:00 Sanne Grinovero <sanne at hibernate.org>:
>
> > Hi all,
> >
> > I just happened to build Hibernate ORM's latest "master" on a clean
> > machine and this is how the build log looks like:
> >
> > No compatible daemons found:
> >   - an idle daemon with different JVM constraints can't run this build
> > Starting a new Gradle Daemon for this build: subsequent builds will be
> > faster
> > :buildSrc:clean UP-TO-DATE
> > :buildSrc:compileJava UP-TO-DATE
> > :buildSrc:compileGroovy
> > :buildSrc:processResources UP-TO-DATE
> > :buildSrc:classes
> > :buildSrc:jar
> > :buildSrc:assemble
> > :buildSrc:compileTestJava UP-TO-DATE
> > :buildSrc:compileTestGroovy UP-TO-DATE
> > :buildSrc:processTestResources UP-TO-DATE
> > :buildSrc:testClasses UP-TO-DATE
> > :buildSrc:test UP-TO-DATE
> > :buildSrc:check UP-TO-DATE
> > :buildSrc:build
> > Download http://repository.jboss.org/nexus/content/groups/public/
> > org/hibernate/hibernate-core/5.2.3-SNAPSHOT/hibernate-core-
> > 5.2.3-20160920.201550-53.jar
> > [...]
> >
> > I'm not having any specific failure, but it seems very suspicious that
> > the build is needing to download hibernate-core at the very beginning
> > of the build?
> >
> > I'm not familiar enough with ORM's build scripts to investigate myself
> > but I suspect some dependency order needs to be cleaned up, or you
> > might be including some side-effects from previous builds.
> >
> > Thanks,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From coladict at gmail.com  Wed Sep 21 11:42:31 2016
From: coladict at gmail.com (Jordan Gigov)
Date: Wed, 21 Sep 2016 18:42:31 +0300
Subject: [hibernate-dev] Build time downloads of ORM itself during an
 ORM clean build?
In-Reply-To: <CAFdSV9uDKspYPdUbV-8F2_G81j4Fw768C38DmNNPwg_73RL8_Q@mail.gmail.com>
References: <CAFm4XO32UpeQbH9Cxo7mUmm1XgsNEYT29N10-TQhkMRQ2zaHOw@mail.gmail.com>
	<CA+nBocAY0TShFZA_8PYzn3kKL1DMHJSsLC7i=uJndav9oy9DaQ@mail.gmail.com>
	<CAFdSV9uDKspYPdUbV-8F2_G81j4Fw768C38DmNNPwg_73RL8_Q@mail.gmail.com>
Message-ID: <CA+nBocCThYGjoELB=NR89y7C-BLjPDAK2htQZ0LiyBsmB6W_Nw@mail.gmail.com>

I mean this dependency in "buildscript"
https://github.com/hibernate/hibernate-orm/blob/master/documentation/documentation.gradle#L22

2016-09-21 17:59 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> By "package buildscripts" do you mean the buildSrc module?  That should
> not be the case.
>
> If not, what do yo mean by "package buildscripts"?
>
>
>
> On Wed, Sep 21, 2016 at 9:47 AM Jordan Gigov <coladict at gmail.com> wrote:
>
>> Well, the CI would generally have a local snapshot to use, instead of
>> downloading it.
>> The problem is that the package buildscripts depend on
>> 'hibernate-gradle-plugin',but it depends on 'hibernate-core'.
>>
>> I just cleared my ~/.gradle/caches and ~/.m2/repository/org/hibernate/,
>> switched to the '5.1' branch and it didn't download the core snapshot as
>> it
>> does in 'master'.
>>
>> As far as I can determine, this plugin enhances entity classes after
>> they're built, which I suppose is meant to speed-up the tests slightly.
>>
>> 2016-09-21 12:50 GMT+03:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> > Hi all,
>> >
>> > I just happened to build Hibernate ORM's latest "master" on a clean
>> > machine and this is how the build log looks like:
>> >
>> > No compatible daemons found:
>> >   - an idle daemon with different JVM constraints can't run this build
>> > Starting a new Gradle Daemon for this build: subsequent builds will be
>> > faster
>> > :buildSrc:clean UP-TO-DATE
>> > :buildSrc:compileJava UP-TO-DATE
>> > :buildSrc:compileGroovy
>> > :buildSrc:processResources UP-TO-DATE
>> > :buildSrc:classes
>> > :buildSrc:jar
>> > :buildSrc:assemble
>> > :buildSrc:compileTestJava UP-TO-DATE
>> > :buildSrc:compileTestGroovy UP-TO-DATE
>> > :buildSrc:processTestResources UP-TO-DATE
>> > :buildSrc:testClasses UP-TO-DATE
>> > :buildSrc:test UP-TO-DATE
>> > :buildSrc:check UP-TO-DATE
>> > :buildSrc:build
>> > Download http://repository.jboss.org/nexus/content/groups/public/
>> > org/hibernate/hibernate-core/5.2.3-SNAPSHOT/hibernate-core-
>> > 5.2.3-20160920.201550-53.jar
>> > [...]
>> >
>> > I'm not having any specific failure, but it seems very suspicious that
>> > the build is needing to download hibernate-core at the very beginning
>> > of the build?
>> >
>> > I'm not familiar enough with ORM's build scripts to investigate myself
>> > but I suspect some dependency order needs to be cleaned up, or you
>> > might be including some side-effects from previous builds.
>> >
>> > Thanks,
>> > Sanne
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From paranoiabla at gmail.com  Wed Sep 21 11:54:48 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 21 Sep 2016 18:54:48 +0300
Subject: [hibernate-dev] Pull request for HHH-11089
Message-ID: <CAKnbemUa2WvqLMnqDT9AT6N86r3WifY-N+HswmDJLWTPk=+9YQ@mail.gmail.com>

Hey guys,

I just created a pull-request for HHH-11089:

https://github.com/hibernate/hibernate-orm/pull/1564

However when I create the Identifier like this:

Identifier.toIdentifier( keyName, true );

I always set quoted to true as I don't know where to get this value from.

Can someone please have a look,

Thanks :)

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Wed Sep 21 11:55:41 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 15:55:41 +0000
Subject: [hibernate-dev] Build time downloads of ORM itself during an
 ORM clean build?
In-Reply-To: <CA+nBocCThYGjoELB=NR89y7C-BLjPDAK2htQZ0LiyBsmB6W_Nw@mail.gmail.com>
References: <CAFm4XO32UpeQbH9Cxo7mUmm1XgsNEYT29N10-TQhkMRQ2zaHOw@mail.gmail.com>
	<CA+nBocAY0TShFZA_8PYzn3kKL1DMHJSsLC7i=uJndav9oy9DaQ@mail.gmail.com>
	<CAFdSV9uDKspYPdUbV-8F2_G81j4Fw768C38DmNNPwg_73RL8_Q@mail.gmail.com>
	<CA+nBocCThYGjoELB=NR89y7C-BLjPDAK2htQZ0LiyBsmB6W_Nw@mail.gmail.com>
Message-ID: <CAFdSV9v5kHonfcX-Ay=-k-RKQHm9d=0J-EhxfXX9L2Ym697veA@mail.gmail.com>

Thanks! Great catch.  That was a bad setup, we will get it fixed.


On Wed, Sep 21, 2016 at 10:42 AM Jordan Gigov <coladict at gmail.com> wrote:

> I mean this dependency in "buildscript"
>
> https://github.com/hibernate/hibernate-orm/blob/master/documentation/documentation.gradle#L22
>
> 2016-09-21 17:59 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> By "package buildscripts" do you mean the buildSrc module?  That should
>> not be the case.
>>
>> If not, what do yo mean by "package buildscripts"?
>>
>>
>>
>> On Wed, Sep 21, 2016 at 9:47 AM Jordan Gigov <coladict at gmail.com> wrote:
>>
>>> Well, the CI would generally have a local snapshot to use, instead of
>>> downloading it.
>>> The problem is that the package buildscripts depend on
>>> 'hibernate-gradle-plugin',but it depends on 'hibernate-core'.
>>>
>>> I just cleared my ~/.gradle/caches and ~/.m2/repository/org/hibernate/,
>>> switched to the '5.1' branch and it didn't download the core snapshot as
>>> it
>>> does in 'master'.
>>>
>>> As far as I can determine, this plugin enhances entity classes after
>>> they're built, which I suppose is meant to speed-up the tests slightly.
>>>
>>> 2016-09-21 12:50 GMT+03:00 Sanne Grinovero <sanne at hibernate.org>:
>>>
>>> > Hi all,
>>> >
>>> > I just happened to build Hibernate ORM's latest "master" on a clean
>>> > machine and this is how the build log looks like:
>>> >
>>> > No compatible daemons found:
>>> >   - an idle daemon with different JVM constraints can't run this build
>>> > Starting a new Gradle Daemon for this build: subsequent builds will be
>>> > faster
>>> > :buildSrc:clean UP-TO-DATE
>>> > :buildSrc:compileJava UP-TO-DATE
>>> > :buildSrc:compileGroovy
>>> > :buildSrc:processResources UP-TO-DATE
>>> > :buildSrc:classes
>>> > :buildSrc:jar
>>> > :buildSrc:assemble
>>> > :buildSrc:compileTestJava UP-TO-DATE
>>> > :buildSrc:compileTestGroovy UP-TO-DATE
>>> > :buildSrc:processTestResources UP-TO-DATE
>>> > :buildSrc:testClasses UP-TO-DATE
>>> > :buildSrc:test UP-TO-DATE
>>> > :buildSrc:check UP-TO-DATE
>>> > :buildSrc:build
>>> > Download http://repository.jboss.org/nexus/content/groups/public/
>>> > org/hibernate/hibernate-core/5.2.3-SNAPSHOT/hibernate-core-
>>> > 5.2.3-20160920.201550-53.jar
>>> > [...]
>>> >
>>> > I'm not having any specific failure, but it seems very suspicious that
>>> > the build is needing to download hibernate-core at the very beginning
>>> > of the build?
>>> >
>>> > I'm not familiar enough with ORM's build scripts to investigate myself
>>> > but I suspect some dependency order needs to be cleaned up, or you
>>> > might be including some side-effects from previous builds.
>>> >
>>> > Thanks,
>>> > Sanne
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From andrea at hibernate.org  Wed Sep 21 12:18:38 2016
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 21 Sep 2016 17:18:38 +0100
Subject: [hibernate-dev] Pull request for HHH-11089
In-Reply-To: <CAKnbemUa2WvqLMnqDT9AT6N86r3WifY-N+HswmDJLWTPk=+9YQ@mail.gmail.com>
References: <CAKnbemUa2WvqLMnqDT9AT6N86r3WifY-N+HswmDJLWTPk=+9YQ@mail.gmail.com>
Message-ID: <CAL00eSRe3WQEPW9-ZfkYwumq_jjc9w5Ma5KutQXQT7t90R0-_g@mail.gmail.com>

Hi Petar,

you can use Identifier#toIdentifier(String text)

this method detects if the text is quoted and it calls
the Identifier#toIdentifier( String text , boolean quoted  ) with the
correct quoted value.



On 21 September 2016 at 16:54, Petar Tahchiev <paranoiabla at gmail.com> wrote:

> Hey guys,
>
> I just created a pull-request for HHH-11089:
>
> https://github.com/hibernate/hibernate-orm/pull/1564
>
> However when I create the Identifier like this:
>
> Identifier.toIdentifier( keyName, true );
>
> I always set quoted to true as I don't know where to get this value from.
>
> Can someone please have a look,
>
> Thanks :)
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Sep 21 12:41:05 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 16:41:05 +0000
Subject: [hibernate-dev] Limited history in HipChat
In-Reply-To: <FDC59BD4-D868-425F-8FEE-69928BBF645F@hibernate.org>
References: <CADGJaX_ckq5ra9bZML7fkVciv_WFO1YiY+NktZy51LoZO+e-7g@mail.gmail.com>
	<CAFdSV9vqtsaQ_hk5xZ4d+cuOicFEnfyYBxBG0bxoqJFZym9CXg@mail.gmail.com>
	<FDC59BD4-D868-425F-8FEE-69928BBF645F@hibernate.org>
Message-ID: <CAFdSV9vsWdm0__hQ+V5YNo77z-St42_wYxaF9f-mcKv2StO28A@mail.gmail.com>

You should refer him to the ticket I mentioned on HC


On Wed, Sep 21, 2016 at 11:19 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> At least on the NoORM side, we do like what it provides and we do exchange
> a lot in it. It doesn?t have to be everyone?s best tool of course.
> The multi client including phone is an awesome feature for my flow for
> example.
>
> I?ve contacted Samuel and he offered options to give it a shot.
>
> Emmanuel
>
>
> > On 21 Sep 2016, at 15:20, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > I thought we had some sort of non-basic license already.  Isn't that why
> we
> > need to explicitly invite people to be non-Guest?
> >
> > Anyway, I agree wrt HipChat being more or less useless.  I've been saying
> > that for a while now.  Yes the GitHub and Jira and social integrations
> *can
> > be* nice (they can also be annoying).
> >
> > Ayway, I am not the one who set up HipChat for Hibernate.  Sanne maybe?
> > Anyway I am looking around for a way.
> >
> > On Wed, Sep 21, 2016 at 7:05 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >
> >> Steve, all,
> >>
> >> Is there any way we can get HipChat Plus licenses for the team from
> >> Atlassian?
> >>
> >> The free client provides access only to a limited part of the chat
> history,
> >> making it impossible to search for discussions discussed more than a few
> >> weeks ago.
> >>
> >> That's starting to be a real problem now that we've been using HipChat
> for
> >> a while and early discussions begin to fall below the threshold of being
> >> available in the free version.
> >>
> >> I don't know whom to reach out to at Atlassian, otherwise I'd do it
> myself.
> >> I'd hope they are supportive given that we can use JIRA at all for free,
> >> too.
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Wed Sep 21 14:40:18 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 18:40:18 +0000
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CA+nBocCxQkmohn3JogaMfoNCKs=hS4a_MwWo4t_gdp2ZRAL9Cg@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
	<CA+nBocCxQkmohn3JogaMfoNCKs=hS4a_MwWo4t_gdp2ZRAL9Cg@mail.gmail.com>
Message-ID: <CAFdSV9vY5DRRMHmz-WGsEfJyU2SbE+xg303s3oqtPq=bqw7jAw@mail.gmail.com>

I never said anything about dropping support for named and positional
parameters in native queries.

I simply mentioned leveraging the new "JPA strict compliance" stuff I am
adding to 6.0.  The idea is to allow you to enable that and get feedback
when you use non-portable things.


On Tue, Sep 20, 2016 at 11:45 PM Jordan Gigov <coladict at gmail.com> wrote:

> Actually JPA defines it as "Only positional parameter binding and
> positional access to result items may be portably used for native queries".
> I believe "portably" means the providers are only required to support
> positional, but not forbidden from supporting other.
>
> 2016-09-21 3:59 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> In the interest of questioning everything, just to make sure we are all on
>> the same page, Hibernate's support for native SQL queries currently
>> recognizes named parameters, positional parameters as well as JDBC-style
>> parameters.
>>
>> JPA only defines support for "JDBC-style parameters" as valid for native
>> SQL queries:
>> {quote}
>> It is assumed that for native queries the parameters themselves use the
>> SQL
>> syntax (i.e., ???, rather than ??1?).
>> {quote}
>>
>> Furthermore Hibernate does not support a native query using both
>> positional
>> parameters and JDBC-style parameters in the same query because it causes a
>> non-determinism wrt the positions.
>>
>> I assume we want to continue to support that full complement of parameter
>> types, with the positional/JDBC-style caveat.
>>
>> Further I assume we will hook up the use of any non-JDBC-style parameters
>> in with the "strict JPA compliance" checking and throw an error when
>> indicated.
>>
>> Anyone have objections to any of that?
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Wed Sep 21 15:03:51 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Sep 2016 19:03:51 +0000
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9vY5DRRMHmz-WGsEfJyU2SbE+xg303s3oqtPq=bqw7jAw@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
	<CA+nBocCxQkmohn3JogaMfoNCKs=hS4a_MwWo4t_gdp2ZRAL9Cg@mail.gmail.com>
	<CAFdSV9vY5DRRMHmz-WGsEfJyU2SbE+xg303s3oqtPq=bqw7jAw@mail.gmail.com>
Message-ID: <CAFdSV9tPLm5prg-0Hx3FCzPavkaqbN82O6y3YXsGD5=0UzboAw@mail.gmail.com>

One additional thing we might consider is possibly unifying this 0- and 1-
based mismatch wrt JDBC-style parameters.

In Hibernate's APIs these JDBC-style parameters were 0-based.  I have
already dropped support (it has been deprecated for a long time anyway) for
using JDBC-style params in HQL.  So this is now only a concern for native
queries.

Interestingly JPA has the following to say (3.10.13 Positional Parameters):
<quote>
Only positional parameter binding ... may be portably used for native
queries... When binding the values of positional parameters, the numbering
starts as ?1?. It is assumed that for native queries the parameters
themselves use the SQL syntax (i.e., ???, rather than ??1?).
</quote>

So for portable JPA, the native query would use JDBC/SQL syntax for the
parameter marker, but use the JPA convention for parameter index (1-based)
rather than the JDBC/SQL convention (0-based).

As bassackwards as we may think JPA is here, it is a spec and we have to
support it: we have to support 1-based binding of these JDBC-style params.
The question is whether we should deviate from Hibernate's legacy decision
to align with JDBC/SQL (0-based) for binding of these JDBC-style params.
Perhaps a setting that controls how this should work - specifically limited
to JDBC-style param markers in native queries.  By default we'd honor the
1-based approach whenever bootstrapping was done via JPA and 0-based when
native bootstrapping is used.  I guess what I am wondering is whether we
want to have a setting for the native bootstrapping piece that controls
whether to use 0-based or 1-based?  I do not think we should allow the
setting (if we add one) to force 0-based usage with JPA bootstrapping; this
would only control how it works in native bootstrapping.

Thoughts?

On Wed, Sep 21, 2016 at 1:40 PM Steve Ebersole <steve at hibernate.org> wrote:

> I never said anything about dropping support for named and positional
> parameters in native queries.
>
> I simply mentioned leveraging the new "JPA strict compliance" stuff I am
> adding to 6.0.  The idea is to allow you to enable that and get feedback
> when you use non-portable things.
>
>
> On Tue, Sep 20, 2016 at 11:45 PM Jordan Gigov <coladict at gmail.com> wrote:
>
>> Actually JPA defines it as "Only positional parameter binding and
>> positional access to result items may be portably used for native queries".
>> I believe "portably" means the providers are only required to support
>> positional, but not forbidden from supporting other.
>>
>> 2016-09-21 3:59 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> In the interest of questioning everything, just to make sure we are all
>>> on
>>> the same page, Hibernate's support for native SQL queries currently
>>> recognizes named parameters, positional parameters as well as JDBC-style
>>> parameters.
>>>
>>> JPA only defines support for "JDBC-style parameters" as valid for native
>>> SQL queries:
>>> {quote}
>>> It is assumed that for native queries the parameters themselves use the
>>> SQL
>>> syntax (i.e., ???, rather than ??1?).
>>> {quote}
>>>
>>> Furthermore Hibernate does not support a native query using both
>>> positional
>>> parameters and JDBC-style parameters in the same query because it causes
>>> a
>>> non-determinism wrt the positions.
>>>
>>> I assume we want to continue to support that full complement of parameter
>>> types, with the positional/JDBC-style caveat.
>>>
>>> Further I assume we will hook up the use of any non-JDBC-style parameters
>>> in with the "strict JPA compliance" checking and throw an error when
>>> indicated.
>>>
>>> Anyone have objections to any of that?
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>

From coladict at gmail.com  Wed Sep 21 15:28:07 2016
From: coladict at gmail.com (Jordan Gigov)
Date: Wed, 21 Sep 2016 22:28:07 +0300
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9tPLm5prg-0Hx3FCzPavkaqbN82O6y3YXsGD5=0UzboAw@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
	<CA+nBocCxQkmohn3JogaMfoNCKs=hS4a_MwWo4t_gdp2ZRAL9Cg@mail.gmail.com>
	<CAFdSV9vY5DRRMHmz-WGsEfJyU2SbE+xg303s3oqtPq=bqw7jAw@mail.gmail.com>
	<CAFdSV9tPLm5prg-0Hx3FCzPavkaqbN82O6y3YXsGD5=0UzboAw@mail.gmail.com>
Message-ID: <CA+nBocDKRKzzmggGpkOQg8OSgn_QCVxERwSgGxFubLNTgT3Mmw@mail.gmail.com>

That sounds reasonable. So long as there is a property to control it from
persistence.xml, more people will be happy with it.

It would be very important to quote whatever error people will get in the
docs, so they can find the solution easier.

2016-09-21 22:03 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> One additional thing we might consider is possibly unifying this 0- and 1-
> based mismatch wrt JDBC-style parameters.
>
> In Hibernate's APIs these JDBC-style parameters were 0-based.  I have
> already dropped support (it has been deprecated for a long time anyway) for
> using JDBC-style params in HQL.  So this is now only a concern for native
> queries.
>
> Interestingly JPA has the following to say (3.10.13 Positional Parameters):
> <quote>
> Only positional parameter binding ... may be portably used for native
> queries... When binding the values of positional parameters, the numbering
> starts as ?1?. It is assumed that for native queries the parameters
> themselves use the SQL syntax (i.e., ???, rather than ??1?).
> </quote>
>
> So for portable JPA, the native query would use JDBC/SQL syntax for the
> parameter marker, but use the JPA convention for parameter index (1-based)
> rather than the JDBC/SQL convention (0-based).
>
> As bassackwards as we may think JPA is here, it is a spec and we have to
> support it: we have to support 1-based binding of these JDBC-style params.
> The question is whether we should deviate from Hibernate's legacy decision
> to align with JDBC/SQL (0-based) for binding of these JDBC-style params.
> Perhaps a setting that controls how this should work - specifically limited
> to JDBC-style param markers in native queries.  By default we'd honor the
> 1-based approach whenever bootstrapping was done via JPA and 0-based when
> native bootstrapping is used.  I guess what I am wondering is whether we
> want to have a setting for the native bootstrapping piece that controls
> whether to use 0-based or 1-based?  I do not think we should allow the
> setting (if we add one) to force 0-based usage with JPA bootstrapping; this
> would only control how it works in native bootstrapping.
>
> Thoughts?
>
> On Wed, Sep 21, 2016 at 1:40 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I never said anything about dropping support for named and positional
>> parameters in native queries.
>>
>> I simply mentioned leveraging the new "JPA strict compliance" stuff I am
>> adding to 6.0.  The idea is to allow you to enable that and get feedback
>> when you use non-portable things.
>>
>>
>> On Tue, Sep 20, 2016 at 11:45 PM Jordan Gigov <coladict at gmail.com> wrote:
>>
>>> Actually JPA defines it as "Only positional parameter binding and
>>> positional access to result items may be portably used for native queries".
>>> I believe "portably" means the providers are only required to support
>>> positional, but not forbidden from supporting other.
>>>
>>> 2016-09-21 3:59 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> In the interest of questioning everything, just to make sure we are all
>>>> on
>>>> the same page, Hibernate's support for native SQL queries currently
>>>> recognizes named parameters, positional parameters as well as JDBC-style
>>>> parameters.
>>>>
>>>> JPA only defines support for "JDBC-style parameters" as valid for native
>>>> SQL queries:
>>>> {quote}
>>>> It is assumed that for native queries the parameters themselves use the
>>>> SQL
>>>> syntax (i.e., ???, rather than ??1?).
>>>> {quote}
>>>>
>>>> Furthermore Hibernate does not support a native query using both
>>>> positional
>>>> parameters and JDBC-style parameters in the same query because it
>>>> causes a
>>>> non-determinism wrt the positions.
>>>>
>>>> I assume we want to continue to support that full complement of
>>>> parameter
>>>> types, with the positional/JDBC-style caveat.
>>>>
>>>> Further I assume we will hook up the use of any non-JDBC-style
>>>> parameters
>>>> in with the "strict JPA compliance" checking and throw an error when
>>>> indicated.
>>>>
>>>> Anyone have objections to any of that?
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>

From steve at hibernate.org  Thu Sep 22 08:06:31 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 22 Sep 2016 12:06:31 +0000
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CA+nBocDKRKzzmggGpkOQg8OSgn_QCVxERwSgGxFubLNTgT3Mmw@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
	<CA+nBocCxQkmohn3JogaMfoNCKs=hS4a_MwWo4t_gdp2ZRAL9Cg@mail.gmail.com>
	<CAFdSV9vY5DRRMHmz-WGsEfJyU2SbE+xg303s3oqtPq=bqw7jAw@mail.gmail.com>
	<CAFdSV9tPLm5prg-0Hx3FCzPavkaqbN82O6y3YXsGD5=0UzboAw@mail.gmail.com>
	<CA+nBocDKRKzzmggGpkOQg8OSgn_QCVxERwSgGxFubLNTgT3Mmw@mail.gmail.com>
Message-ID: <CAFdSV9tEPX=HULCDxCSjYLPc4Mo6-AKcBjeyLaNpRKigyr3TkA@mail.gmail.com>

Well therein lies a minor rub in having split SQM out from ORM.
Specifically if the "compliance violation" occurs in the HQL/JPQL/Criteria
query the exception is a type from SQM (it has no deps on ORM).  Here
though it is not reasonable to throw an SQM exception type.




On Wed, Sep 21, 2016 at 2:28 PM Jordan Gigov <coladict at gmail.com> wrote:

> That sounds reasonable. So long as there is a property to control it from
> persistence.xml, more people will be happy with it.
>
> It would be very important to quote whatever error people will get in the
> docs, so they can find the solution easier.
>
> 2016-09-21 22:03 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> One additional thing we might consider is possibly unifying this 0- and
>> 1- based mismatch wrt JDBC-style parameters.
>>
>> In Hibernate's APIs these JDBC-style parameters were 0-based.  I have
>> already dropped support (it has been deprecated for a long time anyway) for
>> using JDBC-style params in HQL.  So this is now only a concern for native
>> queries.
>>
>> Interestingly JPA has the following to say (3.10.13 Positional
>> Parameters):
>> <quote>
>> Only positional parameter binding ... may be portably used for native
>> queries... When binding the values of positional parameters, the numbering
>> starts as ?1?. It is assumed that for native queries the parameters
>> themselves use the SQL syntax (i.e., ???, rather than ??1?).
>> </quote>
>>
>> So for portable JPA, the native query would use JDBC/SQL syntax for the
>> parameter marker, but use the JPA convention for parameter index (1-based)
>> rather than the JDBC/SQL convention (0-based).
>>
>> As bassackwards as we may think JPA is here, it is a spec and we have to
>> support it: we have to support 1-based binding of these JDBC-style params.
>> The question is whether we should deviate from Hibernate's legacy decision
>> to align with JDBC/SQL (0-based) for binding of these JDBC-style params.
>> Perhaps a setting that controls how this should work - specifically limited
>> to JDBC-style param markers in native queries.  By default we'd honor the
>> 1-based approach whenever bootstrapping was done via JPA and 0-based when
>> native bootstrapping is used.  I guess what I am wondering is whether we
>> want to have a setting for the native bootstrapping piece that controls
>> whether to use 0-based or 1-based?  I do not think we should allow the
>> setting (if we add one) to force 0-based usage with JPA bootstrapping; this
>> would only control how it works in native bootstrapping.
>>
>> Thoughts?
>>
>> On Wed, Sep 21, 2016 at 1:40 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I never said anything about dropping support for named and positional
>>> parameters in native queries.
>>>
>>> I simply mentioned leveraging the new "JPA strict compliance" stuff I am
>>> adding to 6.0.  The idea is to allow you to enable that and get feedback
>>> when you use non-portable things.
>>>
>>>
>>> On Tue, Sep 20, 2016 at 11:45 PM Jordan Gigov <coladict at gmail.com>
>>> wrote:
>>>
>>>> Actually JPA defines it as "Only positional parameter binding and
>>>> positional access to result items may be portably used for native queries".
>>>> I believe "portably" means the providers are only required to support
>>>> positional, but not forbidden from supporting other.
>>>>
>>>> 2016-09-21 3:59 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>> In the interest of questioning everything, just to make sure we are
>>>>> all on
>>>>> the same page, Hibernate's support for native SQL queries currently
>>>>> recognizes named parameters, positional parameters as well as
>>>>> JDBC-style
>>>>> parameters.
>>>>>
>>>>> JPA only defines support for "JDBC-style parameters" as valid for
>>>>> native
>>>>> SQL queries:
>>>>> {quote}
>>>>> It is assumed that for native queries the parameters themselves use
>>>>> the SQL
>>>>> syntax (i.e., ???, rather than ??1?).
>>>>> {quote}
>>>>>
>>>>> Furthermore Hibernate does not support a native query using both
>>>>> positional
>>>>> parameters and JDBC-style parameters in the same query because it
>>>>> causes a
>>>>> non-determinism wrt the positions.
>>>>>
>>>>> I assume we want to continue to support that full complement of
>>>>> parameter
>>>>> types, with the positional/JDBC-style caveat.
>>>>>
>>>>> Further I assume we will hook up the use of any non-JDBC-style
>>>>> parameters
>>>>> in with the "strict JPA compliance" checking and throw an error when
>>>>> indicated.
>>>>>
>>>>> Anyone have objections to any of that?
>>>>>
>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>
>

From steve at hibernate.org  Thu Sep 22 08:07:12 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 22 Sep 2016 12:07:12 +0000
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9tEPX=HULCDxCSjYLPc4Mo6-AKcBjeyLaNpRKigyr3TkA@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
	<CA+nBocCxQkmohn3JogaMfoNCKs=hS4a_MwWo4t_gdp2ZRAL9Cg@mail.gmail.com>
	<CAFdSV9vY5DRRMHmz-WGsEfJyU2SbE+xg303s3oqtPq=bqw7jAw@mail.gmail.com>
	<CAFdSV9tPLm5prg-0Hx3FCzPavkaqbN82O6y3YXsGD5=0UzboAw@mail.gmail.com>
	<CA+nBocDKRKzzmggGpkOQg8OSgn_QCVxERwSgGxFubLNTgT3Mmw@mail.gmail.com>
	<CAFdSV9tEPX=HULCDxCSjYLPc4Mo6-AKcBjeyLaNpRKigyr3TkA@mail.gmail.com>
Message-ID: <CAFdSV9sseXgL5-EVrZ2BNs4xuoBFnL5y_rDje-Suf-OdjrOJhw@mail.gmail.com>

Well therein lies (yet another) minor rub....

On Thu, Sep 22, 2016 at 7:06 AM Steve Ebersole <steve at hibernate.org> wrote:

> Well therein lies a minor rub in having split SQM out from ORM.
> Specifically if the "compliance violation" occurs in the HQL/JPQL/Criteria
> query the exception is a type from SQM (it has no deps on ORM).  Here
> though it is not reasonable to throw an SQM exception type.
>
>
>
>
> On Wed, Sep 21, 2016 at 2:28 PM Jordan Gigov <coladict at gmail.com> wrote:
>
>> That sounds reasonable. So long as there is a property to control it from
>> persistence.xml, more people will be happy with it.
>>
>> It would be very important to quote whatever error people will get in the
>> docs, so they can find the solution easier.
>>
>> 2016-09-21 22:03 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> One additional thing we might consider is possibly unifying this 0- and
>>> 1- based mismatch wrt JDBC-style parameters.
>>>
>>> In Hibernate's APIs these JDBC-style parameters were 0-based.  I have
>>> already dropped support (it has been deprecated for a long time anyway) for
>>> using JDBC-style params in HQL.  So this is now only a concern for native
>>> queries.
>>>
>>> Interestingly JPA has the following to say (3.10.13 Positional
>>> Parameters):
>>> <quote>
>>> Only positional parameter binding ... may be portably used for native
>>> queries... When binding the values of positional parameters, the numbering
>>> starts as ?1?. It is assumed that for native queries the parameters
>>> themselves use the SQL syntax (i.e., ???, rather than ??1?).
>>> </quote>
>>>
>>> So for portable JPA, the native query would use JDBC/SQL syntax for the
>>> parameter marker, but use the JPA convention for parameter index (1-based)
>>> rather than the JDBC/SQL convention (0-based).
>>>
>>> As bassackwards as we may think JPA is here, it is a spec and we have to
>>> support it: we have to support 1-based binding of these JDBC-style params.
>>> The question is whether we should deviate from Hibernate's legacy decision
>>> to align with JDBC/SQL (0-based) for binding of these JDBC-style params.
>>> Perhaps a setting that controls how this should work - specifically limited
>>> to JDBC-style param markers in native queries.  By default we'd honor the
>>> 1-based approach whenever bootstrapping was done via JPA and 0-based when
>>> native bootstrapping is used.  I guess what I am wondering is whether we
>>> want to have a setting for the native bootstrapping piece that controls
>>> whether to use 0-based or 1-based?  I do not think we should allow the
>>> setting (if we add one) to force 0-based usage with JPA bootstrapping; this
>>> would only control how it works in native bootstrapping.
>>>
>>> Thoughts?
>>>
>>> On Wed, Sep 21, 2016 at 1:40 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> I never said anything about dropping support for named and positional
>>>> parameters in native queries.
>>>>
>>>> I simply mentioned leveraging the new "JPA strict compliance" stuff I
>>>> am adding to 6.0.  The idea is to allow you to enable that and get feedback
>>>> when you use non-portable things.
>>>>
>>>>
>>>> On Tue, Sep 20, 2016 at 11:45 PM Jordan Gigov <coladict at gmail.com>
>>>> wrote:
>>>>
>>>>> Actually JPA defines it as "Only positional parameter binding and
>>>>> positional access to result items may be portably used for native queries".
>>>>> I believe "portably" means the providers are only required to support
>>>>> positional, but not forbidden from supporting other.
>>>>>
>>>>> 2016-09-21 3:59 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>
>>>>>> In the interest of questioning everything, just to make sure we are
>>>>>> all on
>>>>>> the same page, Hibernate's support for native SQL queries currently
>>>>>> recognizes named parameters, positional parameters as well as
>>>>>> JDBC-style
>>>>>> parameters.
>>>>>>
>>>>>> JPA only defines support for "JDBC-style parameters" as valid for
>>>>>> native
>>>>>> SQL queries:
>>>>>> {quote}
>>>>>> It is assumed that for native queries the parameters themselves use
>>>>>> the SQL
>>>>>> syntax (i.e., ???, rather than ??1?).
>>>>>> {quote}
>>>>>>
>>>>>> Furthermore Hibernate does not support a native query using both
>>>>>> positional
>>>>>> parameters and JDBC-style parameters in the same query because it
>>>>>> causes a
>>>>>> non-determinism wrt the positions.
>>>>>>
>>>>>> I assume we want to continue to support that full complement of
>>>>>> parameter
>>>>>> types, with the positional/JDBC-style caveat.
>>>>>>
>>>>>> Further I assume we will hook up the use of any non-JDBC-style
>>>>>> parameters
>>>>>> in with the "strict JPA compliance" checking and throw an error when
>>>>>> indicated.
>>>>>>
>>>>>> Anyone have objections to any of that?
>>>>>>
>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>>
>>

From steve at hibernate.org  Thu Sep 22 09:18:19 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 22 Sep 2016 13:18:19 +0000
Subject: [hibernate-dev] JPA Jira project
Message-ID: <CAFdSV9u_dCJh+HMZgXH2LBoWWTFJkcr-afFVNDREvA1L4E2CJw@mail.gmail.com>

I propose that we limit who has the ability to create issues in the
Hibernate Jira JPA project.

Users routinely create issues there incorrectly, rather than the ORM (HHH)
project.

From andrea at hibernate.org  Thu Sep 22 09:30:35 2016
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 22 Sep 2016 14:30:35 +0100
Subject: [hibernate-dev] JPA Jira project
In-Reply-To: <CAFdSV9u_dCJh+HMZgXH2LBoWWTFJkcr-afFVNDREvA1L4E2CJw@mail.gmail.com>
References: <CAFdSV9u_dCJh+HMZgXH2LBoWWTFJkcr-afFVNDREvA1L4E2CJw@mail.gmail.com>
Message-ID: <CAL00eSTACgqd0=t9dmq4HBTC_PX4Z6V_hciTG5LXtZZ6L3SpVQ@mail.gmail.com>

+1

On 22 September 2016 at 14:18, Steve Ebersole <steve at hibernate.org> wrote:

> I propose that we limit who has the ability to create issues in the
> Hibernate Jira JPA project.
>
> Users routinely create issues there incorrectly, rather than the ORM (HHH)
> project.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Thu Sep 22 16:10:04 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 22 Sep 2016 13:10:04 -0700
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
	<1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
Message-ID: <CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>

Hi Christian,

We are only backporting critical issues and regressions to 5.0 at this
point, so it can't be backported to 5.0. If no regressions caused by this
fix are reported in 5.2, I would consider backporting to 5.1.

Regards,
Gail

On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov <
christian.beikov at gmail.com> wrote:

> Thanks, I know that it's a beauty ^^
> Hope this can get into all 5.x branches?
>
> Regards,
> Christian
> Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
> > I took a quick look.  I'd prefer to see better solution as we migrate
> > to SQM; but for 5.x, given how Hibernate generates SQL there, I am not
> > sure how else you would possibly do this
> >
> >
> > On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
> > <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>> wrote:
> >
> >     Thanks,
> >
> >     I'm going to review it tomorrow.
> >
> >     Vlad
> >
> >     On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
> >     christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
> wrote:
> >
> >     > Hey again,
> >     >
> >     > I implemented the approach that I proposed in the issue and a
> >     test in
> >     > https://github.com/hibernate/hibernate-orm/pull/1561
> >     >
> >     > It detects left joins with join tables that use the target table
> >     alias.
> >     > The join table is replaced with a subquery and the WITH clause
> >     is moved
> >     > to the join of the subquery.
> >     >
> >     > Any comments?
> >     >
> >     > Regards,
> >     > Christian
> >     > _______________________________________________
> >     > hibernate-dev mailing list
> >     > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.
> jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     >
> >     _______________________________________________
> >     hibernate-dev mailing list
> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Thu Sep 22 16:11:34 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 22 Sep 2016 13:11:34 -0700
Subject: [hibernate-dev] JPA Jira project
In-Reply-To: <CAL00eSTACgqd0=t9dmq4HBTC_PX4Z6V_hciTG5LXtZZ6L3SpVQ@mail.gmail.com>
References: <CAFdSV9u_dCJh+HMZgXH2LBoWWTFJkcr-afFVNDREvA1L4E2CJw@mail.gmail.com>
	<CAL00eSTACgqd0=t9dmq4HBTC_PX4Z6V_hciTG5LXtZZ6L3SpVQ@mail.gmail.com>
Message-ID: <CAFDzhiQwpVOy1y1ovPFV5qW30WW6ZW_G_JbRE4hmT9BOYN7pZw@mail.gmail.com>

+1

On Thu, Sep 22, 2016 at 6:30 AM, andrea boriero <andrea at hibernate.org>
wrote:

> +1
>
> On 22 September 2016 at 14:18, Steve Ebersole <steve at hibernate.org> wrote:
>
> > I propose that we limit who has the ability to create issues in the
> > Hibernate Jira JPA project.
> >
> > Users routinely create issues there incorrectly, rather than the ORM
> (HHH)
> > project.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Sep 22 18:14:01 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 22 Sep 2016 22:14:01 +0000
Subject: [hibernate-dev] JPA Jira project
In-Reply-To: <CAFDzhiQwpVOy1y1ovPFV5qW30WW6ZW_G_JbRE4hmT9BOYN7pZw@mail.gmail.com>
References: <CAFdSV9u_dCJh+HMZgXH2LBoWWTFJkcr-afFVNDREvA1L4E2CJw@mail.gmail.com>
	<CAL00eSTACgqd0=t9dmq4HBTC_PX4Z6V_hciTG5LXtZZ6L3SpVQ@mail.gmail.com>
	<CAFDzhiQwpVOy1y1ovPFV5qW30WW6ZW_G_JbRE4hmT9BOYN7pZw@mail.gmail.com>
Message-ID: <CAFdSV9tcbLjcQHqKDZ4u_Ew3=1Sw9g0i3ZPnn8wXe+V+JWGanQ@mail.gmail.com>

It is so... :)

On Thu, Sep 22, 2016, 3:11 PM Gail Badner <gbadner at redhat.com> wrote:

> +1
>
> On Thu, Sep 22, 2016 at 6:30 AM, andrea boriero <andrea at hibernate.org>
> wrote:
>
>> +1
>>
>> On 22 September 2016 at 14:18, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > I propose that we limit who has the ability to create issues in the
>> > Hibernate Jira JPA project.
>> >
>> > Users routinely create issues there incorrectly, rather than the ORM
>> (HHH)
>> > project.
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From christian.beikov at gmail.com  Fri Sep 23 01:58:21 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 23 Sep 2016 07:58:21 +0200
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
	<1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
	<CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>
Message-ID: <7f15bbe4-db8f-e88f-6618-6ed36a3c701a@gmail.com>

Well to be fair, I already reported that this "regression" was 
introduced in 4.2.8 by placing the ON predicate on the target table join 
instead of the collection table join as was done before in 4.2.7.SP1.
I am not using 4.x anymore but since Wildfly ships with Hibernate 5.0, I 
suppose that others could benefit from this too.
Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I didn't 
consider upgrading yet because I read of some issues.


Regards,
Christian

Am 22.09.2016 um 22:10 schrieb Gail Badner:
> Hi Christian,
>
> We are only backporting critical issues and regressions to 5.0 at this 
> point, so it can't be backported to 5.0. If no regressions caused by 
> this fix are reported in 5.2, I would consider backporting to 5.1.
>
> Regards,
> Gail
>
> On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Thanks, I know that it's a beauty ^^
>     Hope this can get into all 5.x branches?
>
>     Regards,
>     Christian
>     Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
>     > I took a quick look.  I'd prefer to see better solution as we
>     migrate
>     > to SQM; but for 5.x, given how Hibernate generates SQL there, I
>     am not
>     > sure how else you would possibly do this
>     >
>     >
>     > On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
>     > <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>
>     <mailto:mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>>
>     wrote:
>     >
>     >     Thanks,
>     >
>     >     I'm going to review it tomorrow.
>     >
>     >     Vlad
>     >
>     >     On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
>     >christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
>     <mailto:christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>>> wrote:
>     >
>     >     > Hey again,
>     >     >
>     >     > I implemented the approach that I proposed in the issue and a
>     >     test in
>     >     > https://github.com/hibernate/hibernate-orm/pull/1561
>     <https://github.com/hibernate/hibernate-orm/pull/1561>
>     >     >
>     >     > It detects left joins with join tables that use the target
>     table
>     >     alias.
>     >     > The join table is replaced with a subquery and the WITH clause
>     >     is moved
>     >     > to the join of the subquery.
>     >     >
>     >     > Any comments?
>     >     >
>     >     > Regards,
>     >     > Christian
>     >     > _______________________________________________
>     >     > hibernate-dev mailing list
>     >     > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     >     >https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >     >
>     >     _______________________________________________
>     >     hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>


From steve at hibernate.org  Fri Sep 23 11:50:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 Sep 2016 15:50:47 +0000
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9tPLm5prg-0Hx3FCzPavkaqbN82O6y3YXsGD5=0UzboAw@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
	<CA+nBocCxQkmohn3JogaMfoNCKs=hS4a_MwWo4t_gdp2ZRAL9Cg@mail.gmail.com>
	<CAFdSV9vY5DRRMHmz-WGsEfJyU2SbE+xg303s3oqtPq=bqw7jAw@mail.gmail.com>
	<CAFdSV9tPLm5prg-0Hx3FCzPavkaqbN82O6y3YXsGD5=0UzboAw@mail.gmail.com>
Message-ID: <CAFdSV9vWa19zRukst73gpeniJZkTB8HwcoBkYauq9YApxWthzw@mail.gmail.com>

I did end up adding support for controlling this via a setting[1].  Now,
when recognizing ordinal parameters (as distinct from positional
parameters, i.e. ?1) we define the "base" as:

   if ( factory.getSessionFactoryOptions().isJpaBootstrap() ) {
      ordinalParameterBase = 1;
   }
   else {
      final Integer configuredBase =
factory.getSessionFactoryOptions().getNonJpaNativeQueryOrdinalParameterBase();
      ordinalParameterBase = configuredBase == null
            ? 0
            : configuredBase;
   }
   ordinalParameterImplicitPosition = ordinalParameterBase;


That
`factory.getSessionFactoryOptions().getNonJpaNativeQueryOrdinalParameterBase()`
call is driven by this setting.

However back to the question of whether we want to go ahead and unify this
base across the board (regardless of bootstrap method) to be 1 *by
default*.  The difference is who needs to provide this setting... is it
legacy apps upgrading to 6.0 that happen to use ordinal parameters?  or, is
it apps that want the unified base?

Essentially should it be:

ordinalParameterBase = configuredBase == null ? 0 : configuredBase;

or:

ordinalParameterBase = configuredBase == null ? 1 : configuredBase;

Personally I think it should be the latter.  It is pretty normal for legacy
app upgrading to have to set some "use legacy behavior" flags.

What do y'all think?


[1] https://gist.github.com/sebersole/b13c11a9f7d55b84be6b4371e0259bc5



On Wed, Sep 21, 2016 at 2:03 PM Steve Ebersole <steve at hibernate.org> wrote:

> One additional thing we might consider is possibly unifying this 0- and 1-
> based mismatch wrt JDBC-style parameters.
>
> In Hibernate's APIs these JDBC-style parameters were 0-based.  I have
> already dropped support (it has been deprecated for a long time anyway) for
> using JDBC-style params in HQL.  So this is now only a concern for native
> queries.
>
> Interestingly JPA has the following to say (3.10.13 Positional Parameters):
> <quote>
> Only positional parameter binding ... may be portably used for native
> queries... When binding the values of positional parameters, the numbering
> starts as ?1?. It is assumed that for native queries the parameters
> themselves use the SQL syntax (i.e., ???, rather than ??1?).
> </quote>
>
> So for portable JPA, the native query would use JDBC/SQL syntax for the
> parameter marker, but use the JPA convention for parameter index (1-based)
> rather than the JDBC/SQL convention (0-based).
>
> As bassackwards as we may think JPA is here, it is a spec and we have to
> support it: we have to support 1-based binding of these JDBC-style params.
> The question is whether we should deviate from Hibernate's legacy decision
> to align with JDBC/SQL (0-based) for binding of these JDBC-style params.
> Perhaps a setting that controls how this should work - specifically limited
> to JDBC-style param markers in native queries.  By default we'd honor the
> 1-based approach whenever bootstrapping was done via JPA and 0-based when
> native bootstrapping is used.  I guess what I am wondering is whether we
> want to have a setting for the native bootstrapping piece that controls
> whether to use 0-based or 1-based?  I do not think we should allow the
> setting (if we add one) to force 0-based usage with JPA bootstrapping; this
> would only control how it works in native bootstrapping.
>
> Thoughts?
>
> On Wed, Sep 21, 2016 at 1:40 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I never said anything about dropping support for named and positional
>> parameters in native queries.
>>
>> I simply mentioned leveraging the new "JPA strict compliance" stuff I am
>> adding to 6.0.  The idea is to allow you to enable that and get feedback
>> when you use non-portable things.
>>
>>
>> On Tue, Sep 20, 2016 at 11:45 PM Jordan Gigov <coladict at gmail.com> wrote:
>>
>>> Actually JPA defines it as "Only positional parameter binding and
>>> positional access to result items may be portably used for native queries".
>>> I believe "portably" means the providers are only required to support
>>> positional, but not forbidden from supporting other.
>>>
>>> 2016-09-21 3:59 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> In the interest of questioning everything, just to make sure we are all
>>>> on
>>>> the same page, Hibernate's support for native SQL queries currently
>>>> recognizes named parameters, positional parameters as well as JDBC-style
>>>> parameters.
>>>>
>>>> JPA only defines support for "JDBC-style parameters" as valid for native
>>>> SQL queries:
>>>> {quote}
>>>> It is assumed that for native queries the parameters themselves use the
>>>> SQL
>>>> syntax (i.e., ???, rather than ??1?).
>>>> {quote}
>>>>
>>>> Furthermore Hibernate does not support a native query using both
>>>> positional
>>>> parameters and JDBC-style parameters in the same query because it
>>>> causes a
>>>> non-determinism wrt the positions.
>>>>
>>>> I assume we want to continue to support that full complement of
>>>> parameter
>>>> types, with the positional/JDBC-style caveat.
>>>>
>>>> Further I assume we will hook up the use of any non-JDBC-style
>>>> parameters
>>>> in with the "strict JPA compliance" checking and throw an error when
>>>> indicated.
>>>>
>>>> Anyone have objections to any of that?
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>

From steve at hibernate.org  Fri Sep 23 11:53:12 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 Sep 2016 15:53:12 +0000
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <7f15bbe4-db8f-e88f-6618-6ed36a3c701a@gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
	<1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
	<CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>
	<7f15bbe4-db8f-e88f-6618-6ed36a3c701a@gmail.com>
Message-ID: <CAFdSV9sA5HuZ5vrN7=XXJMDOi=tWk+MKKTqKHs8omDhzEi4_fw@mail.gmail.com>

There are some conceptual mismatch problem that IMO stem from the L2C SPI.
We are discussing that all as part of
https://hibernate.atlassian.net/browse/HHH-10707

Whether that affects you really depends how you configure caching.  If you
try to reuse regions for different types of data (entity, collection, etc)
then it will affect you.  If you define different access strategies for the
same region then it will affect you.


On Fri, Sep 23, 2016 at 1:02 AM Christian Beikov <christian.beikov at gmail.com>
wrote:

> Well to be fair, I already reported that this "regression" was
> introduced in 4.2.8 by placing the ON predicate on the target table join
> instead of the collection table join as was done before in 4.2.7.SP1.
> I am not using 4.x anymore but since Wildfly ships with Hibernate 5.0, I
> suppose that others could benefit from this too.
> Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I didn't
> consider upgrading yet because I read of some issues.
>
>
> Regards,
> Christian
>
> Am 22.09.2016 um 22:10 schrieb Gail Badner:
> > Hi Christian,
> >
> > We are only backporting critical issues and regressions to 5.0 at this
> > point, so it can't be backported to 5.0. If no regressions caused by
> > this fix are reported in 5.2, I would consider backporting to 5.1.
> >
> > Regards,
> > Gail
> >
> > On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov
> > <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
> >
> >     Thanks, I know that it's a beauty ^^
> >     Hope this can get into all 5.x branches?
> >
> >     Regards,
> >     Christian
> >     Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
> >     > I took a quick look.  I'd prefer to see better solution as we
> >     migrate
> >     > to SQM; but for 5.x, given how Hibernate generates SQL there, I
> >     am not
> >     > sure how else you would possibly do this
> >     >
> >     >
> >     > On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
> >     > <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>
> >     <mailto:mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>>
> >     wrote:
> >     >
> >     >     Thanks,
> >     >
> >     >     I'm going to review it tomorrow.
> >     >
> >     >     Vlad
> >     >
> >     >     On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
> >     >christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
> >     <mailto:christian.beikov at gmail.com
> >     <mailto:christian.beikov at gmail.com>>> wrote:
> >     >
> >     >     > Hey again,
> >     >     >
> >     >     > I implemented the approach that I proposed in the issue and a
> >     >     test in
> >     >     > https://github.com/hibernate/hibernate-orm/pull/1561
> >     <https://github.com/hibernate/hibernate-orm/pull/1561>
> >     >     >
> >     >     > It detects left joins with join tables that use the target
> >     table
> >     >     alias.
> >     >     > The join table is replaced with a subquery and the WITH
> clause
> >     >     is moved
> >     >     > to the join of the subquery.
> >     >     >
> >     >     > Any comments?
> >     >     >
> >     >     > Regards,
> >     >     > Christian
> >     >     > _______________________________________________
> >     >     > hibernate-dev mailing list
> >     >     > hibernate-dev at lists.jboss.org
> >     <mailto:hibernate-dev at lists.jboss.org>
> >     <mailto:hibernate-dev at lists.jboss.org
> >     <mailto:hibernate-dev at lists.jboss.org>>
> >     >     >https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >     >     >
> >     >     _______________________________________________
> >     >     hibernate-dev mailing list
> >     > hibernate-dev at lists.jboss.org
> >     <mailto:hibernate-dev at lists.jboss.org>
> >     <mailto:hibernate-dev at lists.jboss.org
> >     <mailto:hibernate-dev at lists.jboss.org>>
> >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >     >
> >
> >     _______________________________________________
> >     hibernate-dev mailing list
> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From christian.beikov at gmail.com  Fri Sep 23 12:33:39 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 23 Sep 2016 18:33:39 +0200
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <CAFdSV9sA5HuZ5vrN7=XXJMDOi=tWk+MKKTqKHs8omDhzEi4_fw@mail.gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
	<1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
	<CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>
	<7f15bbe4-db8f-e88f-6618-6ed36a3c701a@gmail.com>
	<CAFdSV9sA5HuZ5vrN7=XXJMDOi=tWk+MKKTqKHs8omDhzEi4_fw@mail.gmail.com>
Message-ID: <518972bf-7d0d-8ab7-2734-cc73ae93b1fe@gmail.com>

Wrong thread?

Am 23.09.2016 um 17:53 schrieb Steve Ebersole:
> There are some conceptual mismatch problem that IMO stem from the L2C 
> SPI.  We are discussing that all as part of 
> https://hibernate.atlassian.net/browse/HHH-10707
>
> Whether that affects you really depends how you configure caching.  If 
> you try to reuse regions for different types of data (entity, 
> collection, etc) then it will affect you.  If you define different 
> access strategies for the same region then it will affect you.
>
>
> On Fri, Sep 23, 2016 at 1:02 AM Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Well to be fair, I already reported that this "regression" was
>     introduced in 4.2.8 by placing the ON predicate on the target
>     table join
>     instead of the collection table join as was done before in 4.2.7.SP1.
>     I am not using 4.x anymore but since Wildfly ships with Hibernate
>     5.0, I
>     suppose that others could benefit from this too.
>     Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I
>     didn't
>     consider upgrading yet because I read of some issues.
>
>
>     Regards,
>     Christian
>
>     Am 22.09.2016 um 22:10 schrieb Gail Badner:
>     > Hi Christian,
>     >
>     > We are only backporting critical issues and regressions to 5.0
>     at this
>     > point, so it can't be backported to 5.0. If no regressions caused by
>     > this fix are reported in 5.2, I would consider backporting to 5.1.
>     >
>     > Regards,
>     > Gail
>     >
>     > On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov
>     > <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
>     <mailto:christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>>> wrote:
>     >
>     >     Thanks, I know that it's a beauty ^^
>     >     Hope this can get into all 5.x branches?
>     >
>     >     Regards,
>     >     Christian
>     >     Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
>     >     > I took a quick look.  I'd prefer to see better solution as we
>     >     migrate
>     >     > to SQM; but for 5.x, given how Hibernate generates SQL
>     there, I
>     >     am not
>     >     > sure how else you would possibly do this
>     >     >
>     >     >
>     >     > On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
>     >     > <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>
>     <mailto:mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>     >     <mailto:mihalcea.vlad at gmail.com
>     <mailto:mihalcea.vlad at gmail.com> <mailto:mihalcea.vlad at gmail.com
>     <mailto:mihalcea.vlad at gmail.com>>>>
>     >     wrote:
>     >     >
>     >     >     Thanks,
>     >     >
>     >     >     I'm going to review it tomorrow.
>     >     >
>     >     >     Vlad
>     >     >
>     >     >     On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
>     >     >christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>
>     <mailto:christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>>
>     >     <mailto:christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>
>     >     <mailto:christian.beikov at gmail.com
>     <mailto:christian.beikov at gmail.com>>>> wrote:
>     >     >
>     >     >     > Hey again,
>     >     >     >
>     >     >     > I implemented the approach that I proposed in the
>     issue and a
>     >     >     test in
>     >     >     > https://github.com/hibernate/hibernate-orm/pull/1561
>     >     <https://github.com/hibernate/hibernate-orm/pull/1561>
>     >     >     >
>     >     >     > It detects left joins with join tables that use the
>     target
>     >     table
>     >     >     alias.
>     >     >     > The join table is replaced with a subquery and the
>     WITH clause
>     >     >     is moved
>     >     >     > to the join of the subquery.
>     >     >     >
>     >     >     > Any comments?
>     >     >     >
>     >     >     > Regards,
>     >     >     > Christian
>     >     >     > _______________________________________________
>     >     >     > hibernate-dev mailing list
>     >     >     > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     >     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>>
>     >     >     >https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >     >     >
>     >     >  _______________________________________________
>     >     >     hibernate-dev mailing list
>     >     > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     >     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     >     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>>
>     >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >     >
>     >
>     >     _______________________________________________
>     >     hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>     >
>     >
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From steve at hibernate.org  Fri Sep 23 12:36:52 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 Sep 2016 16:36:52 +0000
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <518972bf-7d0d-8ab7-2734-cc73ae93b1fe@gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
	<1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
	<CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>
	<7f15bbe4-db8f-e88f-6618-6ed36a3c701a@gmail.com>
	<CAFdSV9sA5HuZ5vrN7=XXJMDOi=tWk+MKKTqKHs8omDhzEi4_fw@mail.gmail.com>
	<518972bf-7d0d-8ab7-2734-cc73ae93b1fe@gmail.com>
Message-ID: <CAFdSV9tdzY47Az_wk-g7c-h=Oj3Wdczb7bfzTAG_F1hE6zCS5A@mail.gmail.com>

Nope.  You asked:

Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I didn't
consider upgrading yet because I read of some issues.

Now its possibly I misread your reference to HIbernate+Infinispan problems
to mean the only ones I know of. hence the HHH-10707 reference.  If you
meant some other "Hibernate 5.1+ and Infinispan" problem, then I guess you
could have been more specific ;)



On Fri, Sep 23, 2016 at 11:33 AM Christian Beikov <
christian.beikov at gmail.com> wrote:

> Wrong thread?
>
>
> Am 23.09.2016 um 17:53 schrieb Steve Ebersole:
>
> There are some conceptual mismatch problem that IMO stem from the L2C
> SPI.  We are discussing that all as part of
> https://hibernate.atlassian.net/browse/HHH-10707
>
> Whether that affects you really depends how you configure caching.  If you
> try to reuse regions for different types of data (entity, collection, etc)
> then it will affect you.  If you define different access strategies for the
> same region then it will affect you.
>
>
> On Fri, Sep 23, 2016 at 1:02 AM Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
>> Well to be fair, I already reported that this "regression" was
>> introduced in 4.2.8 by placing the ON predicate on the target table join
>> instead of the collection table join as was done before in 4.2.7.SP1.
>> I am not using 4.x anymore but since Wildfly ships with Hibernate 5.0, I
>> suppose that others could benefit from this too.
>> Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I didn't
>> consider upgrading yet because I read of some issues.
>>
>>
>> Regards,
>> Christian
>>
>> Am 22.09.2016 um 22:10 schrieb Gail Badner:
>> > Hi Christian,
>> >
>> > We are only backporting critical issues and regressions to 5.0 at this
>> > point, so it can't be backported to 5.0. If no regressions caused by
>> > this fix are reported in 5.2, I would consider backporting to 5.1.
>> >
>> > Regards,
>> > Gail
>> >
>> > On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov
>> > <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>> >
>> >     Thanks, I know that it's a beauty ^^
>> >     Hope this can get into all 5.x branches?
>> >
>> >     Regards,
>> >     Christian
>> >     Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
>> >     > I took a quick look.  I'd prefer to see better solution as we
>> >     migrate
>> >     > to SQM; but for 5.x, given how Hibernate generates SQL there, I
>> >     am not
>> >     > sure how else you would possibly do this
>> >     >
>> >     >
>> >     > On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
>> >     > <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>
>> >     <mailto:mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>>
>> >     wrote:
>> >     >
>> >     >     Thanks,
>> >     >
>> >     >     I'm going to review it tomorrow.
>> >     >
>> >     >     Vlad
>> >     >
>> >     >     On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
>> >     >christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
>> >     <mailto:christian.beikov at gmail.com
>> >     <mailto:christian.beikov at gmail.com>>> wrote:
>> >     >
>> >     >     > Hey again,
>> >     >     >
>> >     >     > I implemented the approach that I proposed in the issue and
>> a
>> >     >     test in
>> >     >     > https://github.com/hibernate/hibernate-orm/pull/1561
>> >     <https://github.com/hibernate/hibernate-orm/pull/1561>
>> >     >     >
>> >     >     > It detects left joins with join tables that use the target
>> >     table
>> >     >     alias.
>> >     >     > The join table is replaced with a subquery and the WITH
>> clause
>> >     >     is moved
>> >     >     > to the join of the subquery.
>> >     >     >
>> >     >     > Any comments?
>> >     >     >
>> >     >     > Regards,
>> >     >     > Christian
>> >     >     > _______________________________________________
>> >     >     > hibernate-dev mailing list
>> >     >     > hibernate-dev at lists.jboss.org
>> >     <mailto:hibernate-dev at lists.jboss.org>
>> >     <mailto:hibernate-dev at lists.jboss.org
>> >     <mailto:hibernate-dev at lists.jboss.org>>
>> >     >     >https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >     >     >
>> >     >     _______________________________________________
>> >     >     hibernate-dev mailing list
>> >     > hibernate-dev at lists.jboss.org
>> >     <mailto:hibernate-dev at lists.jboss.org>
>> >     <mailto:hibernate-dev at lists.jboss.org
>> >     <mailto:hibernate-dev at lists.jboss.org>>
>> >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >     >
>> >
>> >     _______________________________________________
>> >     hibernate-dev mailing list
>> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org
>> >
>> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >
>> >
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From christian.beikov at gmail.com  Fri Sep 23 12:41:23 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 23 Sep 2016 18:41:23 +0200
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <CAFdSV9tdzY47Az_wk-g7c-h=Oj3Wdczb7bfzTAG_F1hE6zCS5A@mail.gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
	<1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
	<CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>
	<7f15bbe4-db8f-e88f-6618-6ed36a3c701a@gmail.com>
	<CAFdSV9sA5HuZ5vrN7=XXJMDOi=tWk+MKKTqKHs8omDhzEi4_fw@mail.gmail.com>
	<518972bf-7d0d-8ab7-2734-cc73ae93b1fe@gmail.com>
	<CAFdSV9tdzY47Az_wk-g7c-h=Oj3Wdczb7bfzTAG_F1hE6zCS5A@mail.gmail.com>
Message-ID: <58706af7-e75c-66f0-0189-ceae80453ccf@gmail.com>

Ahh okay, I see. Sorry, I didn't fully read my previous mail and forgot 
I asked that question ^^
Well then I'll try upgrading to 5.2 and hope for the best :)

So are you considering merging that to 5.2 then?


Am 23.09.2016 um 18:36 schrieb Steve Ebersole:
> Nope.  You asked:
>
> Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I didn't
> consider upgrading yet because I read of some issues.
>
> Now its possibly I misread your reference to HIbernate+Infinispan 
> problems to mean the only ones I know of. hence the HHH-10707 
> reference.  If you meant some other "Hibernate 5.1+ and Infinispan" 
> problem, then I guess you could have been more specific ;)
>
>
>
> On Fri, Sep 23, 2016 at 11:33 AM Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Wrong thread?
>
>
>     Am 23.09.2016 um 17:53 schrieb Steve Ebersole:
>>     There are some conceptual mismatch problem that IMO stem from the
>>     L2C SPI.  We are discussing that all as part of
>>     https://hibernate.atlassian.net/browse/HHH-10707
>>
>>     Whether that affects you really depends how you configure
>>     caching.  If you try to reuse regions for different types of data
>>     (entity, collection, etc) then it will affect you.  If you define
>>     different access strategies for the same region then it will
>>     affect you.
>>
>>
>>     On Fri, Sep 23, 2016 at 1:02 AM Christian Beikov
>>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>     wrote:
>>
>>         Well to be fair, I already reported that this "regression" was
>>         introduced in 4.2.8 by placing the ON predicate on the target
>>         table join
>>         instead of the collection table join as was done before in
>>         4.2.7.SP1.
>>         I am not using 4.x anymore but since Wildfly ships with
>>         Hibernate 5.0, I
>>         suppose that others could benefit from this too.
>>         Are the problems with Hibernate 5.1+ and Infinispan fixed
>>         yet? I didn't
>>         consider upgrading yet because I read of some issues.
>>
>>
>>         Regards,
>>         Christian
>>
>>         Am 22.09.2016 um 22:10 schrieb Gail Badner:
>>         > Hi Christian,
>>         >
>>         > We are only backporting critical issues and regressions to
>>         5.0 at this
>>         > point, so it can't be backported to 5.0. If no regressions
>>         caused by
>>         > this fix are reported in 5.2, I would consider backporting
>>         to 5.1.
>>         >
>>         > Regards,
>>         > Gail
>>         >
>>         > On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov
>>         > <christian.beikov at gmail.com
>>         <mailto:christian.beikov at gmail.com>
>>         <mailto:christian.beikov at gmail.com
>>         <mailto:christian.beikov at gmail.com>>> wrote:
>>         >
>>         >     Thanks, I know that it's a beauty ^^
>>         >     Hope this can get into all 5.x branches?
>>         >
>>         >     Regards,
>>         >     Christian
>>         >     Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
>>         >     > I took a quick look.  I'd prefer to see better
>>         solution as we
>>         >     migrate
>>         >     > to SQM; but for 5.x, given how Hibernate generates
>>         SQL there, I
>>         >     am not
>>         >     > sure how else you would possibly do this
>>         >     >
>>         >     >
>>         >     > On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
>>         >     > <mihalcea.vlad at gmail.com
>>         <mailto:mihalcea.vlad at gmail.com>
>>         <mailto:mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>
>>         >     <mailto:mihalcea.vlad at gmail.com
>>         <mailto:mihalcea.vlad at gmail.com>
>>         <mailto:mihalcea.vlad at gmail.com
>>         <mailto:mihalcea.vlad at gmail.com>>>>
>>         >     wrote:
>>         >     >
>>         >     >     Thanks,
>>         >     >
>>         >     >     I'm going to review it tomorrow.
>>         >     >
>>         >     >     Vlad
>>         >     >
>>         >     >     On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
>>         >     >christian.beikov at gmail.com
>>         <mailto:christian.beikov at gmail.com>
>>         <mailto:christian.beikov at gmail.com
>>         <mailto:christian.beikov at gmail.com>>
>>         >     <mailto:christian.beikov at gmail.com
>>         <mailto:christian.beikov at gmail.com>
>>         >     <mailto:christian.beikov at gmail.com
>>         <mailto:christian.beikov at gmail.com>>>> wrote:
>>         >     >
>>         >     >     > Hey again,
>>         >     >     >
>>         >     >     > I implemented the approach that I proposed in
>>         the issue and a
>>         >     >     test in
>>         >     >     >
>>         https://github.com/hibernate/hibernate-orm/pull/1561
>>         >     <https://github.com/hibernate/hibernate-orm/pull/1561>
>>         >     >     >
>>         >     >     > It detects left joins with join tables that use
>>         the target
>>         >     table
>>         >     >     alias.
>>         >     >     > The join table is replaced with a subquery and
>>         the WITH clause
>>         >     >     is moved
>>         >     >     > to the join of the subquery.
>>         >     >     >
>>         >     >     > Any comments?
>>         >     >     >
>>         >     >     > Regards,
>>         >     >     > Christian
>>         >     >     > _______________________________________________
>>         >     >     > hibernate-dev mailing list
>>         >     >     > hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>
>>         >     <mailto:hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>>
>>         >     <mailto:hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>
>>         >     <mailto:hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>>>
>>         >     >   
>>          >https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>         >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>         >     >     >
>>         >     >  _______________________________________________
>>         >     >     hibernate-dev mailing list
>>         >     > hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>
>>         >     <mailto:hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>>
>>         >     <mailto:hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>
>>         >     <mailto:hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>>>
>>         >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>         >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>         >     >
>>         >
>>         >  _______________________________________________
>>         >     hibernate-dev mailing list
>>         > hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>
>>         <mailto:hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>>
>>         > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>         >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>         >
>>         >
>>
>>         _______________________________________________
>>         hibernate-dev mailing list
>>         hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>


From steve at hibernate.org  Fri Sep 23 12:50:21 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 Sep 2016 16:50:21 +0000
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <58706af7-e75c-66f0-0189-ceae80453ccf@gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
	<1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
	<CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>
	<7f15bbe4-db8f-e88f-6618-6ed36a3c701a@gmail.com>
	<CAFdSV9sA5HuZ5vrN7=XXJMDOi=tWk+MKKTqKHs8omDhzEi4_fw@mail.gmail.com>
	<518972bf-7d0d-8ab7-2734-cc73ae93b1fe@gmail.com>
	<CAFdSV9tdzY47Az_wk-g7c-h=Oj3Wdczb7bfzTAG_F1hE6zCS5A@mail.gmail.com>
	<58706af7-e75c-66f0-0189-ceae80453ccf@gmail.com>
Message-ID: <CAFdSV9ty7+56dzLwxaUQMeWORuoa070HjTUL1AiFCd0LFL=HVw@mail.gmail.com>

Depends on the "fix" we all agree on.  Mainly whether that leads to any
non-compatible SPI changes.


On Fri, Sep 23, 2016 at 11:41 AM Christian Beikov <
christian.beikov at gmail.com> wrote:

> Ahh okay, I see. Sorry, I didn't fully read my previous mail and forgot I
> asked that question ^^
> Well then I'll try upgrading to 5.2 and hope for the best :)
>
> So are you considering merging that to 5.2 then?
>
>
>
> Am 23.09.2016 um 18:36 schrieb Steve Ebersole:
>
> Nope.  You asked:
>
> Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I didn't
> consider upgrading yet because I read of some issues.
>
> Now its possibly I misread your reference to HIbernate+Infinispan problems
> to mean the only ones I know of. hence the HHH-10707 reference.  If you
> meant some other "Hibernate 5.1+ and Infinispan" problem, then I guess you
> could have been more specific ;)
>
>
>
> On Fri, Sep 23, 2016 at 11:33 AM Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
>> Wrong thread?
>>
>>
>> Am 23.09.2016 um 17:53 schrieb Steve Ebersole:
>>
>> There are some conceptual mismatch problem that IMO stem from the L2C
>> SPI.  We are discussing that all as part of
>> https://hibernate.atlassian.net/browse/HHH-10707
>>
>> Whether that affects you really depends how you configure caching.  If
>> you try to reuse regions for different types of data (entity, collection,
>> etc) then it will affect you.  If you define different access strategies
>> for the same region then it will affect you.
>>
>>
>> On Fri, Sep 23, 2016 at 1:02 AM Christian Beikov <
>> christian.beikov at gmail.com> wrote:
>>
>>> Well to be fair, I already reported that this "regression" was
>>> introduced in 4.2.8 by placing the ON predicate on the target table join
>>> instead of the collection table join as was done before in 4.2.7.SP1.
>>> I am not using 4.x anymore but since Wildfly ships with Hibernate 5.0, I
>>> suppose that others could benefit from this too.
>>> Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I didn't
>>> consider upgrading yet because I read of some issues.
>>>
>>>
>>> Regards,
>>> Christian
>>>
>>> Am 22.09.2016 um 22:10 schrieb Gail Badner:
>>> > Hi Christian,
>>> >
>>> > We are only backporting critical issues and regressions to 5.0 at this
>>> > point, so it can't be backported to 5.0. If no regressions caused by
>>> > this fix are reported in 5.2, I would consider backporting to 5.1.
>>> >
>>> > Regards,
>>> > Gail
>>> >
>>> > On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov
>>> > <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>> wrote:
>>> >
>>> >     Thanks, I know that it's a beauty ^^
>>> >     Hope this can get into all 5.x branches?
>>> >
>>> >     Regards,
>>> >     Christian
>>> >     Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
>>> >     > I took a quick look.  I'd prefer to see better solution as we
>>> >     migrate
>>> >     > to SQM; but for 5.x, given how Hibernate generates SQL there, I
>>> >     am not
>>> >     > sure how else you would possibly do this
>>> >     >
>>> >     >
>>> >     > On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
>>> >     > <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>
>>> >     <mailto:mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>>>
>>> >     wrote:
>>> >     >
>>> >     >     Thanks,
>>> >     >
>>> >     >     I'm going to review it tomorrow.
>>> >     >
>>> >     >     Vlad
>>> >     >
>>> >     >     On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
>>> >     >christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
>>> >     <mailto:christian.beikov at gmail.com
>>> >     <mailto:christian.beikov at gmail.com>>> wrote:
>>> >     >
>>> >     >     > Hey again,
>>> >     >     >
>>> >     >     > I implemented the approach that I proposed in the issue
>>> and a
>>> >     >     test in
>>> >     >     > https://github.com/hibernate/hibernate-orm/pull/1561
>>> >     <https://github.com/hibernate/hibernate-orm/pull/1561>
>>> >     >     >
>>> >     >     > It detects left joins with join tables that use the target
>>> >     table
>>> >     >     alias.
>>> >     >     > The join table is replaced with a subquery and the WITH
>>> clause
>>> >     >     is moved
>>> >     >     > to the join of the subquery.
>>> >     >     >
>>> >     >     > Any comments?
>>> >     >     >
>>> >     >     > Regards,
>>> >     >     > Christian
>>> >     >     > _______________________________________________
>>> >     >     > hibernate-dev mailing list
>>> >     >     > hibernate-dev at lists.jboss.org
>>> >     <mailto:hibernate-dev at lists.jboss.org>
>>> >     <mailto:hibernate-dev at lists.jboss.org
>>> >     <mailto:hibernate-dev at lists.jboss.org>>
>>> >     >     >https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>> >     >     >
>>> >     >     _______________________________________________
>>> >     >     hibernate-dev mailing list
>>> >     > hibernate-dev at lists.jboss.org
>>> >     <mailto:hibernate-dev at lists.jboss.org>
>>> >     <mailto:hibernate-dev at lists.jboss.org
>>> >     <mailto:hibernate-dev at lists.jboss.org>>
>>> >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>> >     >
>>> >
>>> >     _______________________________________________
>>> >     hibernate-dev mailing list
>>> >     hibernate-dev at lists.jboss.org <mailto:
>>> hibernate-dev at lists.jboss.org>
>>> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>> >
>>> >
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From christian.beikov at gmail.com  Fri Sep 23 13:31:52 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 23 Sep 2016 19:31:52 +0200
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <CAFdSV9ty7+56dzLwxaUQMeWORuoa070HjTUL1AiFCd0LFL=HVw@mail.gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
	<1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
	<CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>
	<7f15bbe4-db8f-e88f-6618-6ed36a3c701a@gmail.com>
	<CAFdSV9sA5HuZ5vrN7=XXJMDOi=tWk+MKKTqKHs8omDhzEi4_fw@mail.gmail.com>
	<518972bf-7d0d-8ab7-2734-cc73ae93b1fe@gmail.com>
	<CAFdSV9tdzY47Az_wk-g7c-h=Oj3Wdczb7bfzTAG_F1hE6zCS5A@mail.gmail.com>
	<58706af7-e75c-66f0-0189-ceae80453ccf@gmail.com>
	<CAFdSV9ty7+56dzLwxaUQMeWORuoa070HjTUL1AiFCd0LFL=HVw@mail.gmail.com>
Message-ID: <c82efe4b-827f-74d3-c394-a693c86f41cc@gmail.com>

Is the fix I proposed in my 
PR(https://github.com/hibernate/hibernate-orm/pull/1561) non-compatible?
Did I miss discussion about that somewhere or didn't you have time to 
review that yet?

Am 23.09.2016 um 18:50 schrieb Steve Ebersole:
> Depends on the "fix" we all agree on.  Mainly whether that leads to 
> any non-compatible SPI changes.
>
>
> On Fri, Sep 23, 2016 at 11:41 AM Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Ahh okay, I see. Sorry, I didn't fully read my previous mail and
>     forgot I asked that question ^^
>     Well then I'll try upgrading to 5.2 and hope for the best :)
>
>     So are you considering merging that to 5.2 then?
>
>
>
>     Am 23.09.2016 um 18:36 schrieb Steve Ebersole:
>>     Nope.  You asked:
>>
>>     Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I
>>     didn't
>>     consider upgrading yet because I read of some issues.
>>
>>     Now its possibly I misread your reference to HIbernate+Infinispan
>>     problems to mean the only ones I know of. hence the HHH-10707
>>     reference.  If you meant some other "Hibernate 5.1+ and
>>     Infinispan" problem, then I guess you could have been more
>>     specific ;)
>>
>>
>>
>>     On Fri, Sep 23, 2016 at 11:33 AM Christian Beikov
>>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>     wrote:
>>
>>         Wrong thread?
>>
>>
>>         Am 23.09.2016 um 17:53 schrieb Steve Ebersole:
>>>         There are some conceptual mismatch problem that IMO stem
>>>         from the L2C SPI.  We are discussing that all as part of
>>>         https://hibernate.atlassian.net/browse/HHH-10707
>>>
>>>         Whether that affects you really depends how you configure
>>>         caching.  If you try to reuse regions for different types of
>>>         data (entity, collection, etc) then it will affect you.  If
>>>         you define different access strategies for the same region
>>>         then it will affect you.
>>>
>>>
>>>         On Fri, Sep 23, 2016 at 1:02 AM Christian Beikov
>>>         <christian.beikov at gmail.com
>>>         <mailto:christian.beikov at gmail.com>> wrote:
>>>
>>>             Well to be fair, I already reported that this
>>>             "regression" was
>>>             introduced in 4.2.8 by placing the ON predicate on the
>>>             target table join
>>>             instead of the collection table join as was done before
>>>             in 4.2.7.SP1.
>>>             I am not using 4.x anymore but since Wildfly ships with
>>>             Hibernate 5.0, I
>>>             suppose that others could benefit from this too.
>>>             Are the problems with Hibernate 5.1+ and Infinispan
>>>             fixed yet? I didn't
>>>             consider upgrading yet because I read of some issues.
>>>
>>>
>>>             Regards,
>>>             Christian
>>>
>>>             Am 22.09.2016 um 22:10 schrieb Gail Badner:
>>>             > Hi Christian,
>>>             >
>>>             > We are only backporting critical issues and
>>>             regressions to 5.0 at this
>>>             > point, so it can't be backported to 5.0. If no
>>>             regressions caused by
>>>             > this fix are reported in 5.2, I would consider
>>>             backporting to 5.1.
>>>             >
>>>             > Regards,
>>>             > Gail
>>>             >
>>>             > On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov
>>>             > <christian.beikov at gmail.com
>>>             <mailto:christian.beikov at gmail.com>
>>>             <mailto:christian.beikov at gmail.com
>>>             <mailto:christian.beikov at gmail.com>>> wrote:
>>>             >
>>>             >     Thanks, I know that it's a beauty ^^
>>>             >     Hope this can get into all 5.x branches?
>>>             >
>>>             >     Regards,
>>>             >     Christian
>>>             >     Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
>>>             >     > I took a quick look.  I'd prefer to see better
>>>             solution as we
>>>             >     migrate
>>>             >     > to SQM; but for 5.x, given how Hibernate
>>>             generates SQL there, I
>>>             >     am not
>>>             >     > sure how else you would possibly do this
>>>             >     >
>>>             >     >
>>>             >     > On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
>>>             >     > <mihalcea.vlad at gmail.com
>>>             <mailto:mihalcea.vlad at gmail.com>
>>>             <mailto:mihalcea.vlad at gmail.com
>>>             <mailto:mihalcea.vlad at gmail.com>>
>>>             >     <mailto:mihalcea.vlad at gmail.com
>>>             <mailto:mihalcea.vlad at gmail.com>
>>>             <mailto:mihalcea.vlad at gmail.com
>>>             <mailto:mihalcea.vlad at gmail.com>>>>
>>>             >     wrote:
>>>             >     >
>>>             >     >     Thanks,
>>>             >     >
>>>             >     >     I'm going to review it tomorrow.
>>>             >     >
>>>             >     >     Vlad
>>>             >     >
>>>             >     >     On Tue, Sep 20, 2016 at 8:38 PM, Christian
>>>             Beikov <
>>>             >     >christian.beikov at gmail.com
>>>             <mailto:christian.beikov at gmail.com>
>>>             <mailto:christian.beikov at gmail.com
>>>             <mailto:christian.beikov at gmail.com>>
>>>             >     <mailto:christian.beikov at gmail.com
>>>             <mailto:christian.beikov at gmail.com>
>>>             >     <mailto:christian.beikov at gmail.com
>>>             <mailto:christian.beikov at gmail.com>>>> wrote:
>>>             >     >
>>>             >     >     > Hey again,
>>>             >     >     >
>>>             >     >     > I implemented the approach that I proposed
>>>             in the issue and a
>>>             >     >     test in
>>>             >     >     >
>>>             https://github.com/hibernate/hibernate-orm/pull/1561
>>>             >     <https://github.com/hibernate/hibernate-orm/pull/1561>
>>>             >     >     >
>>>             >     >     > It detects left joins with join tables
>>>             that use the target
>>>             >     table
>>>             >     >     alias.
>>>             >     >     > The join table is replaced with a subquery
>>>             and the WITH clause
>>>             >     >     is moved
>>>             >     >     > to the join of the subquery.
>>>             >     >     >
>>>             >     >     > Any comments?
>>>             >     >     >
>>>             >     >     > Regards,
>>>             >     >     > Christian
>>>             >     >     >
>>>             _______________________________________________
>>>             >     >     > hibernate-dev mailing list
>>>             >     >     > hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>
>>>             >     <mailto:hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>>
>>>             >     <mailto:hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>
>>>             >     <mailto:hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>>>
>>>             >     >   
>>>              >https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>             >   
>>>              <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>             >     >     >
>>>             >     >  _______________________________________________
>>>             >     >     hibernate-dev mailing list
>>>             >     > hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>
>>>             >     <mailto:hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>>
>>>             >     <mailto:hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>
>>>             >     <mailto:hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>>>
>>>             >     >
>>>             https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>             >   
>>>              <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>             >     >
>>>             >
>>>             >  _______________________________________________
>>>             >     hibernate-dev mailing list
>>>             > hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>
>>>             <mailto:hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>>
>>>             > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>             >   
>>>              <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>             >
>>>             >
>>>
>>>             _______________________________________________
>>>             hibernate-dev mailing list
>>>             hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>


From steve at hibernate.org  Fri Sep 23 13:36:33 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 Sep 2016 17:36:33 +0000
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <c82efe4b-827f-74d3-c394-a693c86f41cc@gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
	<1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
	<CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>
	<7f15bbe4-db8f-e88f-6618-6ed36a3c701a@gmail.com>
	<CAFdSV9sA5HuZ5vrN7=XXJMDOi=tWk+MKKTqKHs8omDhzEi4_fw@mail.gmail.com>
	<518972bf-7d0d-8ab7-2734-cc73ae93b1fe@gmail.com>
	<CAFdSV9tdzY47Az_wk-g7c-h=Oj3Wdczb7bfzTAG_F1hE6zCS5A@mail.gmail.com>
	<58706af7-e75c-66f0-0189-ceae80453ccf@gmail.com>
	<CAFdSV9ty7+56dzLwxaUQMeWORuoa070HjTUL1AiFCd0LFL=HVw@mail.gmail.com>
	<c82efe4b-827f-74d3-c394-a693c86f41cc@gmail.com>
Message-ID: <CAFdSV9u=0j_PfSTZ1j_1Gf2G1Gq4etfOxLzgTje-fiCDzg4jyg@mail.gmail.com>

Well again we were just talking about HHH-10707 and you asked "will it be
integrated upstream"...

I can tell by your reaction that you really were asking whether *your*
change would be integrated upstream, but that was not obviously from your
email :)


On Fri, Sep 23, 2016 at 12:32 PM Christian Beikov <
christian.beikov at gmail.com> wrote:

> Is the fix I proposed in my PR(
> https://github.com/hibernate/hibernate-orm/pull/1561) non-compatible?
> Did I miss discussion about that somewhere or didn't you have time to
> review that yet?
>
>
> Am 23.09.2016 um 18:50 schrieb Steve Ebersole:
>
> Depends on the "fix" we all agree on.  Mainly whether that leads to any
> non-compatible SPI changes.
>
>
> On Fri, Sep 23, 2016 at 11:41 AM Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
>> Ahh okay, I see. Sorry, I didn't fully read my previous mail and forgot I
>> asked that question ^^
>> Well then I'll try upgrading to 5.2 and hope for the best :)
>>
>> So are you considering merging that to 5.2 then?
>>
>>
>>
>> Am 23.09.2016 um 18:36 schrieb Steve Ebersole:
>>
>> Nope.  You asked:
>>
>> Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I didn't
>> consider upgrading yet because I read of some issues.
>>
>> Now its possibly I misread your reference to HIbernate+Infinispan
>> problems to mean the only ones I know of. hence the HHH-10707 reference.
>> If you meant some other "Hibernate 5.1+ and Infinispan" problem, then I
>> guess you could have been more specific ;)
>>
>>
>>
>> On Fri, Sep 23, 2016 at 11:33 AM Christian Beikov <
>> christian.beikov at gmail.com> wrote:
>>
>>> Wrong thread?
>>>
>>>
>>> Am 23.09.2016 um 17:53 schrieb Steve Ebersole:
>>>
>>> There are some conceptual mismatch problem that IMO stem from the L2C
>>> SPI.  We are discussing that all as part of
>>> https://hibernate.atlassian.net/browse/HHH-10707
>>>
>>> Whether that affects you really depends how you configure caching.  If
>>> you try to reuse regions for different types of data (entity, collection,
>>> etc) then it will affect you.  If you define different access strategies
>>> for the same region then it will affect you.
>>>
>>>
>>> On Fri, Sep 23, 2016 at 1:02 AM Christian Beikov <
>>> christian.beikov at gmail.com> wrote:
>>>
>>>> Well to be fair, I already reported that this "regression" was
>>>> introduced in 4.2.8 by placing the ON predicate on the target table join
>>>> instead of the collection table join as was done before in 4.2.7.SP1.
>>>> I am not using 4.x anymore but since Wildfly ships with Hibernate 5.0, I
>>>> suppose that others could benefit from this too.
>>>> Are the problems with Hibernate 5.1+ and Infinispan fixed yet? I didn't
>>>> consider upgrading yet because I read of some issues.
>>>>
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>> Am 22.09.2016 um 22:10 schrieb Gail Badner:
>>>> > Hi Christian,
>>>> >
>>>> > We are only backporting critical issues and regressions to 5.0 at this
>>>> > point, so it can't be backported to 5.0. If no regressions caused by
>>>> > this fix are reported in 5.2, I would consider backporting to 5.1.
>>>> >
>>>> > Regards,
>>>> > Gail
>>>> >
>>>> > On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov
>>>> > <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>>> wrote:
>>>> >
>>>> >     Thanks, I know that it's a beauty ^^
>>>> >     Hope this can get into all 5.x branches?
>>>> >
>>>> >     Regards,
>>>> >     Christian
>>>> >     Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
>>>> >     > I took a quick look.  I'd prefer to see better solution as we
>>>> >     migrate
>>>> >     > to SQM; but for 5.x, given how Hibernate generates SQL there, I
>>>> >     am not
>>>> >     > sure how else you would possibly do this
>>>> >     >
>>>> >     >
>>>> >     > On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
>>>> >     > <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>
>>>> >     <mailto:mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com
>>>> >>>
>>>> >     wrote:
>>>> >     >
>>>> >     >     Thanks,
>>>> >     >
>>>> >     >     I'm going to review it tomorrow.
>>>> >     >
>>>> >     >     Vlad
>>>> >     >
>>>> >     >     On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
>>>> >     >christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>
>>>> >     <mailto:christian.beikov at gmail.com
>>>> >     <mailto:christian.beikov at gmail.com>>> wrote:
>>>> >     >
>>>> >     >     > Hey again,
>>>> >     >     >
>>>> >     >     > I implemented the approach that I proposed in the issue
>>>> and a
>>>> >     >     test in
>>>> >     >     > https://github.com/hibernate/hibernate-orm/pull/1561
>>>> >     <https://github.com/hibernate/hibernate-orm/pull/1561>
>>>> >     >     >
>>>> >     >     > It detects left joins with join tables that use the target
>>>> >     table
>>>> >     >     alias.
>>>> >     >     > The join table is replaced with a subquery and the WITH
>>>> clause
>>>> >     >     is moved
>>>> >     >     > to the join of the subquery.
>>>> >     >     >
>>>> >     >     > Any comments?
>>>> >     >     >
>>>> >     >     > Regards,
>>>> >     >     > Christian
>>>> >     >     > _______________________________________________
>>>> >     >     > hibernate-dev mailing list
>>>> >     >     > hibernate-dev at lists.jboss.org
>>>> >     <mailto:hibernate-dev at lists.jboss.org>
>>>> >     <mailto:hibernate-dev at lists.jboss.org
>>>> >     <mailto:hibernate-dev at lists.jboss.org>>
>>>> >     >     >https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>> >     >     >
>>>> >     >     _______________________________________________
>>>> >     >     hibernate-dev mailing list
>>>> >     > hibernate-dev at lists.jboss.org
>>>> >     <mailto:hibernate-dev at lists.jboss.org>
>>>> >     <mailto:hibernate-dev at lists.jboss.org
>>>> >     <mailto:hibernate-dev at lists.jboss.org>>
>>>> >     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>> >     >
>>>> >
>>>> >     _______________________________________________
>>>> >     hibernate-dev mailing list
>>>> >     hibernate-dev at lists.jboss.org <mailto:
>>>> hibernate-dev at lists.jboss.org>
>>>> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>> >
>>>> >
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>

From christian.beikov at gmail.com  Fri Sep 23 13:40:58 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 23 Sep 2016 19:40:58 +0200
Subject: [hibernate-dev] HHH-9329
In-Reply-To: <CAFdSV9u=0j_PfSTZ1j_1Gf2G1Gq4etfOxLzgTje-fiCDzg4jyg@mail.gmail.com>
References: <ab465604-8834-14d3-aeba-86d9a5a78cf7@gmail.com>
	<CA+gWKMD2VXxx54Sa5ef4RqAyTmny1CX_zXxiXw=NAi7s3_XLoQ@mail.gmail.com>
	<CAFdSV9t92W043yBnQj4nA-X85DrXAG3hELkB_c5-V6PTq5+bUQ@mail.gmail.com>
	<1bbae282-698f-8617-52fa-c0e194567762@gmail.com>
	<CAFDzhiSzUzQP81Az5jz314ko7qVgi1RdHzLkdHnM+Y72Byx0oA@mail.gmail.com>
	<7f15bbe4-db8f-e88f-6618-6ed36a3c701a@gmail.com>
	<CAFdSV9sA5HuZ5vrN7=XXJMDOi=tWk+MKKTqKHs8omDhzEi4_fw@mail.gmail.com>
	<518972bf-7d0d-8ab7-2734-cc73ae93b1fe@gmail.com>
	<CAFdSV9tdzY47Az_wk-g7c-h=Oj3Wdczb7bfzTAG_F1hE6zCS5A@mail.gmail.com>
	<58706af7-e75c-66f0-0189-ceae80453ccf@gmail.com>
	<CAFdSV9ty7+56dzLwxaUQMeWORuoa070HjTUL1AiFCd0LFL=HVw@mail.gmail.com>
	<c82efe4b-827f-74d3-c394-a693c86f41cc@gmail.com>
	<CAFdSV9u=0j_PfSTZ1j_1Gf2G1Gq4etfOxLzgTje-fiCDzg4jyg@mail.gmail.com>
Message-ID: <6d3dd637-3be8-604b-6a58-c2eae6a14530@gmail.com>

Oh sorry, I assumed HHH-10707 not affecting me is implied ;P
No I am talking about the fix for HHH-9329 that I proposed.

Am 23.09.2016 um 19:36 schrieb Steve Ebersole:
> Well again we were just talking about HHH-10707 and you asked "will it 
> be integrated upstream"...
>
> I can tell by your reaction that you really were asking whether *your* 
> change would be integrated upstream, but that was not obviously from 
> your email :)
>
>
> On Fri, Sep 23, 2016 at 12:32 PM Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Is the fix I proposed in my
>     PR(https://github.com/hibernate/hibernate-orm/pull/1561)
>     non-compatible?
>     Did I miss discussion about that somewhere or didn't you have time
>     to review that yet?
>
>
>     Am 23.09.2016 um 18:50 schrieb Steve Ebersole:
>>     Depends on the "fix" we all agree on. Mainly whether that leads
>>     to any non-compatible SPI changes.
>>
>>
>>     On Fri, Sep 23, 2016 at 11:41 AM Christian Beikov
>>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>     wrote:
>>
>>         Ahh okay, I see. Sorry, I didn't fully read my previous mail
>>         and forgot I asked that question ^^
>>         Well then I'll try upgrading to 5.2 and hope for the best :)
>>
>>         So are you considering merging that to 5.2 then?
>>
>>
>>
>>         Am 23.09.2016 um 18:36 schrieb Steve Ebersole:
>>>         Nope.  You asked:
>>>
>>>         Are the problems with Hibernate 5.1+ and Infinispan fixed
>>>         yet? I didn't
>>>         consider upgrading yet because I read of some issues.
>>>
>>>         Now its possibly I misread your reference to
>>>         HIbernate+Infinispan problems to mean the only ones I know
>>>         of. hence the HHH-10707 reference.  If you meant some other
>>>         "Hibernate 5.1+ and Infinispan" problem, then I guess you
>>>         could have been more specific ;)
>>>
>>>
>>>
>>>         On Fri, Sep 23, 2016 at 11:33 AM Christian Beikov
>>>         <christian.beikov at gmail.com
>>>         <mailto:christian.beikov at gmail.com>> wrote:
>>>
>>>             Wrong thread?
>>>
>>>
>>>             Am 23.09.2016 um 17:53 schrieb Steve Ebersole:
>>>>             There are some conceptual mismatch problem that IMO
>>>>             stem from the L2C SPI.  We are discussing that all as
>>>>             part of https://hibernate.atlassian.net/browse/HHH-10707
>>>>
>>>>             Whether that affects you really depends how you
>>>>             configure caching.  If you try to reuse regions for
>>>>             different types of data (entity, collection, etc) then
>>>>             it will affect you.  If you define different access
>>>>             strategies for the same region then it will affect you.
>>>>
>>>>
>>>>             On Fri, Sep 23, 2016 at 1:02 AM Christian Beikov
>>>>             <christian.beikov at gmail.com
>>>>             <mailto:christian.beikov at gmail.com>> wrote:
>>>>
>>>>                 Well to be fair, I already reported that this
>>>>                 "regression" was
>>>>                 introduced in 4.2.8 by placing the ON predicate on
>>>>                 the target table join
>>>>                 instead of the collection table join as was done
>>>>                 before in 4.2.7.SP1.
>>>>                 I am not using 4.x anymore but since Wildfly ships
>>>>                 with Hibernate 5.0, I
>>>>                 suppose that others could benefit from this too.
>>>>                 Are the problems with Hibernate 5.1+ and Infinispan
>>>>                 fixed yet? I didn't
>>>>                 consider upgrading yet because I read of some issues.
>>>>
>>>>
>>>>                 Regards,
>>>>                 Christian
>>>>
>>>>                 Am 22.09.2016 um 22:10 schrieb Gail Badner:
>>>>                 > Hi Christian,
>>>>                 >
>>>>                 > We are only backporting critical issues and
>>>>                 regressions to 5.0 at this
>>>>                 > point, so it can't be backported to 5.0. If no
>>>>                 regressions caused by
>>>>                 > this fix are reported in 5.2, I would consider
>>>>                 backporting to 5.1.
>>>>                 >
>>>>                 > Regards,
>>>>                 > Gail
>>>>                 >
>>>>                 > On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov
>>>>                 > <christian.beikov at gmail.com
>>>>                 <mailto:christian.beikov at gmail.com>
>>>>                 <mailto:christian.beikov at gmail.com
>>>>                 <mailto:christian.beikov at gmail.com>>> wrote:
>>>>                 >
>>>>                 >     Thanks, I know that it's a beauty ^^
>>>>                 >     Hope this can get into all 5.x branches?
>>>>                 >
>>>>                 >     Regards,
>>>>                 >     Christian
>>>>                 >     Am 20.09.2016 um 23:05 schrieb Steve Ebersole:
>>>>                 >     > I took a quick look.  I'd prefer to see
>>>>                 better solution as we
>>>>                 >     migrate
>>>>                 >     > to SQM; but for 5.x, given how Hibernate
>>>>                 generates SQL there, I
>>>>                 >     am not
>>>>                 >     > sure how else you would possibly do this
>>>>                 >     >
>>>>                 >     >
>>>>                 >     > On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
>>>>                 >     > <mihalcea.vlad at gmail.com
>>>>                 <mailto:mihalcea.vlad at gmail.com>
>>>>                 <mailto:mihalcea.vlad at gmail.com
>>>>                 <mailto:mihalcea.vlad at gmail.com>>
>>>>                 >     <mailto:mihalcea.vlad at gmail.com
>>>>                 <mailto:mihalcea.vlad at gmail.com>
>>>>                 <mailto:mihalcea.vlad at gmail.com
>>>>                 <mailto:mihalcea.vlad at gmail.com>>>>
>>>>                 >     wrote:
>>>>                 >     >
>>>>                 >     >     Thanks,
>>>>                 >     >
>>>>                 >     >     I'm going to review it tomorrow.
>>>>                 >     >
>>>>                 >     >     Vlad
>>>>                 >     >
>>>>                 >     >     On Tue, Sep 20, 2016 at 8:38 PM,
>>>>                 Christian Beikov <
>>>>                 >     >christian.beikov at gmail.com
>>>>                 <mailto:christian.beikov at gmail.com>
>>>>                 <mailto:christian.beikov at gmail.com
>>>>                 <mailto:christian.beikov at gmail.com>>
>>>>                 >     <mailto:christian.beikov at gmail.com
>>>>                 <mailto:christian.beikov at gmail.com>
>>>>                 >     <mailto:christian.beikov at gmail.com
>>>>                 <mailto:christian.beikov at gmail.com>>>> wrote:
>>>>                 >     >
>>>>                 >     >     > Hey again,
>>>>                 >     >     >
>>>>                 >     >     > I implemented the approach that I
>>>>                 proposed in the issue and a
>>>>                 >     >     test in
>>>>                 >     >     >
>>>>                 https://github.com/hibernate/hibernate-orm/pull/1561
>>>>                 >   
>>>>                  <https://github.com/hibernate/hibernate-orm/pull/1561>
>>>>                 >     >     >
>>>>                 >     >     > It detects left joins with join
>>>>                 tables that use the target
>>>>                 >     table
>>>>                 >     >     alias.
>>>>                 >     >     > The join table is replaced with a
>>>>                 subquery and the WITH clause
>>>>                 >     >     is moved
>>>>                 >     >     > to the join of the subquery.
>>>>                 >     >     >
>>>>                 >     >     > Any comments?
>>>>                 >     >     >
>>>>                 >     >     > Regards,
>>>>                 >     >     > Christian
>>>>                 >     >     >
>>>>                 _______________________________________________
>>>>                 >     >     > hibernate-dev mailing list
>>>>                 >     >     > hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>
>>>>                 >     <mailto:hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>>
>>>>                 >     <mailto:hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>
>>>>                 >     <mailto:hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>>>
>>>>                 >     >   
>>>>                  >https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>                 >   
>>>>                  <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>>                 >     >     >
>>>>                 >     >
>>>>                  _______________________________________________
>>>>                 >     >     hibernate-dev mailing list
>>>>                 >     > hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>
>>>>                 >     <mailto:hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>>
>>>>                 >     <mailto:hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>
>>>>                 >     <mailto:hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>>>
>>>>                 >     >
>>>>                 https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>                 >   
>>>>                  <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>>                 >     >
>>>>                 >
>>>>                 >  _______________________________________________
>>>>                 >     hibernate-dev mailing list
>>>>                 > hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>
>>>>                 <mailto:hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>>
>>>>                 >
>>>>                 https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>                 >   
>>>>                  <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>>                 >
>>>>                 >
>>>>
>>>>                 _______________________________________________
>>>>                 hibernate-dev mailing list
>>>>                 hibernate-dev at lists.jboss.org
>>>>                 <mailto:hibernate-dev at lists.jboss.org>
>>>>                 https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>
>


From gbadner at redhat.com  Fri Sep 23 15:45:10 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 23 Sep 2016 12:45:10 -0700
Subject: [hibernate-dev] NativeQuery and parameters
In-Reply-To: <CAFdSV9vWa19zRukst73gpeniJZkTB8HwcoBkYauq9YApxWthzw@mail.gmail.com>
References: <CAFdSV9uKHXmCpNy9r58-sP6iP5dhRE=UrZpELV_gsos5o2zPOA@mail.gmail.com>
	<CA+nBocCxQkmohn3JogaMfoNCKs=hS4a_MwWo4t_gdp2ZRAL9Cg@mail.gmail.com>
	<CAFdSV9vY5DRRMHmz-WGsEfJyU2SbE+xg303s3oqtPq=bqw7jAw@mail.gmail.com>
	<CAFdSV9tPLm5prg-0Hx3FCzPavkaqbN82O6y3YXsGD5=0UzboAw@mail.gmail.com>
	<CAFdSV9vWa19zRukst73gpeniJZkTB8HwcoBkYauq9YApxWthzw@mail.gmail.com>
Message-ID: <CAFDzhiSLrcyfiFZ_Txmm_MgHfBEzA81oifGb20xjDA9yNgy54w@mail.gmail.com>

+1 to default of 1.

On Fri, Sep 23, 2016 at 8:50 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I did end up adding support for controlling this via a setting[1].  Now,
> when recognizing ordinal parameters (as distinct from positional
> parameters, i.e. ?1) we define the "base" as:
>
>    if ( factory.getSessionFactoryOptions().isJpaBootstrap() ) {
>       ordinalParameterBase = 1;
>    }
>    else {
>       final Integer configuredBase =
> factory.getSessionFactoryOptions().getNonJpaNativeQueryOrdinalPar
> ameterBase();
>       ordinalParameterBase = configuredBase == null
>             ? 0
>             : configuredBase;
>    }
>    ordinalParameterImplicitPosition = ordinalParameterBase;
>
>
> That
> `factory.getSessionFactoryOptions().getNonJpaNativeQueryOrdinalPar
> ameterBase()`
> call is driven by this setting.
>
> However back to the question of whether we want to go ahead and unify this
> base across the board (regardless of bootstrap method) to be 1 *by
> default*.  The difference is who needs to provide this setting... is it
> legacy apps upgrading to 6.0 that happen to use ordinal parameters?  or, is
> it apps that want the unified base?
>
> Essentially should it be:
>
> ordinalParameterBase = configuredBase == null ? 0 : configuredBase;
>
> or:
>
> ordinalParameterBase = configuredBase == null ? 1 : configuredBase;
>
> Personally I think it should be the latter.  It is pretty normal for legacy
> app upgrading to have to set some "use legacy behavior" flags.
>
> What do y'all think?
>
>
> [1] https://gist.github.com/sebersole/b13c11a9f7d55b84be6b4371e0259bc5
>
>
>
> On Wed, Sep 21, 2016 at 2:03 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > One additional thing we might consider is possibly unifying this 0- and
> 1-
> > based mismatch wrt JDBC-style parameters.
> >
> > In Hibernate's APIs these JDBC-style parameters were 0-based.  I have
> > already dropped support (it has been deprecated for a long time anyway)
> for
> > using JDBC-style params in HQL.  So this is now only a concern for native
> > queries.
> >
> > Interestingly JPA has the following to say (3.10.13 Positional
> Parameters):
> > <quote>
> > Only positional parameter binding ... may be portably used for native
> > queries... When binding the values of positional parameters, the
> numbering
> > starts as ?1?. It is assumed that for native queries the parameters
> > themselves use the SQL syntax (i.e., ???, rather than ??1?).
> > </quote>
> >
> > So for portable JPA, the native query would use JDBC/SQL syntax for the
> > parameter marker, but use the JPA convention for parameter index
> (1-based)
> > rather than the JDBC/SQL convention (0-based).
> >
> > As bassackwards as we may think JPA is here, it is a spec and we have to
> > support it: we have to support 1-based binding of these JDBC-style
> params.
> > The question is whether we should deviate from Hibernate's legacy
> decision
> > to align with JDBC/SQL (0-based) for binding of these JDBC-style params.
> > Perhaps a setting that controls how this should work - specifically
> limited
> > to JDBC-style param markers in native queries.  By default we'd honor the
> > 1-based approach whenever bootstrapping was done via JPA and 0-based when
> > native bootstrapping is used.  I guess what I am wondering is whether we
> > want to have a setting for the native bootstrapping piece that controls
> > whether to use 0-based or 1-based?  I do not think we should allow the
> > setting (if we add one) to force 0-based usage with JPA bootstrapping;
> this
> > would only control how it works in native bootstrapping.
> >
> > Thoughts?
> >
> > On Wed, Sep 21, 2016 at 1:40 PM Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> >> I never said anything about dropping support for named and positional
> >> parameters in native queries.
> >>
> >> I simply mentioned leveraging the new "JPA strict compliance" stuff I am
> >> adding to 6.0.  The idea is to allow you to enable that and get feedback
> >> when you use non-portable things.
> >>
> >>
> >> On Tue, Sep 20, 2016 at 11:45 PM Jordan Gigov <coladict at gmail.com>
> wrote:
> >>
> >>> Actually JPA defines it as "Only positional parameter binding and
> >>> positional access to result items may be portably used for native
> queries".
> >>> I believe "portably" means the providers are only required to support
> >>> positional, but not forbidden from supporting other.
> >>>
> >>> 2016-09-21 3:59 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
> >>>
> >>>> In the interest of questioning everything, just to make sure we are
> all
> >>>> on
> >>>> the same page, Hibernate's support for native SQL queries currently
> >>>> recognizes named parameters, positional parameters as well as
> JDBC-style
> >>>> parameters.
> >>>>
> >>>> JPA only defines support for "JDBC-style parameters" as valid for
> native
> >>>> SQL queries:
> >>>> {quote}
> >>>> It is assumed that for native queries the parameters themselves use
> the
> >>>> SQL
> >>>> syntax (i.e., ???, rather than ??1?).
> >>>> {quote}
> >>>>
> >>>> Furthermore Hibernate does not support a native query using both
> >>>> positional
> >>>> parameters and JDBC-style parameters in the same query because it
> >>>> causes a
> >>>> non-determinism wrt the positions.
> >>>>
> >>>> I assume we want to continue to support that full complement of
> >>>> parameter
> >>>> types, with the positional/JDBC-style caveat.
> >>>>
> >>>> Further I assume we will hook up the use of any non-JDBC-style
> >>>> parameters
> >>>> in with the "strict JPA compliance" checking and throw an error when
> >>>> indicated.
> >>>>
> >>>> Anyone have objections to any of that?
> >>>>
> >>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Tue Sep 27 10:28:49 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 27 Sep 2016 16:28:49 +0200
Subject: [hibernate-dev] Hibernate NoORM team meeting transcripts
Message-ID: <CALt0+o-UK_GgHZosKN3s5hxF9dmiKjY8oa8Q4vg8n-1VnT1HQQ@mail.gmail.com>

Hi everyone,

Here are the transcripts of this week's NoORM meeting:

16:26 < jbott> Meeting ended Tue Sep 27 14:26:18 2016 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:26 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-27-13.00.html
16:26 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-27-13.00.txt
16:26 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-27-13.00.log.html

-- 
Guillaume

From steve at hibernate.org  Tue Sep 27 20:15:23 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 28 Sep 2016 00:15:23 +0000
Subject: [hibernate-dev] ORM and Java 9
Message-ID: <CAFdSV9vFpizma3H249rSsoQN3DsoR_KSRGPy1AB7dY2B1DDQmw@mail.gmail.com>

It seems like Shigeru and team have Javassist Java 9 compatible now.  Per
https://issues.jboss.org/browse/JASSIST-261 I have played with the propsed
changes using a SNAPSHOT of that built and pushed by Scott.  Using that
SNAPSHOT, all those tests which used to fail due to Javassist now pass.

We do still have some failures under Java 9 which are now all attributable
to the version of WildFly we use for some Arquillian-based testing not
being Java 9 compatible.  But WildFly is now Java 9 compatible from what I
understand.  Anyone know if there is a WildFly 10 release yet that is Java
9 compatible?

From yoann at hibernate.org  Wed Sep 28 08:56:48 2016
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 28 Sep 2016 14:56:48 +0200
Subject: [hibernate-dev] HSEARCH-2358 "fields" attribute in Elasticsearch
 search results is being ignored
Message-ID: <CAEqagpo0Cw8TvRgJ7wGbRCAEcZdP2KgGNaEo0vCkzx2aym6r8g@mail.gmail.com>

Hi,

I wanted to start a discussion about this issue.

It's about stored field retrieval. When searching, Elasticsearch can return
field values two different ways:

 * through the "_source" attribute [1], which basically provides a
copy-paste of the JSON that was submitted when indexing
 * or through the "fields" attribute [2], which only works for stored
fields and provides the actual value that Elasticsearch stored

The main difference really boils down to formatting. With the "_source"
attribute, there's no formatting involved, you get exactly what was
originally submitted. With the "fields" attribute, the value is formatted
according to the first format in the mapping's format list [3].

The thing is, Elasticsearch allows admins to set multiple formats for a
given field. This won't change the output format, but will allow using any
one of these formats when submitting information. Since these "extra"
formats probably aren't understood by Hibernate Search, this means that
using the "_source" attribute to retrieve field values becomes unreliable
as soon as someone else adds/changes documents in Elasticsearch...

So we have two solutions:

 1. Either we only use the "fields" attribute to retrieve field values, and
we force users to have the output format set to something HSearch will
understand, but allow extra input formats.
 2. or we use the "_source" attribute to retrieve field values, and then we
force both output and input format on users, and do not allow extra formats.

I'd be in favor of 1, which seems more rational to me. It only has one
downside: if we go on with this approach, Calendar values (and
ZonedDateTime, ZonedTime, etc.) will have to be stored as String, not as
Date, since Elasticsearch doesn't store the timezone, just the UTC
timestamp. We're currently working this around by inspecting the "_source",
which contains the original timezone (since it's just the raw, originally
submitted JSON).

What do you think?

[1]
https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-source-field.html
[2]
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-fields.html
[3]
https://www.elastic.co/guide/en/elasticsearch/reference/2.4/mapping-date-format.html#custom-date-formats

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

From guillaume.smet at gmail.com  Wed Sep 28 09:23:57 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 28 Sep 2016 15:23:57 +0200
Subject: [hibernate-dev] HSEARCH-2358 "fields" attribute in
 Elasticsearch search results is being ignored
In-Reply-To: <CAEqagpo0Cw8TvRgJ7wGbRCAEcZdP2KgGNaEo0vCkzx2aym6r8g@mail.gmail.com>
References: <CAEqagpo0Cw8TvRgJ7wGbRCAEcZdP2KgGNaEo0vCkzx2aym6r8g@mail.gmail.com>
Message-ID: <CALt0+o-rLz6k6Lj0Opf2FObPzit47rEGRsB=Xp-z=djGZEpoxw@mail.gmail.com>

Hi Yoann,

On Wed, Sep 28, 2016 at 2:56 PM, Yoann Rodiere <yoann at hibernate.org> wrote:

> I'd be in favor of 1, which seems more rational to me. It only has one
> downside: if we go on with this approach, Calendar values (and
> ZonedDateTime, ZonedTime, etc.) will have to be stored as String, not as
> Date, since Elasticsearch doesn't store the timezone, just the UTC
> timestamp. We're currently working this around by inspecting the "_source",
> which contains the original timezone (since it's just the raw, originally
> submitted JSON).
>
> What do you think?
>

I'm not sure you completely understood the consequences of storing dates as
strings.

You won't be able to use these sorts of features:
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-datehistogram-aggregation.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-daterange-aggregation.html
which are used very often when dealing with dates.

I don't think storing dates as strings is a viable alternative.

IMHO, the choice is between:
- using _source as we currently do it. I'm not sure allowing people to
directly inject data into Elasticsearch and bypass Hibernate Search is
something we can support in the long run so I think it would be acceptable
if we document that we don't expect people to index documents directly (or
at least that they should carefully follow the HS indexing format - which
looks like an acceptable thing).
- using fields and be aware that we will get back UTC values from
projections on these fields

-- 
Guillaume

From yoann at hibernate.org  Wed Sep 28 10:07:26 2016
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 28 Sep 2016 16:07:26 +0200
Subject: [hibernate-dev] HSEARCH-2358 "fields" attribute in
 Elasticsearch search results is being ignored
In-Reply-To: <CALt0+o-rLz6k6Lj0Opf2FObPzit47rEGRsB=Xp-z=djGZEpoxw@mail.gmail.com>
References: <CAEqagpo0Cw8TvRgJ7wGbRCAEcZdP2KgGNaEo0vCkzx2aym6r8g@mail.gmail.com>
	<CALt0+o-rLz6k6Lj0Opf2FObPzit47rEGRsB=Xp-z=djGZEpoxw@mail.gmail.com>
Message-ID: <CAEqagpoLAghfpmzOeGszz+wH6k=T__=-kF0c-_C64LvLDCAdsA@mail.gmail.com>

On 28 September 2016 at 15:23, Guillaume Smet <guillaume.smet at gmail.com>
wrote:
>
> You won't be able to use these sorts of features:
> https://www.elastic.co/guide/en/elasticsearch/reference/curr
> ent/search-aggregations-bucket-datehistogram-aggregation.html
> https://www.elastic.co/guide/en/elasticsearch/reference/curr
> ent/search-aggregations-bucket-daterange-aggregation.html
> which are used very often when dealing with dates.
>
> I don't think storing dates as strings is a viable alternative.
>

Right. I didn't know about these.


> IMHO, the choice is between:
> - using _source as we currently do it. I'm not sure allowing people to
> directly inject data into Elasticsearch and bypass Hibernate Search is
> something we can support in the long run so I think it would be acceptable
> if we document that we don't expect people to index documents directly (or
> at least that they should carefully follow the HS indexing format - which
> looks like an acceptable thing).
> - using fields and be aware that we will get back UTC values from
> projections on these fields
>

... and the latter is a no-go for ZonedDate et al., since the point of
those classes is to preserve timezone/offset.
Maybe we could just use "_source" when we really need to, but I doubt
there's an elegant way to do this, so I guess we'd better not.

Anyway, it seems we're down to only one acceptable solution... Unless
anyone has another view on all this, I'll index ZonedDate/etc. as dates and
use "_source" for value retrieval, and I'll close HSEARCH-2358 as "Won't
fix".

Thanks for the insight!

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

From christian.beikov at gmail.com  Thu Sep 29 08:28:28 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 29 Sep 2016 14:28:28 +0200
Subject: [hibernate-dev] PR for HQLPARSER-15
Message-ID: <514d6c1b-fd1c-0a7b-b4ee-4d06b74e31c2@gmail.com>

Hello,

I prepared another PR for a very old issue: 
https://github.com/hibernate/hibernate-orm/pull/1577
The PR contains a testcase and the fix for the 
issue(https://hibernate.atlassian.net/browse/HQLPARSER-15)

Regards,
Christian

From w.schoenborn at gmail.com  Thu Sep 29 08:43:28 2016
From: w.schoenborn at gmail.com (=?UTF-8?Q?Willi_Sch=C3=B6nborn?=)
Date: Thu, 29 Sep 2016 14:43:28 +0200
Subject: [hibernate-dev] Money Validation
Message-ID: <CAA46BD=hrqMf2wdjpyDAaPBgzn6SoKoXB2HAY=qP9DpkscST2A@mail.gmail.com>

Hi,

I'm currently preparing a pull request to contribute Java Money related
validators to HV:
https://github.com/zalando/money-validation

The main part are custom validators to add support for MonetaryAmount to
the following constraints:

   - DecimalMax
   - DecimalMin
   - Max
   - Min

As an addition we defined the following custom constraints:

   - Negative
   - NegativeOrZero
   - Positive
   - PositiveOrZero
   - Zero

Their names are closely aligned to methods in MonetaryAmount, but they are
in fact built solely on top of the standard constraints DecimalMax and
DecimalMin. So in theory somebody can use those with int, longs,
BigDecimals, BigInteger, CharSequence, ... You get the idea.

My question now is, are you guys interested in those custom constraints as
well or should I limit my pull request to the validators for MonetaryAmount?

Best,
Willi

From smarlow at redhat.com  Thu Sep 29 09:46:38 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 29 Sep 2016 09:46:38 -0400
Subject: [hibernate-dev] ORM and Java 9
In-Reply-To: <CAFdSV9vFpizma3H249rSsoQN3DsoR_KSRGPy1AB7dY2B1DDQmw@mail.gmail.com>
References: <CAFdSV9vFpizma3H249rSsoQN3DsoR_KSRGPy1AB7dY2B1DDQmw@mail.gmail.com>
Message-ID: <46fd3dcd-cc8d-be66-a50a-203a72d7a504@redhat.com>



On 09/27/2016 08:15 PM, Steve Ebersole wrote:
> It seems like Shigeru and team have Javassist Java 9 compatible now.  Per
> https://issues.jboss.org/browse/JASSIST-261 I have played with the propsed
> changes using a SNAPSHOT of that built and pushed by Scott.  Using that
> SNAPSHOT, all those tests which used to fail due to Javassist now pass.

I'd really like to get this working with ORM 5.1, since that is what we 
want to upgrade WildFly 11 to use.  The best idea that I have for that 
would be via a Javassist 3.18.3-GA that would contain a backport of the 
https://github.com/jboss-javassist/javassist/tree/test/java9-jigsaw 
changes (which means that we would need to build 3.18.3-GA with the JDK9 
EA javac.)

I'm not sure if we have enough time to do this (Javassist) backport but 
if that is the best way to get ORM 5.1 working with JDK9, we could do 
the work, when we find the time.  This would likely be after Java9 
stabilizes.

Thoughts?

>
> We do still have some failures under Java 9 which are now all attributable
> to the version of WildFly we use for some Arquillian-based testing not
> being Java 9 compatible.  But WildFly is now Java 9 compatible from what I
> understand.  Anyone know if there is a WildFly 10 release yet that is Java
> 9 compatible?

As discussed on IRC, not yet, as Java 9 is still changing.  There is a 
nightly build WildFly build that produces a zip [1].

Scott

[1] 
https://ci.wildfly.org/repository/download/WF_Nightly/latest.lastSuccessful/wildfly-11.0.0.Alpha1-SNAPSHOT.zip

From sanne at hibernate.org  Thu Sep 29 09:54:33 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 29 Sep 2016 14:54:33 +0100
Subject: [hibernate-dev] ORM and Java 9
In-Reply-To: <46fd3dcd-cc8d-be66-a50a-203a72d7a504@redhat.com>
References: <CAFdSV9vFpizma3H249rSsoQN3DsoR_KSRGPy1AB7dY2B1DDQmw@mail.gmail.com>
	<46fd3dcd-cc8d-be66-a50a-203a72d7a504@redhat.com>
Message-ID: <CAFm4XO1cCGPFcng=jfg6yWOkyeRvZfrR7x+aOj9vx2UbNqSUxA@mail.gmail.com>

Hi Steve,

In Search and OGM we simply skip the Wildfly integration tests when running
on Java 9.

Sanne

On 29 Sep 2016 14:49, "Scott Marlow" <smarlow at redhat.com> wrote:

>
>
> On 09/27/2016 08:15 PM, Steve Ebersole wrote:
> > It seems like Shigeru and team have Javassist Java 9 compatible now.  Per
> > https://issues.jboss.org/browse/JASSIST-261 I have played with the
> propsed
> > changes using a SNAPSHOT of that built and pushed by Scott.  Using that
> > SNAPSHOT, all those tests which used to fail due to Javassist now pass.
>
> I'd really like to get this working with ORM 5.1, since that is what we
> want to upgrade WildFly 11 to use.  The best idea that I have for that
> would be via a Javassist 3.18.3-GA that would contain a backport of the
> https://github.com/jboss-javassist/javassist/tree/test/java9-jigsaw
> changes (which means that we would need to build 3.18.3-GA with the JDK9
> EA javac.)
>
> I'm not sure if we have enough time to do this (Javassist) backport but
> if that is the best way to get ORM 5.1 working with JDK9, we could do
> the work, when we find the time.  This would likely be after Java9
> stabilizes.
>
> Thoughts?
>
> >
> > We do still have some failures under Java 9 which are now all
> attributable
> > to the version of WildFly we use for some Arquillian-based testing not
> > being Java 9 compatible.  But WildFly is now Java 9 compatible from what
> I
> > understand.  Anyone know if there is a WildFly 10 release yet that is
> Java
> > 9 compatible?
>
> As discussed on IRC, not yet, as Java 9 is still changing.  There is a
> nightly build WildFly build that produces a zip [1].
>
> Scott
>
> [1]
> https://ci.wildfly.org/repository/download/WF_
> Nightly/latest.lastSuccessful/wildfly-11.0.0.Alpha1-SNAPSHOT.zip
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Sep 29 10:03:20 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 29 Sep 2016 14:03:20 +0000
Subject: [hibernate-dev] ORM and Java 9
In-Reply-To: <CAFm4XO1cCGPFcng=jfg6yWOkyeRvZfrR7x+aOj9vx2UbNqSUxA@mail.gmail.com>
References: <CAFdSV9vFpizma3H249rSsoQN3DsoR_KSRGPy1AB7dY2B1DDQmw@mail.gmail.com>
	<46fd3dcd-cc8d-be66-a50a-203a72d7a504@redhat.com>
	<CAFm4XO1cCGPFcng=jfg6yWOkyeRvZfrR7x+aOj9vx2UbNqSUxA@mail.gmail.com>
Message-ID: <CAFdSV9trYWg1K6qS7fP6ba2_vzZ_56Y+t+C4OjZEF3JgqZZ6Jg@mail.gmail.com>

Sanne, sure.  But that sucks.  Because its not just "WF integration" we are
testing.  We also use that as the basis for testing how Hibernate works in
various in-container scenarios (CDI, BV, etc) which are not WF-specific.

So, at the moment I cannot begin to tell you, e.g., whether Hibernate's CDI
or BV integration work under Java 9...



On Thu, Sep 29, 2016 at 8:54 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Steve,
>
> In Search and OGM we simply skip the Wildfly integration tests when
> running on Java 9.
>
> Sanne
>
> On 29 Sep 2016 14:49, "Scott Marlow" <smarlow at redhat.com> wrote:
>
>>
>>
>> On 09/27/2016 08:15 PM, Steve Ebersole wrote:
>> > It seems like Shigeru and team have Javassist Java 9 compatible now.
>> Per
>> > https://issues.jboss.org/browse/JASSIST-261 I have played with the
>> propsed
>> > changes using a SNAPSHOT of that built and pushed by Scott.  Using that
>> > SNAPSHOT, all those tests which used to fail due to Javassist now pass.
>>
>> I'd really like to get this working with ORM 5.1, since that is what we
>> want to upgrade WildFly 11 to use.  The best idea that I have for that
>> would be via a Javassist 3.18.3-GA that would contain a backport of the
>> https://github.com/jboss-javassist/javassist/tree/test/java9-jigsaw
>> changes (which means that we would need to build 3.18.3-GA with the JDK9
>> EA javac.)
>>
>> I'm not sure if we have enough time to do this (Javassist) backport but
>> if that is the best way to get ORM 5.1 working with JDK9, we could do
>> the work, when we find the time.  This would likely be after Java9
>> stabilizes.
>>
>> Thoughts?
>>
>> >
>> > We do still have some failures under Java 9 which are now all
>> attributable
>> > to the version of WildFly we use for some Arquillian-based testing not
>> > being Java 9 compatible.  But WildFly is now Java 9 compatible from
>> what I
>> > understand.  Anyone know if there is a WildFly 10 release yet that is
>> Java
>> > 9 compatible?
>>
>> As discussed on IRC, not yet, as Java 9 is still changing.  There is a
>> nightly build WildFly build that produces a zip [1].
>>
>> Scott
>>
>> [1]
>>
>> https://ci.wildfly.org/repository/download/WF_Nightly/latest.lastSuccessful/wildfly-11.0.0.Alpha1-SNAPSHOT.zip
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gunnar at hibernate.org  Thu Sep 29 13:46:02 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 29 Sep 2016 19:46:02 +0200
Subject: [hibernate-dev] Money Validation
In-Reply-To: <CAA46BD=hrqMf2wdjpyDAaPBgzn6SoKoXB2HAY=qP9DpkscST2A@mail.gmail.com>
References: <CAA46BD=hrqMf2wdjpyDAaPBgzn6SoKoXB2HAY=qP9DpkscST2A@mail.gmail.com>
Message-ID: <CADGJaX_ANb99_ihoVg326DrrwK-CBocHro+mdfy7tsjqJznPkQ@mail.gmail.com>

Hi Willi,

My preference would be to limit the first round to the actual javax.money
stuff.

We are running a survey currently at
http://beanvalidation.org/news/2016/09/15/which-constraints-to-add/ asking
whether to add @Negative/@Positive. Based on that we need to decide whether
to add them to the spec, or - if not - to HV. On the others I'm not so
sure, they don't seem to add too much IMHO.

Cheers,

--Gunnar


2016-09-29 14:43 GMT+02:00 Willi Sch?nborn <w.schoenborn at gmail.com>:

> Hi,
>
> I'm currently preparing a pull request to contribute Java Money related
> validators to HV:
> https://github.com/zalando/money-validation
>
> The main part are custom validators to add support for MonetaryAmount to
> the following constraints:
>
>    - DecimalMax
>    - DecimalMin
>    - Max
>    - Min
>
> As an addition we defined the following custom constraints:
>
>    - Negative
>    - NegativeOrZero
>    - Positive
>    - PositiveOrZero
>    - Zero
>
> Their names are closely aligned to methods in MonetaryAmount, but they are
> in fact built solely on top of the standard constraints DecimalMax and
> DecimalMin. So in theory somebody can use those with int, longs,
> BigDecimals, BigInteger, CharSequence, ... You get the idea.
>
> My question now is, are you guys interested in those custom constraints as
> well or should I limit my pull request to the validators for
> MonetaryAmount?
>
> Best,
> Willi
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From andrea at hibernate.org  Fri Sep 30 03:40:36 2016
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 30 Sep 2016 08:40:36 +0100
Subject: [hibernate-dev] Starting 5.2.3 release
Message-ID: <CAL00eSTBSGOGKU4e-CEMsQ9E+fC+_GgF8=0sFkzvJ=GeFLN9LQ@mail.gmail.com>

Please do not push anything to master branch.

Thanks,

Andrea

From andrea at hibernate.org  Fri Sep 30 08:41:58 2016
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 30 Sep 2016 13:41:58 +0100
Subject: [hibernate-dev] Starting 5.2.3 release
Message-ID: <CAL00eSSUU-KhTXJYYSO81XMQN5Mmgoa7GhOrE30Ot7F2Gk7c_A@mail.gmail.com>

Due to troubles with my Nexus account the release is not yet completed
anyway It's now possible to push to master.

From steve at hibernate.org  Fri Sep 30 10:11:54 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 30 Sep 2016 14:11:54 +0000
Subject: [hibernate-dev] Dialect#remapSqlTypeDescriptor
Message-ID: <CAFdSV9st561i-CVrtp+iBVV0kBmn4C8Lq_JJrFe0Afyq+G=29g@mail.gmail.com>

TLDR: Should we adjust to allow Dialect to know the "context" of where the
remapping is requested?

Ah Oracle...

So this comes from the fact that Oracle does not support a BOOLEAN
datatype.  Well kind of.  It does not support a BOOLEAN datatype in its
"SQL engine".  However, in PL/SQL it does in fact support a BOOLEAN
datatype.  Which comes into play when we talk about calling functions and
procedures: the arguments and returns can in fact be a BOOLEAN.

As far as I know, Oracle is the only database with this type of
inconsistency in its type system.  But the question is whether we want to
pass along some kind of information regarding the context (SQL v function v
procedure) to the Dialect#remapSqlTypeDescriptor.

You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an
illustration of how this impacts applications.  And if you look through the
comments you can see the kind-of-crazy workaround needed.

From andrea at hibernate.org  Fri Sep 30 10:45:55 2016
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 30 Sep 2016 15:45:55 +0100
Subject: [hibernate-dev] Dialect#remapSqlTypeDescriptor
In-Reply-To: <CAFdSV9st561i-CVrtp+iBVV0kBmn4C8Lq_JJrFe0Afyq+G=29g@mail.gmail.com>
References: <CAFdSV9st561i-CVrtp+iBVV0kBmn4C8Lq_JJrFe0Afyq+G=29g@mail.gmail.com>
Message-ID: <CAL00eSSy5aUkeVAJBOpL8zwri+SMkXYo1Fah4uag7_8fcUfaQw@mail.gmail.com>

reading the jira comments I think yes we should.

On 30 September 2016 at 15:11, Steve Ebersole <steve at hibernate.org> wrote:

> TLDR: Should we adjust to allow Dialect to know the "context" of where the
> remapping is requested?
>
> Ah Oracle...
>
> So this comes from the fact that Oracle does not support a BOOLEAN
> datatype.  Well kind of.  It does not support a BOOLEAN datatype in its
> "SQL engine".  However, in PL/SQL it does in fact support a BOOLEAN
> datatype.  Which comes into play when we talk about calling functions and
> procedures: the arguments and returns can in fact be a BOOLEAN.
>
> As far as I know, Oracle is the only database with this type of
> inconsistency in its type system.  But the question is whether we want to
> pass along some kind of information regarding the context (SQL v function v
> procedure) to the Dialect#remapSqlTypeDescriptor.
>
> You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an
> illustration of how this impacts applications.  And if you look through the
> comments you can see the kind-of-crazy workaround needed.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Sep 30 12:02:16 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 30 Sep 2016 16:02:16 +0000
Subject: [hibernate-dev] mixing named and positional parameters
Message-ID: <CAFdSV9vSxd7yw69FK798Ej1ngvE89USXwngaEywB3Su0JSu5dw@mail.gmail.com>

The JPA spec specifically says:

<quote>
Either positional or named parameters may be used. Positional and named
parameters must not be mixed in a single query.
</quote>

I was thinking about how it does not make sense to mix these in a query
(its confusing) and went looking to see what, if anything, the spec had to
say on the subject.  Which is when I found that passage.

Currently we do not validate this one way or the other.  But I think we
ought to start.  The only real question is whether to make this an
exception all the time, or just when strict-JPA-compliance is requested.
Personally I vote for always disallowing this (like I said, I find it
confusing), but would like to get other's thoughts.

From andrea at hibernate.org  Fri Sep 30 12:06:53 2016
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 30 Sep 2016 17:06:53 +0100
Subject: [hibernate-dev] mixing named and positional parameters
In-Reply-To: <CAFdSV9vSxd7yw69FK798Ej1ngvE89USXwngaEywB3Su0JSu5dw@mail.gmail.com>
References: <CAFdSV9vSxd7yw69FK798Ej1ngvE89USXwngaEywB3Su0JSu5dw@mail.gmail.com>
Message-ID: <CAL00eSSBrF1BoFZQCz+6_+MMxru6xbJ846L8PhC4vtMN++nC0g@mail.gmail.com>

+1 for always disallowing

On 30 September 2016 at 17:02, Steve Ebersole <steve at hibernate.org> wrote:

> The JPA spec specifically says:
>
> <quote>
> Either positional or named parameters may be used. Positional and named
> parameters must not be mixed in a single query.
> </quote>
>
> I was thinking about how it does not make sense to mix these in a query
> (its confusing) and went looking to see what, if anything, the spec had to
> say on the subject.  Which is when I found that passage.
>
> Currently we do not validate this one way or the other.  But I think we
> ought to start.  The only real question is whether to make this an
> exception all the time, or just when strict-JPA-compliance is requested.
> Personally I vote for always disallowing this (like I said, I find it
> confusing), but would like to get other's thoughts.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From davide at hibernate.org  Fri Sep 30 13:39:04 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Fri, 30 Sep 2016 18:39:04 +0100
Subject: [hibernate-dev] mixing named and positional parameters
In-Reply-To: <CAL00eSSBrF1BoFZQCz+6_+MMxru6xbJ846L8PhC4vtMN++nC0g@mail.gmail.com>
References: <CAFdSV9vSxd7yw69FK798Ej1ngvE89USXwngaEywB3Su0JSu5dw@mail.gmail.com>
	<CAL00eSSBrF1BoFZQCz+6_+MMxru6xbJ846L8PhC4vtMN++nC0g@mail.gmail.com>
Message-ID: <CANoTJYO+ODwT5SMyL+ubFD8WAAY29Zz2pSO4=ysY5F-pxn+ABg@mail.gmail.com>

+1 for always disallowing

On Fri, Sep 30, 2016 at 5:06 PM, andrea boriero <andrea at hibernate.org> wrote:
> +1 for always disallowing
>
> On 30 September 2016 at 17:02, Steve Ebersole <steve at hibernate.org> wrote:
>
>> The JPA spec specifically says:
>>
>> <quote>
>> Either positional or named parameters may be used. Positional and named
>> parameters must not be mixed in a single query.
>> </quote>
>>
>> I was thinking about how it does not make sense to mix these in a query
>> (its confusing) and went looking to see what, if anything, the spec had to
>> say on the subject.  Which is when I found that passage.
>>
>> Currently we do not validate this one way or the other.  But I think we
>> ought to start.  The only real question is whether to make this an
>> exception all the time, or just when strict-JPA-compliance is requested.
>> Personally I vote for always disallowing this (like I said, I find it
>> confusing), but would like to get other's thoughts.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Fri Sep 30 13:54:30 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 30 Sep 2016 20:54:30 +0300
Subject: [hibernate-dev] mixing named and positional parameters
In-Reply-To: <CAFdSV9vSxd7yw69FK798Ej1ngvE89USXwngaEywB3Su0JSu5dw@mail.gmail.com>
References: <CAFdSV9vSxd7yw69FK798Ej1ngvE89USXwngaEywB3Su0JSu5dw@mail.gmail.com>
Message-ID: <CA+gWKMD8u+DyQfMZ_woHoqpuiwAYrQ4iQhAP9oLtczagL4_8dA@mail.gmail.com>

+1

On Fri, Sep 30, 2016 at 7:02 PM, Steve Ebersole <steve at hibernate.org> wrote:

> The JPA spec specifically says:
>
> <quote>
> Either positional or named parameters may be used. Positional and named
> parameters must not be mixed in a single query.
> </quote>
>
> I was thinking about how it does not make sense to mix these in a query
> (its confusing) and went looking to see what, if anything, the spec had to
> say on the subject.  Which is when I found that passage.
>
> Currently we do not validate this one way or the other.  But I think we
> ought to start.  The only real question is whether to make this an
> exception all the time, or just when strict-JPA-compliance is requested.
> Personally I vote for always disallowing this (like I said, I find it
> confusing), but would like to get other's thoughts.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Fri Sep 30 13:57:55 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 30 Sep 2016 20:57:55 +0300
Subject: [hibernate-dev] Dialect#remapSqlTypeDescriptor
In-Reply-To: <CAFdSV9st561i-CVrtp+iBVV0kBmn4C8Lq_JJrFe0Afyq+G=29g@mail.gmail.com>
References: <CAFdSV9st561i-CVrtp+iBVV0kBmn4C8Lq_JJrFe0Afyq+G=29g@mail.gmail.com>
Message-ID: <CA+gWKMDF+DpTxp+y7d0ig+Sb-SZqd4PdTBs17H_YiKHGtHi5vA@mail.gmail.com>

I also consider that we should provide info so that we can properly map the
Boolean type according to the expected SQL type.
Especially since we have revamped the support for Stored procedures and
functions.

Vlad

On Fri, Sep 30, 2016 at 5:11 PM, Steve Ebersole <steve at hibernate.org> wrote:

> TLDR: Should we adjust to allow Dialect to know the "context" of where the
> remapping is requested?
>
> Ah Oracle...
>
> So this comes from the fact that Oracle does not support a BOOLEAN
> datatype.  Well kind of.  It does not support a BOOLEAN datatype in its
> "SQL engine".  However, in PL/SQL it does in fact support a BOOLEAN
> datatype.  Which comes into play when we talk about calling functions and
> procedures: the arguments and returns can in fact be a BOOLEAN.
>
> As far as I know, Oracle is the only database with this type of
> inconsistency in its type system.  But the question is whether we want to
> pass along some kind of information regarding the context (SQL v function v
> procedure) to the Dialect#remapSqlTypeDescriptor.
>
> You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an
> illustration of how this impacts applications.  And if you look through the
> comments you can see the kind-of-crazy workaround needed.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Sep 30 20:02:37 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 01 Oct 2016 00:02:37 +0000
Subject: [hibernate-dev] Dialect#remapSqlTypeDescriptor
In-Reply-To: <CA+gWKMDF+DpTxp+y7d0ig+Sb-SZqd4PdTBs17H_YiKHGtHi5vA@mail.gmail.com>
References: <CAFdSV9st561i-CVrtp+iBVV0kBmn4C8Lq_JJrFe0Afyq+G=29g@mail.gmail.com>
	<CA+gWKMDF+DpTxp+y7d0ig+Sb-SZqd4PdTBs17H_YiKHGtHi5vA@mail.gmail.com>
Message-ID: <CAFdSV9ux41VH=jJdjOt9p94_oTYRnAEPU19EXiE_wbUKf2+Okw@mail.gmail.com>

We may be able to look at the procedures Metadata from CallableStatement.
I forget the exact details of how it reports the argument types, especially
for Oracle specifcally

On Fri, Sep 30, 2016, 12:57 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I also consider that we should provide info so that we can properly map
> the Boolean type according to the expected SQL type.
> Especially since we have revamped the support for Stored procedures and
> functions.
>
> Vlad
> On Fri, Sep 30, 2016 at 5:11 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> TLDR: Should we adjust to allow Dialect to know the "context" of where the
>> remapping is requested?
>>
>> Ah Oracle...
>>
>> So this comes from the fact that Oracle does not support a BOOLEAN
>> datatype.  Well kind of.  It does not support a BOOLEAN datatype in its
>> "SQL engine".  However, in PL/SQL it does in fact support a BOOLEAN
>> datatype.  Which comes into play when we talk about calling functions and
>> procedures: the arguments and returns can in fact be a BOOLEAN.
>>
>> As far as I know, Oracle is the only database with this type of
>> inconsistency in its type system.  But the question is whether we want to
>> pass along some kind of information regarding the context (SQL v function
>> v
>> procedure) to the Dialect#remapSqlTypeDescriptor.
>>
>> You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an
>> illustration of how this impacts applications.  And if you look through
>> the
>> comments you can see the kind-of-crazy workaround needed.
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Fri Sep 30 20:10:37 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 01 Oct 2016 00:10:37 +0000
Subject: [hibernate-dev] Dialect#remapSqlTypeDescriptor
In-Reply-To: <CAFdSV9ux41VH=jJdjOt9p94_oTYRnAEPU19EXiE_wbUKf2+Okw@mail.gmail.com>
References: <CAFdSV9st561i-CVrtp+iBVV0kBmn4C8Lq_JJrFe0Afyq+G=29g@mail.gmail.com>
	<CA+gWKMDF+DpTxp+y7d0ig+Sb-SZqd4PdTBs17H_YiKHGtHi5vA@mail.gmail.com>
	<CAFdSV9ux41VH=jJdjOt9p94_oTYRnAEPU19EXiE_wbUKf2+Okw@mail.gmail.com>
Message-ID: <CAFdSV9vo+YPJ-pQiNRe-SFLeG9q2igG1qUK9y4eQ=aMEer3v5w@mail.gmail.com>

Specifically, does anyone know how Oracle driver
reports ParameterMetaData#getParameterType for CallableStatement arguments
that are defined as PL/SQL BOOLEAN types?

On Fri, Sep 30, 2016 at 7:02 PM Steve Ebersole <steve at hibernate.org> wrote:

> We may be able to look at the procedures Metadata from CallableStatement.
> I forget the exact details of how it reports the argument types, especially
> for Oracle specifcally
>
> On Fri, Sep 30, 2016, 12:57 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
> I also consider that we should provide info so that we can properly map
> the Boolean type according to the expected SQL type.
> Especially since we have revamped the support for Stored procedures and
> functions.
>
> Vlad
> On Fri, Sep 30, 2016 at 5:11 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> TLDR: Should we adjust to allow Dialect to know the "context" of where the
> remapping is requested?
>
> Ah Oracle...
>
> So this comes from the fact that Oracle does not support a BOOLEAN
> datatype.  Well kind of.  It does not support a BOOLEAN datatype in its
> "SQL engine".  However, in PL/SQL it does in fact support a BOOLEAN
> datatype.  Which comes into play when we talk about calling functions and
> procedures: the arguments and returns can in fact be a BOOLEAN.
>
> As far as I know, Oracle is the only database with this type of
> inconsistency in its type system.  But the question is whether we want to
> pass along some kind of information regarding the context (SQL v function v
> procedure) to the Dialect#remapSqlTypeDescriptor.
>
> You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an
> illustration of how this impacts applications.  And if you look through the
> comments you can see the kind-of-crazy workaround needed.
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Fri Sep 30 23:19:07 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 01 Oct 2016 03:19:07 +0000
Subject: [hibernate-dev] Dialect#remapSqlTypeDescriptor
In-Reply-To: <CAFdSV9vo+YPJ-pQiNRe-SFLeG9q2igG1qUK9y4eQ=aMEer3v5w@mail.gmail.com>
References: <CAFdSV9st561i-CVrtp+iBVV0kBmn4C8Lq_JJrFe0Afyq+G=29g@mail.gmail.com>
	<CA+gWKMDF+DpTxp+y7d0ig+Sb-SZqd4PdTBs17H_YiKHGtHi5vA@mail.gmail.com>
	<CAFdSV9ux41VH=jJdjOt9p94_oTYRnAEPU19EXiE_wbUKf2+Okw@mail.gmail.com>
	<CAFdSV9vo+YPJ-pQiNRe-SFLeG9q2igG1qUK9y4eQ=aMEer3v5w@mail.gmail.com>
Message-ID: <CAFdSV9t9vSU8p2WAAto7Qey8yDBc4LtkPSzKb64hXQkd=m_zhg@mail.gmail.com>

Actually I am finding a lot of references online that calling Oracle
procs/functions that define PL/SQL BOOLEAN arguments/returns cannot be done
via CallableStatement.  This is going to take some investigation.

On Fri, Sep 30, 2016 at 7:10 PM Steve Ebersole <steve at hibernate.org> wrote:

> Specifically, does anyone know how Oracle driver
> reports ParameterMetaData#getParameterType for CallableStatement arguments
> that are defined as PL/SQL BOOLEAN types?
>
> On Fri, Sep 30, 2016 at 7:02 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> We may be able to look at the procedures Metadata from CallableStatement.
> I forget the exact details of how it reports the argument types, especially
> for Oracle specifcally
>
> On Fri, Sep 30, 2016, 12:57 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
> I also consider that we should provide info so that we can properly map
> the Boolean type according to the expected SQL type.
> Especially since we have revamped the support for Stored procedures and
> functions.
>
> Vlad
> On Fri, Sep 30, 2016 at 5:11 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> TLDR: Should we adjust to allow Dialect to know the "context" of where the
> remapping is requested?
>
> Ah Oracle...
>
> So this comes from the fact that Oracle does not support a BOOLEAN
> datatype.  Well kind of.  It does not support a BOOLEAN datatype in its
> "SQL engine".  However, in PL/SQL it does in fact support a BOOLEAN
> datatype.  Which comes into play when we talk about calling functions and
> procedures: the arguments and returns can in fact be a BOOLEAN.
>
> As far as I know, Oracle is the only database with this type of
> inconsistency in its type system.  But the question is whether we want to
> pass along some kind of information regarding the context (SQL v function v
> procedure) to the Dialect#remapSqlTypeDescriptor.
>
> You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an
> illustration of how this impacts applications.  And if you look through the
> comments you can see the kind-of-crazy workaround needed.
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>