Re: [VOTE] Deprecate queryForObject ("statement", paramObject, resultObject)

[Davide Marche]

+1 I believe that ResultObjectFactory is much better (as described), and it is something we were looking for time ago. Davide Marche Jeff Butler ha scritto: +1   Jeff Butler   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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.13.28/518 - Release Date: 04/11/2006 17.30