[hibernate-dev] Master

[Sanne Grinovero]

On 15 April 2016 at 17:10, Steve Ebersole <steve at hibernate.org> wrote:
> That's not the intent.  Users do deal with Session or StatelessSession.
> SharedSessionContract simply exists as a convenience for us to make sure
> Session and StatelessSession implement some of the same signatures.

Ok, I got it know. Sorry I had interpreted the opposite, just returned
from a flight late night and I'm a bit confused I'm afraid :)

Looks good then!

>
> Now, if you are talking about the *Implementor forms those are the same as
> any of the other *Implementor interfaces used throughout Hibernate.  They
> extend the public API with additional capabilities needed internally.  A
> user would never directly use a SharedSessionContract, a
> SharedSessionContract Implementor, a SessionImplementor, etc.
>
> I am asking this question because it has an impact on integrations (which is
> expected, it's an SPI) not users
>
>
> On Fri, Apr 15, 2016, 9:46 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Do you have a practical need for SharedSessionContract and
>> SharedSessionContractImplementor to exist within the internal
>> contracts of ORM?
>>
>> As a general rule, I don't mind having implementations which implement
>> multiple interfaces.
>>
>> Assuming you need these as a convenience for internal helpers, then
>> I'd propose to treat these as internal interfaces rather than APIs or
>> SPIs. For example, have users deal just with "Session" and
>> "StatelessSession" and not need learning (nor bothering) with more
>> stuff.
>>
>> my 2 cents.. not a strong opinion.
>> Sanne
>>
>>
>> On 15 April 2016 at 15:30, Steve Ebersole <steve at hibernate.org> wrote:
>> > So here is what I ended up doing, with one questionable decision which
>> > I'll
>> > highlight below.
>> >
>> > First, the existing situation...  We have Session and StatelessSession
>> > which
>> > are largely independent contracts.  There is a "shared" bit that is
>> > represented by an interface SharedSessionContract.  There is also a
>> > SessionImplementor contract.  Now previously a SessionImplementor could
>> > be a
>> > Session or a StatelessSession; very poorly named.
>> >
>> > SessionImplementor is poorly named.  Following the normal *Implementor
>> > naming convention we follow every else in the code base a
>> > SessionImplementor
>> > ought to be the internal contract for a Session.  But that's not what it
>> > is
>> > today.  Really SessionImplementor as it exists today is the *Implementor
>> > for
>> > SharedSessionContract.  So I normalized this.  I created a
>> > SharedSessionContractImplementor contract that extends
>> > SharedSessionContract.  SessionImplementor then extends
>> > SharedSessionContractImplementor.  However this is the "questionable"
>> > part
>> > because that means changing an awful lot of SPI methods to accept/return
>> > SharedSessionContractImplementor as opposed to SessionImplementor.
>> >
>> > So in terms of API, we have:  SharedSessionContract <- (Session &
>> > StatelessSession)
>> > In terms of SPI, we have: SharedSessionContractImplementor <-
>> > (SessionImplementor & StatelessSessionImplementor)
>> >
>> > As far as Query object creation, SharedSessionContract also fulfills the
>> > role of (extends) the QueryProducer contract which defines a unified set
>> > of
>> > methods that cover the JPA cases without having to implement
>> > EntityManager.
>> > ATM QueryProducer covers HQL/JPQL and Native (SQL) queries.  For 5.2 It
>> > will
>> > still have to deal with procedure/function calls.  Eventually in 6.0 it
>> > will
>> > have to deal with criteria queries as well.
>> >
>> > Gunnar to your specific question about naming, yes.  I had already
>> > started
>> > on that path actually.  So in terms of API contracts we have:
>> >
>> > org.hibernate.query.Query
>> > org.hibernate.query.NativeQuery extends org.hibernate.query.Query
>> >
>> > Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I
>> > can't remove them in a 5.2 release.  However I have deprecated them as
>> > scheduled them for removal in 6.0.  This follows the typical "shadow"
>> > approach we have followed before for deprecating APIs.
>> > org.hibernate.query.Query extends the deprecated org.hibernate.Query and
>> > org.hibernate.query.NativeQuery extends the deprecated
>> > org.hibernate.SQLQuery.  That allows existing code to continue to work
>> > with
>> > deprecation warnings.  Users can chose to migrate to the new contracts
>> > in
>> > moving to 5.2 or at least know that is a task in upgrading to 6.0.
>> >
>> > I'd love some votes on the
>> > SessionImplementor/SharedSessionContractImplementor point above.  There
>> > are
>> > other, less disruptive ways to do that; I just think this is the most
>> > correct way.  Some other options include more fully distinguishing
>> > between a
>> > "stateful" and a "stateless" Session - then SessionImplementor term fits
>> > better as we'd have StatefulSessionImplementor and
>> > StatelessSessionImplementor variants.  I really dislike the phrases
>> > stateful
>> > and stateless here though.  Anyway, let me know what y'all think.
>> >
>> > On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> >>
>> >> 2016-04-13 0:48 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> >>>
>> >>> Another question as I work through Query...
>> >>>
>> >>> Currently both Session and StatelessSession inherit the same query
>> >>> creation
>> >>> methods (returning org.hibernate.Query) via SharedSessionContract
>> >>> (which
>> >>> is
>> >>> the common base type between them).  There is therefore an inherent
>> >>> difficulty in having org.hibernate.Query extend from the JPA
>> >>> javax.persistence.Query/TypedQuery when we only want Session to be an
>> >>> EntityManager, not StatelessSession.
>> >>>
>> >>> The simplest solution is to:
>> >>>
>> >>>    1. Leave org.hibernate.Query as a "legacy Hibernate query contract"
>> >>> and
>> >>>
>> >>>
>> >>>       move all of the existing SharedSessionContract query creation
>> >>> methods
>> >>>       returning org.hibernate.Query directly to StatelessSession
>> >>>
>> >>>       2. develop a new org.hibernate.query.Query (prefacing 6.0) that
>> >>>
>> >>>
>> >>>       provides some of the "legacy Hibernate query contract" and
>> >>> extends
>> >>> from
>> >>>       javax.persistence.Query.  Directly on Session we'd write new
>> >>> methods with
>> >>>       the same name and args but returning this
>> >>> org.hibernate.query.Query.
>> >>>
>> >>> This would give us 2 distinct Query hierarchies and allow the
>> >>> underlying
>> >>> goal of Session extending EntityManager, but not StatelessSession.  We
>> >>> could also flip these based on the knowledge that Session is more
>> >>> widely
>> >>> used (less disruptive).
>> >>>
>> >>> In other words we'd go from both Session and StatelessSession
>> >>> returning
>> >>> org.hibernate.Query via inheriting from SharedSessionContract:
>> >>>
>> >>> public interface SharedSessionContract {
>> >>>     ...
>> >>>      org.hibernate.Query createQuery(String hql);
>> >>> }
>> >>>
>> >>>
>> >>> to each Session and StatelessSession implementing different methods
>> >>> altogether:
>> >>>
>> >>> public interface StatelessSession {
>> >>>     ...
>> >>>      org.hibernate.Query createQuery(String hql);
>> >>> }
>> >>>
>> >>> public interface Session {
>> >>>     ...
>> >>>      org.hibernate.query.Query createQuery(String hql);
>> >>> }
>> >>>
>> >>>
>> >>> Unifying these returns across Session and StatelessSession would
>> >>> require
>> >>> StatelessSession also being an EntityManager.  I had decided against
>> >>> that
>> >>> for the same reasons that StatelessSession is distinct from Session.
>> >>
>> >>
>> >> Why would it require StatelessSession to extend EntityManager? Both,
>> >> StatelessSession and Session could define the same method, also if not
>> >> being
>> >> part of the same hierarchy.
>> >>
>> >> I'm concerned about the two Query types with the same simple name,
>> >> users
>> >> may be easily confused which one to import.
>> >>
>> >>> Maybe a hybrid approach would be to break the query creation methods
>> >>> out
>> >>> of
>> >>> SharedSessionContract into a new targeted interface named
>> >>> QueryProducer
>> >>> which both Session and StatelessSession would implement.  That would
>> >>> allow
>> >>> unifying the query creation return to something that implements JPA
>> >>> Query
>> >>> contract too, but the source (Session/StatelessSession via
>> >>> QueryProducer)
>> >>> would not necessarily need to implement EntityManager.
>> >>>
>> >>>
>> >>> I think the QueryProducer route is probably the best option in terms
>> >>> of
>> >>> allowing the consolidation but still allowing users to upgrade easily.
>> >>>
>> >>> Thoughts?  Other options?  Hopefully I explained it well enough :)
>> >>
>> >>
>> >> Something related; If you are touching these bits, could you rename
>> >> createSQLQuery() into createNativeQuery() and SQLQuery into
>> >> NativeQuery?
>> >> That'd give a much better experience for users of Hibernate OGM which
>> >> otherwise wonder how SQL queries relate to their chosen NoSQL store.
>> >> createNativeQuery() makes that smoother.
>> >>
>> >>> On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole <steve at hibernate.org>
>> >>> wrote:
>> >>>
>> >>> > Just a quick update on my progress.  I pretty much have
>> >>> > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted
>> >>> > out as
>> >>> > well as bootstrapping.
>> >>> >
>> >>> > I am currently working through the different Query hierarchies.
>> >>> >
>> >>> > Looking at what is left, I hope to be done with all of this by
>> >>> > Thursday
>> >>> >
>> >>> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero <sanne at hibernate.org>
>> >>> > wrote:
>> >>> >
>> >>> >> On 8 April 2016 at 15:04, Scott Marlow <smarlow at redhat.com> wrote:
>> >>> >> > I'm curious if Search/OGM master branches would likely align with
>> >>> >> > 5.2?
>> >>> >> > Or some other branch?
>> >>> >>
>> >>> >> Good question, time for an update on these.
>> >>> >>
>> >>> >> We'll certainly have a version of Search compatible, at some point.
>> >>> >> Not sure though about which version that shall be as we want to be
>> >>> >> feature complete with our Elasticsearch work, and that will take a
>> >>> >> couple more months at least so we'll see a bit longer than usual
>> >>> >> gap
>> >>> >> between stable releases.
>> >>> >>
>> >>> >> Generally speaking we need at least a minor release for OGM or
>> >>> >> Search
>> >>> >> to happen to upgrade the minor of ORM.
>> >>> >> Since we didn't release yet, Search is still building with ORM
>> >>> >> 5.0.x
>> >>> >> as a target.. we can then decide if we should skip ORM 5.1 and jump
>> >>> >> to
>> >>> >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As
>> >>> >> far as I know only some test helpers broke though, so while I
>> >>> >> couldn't
>> >>> >> test it all on both versions 5.0 and 5.1 of ORM, I think that they
>> >>> >> are
>> >>> >> compatible at runtime and we also expect to be compatible with ORM
>> >>> >> 5.2.
>> >>> >>
>> >>> >> With OGM we're now in candidate release phase for a ORM 5.0
>> >>> >> compatible
>> >>> >> version so not really thinking to bump it to ORM 5.1 yet.
>> >>> >>
>> >>> >> OGM tends to release less frequently, so in this case it is
>> >>> >> possible
>> >>> >> that we might want to skip ORM 5.1 and go on 5.2 already to catch
>> >>> >> up,
>> >>> >> but we can work on aiming a specific version if and when need
>> >>> >> arises.
>> >>> >>
>> >>> >> If you need any of these aligned let us know?
>> >>> >>
>> >>> >> Thanks,
>> >>> >> Sanne
>> >>> >>
>> >>> >> >
>> >>> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote:
>> >>> >> >> As a follow up to this...
>> >>> >> >>
>> >>> >> >> Sanne had a great suggestion on HipChat.  What about turning all
>> >>> >> >> this
>> >>> >> work
>> >>> >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0.  The idea
>> >>> >> >> would
>> >>> >> be
>> >>> >> >> 5.2 would include:
>> >>> >> >>
>> >>> >> >>     1. Move to Java 8
>> >>> >> >>     2. Consolidation of hibernate-entitymanager into
>> >>> >> >> hibernate-core
>> >>> >> >>     3. Deprecations, lots of deprecations :)
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> The idea is that then we could start 6.0 off "clean" by removing
>> >>> >> >> all
>> >>> >> the
>> >>> >> >> deprecations and layering in SQM work.
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea
>> >>> >> >> <mihalcea.vlad at gmail.com
>> >>> >> >
>> >>> >> >> wrote:
>> >>> >> >>
>> >>> >> >>> Hi,
>> >>> >> >>>
>> >>> >> >>> Until the merge is done, I'll take a break integrating the PRs
>> >>> >> >>> that
>> >>> >> are
>> >>> >> >>> also relevant to the master branch.
>> >>> >> >>>
>> >>> >> >>> Vlad
>> >>> >> >>>
>> >>> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole
>> >>> >> >>> <steve at hibernate.org>
>> >>> >> >>> wrote:
>> >>> >> >>>
>> >>> >> >>>> I agree that would be best.  If everyone agrees to stop
>> >>> >> >>>> pushing
>> >>> >> >>>> to
>> >>> >> master
>> >>> >> >>>> for the time being to allow me to finish this consolidation
>> >>> >> >>>> then
>> >>> >> >>>> I
>> >>> >> can not
>> >>> >> >>>> rush it as much
>> >>> >> >>>>
>> >>> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
>> >>> >> >>>> <crancran at gmail.com>
>> >>> >> wrote:
>> >>> >> >>>>
>> >>> >> >>>>> I have to concur with Sanne, a hold on master pushes until
>> >>> >> >>>>> this
>> >>> >> merge of
>> >>> >> >>>>> artifacts is complete makes the most sense from an all around
>> >>> >> logistics
>> >>> >> >>>>> perspective.
>> >>> >> >>>>>
>> >>> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <
>> >>> >> sanne at hibernate.org>
>> >>> >> >>>>> wrote:
>> >>> >> >>>>>
>> >>> >> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e.
>> >>> >> >>>>>> should we
>> >>> >> >>>>>> temporarily disable complaint emails from Jenkins, or even
>> >>> >> >>>>>> the
>> >>> >> >>>>>> full
>> >>> >> >>>>>> build tasks?
>> >>> >> >>>>>>
>> >>> >> >>>>>> Also, this implies that any future backport becomes
>> >>> >> >>>>>> similarly
>> >>> >> harder,
>> >>> >> >>>>>> so you could also simply ask others to hold pushing on
>> >>> >> >>>>>> master,
>> >>> >> >>>>>> then
>> >>> >> >>>>>> have people forward-port when it's done.. it's the same
>> >>> >> >>>>>> really
>> >>> >> >>>>>> but
>> >>> >> >>>>>> that's why I mention it: as the complexity is
>> >>> >> >>>>>> interchangeable
>> >>> >> >>>>>> it's
>> >>> >> a
>> >>> >> >>>>>> fair request, with the difference you have:
>> >>> >> >>>>>>   - others help you port the other patches forward rather
>> >>> >> >>>>>> than
>> >>> >> doing it
>> >>> >> >>>>> all
>> >>> >> >>>>>> alone
>> >>> >> >>>>>>   - the authors of the original patch doing it, that should
>> >>> >> >>>>>> make
>> >>> >> it a
>> >>> >> >>>> bit
>> >>> >> >>>>>> simpler
>> >>> >> >>>>>>
>> >>> >> >>>>>>
>> >>> >> >>>>>>
>> >>> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole
>> >>> >> >>>>>> <steve at hibernate.org>
>> >>> >> wrote:
>> >>> >> >>>>>>> Obviously consolidating hibernate-entitymanager into
>> >>> >> hibernate-core
>> >>> >> >>>> is
>> >>> >> >>>>> a
>> >>> >> >>>>>>> fairly big effort.  And I am getting concerned about the
>> >>> >> continuing
>> >>> >> >>>>>> pushes
>> >>> >> >>>>>>> to master in the meantime, many of which I know touch on
>> >>> >> >>>>>>> code
>> >>> >> >>>>>>> I
>> >>> >> have
>> >>> >> >>>>>>> changed.  My concern is obviously getting done all this
>> >>> >> refactoring
>> >>> >> >>>>> work
>> >>> >> >>>>>>> and then having to sift through all of the changes that
>> >>> >> >>>>>>> have
>> >>> >> >>>>>>> been
>> >>> >> >>>>> pushed
>> >>> >> >>>>>> in
>> >>> >> >>>>>>> the interim and attempting to work out the proper
>> >>> >> >>>>>>> integration
>> >>> >> >>>> strategy.
>> >>> >> >>>>>>>
>> >>> >> >>>>>>> Long story short... I am contemplating pushing to master
>> >>> >> >>>>>>> sooner
>> >>> >> >>>> rather
>> >>> >> >>>>>> than
>> >>> >> >>>>>>> later even though my refactoring may not be completely
>> >>> >> >>>>>>> finished,
>> >>> >> >>>>>> especially
>> >>> >> >>>>>>> as we get towards the end of the week.
>> >>> >> >>>>>>> _______________________________________________
>> >>> >> >>>>>>> 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
>> >>> >> >>>>
>> >>> >> >>>
>> >>> >> >>>
>> >>> >> >> _______________________________________________
>> >>> >> >> 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