[hibernate-dev] Master

andrea boriero andrea at hibernate.org
Fri Apr 15 10:33:02 EDT 2016 

+1 SharedSessionContractImplementor <- (Session
Implementor & StatelessSessionImplementor)

On 15 April 2016 at 14: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 <- (Session
> Implementor & 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
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

More information about the hibernate-dev mailing list