+1 for QueryProducer
On Tue, Apr 12, 2016 at 3:48 PM, Steve Ebersole <st...@hibernate.org> wrote:
> 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.
>
> 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 :)
>
>
> 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
