On 15 April 2016 at 17:10, Steve Ebersole <st...@hibernate.org> wrote:
> 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.
Ok, I got it know. Sorry I had interpreted the opposite, just returned
from a flight late night and I'm a bit confused I'm afraid :)
Looks good then!
>
> 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
