MS SQL Server and Those Pesky NULLs

2008-03-19T22:38:00Z

So I'm working on a Rails application with a MS SQL Server 2005 back-end. The application needs to access the Dynamics GP data stored on that server, and while I could have other tables (users, sessions, etc) stored separately in, say MySQL, I elected to keep them all together, at least for the time being. (I'll detail the steps I used to get unixODBC and FreeTDS installed and working on OpenBSD 4.2 in another post. In the meantime, this is the Rails wiki article that got me started. Anyways, back to the problem I ran into. Parts of the application follow the standard Rails new/create idiom. A user clicks on the New Foobar link, and gets taken to a blank form to fill-out. However, with this unixODBC/FreeTDS/MS SQL setup, all of my text fields were winding defaulting not to blanks, but to the text string "NULL". A quick search on Google turned up this issue on Rails Trac, along with a temporary monkeypatch fix posted in the comments by meekish:

ActiveRecord::Base.class_eval do
  def attributes_from_column_definition_with_null_fix
    returning attributes = attributes_from_column_definition_without_null_fix do
      attributes.each_value { |value| value.replace('') if value == 'NULL' }
    end
  end
	
  alias_method_chain :attributes_from_column_definition, :null_fix
end

He suggested putting this in a lib/ file, and requiring that file in environment.rb. This was cool, and it almost met my needs. Being picky, I wasn't quite satisfied with replacing a "NULL" string with a blank. It's supposed to represent a null value. Then there's a more practical issue: if new action created a new object, saved it, and immediately redirected to an edit action (long story), Ruby would scream. So here's my version of this monkeypatch that instead replaces "NULL" strings with nils:

ActiveRecord::Base.class_eval do
  def attributes_from_column_definition_with_null_fix
    returning attributes = attributes_from_column_definition_without_null_fix do
      attributes.each_pair do |key, value| 
        attributes[key] = nil if value == 'NULL'
      end
    end
  end
	
  alias_method_chain :attributes_from_column_definition, :null_fix
end

Works like a charm.

Food Goes In Here

2008-03-18T19:56:00Z

There's an episode of The Simpsons where Homer's inner-child point's to his mouth saying "Food goes in here." To which Homer replies "It sure does."

Model	<= Business logic goes in here
View
Controller

It sure does. As a general rule I avoid blogging about the obvious, but sometimes what's obvious varies from person to person. I've run into the misconception that Rails does not support this obvious statement, that business logic goes into the Model. In Rails, according to this misconception, the Model is simply a Data Access Layer, and business logic winds up in the helpers or elsewhere. The purpose of this post is mainly to give me something to link to or copy and paste as the mood strikes me when I next run into this misconception. In Ruby on Rails, as in any good MVC framework, business logic goes in the Model. All of it. Every shred of it. I'm currently working on a project to develop a point-of-sale and online purchasing system with a great deal of very complex (some might argue overly complex) business logic. As a simpler example, displaying the available quantity of a specific item involves considering at which warehouse the order is being fulfilled, the quantities in various bins, and quantities from the bins which have already been allocated to an order but not yet pulled. None of that business logic is in the Controller. None of it is in the View. And none of it is in a helper. It's all in the Model. The only thing the View needs to do is this:

item.quantity_available

I'm not sure where this notion that business logic goes in the helper comes from. For the record:

A helper is simply a module containing methods that assist a view. Helper methods are output-centric. They exist to generate HTML (or XML, or JavaScript) -- a helper extends the behavior of a template.

-- <u>Agile Web Development With Rails</u>, Dave Thomas, David Heinemeier Hansson

Put another way, you can off-load code to the helper to avoid putting too much into your View templates.

For further reading on this topic, here's a few handy links:

Skinny Controller, Fat Model by Jamis Buck
RailsConf Recap: Skinny Controllers by Jamis Buck
Skinny Controller, Fat Model by Colin A. Bartlett
Find methods in controllers by Graeme Nelson
Rspec notes from the trenches-2 by Courtenay over on Caboo.se

This Old Coder - Home

MS SQL Server and Those Pesky NULLs

Food Goes In Here