Yeah, so much for “I’ll post part 2 tomorrow…“. Sorry guys, life and work got kind of in the way. Here’s part 2 now though 🙂
4. Date comparison
If you use if constructs for string comparison in ColdFusion, the server will always check if a string on either side of your if-condition could potentially be a date value in a string. Railo uses a different approach and will only check for this if at compile time there’s a date value (for example from a query column) on at least one side of the comparison. This obviously saves a lot of very expensive string comparisons at runtime.
If you want to explicitly check for dates in a comparison, you should use parseDateTime():
<cfif parseDateTime(strDate) EQ parseDateTime("01.01.13")>
5. More date stuff: Date parsing
Adobe ColdFusion allows implicit parsing in locale formats. Something along the lines of:
<cfif now() EQ "Wednesday, January 30, 2013 4:02:12 AM NZDT">
In Railo you can’t do this and you’d have to use parseDateTime() again (see above). The reason is: Parsing reasonably complex strings is a noticeable performance overhead and the Railo team has decided not to support this approach.
<cfif now() EQ ParseDateTime("Wednesday, January 30, 2013 4:02:12 AM NZDT")>
6. Passing-by-value vs. passing-by-reference
You might know that if you’re passing complex datatypes such as Arrays and Structures around and assign them to new variables, Adobe ColdFusion would always pass Arrays by value but all other complex datatypes by references (i.e. as a pointer). That’s not new and I think everyone has probably realised this by now.
There’s a funny inconsistency though: If you pass an Array as an argument into one of your own custom functions, the Array is passed by value (as I’ve described above). However, if you pass an Array into various Built-In-Functions in Adobe ColdFusion, it’s being passed in by reference.
Take for instance ArrayAppend(array_to_append_to,value). Clearly the array_to_append_to value I’m passing into my function is passed in by reference here.
Railo is treating this scenario differently. In Railo, all variables of complex type are passed into functions (both Built-In and one’s own) as references. That provides consistency and it might actually even give you a tiny performance gain.
If you wanted to have an Array passed into your function by value (as Adobe ColdFusion would do), you can specify a passby-attribute for the argument:
<cfargument name="x" type="array" passby="value">
Wrap-up
There you go, some more differences between Adobe ColdFusion and Railo. Let’s hope I’ll get part 3 out of the door really soon 🙂 On the list for part 3: Differences in managing and dealing with nested struct keys and some more goodies.
Kai,
great post. And thanks for addressing these differences. May I request one thing of you? Could you post them in the Railo Wiki on GitHub please? Others might stumble across inconsistencies as well and I think it would make sense to gather all of them there. I think there is the place, where people might expect it.. And even better if it is done by the community. For various reasons, we hesitated publishing these differences, but since we have seen several posts about these differences, we’d like to encourage a community project or wiki pages around them.
Thanks a lot!
Hi Kai
Do you use the ‘locale-specific’ functions, eg LSParseDateTime?
The other thing that I keep running into when porting application from ACF to Railo is the inconsistent implementation of some of the BlazeDS stuff. Things like the BlazeDS event gateway are completely missing, all the while sending data back in a normal channel is different. It sometimes seems like I’m the only one that uses some of these technologies together :S
If you stick with the mainstream stuff, Railo is plain awesome. If you do new development, Railo is awesome as well. Porting apps is still a pain (its the little differences that usually get you…) But it is worth it in the end… Much better support, and much faster. But you have to prepare to get your hands dirty and not be afraid of doing so 😛
There’s one pretty important addition. It’s been discussed in Railo groups and even filed as a bug.
Railo doesn’t support multiple datasources with ORM. You simply cannot use datasource=”xyz” in the model.
Railo guys promised to fix it “eventually”, but it’s not going to happen in the upcoming 4.1 release.
So for now it remains a major difference for people using ORM.
Sergii, as far as I understand that’s one of the features that might end up having to be funded by either the community or a client as there doesn’t seem to be much demand for supporting multiple datasources with ORM.
Comments on this entry are closed.
{ 1 trackback }