ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject [VOTE] Deprecate queryForObject ("statement", paramObject, resultObject)
Date Sun, 05 Nov 2006 15:42:31 GMT
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

Please offer your +1/-1 vote!

Thanks much,


View raw message