ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry Meadors" <lmead...@apache.org>
Subject Re: [VOTE] Deprecate queryForObject ("statement", paramObject, resultObject)
Date Mon, 06 Nov 2006 00:29:15 GMT
+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
> >
>
>

Mime
View raw message