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.
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 <sa...@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 <st...@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 <gun...@hibernate.org>
> wrote:
> >>
> >> 2016-04-13 0:48 GMT+02:00 Steve Ebersole <st...@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 <st...@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 <sa...@hibernate.org>
> >>> > wrote:
> >>> >
> >>> >> On 8 April 2016 at 15:04, Scott Marlow <smar...@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.v...@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
> >>> >> >>> <st...@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
> >>> >> >>>> <cranc...@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 <
> >>> >> sa...@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 <
> st...@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@lists.jboss.org
> >>> >> >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >> >>>>>> _______________________________________________
> >>> >> >>>>>> hibernate-dev mailing list
> >>> >> >>>>>> hibernate-dev@lists.jboss.org
> >>> >> >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >> >>>>>>
> >>> >> >>>>> _______________________________________________
> >>> >> >>>>> hibernate-dev mailing list
> >>> >> >>>>> hibernate-dev@lists.jboss.org
> >>> >> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >> >>>>>
> >>> >> >>>> _______________________________________________
> >>> >> >>>> hibernate-dev mailing list
> >>> >> >>>> hibernate-dev@lists.jboss.org
> >>> >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >> >>>>
> >>> >> >>>
> >>> >> >>>
> >>> >> >> _______________________________________________
> >>> >> >> hibernate-dev mailing list
> >>> >> >> hibernate-dev@lists.jboss.org
> >>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >> >>
> >>> >> > _______________________________________________
> >>> >> > hibernate-dev mailing list
> >>> >> > hibernate-dev@lists.jboss.org
> >>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >> _______________________________________________
> >>> >> hibernate-dev mailing list
> >>> >> hibernate-dev@lists.jboss.org
> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >>
> >>> >
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
