+1
On 11/5/06, Brandon Goodin <[EMAIL PROTECTED]> wrote:
+1
On 11/5/06, Clinton Begin <[EMAIL PROTECTED]> 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
>
