9:04 a.m.
Hi,
There are several deprecated methods on Session:
* public Object load(Class theClass, Serializable id, LockMode lockMode)
* public Object load(String entityName, Serializable id, LockMode lockMode);
* public void lock(Object object, LockMode lockMode);
* public void lock(String entityName, Object object, LockMode lockMode);
* public void refresh(Object object, LockMode lockMode);
* public Object get(Class clazz, Serializable id, LockMode lockMode);
* public Object get(String entityName, Serializable id, LockMode lockMode);
and SessionFactory:
* public void evict(Class persistentClass) throws HibernateException;
* public void evict(Class persistentClass, Serializable id) throws
HibernateException;
* public void evictEntity(String entityName) throws HibernateException;
* public void evictEntity(String entityName, Serializable id) throws
HibernateException;
* public void evictCollection(String roleName) throws HibernateException;
* public void evictCollection(String roleName, Serializable id) throws
HibernateException;
* public void evictQueries(String cacheRegion) throws HibernateException;
* public void evictQueries() throws HibernateException;
The docs point to methods to be used alternatively, so the upcoming ORM 5
major release seems like a good occasion to remove these methods and
simplifying these contracts a bit. Any thoughts?
On a related note, I am wondering whether
Session#public Object get(Class clazz, Serializable id, LockOptions
lockOptions);
etc. pull their weight. The same could be achieved via
byId( entityClass ).with( lockOptions ).load( id )
Is it actually worth to have these "shortcut" methods?
--Gunnar
3:12 p.m.
In regards to the first 2 sets, yes I agree.
In regards to your second point, see the discussion on
https://hibernate.atlassian.net/browse/HHH-9761 first. One idea was to
keep those methods as an "untyped API". Another option would be to add
another byId (etc) method for untyped operations, something like:
User user = (User) session.byIdUntyped( UserImpl.class )...load( id );
versus
User user = session.byId( User.class )...load( id );
On Tue, May 5, 2015 at 2:04 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi,
There are several deprecated methods on Session:
* public Object load(Class theClass, Serializable id, LockMode lockMode)
* public Object load(String entityName, Serializable id, LockMode
lockMode);
* public void lock(Object object, LockMode lockMode);
* public void lock(String entityName, Object object, LockMode lockMode);
* public void refresh(Object object, LockMode lockMode);
* public Object get(Class clazz, Serializable id, LockMode lockMode);
* public Object get(String entityName, Serializable id, LockMode lockMode);
and SessionFactory:
* public void evict(Class persistentClass) throws HibernateException;
* public void evict(Class persistentClass, Serializable id) throws
HibernateException;
* public void evictEntity(String entityName) throws HibernateException;
* public void evictEntity(String entityName, Serializable id) throws
HibernateException;
* public void evictCollection(String roleName) throws HibernateException;
* public void evictCollection(String roleName, Serializable id) throws
HibernateException;
* public void evictQueries(String cacheRegion) throws HibernateException;
* public void evictQueries() throws HibernateException;
The docs point to methods to be used alternatively, so the upcoming ORM 5
major release seems like a good occasion to remove these methods and
simplifying these contracts a bit. Any thoughts?
On a related note, I am wondering whether
Session#public Object get(Class clazz, Serializable id, LockOptions
lockOptions);
etc. pull their weight. The same could be achieved via
byId( entityClass ).with( lockOptions ).load( id )
Is it actually worth to have these "shortcut" methods?
--Gunnar
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:18 p.m.
Please don't remove deprecated methods if there is no real need!
On 5 May 2015 at 14:12, Steve Ebersole <steve(a)hibernate.org> wrote:
In regards to the first 2 sets, yes I agree.
In regards to your second point, see the discussion on
https://hibernate.atlassian.net/browse/HHH-9761 first. One idea was to
keep those methods as an "untyped API". Another option would be to add
another byId (etc) method for untyped operations, something like:
User user = (User) session.byIdUntyped( UserImpl.class )...load( id );
versus
User user = session.byId( User.class )...load( id );
On Tue, May 5, 2015 at 2:04 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> Hi,
>
> There are several deprecated methods on Session:
>
> * public Object load(Class theClass, Serializable id, LockMode lockMode)
> * public Object load(String entityName, Serializable id, LockMode
> lockMode);
> * public void lock(Object object, LockMode lockMode);
> * public void lock(String entityName, Object object, LockMode lockMode);
> * public void refresh(Object object, LockMode lockMode);
> * public Object get(Class clazz, Serializable id, LockMode lockMode);
> * public Object get(String entityName, Serializable id, LockMode lockMode);
>
> and SessionFactory:
>
> * public void evict(Class persistentClass) throws HibernateException;
> * public void evict(Class persistentClass, Serializable id) throws
> HibernateException;
> * public void evictEntity(String entityName) throws HibernateException;
> * public void evictEntity(String entityName, Serializable id) throws
> HibernateException;
> * public void evictCollection(String roleName) throws HibernateException;
> * public void evictCollection(String roleName, Serializable id) throws
> HibernateException;
> * public void evictQueries(String cacheRegion) throws HibernateException;
> * public void evictQueries() throws HibernateException;
>
> The docs point to methods to be used alternatively, so the upcoming ORM 5
> major release seems like a good occasion to remove these methods and
> simplifying these contracts a bit. Any thoughts?
>
> On a related note, I am wondering whether
>
> Session#public Object get(Class clazz, Serializable id, LockOptions
> lockOptions);
>
> etc. pull their weight. The same could be achieved via
>
> byId( entityClass ).with( lockOptions ).load( id )
>
> Is it actually worth to have these "shortcut" methods?
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:36 p.m.
Why? Why even deprecate methods then?
On Tue, May 5, 2015 at 8:18 AM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
Please don't remove deprecated methods if there is no real need!
On 5 May 2015 at 14:12, Steve Ebersole <steve(a)hibernate.org> wrote:
> In regards to the first 2 sets, yes I agree.
>
> In regards to your second point, see the discussion on
> https://hibernate.atlassian.net/browse/HHH-9761 first. One idea was to
> keep those methods as an "untyped API". Another option would be to add
> another byId (etc) method for untyped operations, something like:
>
> User user = (User) session.byIdUntyped( UserImpl.class )...load( id );
>
> versus
>
> User user = session.byId( User.class )...load( id );
>
>
> On Tue, May 5, 2015 at 2:04 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
>
>> Hi,
>>
>> There are several deprecated methods on Session:
>>
>> * public Object load(Class theClass, Serializable id, LockMode lockMode)
>> * public Object load(String entityName, Serializable id, LockMode
>> lockMode);
>> * public void lock(Object object, LockMode lockMode);
>> * public void lock(String entityName, Object object, LockMode lockMode);
>> * public void refresh(Object object, LockMode lockMode);
>> * public Object get(Class clazz, Serializable id, LockMode lockMode);
>> * public Object get(String entityName, Serializable id, LockMode
lockMode);
>>
>> and SessionFactory:
>>
>> * public void evict(Class persistentClass) throws HibernateException;
>> * public void evict(Class persistentClass, Serializable id) throws
>> HibernateException;
>> * public void evictEntity(String entityName) throws HibernateException;
>> * public void evictEntity(String entityName, Serializable id) throws
>> HibernateException;
>> * public void evictCollection(String roleName) throws
HibernateException;
>> * public void evictCollection(String roleName, Serializable id) throws
>> HibernateException;
>> * public void evictQueries(String cacheRegion) throws
HibernateException;
>> * public void evictQueries() throws HibernateException;
>>
>> The docs point to methods to be used alternatively, so the upcoming ORM
5
>> major release seems like a good occasion to remove these methods and
>> simplifying these contracts a bit. Any thoughts?
>>
>> On a related note, I am wondering whether
>>
>> Session#public Object get(Class clazz, Serializable id, LockOptions
>> lockOptions);
>>
>> etc. pull their weight. The same could be achieved via
>>
>> byId( entityClass ).with( lockOptions ).load( id )
>>
>> Is it actually worth to have these "shortcut" methods?
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:47 p.m.
Of course we can delete them, I just meant to stress there should be a
different "appropriate moment" for:
A] removal of deprecated methods for the sake of it (cleanup of old garbage)
B] removal of a method during a major release (API changes allowed)
because we can't otherwise get some improvement
When a new major release comes - say Hibernate ORM 5.0 - we'll have
quite a bit of "B" changes, as they are unavoidable and desired.
If we also make all changes in category A, the steer amount of changes
might become a critical mass which scare off people from upgrading.
Speaking as a user who regularly codes as a client for such changes
(for example Lucene 4 was a rather dramatic "fix" with over 2,000
compilation problems in Hibernate Search), I can swear that it's very
nice if I can upgrade my application by fixing *some limited*
compilation failures, and then run my testsuite. Then rinse and
repeat... if I have to code 2 weeks straight w/o being able to run my
tests I'll despair.
So for ORM I'd not immediately delete all deprecated methods: let it
be easy for people to upgrade to 5 as that's an intimidating process;
let them realise that with a couple of changes they can do it. Once
they're over the scary part, you can remove the long deprecated
methods in some minor.
But if any of these methods is a hindrance to get improvements done, no mercy :)
Sanne
On 5 May 2015 at 19:38, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
> Why? Why even deprecate methods then?
+1
--Hardy
7:33 p.m.
I don't know if I agree with this. I'll play the other side... What if you
had done the Lucene 4 upgrade and spent a bunch of time managing API
changes and finally got it right and then Lucene 4.1 cam along and removed
a bunch of deprecated methods? I think I'd actually be a tad more pissed
off at this scenario. Maybe that's just me? And realize that alot of the
methods that are deprecated and being discussed have actually be deprecated
in before 4.0 even. That's a long time...
On Fri, May 8, 2015 at 11:47 AM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
Of course we can delete them, I just meant to stress there should be
a
different "appropriate moment" for:
A] removal of deprecated methods for the sake of it (cleanup of old
garbage)
B] removal of a method during a major release (API changes allowed)
because we can't otherwise get some improvement
When a new major release comes - say Hibernate ORM 5.0 - we'll have
quite a bit of "B" changes, as they are unavoidable and desired.
If we also make all changes in category A, the steer amount of changes
might become a critical mass which scare off people from upgrading.
Speaking as a user who regularly codes as a client for such changes
(for example Lucene 4 was a rather dramatic "fix" with over 2,000
compilation problems in Hibernate Search), I can swear that it's very
nice if I can upgrade my application by fixing *some limited*
compilation failures, and then run my testsuite. Then rinse and
repeat... if I have to code 2 weeks straight w/o being able to run my
tests I'll despair.
So for ORM I'd not immediately delete all deprecated methods: let it
be easy for people to upgrade to 5 as that's an intimidating process;
let them realise that with a couple of changes they can do it. Once
they're over the scary part, you can remove the long deprecated
methods in some minor.
But if any of these methods is a hindrance to get improvements done, no
mercy :)
Sanne
On 5 May 2015 at 19:38, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
>> Why? Why even deprecate methods then?
>
> +1
>
> --Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:59 p.m.
On 8 May 2015 at 18:33, Steve Ebersole <steve(a)hibernate.org> wrote:
I don't know if I agree with this. I'll play the other
side... What if you
had done the Lucene 4 upgrade and spent a bunch of time managing API changes
and finally got it right and then Lucene 4.1 cam along and removed a bunch
of deprecated methods? I think I'd actually be a tad more pissed off at
this scenario. Maybe that's just me? And realize that alot of the methods
that are deprecated and being discussed have actually be deprecated in
before 4.0 even. That's a long time...
If that would have happened, I'd open the source code before
upgrading, get my IDE to highlight deprecated methods and resolve
them.
I would have been able to remove a dozen trivial ones, then run the
testsuite to confirm.. then remove a tricky one, run the testsuite to
confirm.. etc..
When I'm done, I upgrade to Lucene 4.1 and test again.
I would have loved that!
Think about the opposite: you code flat out for two weeks, and then
you have some test failing in a very mysterious way; then it's like
"ok, one of these 40,000 lines of changes is wrong".
It took us 2 months of work, or almost a year if you include finding
an appropriate moment in which you can actually afford to block any
other activity for no other reason than an upgrade.
Sanne
On Fri, May 8, 2015 at 11:47 AM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>
> Of course we can delete them, I just meant to stress there should be a
> different "appropriate moment" for:
> A] removal of deprecated methods for the sake of it (cleanup of old
> garbage)
> B] removal of a method during a major release (API changes allowed)
> because we can't otherwise get some improvement
>
> When a new major release comes - say Hibernate ORM 5.0 - we'll have
> quite a bit of "B" changes, as they are unavoidable and desired.
>
> If we also make all changes in category A, the steer amount of changes
> might become a critical mass which scare off people from upgrading.
>
> Speaking as a user who regularly codes as a client for such changes
> (for example Lucene 4 was a rather dramatic "fix" with over 2,000
> compilation problems in Hibernate Search), I can swear that it's very
> nice if I can upgrade my application by fixing *some limited*
> compilation failures, and then run my testsuite. Then rinse and
> repeat... if I have to code 2 weeks straight w/o being able to run my
> tests I'll despair.
>
> So for ORM I'd not immediately delete all deprecated methods: let it
> be easy for people to upgrade to 5 as that's an intimidating process;
> let them realise that with a couple of changes they can do it. Once
> they're over the scary part, you can remove the long deprecated
> methods in some minor.
> But if any of these methods is a hindrance to get improvements done, no
> mercy :)
>
> Sanne
>
> On 5 May 2015 at 19:38, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> > On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
> >> Why? Why even deprecate methods then?
> >
> > +1
> >
> > --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:30 p.m.
Sanne, the methods are already deprecated. You can already do that step.
For the deprecated methods that actually have a replacement anyway.
But think about the ones that don't. They are the ones that are likely to
"still be there" on the API and likely do absolutely nothing. Because if
there was a corollary, we would have named it in the deprecation message
when we deprecated it.
I mean following your logic (assuming that we are good citizens) you would
always do a first step of upgrading to the latest bugfixz release of the
previous release family. That version will have the deprecations in
place. For example, if I want to upgrade to 5.0 I would first upgrade to
the latest 4.3 and fix any deprecations. *Then* I can update to 5.0. Its
exactly what you described just in reverse. Except that it allows us to
actually clean up trash :)
On Fri, May 8, 2015 at 12:59 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
On 8 May 2015 at 18:33, Steve Ebersole <steve(a)hibernate.org>
wrote:
> I don't know if I agree with this. I'll play the other side... What if
you
> had done the Lucene 4 upgrade and spent a bunch of time managing API
changes
> and finally got it right and then Lucene 4.1 cam along and removed a
bunch
> of deprecated methods? I think I'd actually be a tad more pissed off at
> this scenario. Maybe that's just me? And realize that alot of the
methods
> that are deprecated and being discussed have actually be deprecated in
> before 4.0 even. That's a long time...
If that would have happened, I'd open the source code before
upgrading, get my IDE to highlight deprecated methods and resolve
them.
I would have been able to remove a dozen trivial ones, then run the
testsuite to confirm.. then remove a tricky one, run the testsuite to
confirm.. etc..
When I'm done, I upgrade to Lucene 4.1 and test again.
I would have loved that!
Think about the opposite: you code flat out for two weeks, and then
you have some test failing in a very mysterious way; then it's like
"ok, one of these 40,000 lines of changes is wrong".
It took us 2 months of work, or almost a year if you include finding
an appropriate moment in which you can actually afford to block any
other activity for no other reason than an upgrade.
Sanne
>
> On Fri, May 8, 2015 at 11:47 AM, Sanne Grinovero <sanne(a)hibernate.org>
> wrote:
>>
>> Of course we can delete them, I just meant to stress there should be a
>> different "appropriate moment" for:
>> A] removal of deprecated methods for the sake of it (cleanup of old
>> garbage)
>> B] removal of a method during a major release (API changes allowed)
>> because we can't otherwise get some improvement
>>
>> When a new major release comes - say Hibernate ORM 5.0 - we'll have
>> quite a bit of "B" changes, as they are unavoidable and desired.
>>
>> If we also make all changes in category A, the steer amount of changes
>> might become a critical mass which scare off people from upgrading.
>>
>> Speaking as a user who regularly codes as a client for such changes
>> (for example Lucene 4 was a rather dramatic "fix" with over 2,000
>> compilation problems in Hibernate Search), I can swear that it's very
>> nice if I can upgrade my application by fixing *some limited*
>> compilation failures, and then run my testsuite. Then rinse and
>> repeat... if I have to code 2 weeks straight w/o being able to run my
>> tests I'll despair.
>>
>> So for ORM I'd not immediately delete all deprecated methods: let it
>> be easy for people to upgrade to 5 as that's an intimidating process;
>> let them realise that with a couple of changes they can do it. Once
>> they're over the scary part, you can remove the long deprecated
>> methods in some minor.
>> But if any of these methods is a hindrance to get improvements done, no
>> mercy :)
>>
>> Sanne
>>
>> On 5 May 2015 at 19:38, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
>> > On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
>> >> Why? Why even deprecate methods then?
>> >
>> > +1
>> >
>> > --Hardy
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:02 p.m.
Right, seems we agree then; mine is purely a quantitative approach:
don't break too much in a single version, but if these have been
deprecated already my comment doesn't apply.
Sanne
On 8 May 2015 at 19:30, Steve Ebersole <steve(a)hibernate.org> wrote:
Sanne, the methods are already deprecated. You can already do that
step.
For the deprecated methods that actually have a replacement anyway.
But think about the ones that don't. They are the ones that are likely to
"still be there" on the API and likely do absolutely nothing. Because if
there was a corollary, we would have named it in the deprecation message
when we deprecated it.
I mean following your logic (assuming that we are good citizens) you would
always do a first step of upgrading to the latest bugfixz release of the
previous release family. That version will have the deprecations in place.
For example, if I want to upgrade to 5.0 I would first upgrade to the latest
4.3 and fix any deprecations. *Then* I can update to 5.0. Its exactly what
you described just in reverse. Except that it allows us to actually clean
up trash :)
On Fri, May 8, 2015 at 12:59 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>
> On 8 May 2015 at 18:33, Steve Ebersole <steve(a)hibernate.org> wrote:
> > I don't know if I agree with this. I'll play the other side... What if
> > you
> > had done the Lucene 4 upgrade and spent a bunch of time managing API
> > changes
> > and finally got it right and then Lucene 4.1 cam along and removed a
> > bunch
> > of deprecated methods? I think I'd actually be a tad more pissed off at
> > this scenario. Maybe that's just me? And realize that alot of the
> > methods
> > that are deprecated and being discussed have actually be deprecated in
> > before 4.0 even. That's a long time...
>
> If that would have happened, I'd open the source code before
> upgrading, get my IDE to highlight deprecated methods and resolve
> them.
> I would have been able to remove a dozen trivial ones, then run the
> testsuite to confirm.. then remove a tricky one, run the testsuite to
> confirm.. etc..
>
> When I'm done, I upgrade to Lucene 4.1 and test again.
>
> I would have loved that!
>
> Think about the opposite: you code flat out for two weeks, and then
> you have some test failing in a very mysterious way; then it's like
> "ok, one of these 40,000 lines of changes is wrong".
> It took us 2 months of work, or almost a year if you include finding
> an appropriate moment in which you can actually afford to block any
> other activity for no other reason than an upgrade.
>
> Sanne
>
>
> >
> > On Fri, May 8, 2015 at 11:47 AM, Sanne Grinovero <sanne(a)hibernate.org>
> > wrote:
> >>
> >> Of course we can delete them, I just meant to stress there should be a
> >> different "appropriate moment" for:
> >> A] removal of deprecated methods for the sake of it (cleanup of old
> >> garbage)
> >> B] removal of a method during a major release (API changes allowed)
> >> because we can't otherwise get some improvement
> >>
> >> When a new major release comes - say Hibernate ORM 5.0 - we'll have
> >> quite a bit of "B" changes, as they are unavoidable and desired.
> >>
> >> If we also make all changes in category A, the steer amount of changes
> >> might become a critical mass which scare off people from upgrading.
> >>
> >> Speaking as a user who regularly codes as a client for such changes
> >> (for example Lucene 4 was a rather dramatic "fix" with over 2,000
> >> compilation problems in Hibernate Search), I can swear that it's very
> >> nice if I can upgrade my application by fixing *some limited*
> >> compilation failures, and then run my testsuite. Then rinse and
> >> repeat... if I have to code 2 weeks straight w/o being able to run my
> >> tests I'll despair.
> >>
> >> So for ORM I'd not immediately delete all deprecated methods: let it
> >> be easy for people to upgrade to 5 as that's an intimidating process;
> >> let them realise that with a couple of changes they can do it. Once
> >> they're over the scary part, you can remove the long deprecated
> >> methods in some minor.
> >> But if any of these methods is a hindrance to get improvements done, no
> >> mercy :)
> >>
> >> Sanne
> >>
> >> On 5 May 2015 at 19:38, Hardy Ferentschik <hardy(a)hibernate.org>
wrote:
> >> > On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
> >> >> Why? Why even deprecate methods then?
> >> >
> >> > +1
> >> >
> >> > --Hardy
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
3276
days inactive
3279
days old
9 comments
4 participants
participants (4)
-
Gunnar Morling -
Hardy Ferentschik -
Sanne Grinovero -
Steve Ebersole