he's got a nifty demo version so you don't "ซื้อควายในหนอง" (thai idiom, "buying a water buffalo out in the swamp") or "een kat in de zak kopen" (dutch one for "buying a cat in a sack"--cats in sacks seem to be real popular throughout europe).
if you're serious about coldfusion certification then hurry on over to brian's centrasoft site.
// the old way if you needed the precision bd=createObject("java","java.math.BigDecimal");
bd1=bd.init("234.567890123456");
bd2=bd.init("123.67141525678901345");
x=bd1.multiply(bd2);
// "high" precision math y=precisionEvaluate(234.567890123456*123.67141525678901345);
// "normal" cf math
z=234.567890123456*123.67141525678901345;
writeoutput("<table border='1'>
<tr><td>old fashioned java way</td><td>#x#</td></tr>
<tr><td>new precisionEvaluate</td><td>#y#</td></tr>
<tr><td>normal cf math</td><td>#z#</td></tr>
</table>");
</cfscript>
which produces something like:
| old fashioned java way | 29009.34294536678530209026494448320 |
| new precisionEvaluate | 29009.34294536678530209026494448320 |
| normal cf math | 29009.3429454 |
i would imagine that cf's handling the expression parsing and data type casting in the background similar to the above example using BigDecimal.
ps: coldfusion 8 added BigDecimal as one of the data types for javaCast(), so you could ditch the createObject() and use something like this:
zz1=javacast("BigDecimal","123.67141525678901345");
zz=zz0.multiply(zz1);
one other useful bit of info returned in the result structure is recordcount which according to the docs returns the Number of records (rows) returned from the query. that doesn't sound all that interesting but what it really means is that it returns the number of rows affected by the cfquery's SQL, something akin to sql server's @@ROWCOUNT. so for UPDATEs and DELETEs (at least for sql server using the builtin datadirect and jTDS JDBC drivers that i tested with) you can very easily get at how many rows were deleted or updated without any extra SQL, etc. for instance:
DELETE a
WHERE ID >= 13050
</cfquery>
<cfdump var="#r#">
will return the number of rows deleted in r.recordcount along with the SQL used, execution time and whether this query is cached. sweet.
note that batching your SQL statements like this:
<cfloop index="i" to="10" from="1">
UPDATE a
SET testA='a'
</cfloop>
</cfquery>
will only return the affected row count for the last SQL statement (or first, haven't tested which yet). or if you wrap your SQL code in NOCOUNT blocks (in sql server this tells the db not to return row counts to the client):
SET NOCOUNT ON
UPDATE a
SET testA='a'
SET NOCOUNT OFF
</cfquery>
you won't get anything back for recordcount.
- bigdecimal
- byte
- char
- short
as well as the nifty new ability to cast Arrays (which has been something i'd actually requested a while back):
bigDecimalArray=javacast("bigdecimal[]",cfArray);
very cool.
- zh_SG - Chinese (Simplified), Singapore
- en_MT - English, Malta
- en_PH - English, Philippines
- en_SG - English, Singapore
- el_CY - Greek, Cyprus
- id_ID - Indonesian, Indonesia
- ga_IE - Irish, Ireland
- ms_MY - Malay, Malaysia
- mt_MT - Maltese, Malta
- pt_BR - Portuguese, Brazil
- pt_PT - Portuguese, Portugal
- es_US - Spanish, United States
hopefully this trend will continue.
beyond the new locale data it also provides support for the Japanese Imperial Calendar which we can tap into for date conversion and formatting simply by setting coldfusion's locale to the new JP variant:
// set appropriate locale
setLocale("ja_JP_JP");
// Japanese Imperial Calendar date format writeoutput("#lsDateFormat(now(),"FULL")#");
</cfscript>
which should give you something like: 平成19年7月26日 how cool is that?
for more details on the new i18n bits in JDK 6 see this.
while it's a short term annoyance i think this is probably for the better long term.
update: tom jordahl's mentioned that the "any" bit will get fixed for the final release.
given the timezone hell i recently passed through and the recent US and Australia DST changes, i plan on beefing up the section on timezones. and in keeping w/ben's idea to slim things down, we'll be pushing most of those "boring" locale table comparisons out to on-line appendices. might also add a wee bit on using flex in g11n cf apps.
so before i really begin the excruciating process of revising that chapter, i'm looking for feedback on it. anything missing? anything not too clear? you can respond here or simply email me with your suggestions.
thanks.
and i'd also like to remind folks that dean harmon's looking for help localizing the cfreport builder application.
so what are you waiting for?
- native resource bundles (heck flex 2.0 got them, but frankly that's about all it got in terms of i18n)
- setTimeZone() function that might allow me to find my way out of timezone hell
- use icu4j library (used in a modular/plugin fashion, one of the really sweet things aboout this project is how often it's updated with new functionality and improved locale data from the CLDR). this would buy us better locale data, offer easier access to non-gregorian calendars, etc.
and that's it.
i guess you can take this posting as a stealthy complement to the good work the CF team has done over the years to get ColdFusion to it's current i18n state.
and in case you're wondering, brian simmons, who built the exam buster, is a genuine good guy. besides "exam buster" sounds like a pretty good name for comic super hero ;-)
![[Valid RSS]](/blog/valid-rss.png "Validate my RSS feed"){kind=small}