tracker issue : CF-3196326

select a category, or use search below
(searches all categories and all time range)
Title:

CF9.0.1 vs CF10 wrt cfgrid + bind = floating point

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Aaron Neff / Aaron Neff (Aaron Neff)

Created: 05/22/2012

Components: AJAX

Versions: 10.0

Failure Type:

Found In Build/Fixed In Build: Final / 289071

Priority/Frequency: Major / Some users will encounter

Locale/System: English / Win All

Vote Count: 0

When cfgrid uses the bind attribute, then CF9.0.1 and CF10 differ when handling strings of numbers.

CF9.0.1 treats the string of numbers as, well, a string of numbers.  Good. CF10 treats the string of numbers as a floating point number.  Not so good.  I thought the goal was to prevent strings of numbers from becoming floating point (#74140).

Please see attached image for comparison.

Repro:

index.cfm
-----------
<cfform>
  <cfgrid name="myGrid" format="html" width="200" bind="cfc:MyCFC.myFunction({cfgridpage},{cfgridpagesize},{cfgridsortcolumn},{cfgridsortdirection})">
    <cfgridcolumn name="myString" />
  </cfgrid>
</cfform>

MyCFC.cfc
-----------
<cfcomponent output="no">
<cffunction name="myFunction" access="remote" output="no" returntype="struct">
  <cfargument name="gridPage" type="numeric" />
  <cfargument name="gridPageSize" type="numeric" />
  <cfargument name="gridSortColumn" type="string" />
  <cfargument name="gridSortDirection" type="string" />
  <cfscript>
    var myQuery = queryNew("myString", "varchar");
    queryAddRow(myQuery, 1);
    querySetCell(myQuery, "myString", "9876543210987654321098", 1);
    return queryConvertForGrid(myQuery, ARGUMENTS.gridPage, ARGUMENTS.gridPageSize);
  </cfscript>
</cffunction>
</cfcomponent>

Actual Result (see attached image): 9.876543210987654e+21

Expected result: 9876543210987654321098

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3196326

External Customer Info:
External Company:  
External Customer Name: itisdesign
External Customer Email:

Attachments:

  1. May 23, 2012 00:00:00: 1_20120517_CFGridBindFloatingPoint.jpg
  2. June 07, 2012 00:00:00: 2_CFAjaxFloatingPoint.zip

Comments:

Related thread: http://prerelease.adobe.com/r/?60245985c8ac4dd9a6e94e9c410b7f0d
Comment by External U.
19290 | May 22, 2012 10:20:10 PM GMT
Per this post: http://prerelease.adobe.com/r/?c207d29ef9c94522ae53c3fd2adc3248 ---------------------- Regarding "CF9.0.1 and CF10 differ when handling strings of numbers": They differ in multiple ways. And when they’re consistent, they’re actually sometimes inconsistent w/ other ways in which they’re consistent. If that makes any sense. =P 1) In CF8 and CF10, if a cfgrid uses bind="cfc:", then strings of numbers are converted to floating point. CF9.0.1 preserves the original string. 2) In CF9.0.1 and CF10, if a cfgrid uses bind="url:", then strings of numbers are converted to floating point. 3) In CF9.0.1 serializeJSON() wraps a string of numbers with double quotes. In CF10 the string is not wrapped with quotes. 4) In CF9.0.1 if a cfdiv uses bind="url:", then the string of numbers is wrapped with double quotes. In CF10 the string is not wrapped with quotes. 5) In CF9.0.1 and CF10, if a cfdiv uses bind="cfc:", then strings of numbers are converted to floating point. 6) In CF9.0.1 and CF10, strings of numbers are converted to floating point in all of the following scenarios: 6a) If a cfajaxproxy uses bind="url:" 6b) If a cfajaxproxy uses bind="cfc:" 6c) If a cfajaxproxy uses cfc="" To see, just unzip CFAjaxFloatingPoint.zip and run the attached on CF9.0.1 and CF10. If this is expected behavior, then can this be documented so that people know about all the differences? If it’s not expected, then can/should a patch be pushed thru? I’d vote for CF not converting strings of numbers to floating point. If that isn’t possible, then I’d vote for it wrapping strings of numbers w/ double quotes. Whatever the case, I vote for it staying fixed once fixed (instead of reverting to broken in a future version, as we see has already happened). ----------------------
Comment by External U.
19291 | June 07, 2012 12:20:20 AM GMT
Adobe, Splendor Public Beta still converts the varchar "9876543210987654321098" to floating point 9.876543210987654e+21 Steps to Reproduce: Just run the code above. Can this ticket please be re-opened? Thanks!, -Aaron
Comment by External U.
19292 | February 28, 2014 05:48:26 AM GMT
Adobe, I created #CF-3717523 so that you could see 9876543210987654321098 is converted to 9.876543210987654e+21. But, it correctly displays as 9876543210987654321098 in the Bug Base's grid. Could you please try running my code above and see if 9876543210987654321098 is displayed as 9.876543210987654e+21? Thanks!, -Aaron
Comment by External U.
19293 | March 04, 2014 09:46:13 PM GMT
OH, Bug Base must be running CF9 isn't it? B/c CF9 correctly displays the number, but CF10 does not.
Comment by External U.
19294 | March 04, 2014 09:49:24 PM GMT
I mean.. Bug Base must be running CF 9.0.1, which explains the 2011 Adobe copyright at the bottom. OK, can someone please try running my code on CF11 and see if this bug is really fixed? It's still broken for me in Splendor Public Beta. Thanks!, -Aaron
Comment by External U.
19295 | March 04, 2014 09:54:15 PM GMT
Json Custom serializer implementation was missing some flows due to which our code was trying to do custom serialization despite not being available. Passing it to Paul as he had implemented this feature. During startup only we should check if custom serialization has to be used or not. It should not be checked for every invocation
Comment by Uday O.
19296 | March 11, 2014 08:10:54 AM GMT
If the custom serializer is not specified in the Application settings, changing the useCustomSerializer to false.
Comment by Paul N.
19297 | March 12, 2014 08:19:26 AM GMT
fixed in the upcoming major version release of CF. Now cfgrid with cfc binding displays the number as 9876543210987654321098.
Comment by Piyush K.
19298 | March 15, 2014 09:48:32 AM GMT
Hi Uday, Paul, and Piyush, Thank you all very much!! -Aaron
Comment by External U.
19299 | March 15, 2014 01:30:12 PM GMT