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