I actually found a use for this and I am using it currently. Please don't
ask me to go find it in my code as it's been months since I visited it, but I
did find a valid use case for it.
On 11/5/06, Clinton
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
So if you agree with the above, I'll deprecate this method
signature for the 2.3 release.
- 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).
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.
your +1/-1 vote!