September 15, 2007

icu4j 3.8 final released

the final version of icu4j version 3.8 has just been released. to recap what's in this release:
  • uses the latest cldr 1.5.0.1 locale data
  • the long discussed rule based timezone changes which gives us the ability to read and write timezone data in RFC2445 VTIMEZONE format as well as also providing access to Olson timezone transitions! this is something many people have been needing for quite some time now, this is going to be very useful
  • tawainese calendar (a flavor of gregorian calendar that numbers years since 1912AD)
  • the Indian National Calendar (more complicated flavor of the gregorian calendar, eg it's synched up with the gregorian calendar's leap years but the extra day is added to the first month, Chaitra which starts march 22 on gregorian calendar--so, yup, it's complicated)
  • charset conversion bugs were fixed and CESU-8, UTF-7 and ISCII converters have been added. also some conversion speed improvements. the UTF-7 one will be useful for email (bounce) handling
  • a new MessageFormat type for plurals was added
  • a pretty useful new DurationFormat class was added so you can format messages over a duration in time such as "2 days from now" or "3 hours ago"
  • also the MessageFormat class will now take named arguments instead of just arrays (too bad now that coldfusion 8's javacast got a shot of steroids)
  • new BIDI stuff (which i still need to investigate)

next month i'll be adding the new calendars as CFCs to the usual bits. i'll also be doing some significant changes to most of the i18n formatting methods to take better advantage of the calendar, etc. keywords (en_GB@calendar=indian,currency=EUR) on the ULocale class (icu4j's super cool locale class).

unfortunately the persian calendar still appears to be only in icu4c (C/C++) only.

Labels:

posted by Paul Hastings @ 9:18 PM 0 comments

September 01, 2007

more coldfusion 8 cfquery goodness

by now i suppose everyone knows about the new SQL goodness in coldfusion 8's cfquery. by using cfquery's optional result argument you can access identity (auto-increment) values if your database returns them (and of course you actually use them). 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:
<cfquery datasource="jTDS" name="q" result="r">
   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:
<cfquery datasource="lab" name="q" result="r">
   <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):
<cfquery datasource="lab" name="q" result="r">
   SET NOCOUNT ON
   UPDATE a
      SET testA='a'
   SET NOCOUNT OFF
</cfquery>
you won't get anything back for recordcount.

posted by Paul Hastings @ 11:43 AM 1 comments