PMKenney.com

I realized today it’s been nearly a month since I’ve posted an update to this blog. I blame my current projects and the additional time I’ve spent on professional development this past month. 

I’ve taken quite a bit of time over the past month to pick apart and play around with the new features in Rails 2.1. I won’t go into detail about every new feature, you can read all the juicy details here. 

I do want to quickly mention a very nice new feature in ActiveRecord 2.1, the ability to read if a record or a specific attribute in a record has changed. This make validation loops easier to write and minimizes round trips to your database if the application is engineered and tested accordingly. Take a look at the example below and checkout http://www.rubyonrails.org for more details on the 2.1 update. 

 
article = Article.find(:first)
article.changed? #=> false

# Track changes to individual attributes with
# attr_name_changed? accessor
article.title #=> "Title"
article.title = "New Title"
article.title_changed? #=> true

# See both previous and current value with attr_name_change accessor
article.title_change #=> ["Title", "New Title"]

Lately I’ve had to endure working on a Rails project where the requirements dictate the use of Microsoft SQL Server as the choice database. In addition, we’ve had to test environments consisting of Microsoft Windows/Apache 2.2/Mongrel and Red Hat/Apache 2.2/Mongrel with various adapter(odbc, oledb) and tabular data stream translators. When testing several operating systems, adapters, manipulators, etc there were inevitable issues between the different setups. One of the most common issues was the adapter specific handling of dates. Depending on the adapter’s TDS(tabular data stream), dates can be returned as strings or date objects. This issue made our project less flexible as we were having to modify view code here and there. To solve the issue we extended the rails core and created a DBI override class in the lib directory of our project.

To do this, add a core_ext folder inside of your project’s lib directory. Next, add a ruby file called core_ext.rb; contents shown below.

#Include each of the files in the core_ext directory
Dir[File.dirname(__FILE__) + "/core_ext/*.rb"].each{ |file| require(file) }


Once your core_ext folder and file are setup in lib you’ll need to tell the environment.rb file to include your core extenders. Append the following line to your environment.rb file.

require 'core_ext'

Once our extensions are visible in the environment we can add our date time handler for dates where DBI is the project adapter. Add a file called DBI.rb in the core_ext directory. Contents shown below.

require "date"
module DBI
  class Date
      def to_friendly_str(options = {})
       t = self.to_time
       t.to_friendly_str(options) rescue self
      end

      def strftime(options = {})
        t = self.to_time
        t.strftime(options) rescue self
      end
   end
end

You’ll notice a non-standard method called “to_friendly_str”. You can replace this with stftime or create a custom date string handler like we did. I’ve added to_friendly_str below if you want to add it to the core_ext directory in addition to the DBI module or you can place it in your application controller. Enjoy!

def to_friendly_str(options = {})
# Attempt to init a new time object
# from this string then call
# to friendly_str on it.
    t = Time.parse(self)
    t.to_friendly_str(options) rescue self
end