ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Goodin" <brandon.goo...@gmail.com>
Subject Re: [VOTE] Deprecate queryForObject ("statement", paramObject, resultObject)
Date Sun, 05 Nov 2006 21:39:36 GMT
+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
>

Mime
View raw message