ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher.Mathru...@sybase.com
Subject RE: [VOTE] Deprecate queryForObject ("statement", paramObject, resultObject)
Date Mon, 06 Nov 2006 07:30:35 GMT
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<META boundary="----=_Part_31236_20331558.1162741742368" alternative; multipart 
<META http-equiv=Content-Type content="text/html; charset=us-ascii" 
Content-Type: ------="_Part_31236_20331558.1162741742368" inline 
Content-Disposition: html; text 7bit Content-Transfer-Encoding:>
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<DIV dir=ltr align=left><SPAN class=254312907-06112006><FONT color=#0000ff

<DIV dir=ltr align=left><SPAN class=254312907-06112006><FONT color=#0000ff

size=2>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.</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> "Jeff Butler" 
&lt;jeffgbutler@gmail.com&gt; [mailto:"Jeff Butler" 
&lt;jeffgbutler@gmail.com&gt;] <BR><B>Sent:</B> Sunday, November
05, 2006 7:49 
AM<BR><B>To:</B> user-java@ibatis.apache.org<BR><B>Subject:</B>
Re: [VOTE] 
Deprecate queryForObject ("statement", paramObject, 
<DIV>Jeff Butler<BR><BR>&nbsp;</DIV>
<DIV><SPAN class=gmail_quote>On 11/5/06, <B class=gmail_sendername>Clinton

Begin</B> &lt;<A 
<BLOCKQUOTE class=gmail_quote 
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi 
  all,<BR><BR>One more deprecation request before 2.3.<BR><BR>The
version of 
  queryForObject that takes both a parameterObject and a resultObject strikes me 
  as both confusing and unecessary.&nbsp; Originally I implemented it for two 
  reasons: <BR><BR>
    <LI><SPAN style="FONT-WEIGHT: bold">Performance.&nbsp; </SPAN>To
    instantiating an instance per row.&nbsp; 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! <BR>
    <LI><SPAN style="FONT-WEIGHT: bold">Instance lifecycle management.&nbsp;

    <SPAN style="FONT-WEIGHT: bold"></SPAN></SPAN>This allowed you to 
    instantiate your classes as you saw fit, then pass them to the query to be 
    further populated.&nbsp; Unfortunately, this approach is inconsistent.&nbsp; 
    It's inconsistent in that this only works for single row cases 
    (queryForObject).&nbsp; When querying a list, you don't have the option of 
    providing a list of pre-allocated objects (which would be silly).&nbsp; The 
    new ResultObjectFactory feature takes care of the need to more closely 
    manage the lifecycle of result objects.&nbsp; So this feature is unecessary. 

    <LI><SPAN style="FONT-WEIGHT: bold">Caching behaviour.&nbsp; </SPAN>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). 
  <BR></LI></UL>So if you agree with the above, I'll deprecate this method

  signature for the 2.3 release.&nbsp; <BR><BR>User Note:&nbsp; Deprecation
  only generate a warning, it will not break existing code or stop you from 
  using it.&nbsp; We just strongly recommend against it. <BR><BR>Please offer

  your +1/-1 vote!<BR><BR>Thanks much,<BR><SPAN 

View raw message