Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: pass (herse.apache.org: domain of larry.meadors@gmail.com
 designates 66.249.82.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=B5NaVeRCTkzVcYMxaxppRTL8rf9Yw6p0S+Oh8UbxouRzF2ilctfBQ5zDoeUs1LHo0uKbDA7riKafDBDwLQ/nhtdLhoOcnawf+qJmLcvP1qkhfwSjIaLE49792SqPerBGwje8PpkHbFs2/bNdPuBa79z04I1mhX/2VORwy9HgF8c=
Message-ID: <a10a823c0611051629m7190d419we491bcab8cf8ba1a@mail.gmail.com>
Date: Sun, 5 Nov 2006 17:29:15 -0700
From: "Larry Meadors" <lmeadors@apache.org>
Reply-To: lmeadors@apache.org
Sender: larry.meadors@gmail.com
To: user-java@ibatis.apache.org
Subject: Re: [VOTE] Deprecate queryForObject ("statement", paramObject,
 resultObject)
In-Reply-To: <2fe5ef5b0611051339x43a4e225l89ba6e1e06bff304@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <16178eb10611050742k837cc1fra9d523740b703c40@mail.gmail.com>
	 <2fe5ef5b0611051339x43a4e225l89ba6e1e06bff304@mail.gmail.com>

+1

On 11/5/06, Brandon Goodin <brandon.goodin@gmail.com> wrote:
> +1
>
> On 11/5/06, Clinton Begin <clinton.begin@gmail.com> wrote:
> > Hi all,
> >
> > One more deprecation request before 2.3.
> >
> > The version of queryForObject that takes both a parameterObject and a
> resultObject strikes me as both confusing and unecessary.  Originally I
> implemented it for two reasons:
> >
> >
> >
> > Performance.  To avoid instantiating an instance per row.  This is not a
> concern anymore, as class instantiation in modern JVMs is practically cost
> free -- at least when compared to the SQL Statement being executed in the
> same line of code!
> >
> > Instance lifecycle management.  This allowed you to instantiate your
> classes as you saw fit, then pass them to the query to be further populated.
>  Unfortunately, this approach is inconsistent.  It's inconsistent in that
> this only works for single row cases (queryForObject).  When querying a
> list, you don't have the option of providing a list of pre-allocated objects
> (which would be silly).  The new ResultObjectFactory feature takes care of
> the need to more closely manage the lifecycle of result objects.  So this
> feature is unecessary.
> > Caching behaviour.  When dealing with cached instances, the cached
> instance may be returned instead of the resultObject you've passed in (as
> per Brandon's JIRA entry).
> > So if you agree with the above, I'll deprecate this method signature for
> the 2.3 release.
> >
> > User Note:  Deprecation will only generate a warning, it will not break
> existing code or stop you from using it.  We just strongly recommend against
> it.
> >
> > Please offer your +1/-1 vote!
> >
> > Thanks much,
> >
> > Clinton
> >
>
>