[hibernate-dev] [Fwd: Re: UserType.nullSafeSet() and nullSafeGet() in H4]

[Gail Badner]

The biggest change is in UserType. In the 3.6 branch (i.e., 3.6.2 and 
later 3.6.x releases) , the following UserType methods will be deprecated:
    public Object nullSafeGet(ResultSet rs, String[] names, Object owner)
    public void nullSafeSet(PreparedStatement st, Object value, int index)

A non-deprecated alternative cannot be provided in 3.6.x, because doing 
so would break implementations of UserType.

In master (H4), these deprecated methods will be replaced by:
    public Object nullSafeGet(ResultSet rs, String[] names, 
SessionImplementor session, Object owner)
    public void nullSafeSet(PreparedStatement st, Object value, int 
index, SessionImplementor session)

This change in master will be a breaking change that will be documented 
in the H4 migration guide.

Also in master, I will be removing the nullSafeGet/nullSafeSet/get/set 
methods from SingleColumnType and AbstractSingleColumnStandardBasicType  
that were deprecated in 3.6

When I make these changes, I will make sure that any UserTypes defined 
in master are intact.

Please let me know if there would be a problem making these changes to 
master.  Unless I hear otherwise, I plan to make these changes on Friday.

Cheers,
Gail

-------- Original Message --------
Subject: 	Re: [hibernate-dev] UserType.nullSafeSet() and nullSafeGet() 
in H4
Date: 	Fri, 18 Feb 2011 16:50:21 -0600
From: 	Steve Ebersole <steve at hibernate.org>
Organization: 	http://hibernate.org
To: 	Gail Badner <gbadner at redhat.com>
References: 	<4D5DDBB8.6050801 at redhat.com> 
<AANLkTin+bnBhue8k-nrxuVmw1fw3h0Qe4JxuZWG813j2 at mail.gmail.com> 
<4D5EC0CC.8030709 at redhat.com>



Yes stuff like this should always be disucssed in open (mailing list or dev 
irc).  See inline...

On Friday, February 18, 2011, at 12:56 pm, Gail Badner wrote:
> I also plan to do the following in master:
> 1) remove the following from SingleColumnType in master
>     (already deprecated in 3.6.1):
>         public T nullSafeGet(ResultSet rs, String name)
>         public Object get(ResultSet rs, String name)
>         public void nullSafeSet(PreparedStatement st, T value, int index)
>         public void set(PreparedStatement st, T value, int index)
OK...

> 2) remove the following from AbstractSingleColumnStandardBasicType in
> master
>     (needs to be deprecated in 3.6.2; {@inheritDoc} didn't seem to apply
> the deprecation)
>        public T nullSafeGet(ResultSet rs, String name)
>        public Object get(ResultSet rs, String name)
>        public void nullSafeSet(PreparedStatement st, T value, int index)
>        public void set(PreparedStatement st, T value, int index)
>        NO_OPTIONS (no longer needed in master)
OK (to me the deprecation applies to the API overall)

> 3) In UserType in master:
>     - remove
>         Q: people complain if a method is deprecated w/o providing the
> preferred method;
>              providing the preferred method in 3.6.2 would break UserType;
>              should this just be documented as a breaking change in the
> migration guide?
I've already defended this many many times.  People are always going to be 
unhappy about something.  I firmly believe this is the right approach.

>          public Object nullSafeGet(ResultSet rs, String[] names, Object
> owner)
>          public void nullSafeSet(PreparedStatement st, Object value, int
> index)
>     - add to master:
>          public Object nullSafeGet(ResultSet rs, String[] names,
> SessionImplementor session, Object owner)
>          public void nullSafeSet(PreparedStatement st, Object value, int
> index, SessionImplementor session)
> 
> 4) update references to removed methods in master
Well yeah ;)

> 
> I don't want to break other software that is trying to integrate with
> H4. I don't want to get slapped like when I removed ServiceRegistry from
> Configuration.
Not sure about the point here.  Making breaking changes is going to break 
people's uses.  IMO we got into trouble with ServiceRegistry because its not 
really ready yet and we should have hidden it for a bit longer.  For 
integrators I usually recommend they implement through Type rather than 
UserType.

> 
> So, should I wait on these changes, or would it suffice to give a heads
> up about these changes on the hibernate-dev mailing list?
> 
> Is there a migration guide for H4?
Yep, http://community.jboss.org/wiki/HibernateCoreMigrationGuide40

> Please let me know.
> 
> Thanks,
> Gail
> 
> Steve Ebersole wrote:
> > For sure now is the time to make whatever change we are going to make.
> > 
> > I for one say +1
> > 
> > Furthermore I think we should evaluate the overloaded
> > nullSafeGet/nullSafeSet methods on Type
> > 
> > On Feb 17, 2011 9:39 PM, "Gail Badner" <gbadner at redhat.com
> > 
> > <mailto:gbadner at redhat.com>> wrote:
> > > I noticed that UserType.nullSafeSet() and nullSafeGet() don't have a
> > > SessionImplementor argument, but those methods in CompositeUserType do
> > > have it.
> > > 
> > > This might not make a difference in 3.6.x, but in H4, not having the
> > > SessionImplementor argument makes it impossible to do dynamic type
> > > overrides specified by the dialect.
> > > 
> > > As an example, suppose a UserType delegates nullSafeGet()/nullSafeSet()
> > > to StandardBasicTypes.BLOB.nullSafeGet()/nullSafeSet(). True, the
> > > UserType could delegate to the proper type (streaming or lob-binding).
> > > To be able to use the same UserType for, say, both Oracle and
> > > PostgreSQL, it would have to be possible to do the override based on
> > > dialect.
> > > 
> > > I think the right thing to do is add the SessionImplementor argument
> > 
> > for H4.
> > 
> > > Comments?
> > > 
> > > Gail
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev

---
Steve Ebersole <steve at hibernate.org>
http://hibernate.org