[hibernate-dev] Master
Steve Ebersole
steve at hibernate.org
Fri Apr 15 09:30:07 EDT 2016
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
>>
>
More information about the hibernate-dev
mailing list