Let me be the first to admit that there’s no one right way to do things. In fact, I’m writing this post particularly because I have a few objections to how this functionality is ultimately exposed, and I’d like to hear arguments from those who disagree. In other words, let me acknowledge the possibility that I am the misguided one.

Review of Nested Object Forms

As a quick review, we can now prepare our models for nested object mass assignment:

class Person < ActiveRecord::Base
 
  validates_presence_of :name
 
  has_many :children
  accepts_nested_attributes_for :children
    # can also be used on has_one etc.. associations
 
end
 
class Child < ActiveRecord::Base
  belongs_to :person
end

We specify which nested relationships can be passed in via mass assignment using the accepts_nested_attributes_for() function. Continuing the example, we can now execute the following to actually save a person and two children at the same time:

person = Person.create!(:name => 'George', :children_attributes => {"new_1" => {:name => 'Amy'}, "new_2" => {:name => 'Stephanie'}})

For full disclosure, my console session from start to finish:

john-mbp:playground john$ rails -v
Rails 2.3.0
john-mbp:playground john$ rails anewapp
...
...
john-mbp:playground john$ cd anewapp/
john-mbp:anewapp john$ ruby script/generate model person name:string
...
john-mbp:anewapp john$ ruby script/generate model child name:string person_id:integer
...
 
# edit app/models/person.rb as above
# edit app/models.child.rb as above
 
john-mbp:anewapp john$ rake db:migrate
(in /Users/john/playground/anewapp)
==  CreatePeople: migrating ===================================================
-- create_table(:people)
   -> 0.0044s
==  CreatePeople: migrated (0.0046s) ==========================================
 
==  CreateChildren: migrating =================================================
-- create_table(:children)
   -> 0.0041s
==  CreateChildren: migrated (0.0045s) ========================================
 
john-mbp:anewapp john$ ruby script/console 
Loading development environment (Rails 2.3.0)
>> person = Person.create!(:name => 'George', :children_attributes => {"new_1" => {:name => 'Amy'}, "new_2" => {:name => 'Stephanie'}})
=> #<Person id: 1, name: "George", created_at: "2009-02-24 00:49:21", updated_at: "2009-02-24 00:49:21">
>> person.children
=> [#<Child id: 1, name: "Amy", person_id: 1, created_at: "2009-02-24 00:49:21", updated_at: "2009-02-24 00:49:21">, #<Child id: 2, name: "Stephanie", person_id: 1, created_at: "2009-02-24 00:49:21", updated_at: "2009-02-24 00:49:21">]
>> person.children.size
=> 2

Pretty cool, huh? I agree. I think this is fantastic, and with the integration with fields_for, it will really ease a lot of the pain that previously existed with multi-model forms.

This said, I’ve got a few major bones to pick with how it’s implemented.

So What’s Wrong?

The primary issue is the fact that this functionality is statically defined (in that you can’t turn it on/off in specific scenarios). Why is this an issue? Well, this is a potentially dangerous functionality to expose everywhere. Let’s say that you wanted to take advantage of this new feature to allow administrators to create new accounts that came pre-loaded with a complementary $X credit to their accounts. So you built a form for admins to fill out that included a fields_for :credits to achieve this single-form implementation of an account with credits. Now, in order to avail of this, I need to turn on the nested mass assignment.

class Person < ActiveRecord::Base
  has_many :credits
  accepts_nested_attributes_for :credits
end
 
class Credit < ActiveRecord::Base
  belongs_to :person
end

Wait….I’ve just turned this feature on globally…..I can’t just make it available at the controller level? But isn’t the controller where I define authorization, who can edit/update/create what? Precisely.

So….unless I want to go old school and rewrite this all by hand, anytime I want to render a person form (e.g. on an “Edit My Profile” link for authenticated users), I need to recall that I’ve exposed myself to a possible POST data hack (anyone who understands this feature in rails will know how to handcraft the POST data). This is a fairly ridiculous thing to expect on a project of any nontrivial size.

However, there’s another way around this issue. Rather than rewriting all of the multi-model form stuff by hand, I could simply ward off the extra parameters at the controller level, e.g.

class ProfileController < ApplicationController
  before_filter :remove_nested_params
 
  def update
    @user = User.find(current_user.id)
    @user.update_attributes!(params[:user])
    redirect_to profile_path
  rescue
    render :action => 'edit'
  end
 
  protected
    def remove_nested_params
      params[:user].delete(:credits)
    end
end

This works fine in isolation or for a one-off, but again, this is a piece of information that is going to be lost as the project trudges along. Your team will forget this, and someone is going to forget to “close the hole” when adding that new “quick edit profile” form that only shows their email address and display name.

Counter Suggestions

I would advocate any solution where this behavior was pushed out to controllers. That said, I don’t have an airtight procedure planned out. I will, however, leave you with a few suggestions.

We could implement it around_filter style where the feature is enabled/disabled in an around_filter. The primary benefit of this approach would be that the majority of the code could probably stay put in ActiveRecord. We’d just need to expose hooks to turn it on/off. Then we could define a controller-level meta-function (e.g. filter_parameter_logging) that could set which actions to apply the behavior on, or which models can be nested. The syntax could look like:

class ProfileController < ApplicationController
  allow_nested_assignment_for User, [:children], :only => [:update]
end

I’ll be perfectly honest in that I don’t love this suggestion. It incorrectly scopes this authorization tweak to the whole action and any before/after filters that execute in between it (still leaving holes, albeit smaller) as opposed to scoping it directly to the single save! action that we really want to special-case. If we perhaps exposed a separate save_with_nested() function, then we could isolate the scope down to the specific call. Needless to say, I doubt this is a course of action rails would take, and it’s not one I would advocate.

Another alternative would be to keep the functionality as is, but then allow you to override or extend it at the controller level (a la my initial suggestion). This would allow developers to avail of the benefits in the less-risky areas, and then conditionally avail of them in more risky areas by simply turning it on for specific controller/action combos. In this case, we’d define a basic harmless nested assignment baseline in the model, and the more risky nested assignment in those controllers where we wanted to isolate it, e.g.

class Person < ActiveRecord::Base
  has_many :children
  has_many :credits
  accepts_nested_attributes_for :children
end
 
class Admin::PeopleController < ActiveRecord::Base
  allow_nested_assignment_for User, :credits, :only => [:create, :update]
end

The primary benefit of an approach like this is that it aligns properly to a developer’s train of thought. When you go to add a trivial feature, you don’t think “I need to close that gap my unrelated nontrivial feature added for me.” However, when you go to add a nontrival feature (like allowing an admin to auto-create credits in their new account form), you do think “what do I need to differently?” In the former case, the developer thinks his new feature is trivial, and doesn’t expect to have do anything exceptional for it. In the latter case, the developer thinks his new feature is nontrivial, and will think about it from a “what extra work does that mean for me?” standpoint.

Closing Thoughts

One of the biggest things that worries me is that no one is talking about this. The whole community requested this feature, and at this point it has received quite a bit of fanfare. But there are some clear ways to accidentally screw yourself that just aren’t being mentioned as caveats.

To be entirely blunt, I just feel like this is plugin material at this point. Though I commend rails for opening up its feature set to a community vote, I fear that we may have misstepped with this feature in particular. I’m very curious to hear what others think. (Be gentle with the flame)

I started by creating a module that opens up the will_paginate collection class and includes ActiveResource and alias method chain the to_xml method to include these values. Example code below.

#enviroment.rb
...
require 'to_xml_extensions'

#lib/to_xml_extensions.rb
module WillPaginateHelpers
  include ActiveSupport::CoreExtensions::Array::Conversions
  def to_xml_with_collection_type(options = {})
        serializeable_collection.to_xml_without_collection_type(options) do |xml|
          xml.tag!(:current_page, {:type => ActiveSupport::CoreExtensions::Hash::Conversions::XML_TYPE_NAMES[current_page.class.name]}, current_page)
          xml.tag!(:per_page, {:type => ActiveSupport::CoreExtensions::Hash::Conversions::XML_TYPE_NAMES[per_page.class.name]}, per_page)
          xml.tag!(:total_entries, {:type => ActiveSupport::CoreExtensions::Hash::Conversions::XML_TYPE_NAMES[total_entries.class.name]}, total_entries)
        end.sub(%{type="array"}, %{type="collection"})
      end
      alias_method_chain :to_xml, :collection_type
 
      def serializeable_collection #:nodoc:
        # Ugly hack because to_xml will not yield the XML Builder object when empty?
        empty? ? returning(self.clone) { |c| c.instance_eval {|i| def empty?; false; end } } : self
      end
end
 
WillPaginate::Collection.send(:include, WillPaginateHelpers)

This now gives me the proper xml when I call to_xml

<?xml version="1.0" encoding="UTF-8"?>
<time-cards type="collection">
  <current_page type="integer">1</current_page>
  <per_page type="integer">25</per_page>
  <total_entries type="integer">108</total_entries>
  <time_card>
    <approved type="boolean">false</approved>
    <billable type="boolean">false</billable>
    <created_at type="datetime">2008-10-10T14:04:13-04:00</created_at>
    <date type="datetime">2008-10-10T14:04:13-04:00</date>
    <has_been_billed type="boolean">false</has_been_billed>
    <has_been_paid type="boolean">true</has_been_paid>
    <hours type="float">2.0</hours>
    <id type="integer">98</id>
    <is_overtime type="boolean">false</is_overtime>
    <task_id type="integer">6</task_id>
    <updated_at type="datetime">2008-10-10T14:04:13-04:00</updated_at>
    <user_id type="integer">1</user_id>
  </time_card>
  ...
</timecards>

So what do we do?

You could multithread the application, and the simple way is to say:

items.each do |i|
  Thread.new(i) do |i|
    handle(i)
  end
end

The problem is that this will spawn 1000 threads, each of which will go out simultaneously, and after 100ms when they come back your system will be overloaded.

Ideally, we would like to pipeline the processing to that each ms of execution we are working on one thread, so our cpu is used to the max as well as our internet connection. In this ideal situation, the task would take 10000ms (10ms per item) + 100ms (time to wait for first to come back).

So a little calculation lets us know that we want 10 threads working at once, each 10ms apart from each other. Now we’re going to get into thread pooling! Actually, I am going to be working with forking, which is more memory intensive but it can actually use multiple cores, so it’s more useful. Using enterprise ruby, a lot of that memory is shared, so it’s not so bad.

# here we keep our items
items_to_process = my_items
# max at once
max_process = 10
# keep track of the processes running
processing_pids = {}
# while we have items to work on and we aren't done with the
# ones we're working on
while !items_to_process.empty? or !processing_pids.empty? do
  # If we are below our max number of running items,
  # add a thread
  while items_to_process.size < max_process do
    item_to_process = items_to_process.pop
 
    # keep the connection across the forks
    ActiveRecord::Base.remove_connection
    pid_starting = Process.fork{
      ActiveRecord::Base.establish_connection
      process_item(item_to_process)
      ActiveRecord::Base.remove_connection
    }
    ActiveRecord::Base.establish_connection
    # keep track of the item by pid.
    #You could put other stuff in this hash too
    processing_pids[pid_starting] = {:item => item_to_process}
  end
 
  # pick up a finished task. This will get one task whose
  # parent is the current thread.
  # If it doesn't get one immediately, it returns nil and loops
  if pid_done = Process.wait(0, Process::WNOHANG)
    # grab it out of the hash
    if job_finished = processing_pids.delete(pid_done)
      puts "We finished item #{job_finished[:item].to_s}"
    end
  end
  # quick nap so we don't hit this loop a lot
  sleep(0.001)
end

The basic idea here is to keep a pool of forks running, and each 1ms we’ll check to see if any finished and need to be started. When a fork finishes we can do any post-processing, and the next time around the loop a new one will be added.

The Options Hash

The most obvious way to change the output is to use the options hash outlined in the docs. A short list of options you might want to explore is:

• except => [:attr1, :attr2] — excludes attributes in array from output
• only => [:attr1, :attr2] — output contains only the specified attributes
• include => [:assoc1, :assoc2] — calls to_xml on the given first level association and nests it in the output
• methods => [:meth1, :meth2] — adds a tag to output in the format <method-name>[method output]</method-name>

Usage is incredibly simple:

  # grab xml for a record and its child
  my_record.to_xml(:include => :child)
 
  # same, but only output the ids and names (assuming both have these attributes)
  my_record.to_xml(:only => [:id, :name], :include => :child)

Behold, the Builder

A fantastic feature of to_xml that Ryan blogged about last year is that it yields the builder, thus allowing you to add arbitrary tags into the output. What’s more is you can pass the builder into another object’s to_xml method inside the outer block and produced nested xml.

For example:

  # Arbitrarily insert a tag
  my_record.to_xml do |xml|
    xml.some_tag some_value   #=> <some_tag>some_value</some_tag>
  end
 
  # I want to get xml for my record and all its children
  my_record.to_xml do |xml|
    my_record.children.each{|child| child.to_xml(:builder => xml, :skip_instruct => true)}
  end

You can nest as deep as you want without overriding a model’s own to_xml method:

  output = my_record.to_xml do |xml|
    my_record.children.each do |child|
      child.to_xml(:builder => xml, :skip_instruct => true) do |fxml|
        child.grandchild.to_xml(:builder => fxml, :skip_instruct => true)
      end
    end
  end

deep_xml: Model methods that utilize (but do not overwrite) to_xml

I chose to write methods in the models that handled including the children’s xml such that a single call to my_record.full_xml would produce nested xml automatically. Notice how the builder is being passed to the children, it’s important!

  class ParentClass < ActiveRecord::Base
    has_many :children
 
    def deep_xml(builder=nil)
      to_xml(:builder => builder) do |xml|
        children.each{|child| child.deep_xml(xml)}
      end
    end
  end
 
  class Child < ActiveRecord::Base
    belongs_to :parent
    has_one :grandchild
 
    def deep_xml(builder=nil)
      to_xml(:builder => builder, :skip_instruct => true) do |xml|
        grandchild.to_xml(:builder => xml, :skip_instruct => true)
      end
    end
  end
 
  class Grandchild < ActiveRecord::Base
    belongs_to :child
  end
 
# Now the call is simple:
Parent.firstdeep_xml #=> custom xml for a parent that includes its 
                        #   children and their grandchildren (1 each in this case)

There’s not much to it, but I found this solution to be nice shorthand that cleaned up ugly nested to_xml blocks I was writing over and over. I call my_record.deep_xml from any layer of the family tree and return a nice drill down of data to the leaf children. It’s great if you’re working with a complicated database and need to be able to present your data in xml.

If you are so inclined…

If you really need to, you can just overwrite the to_xml method in the model. While fine to do if you know you’ll always want that one specific template, I avoid it as much as possible and won’t cover it since examples are all over the blogosphere. Why not just make a separate function to avoid producing unexpected results for someone else who joins your project later on?

Model

class ExportSearch
 
  def timecards
    find_cards
  end
 
  def users(u)
    @u = u
  end
 
  def projects(p)
    @p = p
  end
 
  def tasks(t)
    @t = t
  end
 
  def dates(date1, date2)
    @d1 = date1
    @d2 = date2
  end
 
  def clients(c)
    @c = c
  end
 
private
 
  def find_cards
    TimeCard.find(:all, :conditions => conditions, :include => {:task => :project}, :order => :date)
  end
 
  def projects_conditions
    ["tasks.project_id IN (?)", @p] unless @p.blank?
  end
 
  def client_conditions
    ["projects.client_id IN (?)", @c] unless @c.blank?
  end
 
  def date_conditions
    ["date BETWEEN ? AND ?", @d1, @d2] unless (@d1.blank? || @d2.blank?)
  end
 
  def task_conditions
    ["task_id IN (?)", @t] unless @t.blank?
  end
 
  def users_conditions
    ["user_id IN (?)", @u] unless @u.blank?
  end
 
  def conditions
    [conditions_clauses.join(' AND '), *conditions_options]
  end
 
  def conditions_clauses
    conditions_parts.map { |condition| condition.first }
  end
 
  def conditions_options
    conditions_parts.map { |condition| condition[1..-1] }.flatten
  end
 
  def conditions_parts
    private_methods(false).grep(/_conditions$/).map { |m| send(m) }.compact
  end
end

Controller

    search = ExportSearch.new
    search.users(params[:export][:users].join(',')) unless params[:export][:users].blank?
    search.tasks(params[:export][:tasks].join(',')) unless params[:export][:tasks].blank?
    search.projects(params[:export][:projects].join(',')) unless params[:export][:projects].blank?
    search.dates(start_date, end_date)
 
    @time_cards = search.timecards

  def object
    tmp = objects.first
    objects.each {|o| tmp.attributes.each {|key, value| tmp[key] = o[key] if value.blank? && key != 'id'}}
    tmp.freeze
  end

However there was a flaw here. Every time I would view the page all of the data in the objects was getting overwritten with one copy of it. After banging my head on the desk it was realized that tmp[key] = o[key] was actually writing the changes to the database permanently rewriting all of the objects (which still seems counter intuitive to me, because it seems like only the first record should have been the one changing). But the solution was pretty simple. The working method is as follows.

  def object
    tmp = Object.new
    objects.each {|o| tmp.attributes.each {|key, value| tmp[key] = o[key] if value.blank? && key != 'id'}}
    tmp.freeze
  end

After a few starts and stops, many hours of reading through the webdav documentation, and browsing through the http traffic using Fiddler – it was determined that locking was the issue.

What I found in the RailsDav plugin is that the implementation of locking is as follows (lines 92-100 of railsdav/act_as_railsdav.rb):

def webdav_lock()
    #TODO implementation for now return a 200 OK
    render :nothing => true, :status => 200 and return
end
 
def webdav_unlock()
    #TODO implementation for now return a 200 OK
    render :nothing => true, :status => 200 and return
end

However, Microsoft actually won’t let you edit a document with such lax locking. So I rewrote the lock method so that it returned a valid lock.

def webdav_lock()
     @lock = get_lock(@path_info)
     if @lock
         response.headers["Lock-Token"] = "<#{@lock.token}>"
         response.headers["Content-Type"] = 'text/xml; charset="utf-8"'
         render :inline => self.class.lock_xml, :layout => false, :type => :rxml, :status => 200  and return
       else
         render  :nothing => true, :status => WebDavErrors::ForbiddenError and return
       end
end

There were a few other pieces of code that were needed to get this working though. Namely the .lock_xml method, and get_lock. Let’s tackle them each in turn.

In railsdav/propxml.rb you can find the XML structures for the PROPFIND and the PROPPATCH methods for WebDAV. However both locking and unlocking require their own structures. So I added one for locking. It is as follows:

def lock_xml
<&lt;EOPROPFIND_XML 
         xml.D(:multistatus, {"xmlns:D" => "DAV:"}) do
           xml.D :lockdiscovery do
             xml.D :activelock do
               xml.D :locktype do 
                 xml.D @lock.type.to_sym
               end
               xml.D :lockscope do 
                 xml.D @lock.scope.to_sym
               end
               xml.D :depth, @lock.depth
               xml.D :timeout, @lock.timeout_full               
               xml.D :locktoken do 
                 xml.D :href, @lock.token
               end               
               xml.D :lockroot do 
                 xml.D :href, @lock.href
               end
             end
           end
         end  
EOPROPFIND_XML
end

Then there is the get_lock method. Writing get_lock was a two step process. If you look at (lines 269-287 of railsdav/act_as_railsdav.rb) you can see several methods that are very similar in function to their respective purposes. So I began by simply adding the following in this section:

def get_lock(path)
      raise WebDavErrors::ForbiddenError
end

Then in my application’s controller that overrides all of the acts_as_railsdav methods I did just that:

def get_lock(path)
    return false unless get_resource_for_path(path).locked?
    return ActiveRecordLock.new({:type => 'write', :scope => 'exclusive', :timeout => 60*60*5, :href => path, :id =>4})
end

So now you’ll notice two new things that need coding here. The .locked? method for the resource and ActiveRecordLock. We decided to not worry about multiple users editing the same document at the same time on this project. Because of this and the time constraints .locked? simply returns true. If one were to deal with unlocking at some point this would have to be come a check to the database or something to make sure that the document is indeed unlocked. The same goes for ActiveRecordLock. It really just deals with the flat information needed by the Lock XML and not saving it to check if it is locked later on. Maybe someday, somebody will undertake that task I suppose. Anyway, here is what I had for the portion of the ActiveRecordLock model that I needed.

class ActiveRecordLock
   attr_accessor :type, :scope, :timeout, :depth, :timeout_units, :href, :token
 
   def initialize(args)      
      @type    = args[:type]
      @scope   = args[:scope]
      @timeout = args[:timeout]
      @href    = args[:href]  
      @depth   = 'Infinity'
      @timeout_units = 'Second'
      @token   = build_token(args[:id])
   end
 
   def timeout_full
     "#{self.timeout_units}-#{self.timeout}"
   end
 
   protected
     def build_token(text)
       require 'digest/md5'
       md5 = Digest::MD5.hexdigest(text.to_s).to_s
       'opaquelocktoken:'+md5[0,7]+'-'+md5[8,11]+'-'+md5[12,15]+'-'+md5[16,19]+'-'+md5[20,31]
     end
end

There is still plenty that needs to be done to get the full lock/unlock, but hopefully this will get someone started and save a few headaches.

  # Maps logical Rails types to MySQL-specific data types.
  def type_to_sql(type, limit = nil, precision = nil, scale = nil)
    return super unless type.to_s == 'integer'
 
    case limit
    when 0..3
      "smallint(#{limit})"
    when 4..8
      "int(#{limit})"
    when 9..20
      "bigint(#{limit})"
    else
      'int(11)'
    end
  end

Mirko Froehlich suggests monkey patching this function. Timothy Jones blogged about it.

To monkey-patch this, just drop a file (fix_mysql_adapter.rb) into your initializers/ directory, as such:

module ActiveRecord
  module ConnectionAdapters
    class MysqlAdapter < AbstractAdapter
      # Maps logical Rails types to MySQL-specific data types.
      def type_to_sql(type, limit = nil, precision = nil, scale = nil)
        return super unless type.to_s == 'integer'
 
        case limit
        when 0..3
          "smallint(#{limit})"
        when 4..11
          "int(#{limit})"
        when 12..20
          "bigint(#{limit})"
        else
          'int(11)'
        end
      end
    end
  end
end

All we’ve done is change how the mysql adapter interprets the limit attribute. In my opinion, this isn’t a particularly great solution, as it’s more appropriate for non-foreign key integers to behave as the rails team suggested. This really only affects us when we’re dealing with foreign keys, because mysql enforces our column types to match.

The Real Problem
So, if the problem isn’t here, where is it? The problem actually lies in the schema dumper. Notice in the previous code samples the else clause in the case statement. If limit is nil (or outside of 0..20), then this falls back to int(11). Curiously, when I have a migration such as the following, the schema dumper adds a :limit => 11, even though I didn’t specify it!

$> rails test -d mysql
$> cd test
$> ruby script/generate model user name:string
$> ruby script/generate model game name:string user_id:integer
$> rake db:create db:migrate

First, let’s check our game migration to verify that it doesn’t specify :limit => 11.

class CreateGames < ActiveRecord::Migration
  def self.up
    create_table :games do |t|
      t.string :name
      t.integer :user_id
 
      t.timestamps
    end
  end
 
  def self.down
    drop_table :games
  end
end

So, there’s no limit specified. But let’s take a look at schema.rb.

ActiveRecord::Schema.define(:version => 20080624161220) do
 
  create_table "games", :force => true do |t|
    t.string   "name"
    t.integer  "user_id",    :limit => 11
    t.datetime "created_at"
    t.datetime "updated_at"
  end
 
  create_table "users", :force => true do |t|
    t.string   "name"
    t.datetime "created_at"
    t.datetime "updated_at"
  end
 
end

Ah ha! Where’d that :limit => 11 come from? The schema generator!!! This is our culprit. We need to isolate the schema generation code, and ensure that isn’t forcing :limit => 11 onto our integers that don’t explicitly set a limit.

As I started down this track, I hooked up with Rob Sterner from ITA Software on IRC. He filed the original ticket. By the time I got in touch with him, he pretty much had the problem solved.

First, let’s fully illustrate the problem. When you run migrations, naked integer statements

t.integer :myvalue

are inserted into the database with :limit => 11 (this is handled by the extract_limit() function in the adapters). SchemaDumper.dump is called after your migrations are finished, and creates schema.rb by inspecting the database (not your migrations — which makes sense). However, when extracting the information from the database, the SchemaDumper picks up this limit of 11, which causes it to write this out in your schema.rb file:

t.integer :myvalue, :limit => 11

See a problem? Yup, where in our migration we did not explicitly set a limit, the SchemaDumper did!

The Solution
So what’s the solution? Well, what we need to do is alter SchemaDumper to identify int(11), and special case the output (so that :limit => 11 is not appended). At first, this seemed very hacky to me. What if I want a bigint(11) and not int(11)? Well, turns out this isn’t a valid concern. Why? If we really wanted bigint(11), our migration would look different:

t.integer :myvalue, :limit => 11

So, when migrations are run, this field would be placed into the database as a bigint(11) column. And, when SchemaDumper encounters it, it will also see it as bigint(11), As long as our special case discriminates between bigint(11) and int(11), then we’re in the clear! The fact is, in rails 2.1, there’s no way to get an int(11) column in mysql unless you’ve left off the :limit in your migration.

Where’s the patch?
Funny (read: agonizing) story…..we were testing all of this against 2.1.0. When we checked out edge rails, all of this code had changed!!! In fact, looks like Jeremy Kemper (bitsweat) already fixed it.

For the sake of completeness, I’m including the patch that Rob threw together that does the trick for 2.1.0. This patch applied to /activerecord-2.1.0/lib/active_record/connection_adapters/mysql_adapter.rb does the trick.

127c127,129
<           else
---
>           elsif sql_type == 'int(11)'
>             nil # special case for :integer columns w/ no explicit :limit set in their migration
>           else

The Lesson
Check out edge rails to make sure that the problem is still unresolved before you spend all day on something!!!

Also, be aware that edge has changed the meaning of :limit. See the ticket for Jeremy’s explanation. Up through Rails 2.1, the :limit attribute for integers dictated the display width. In other words, it did not specify the storage size, but rather the amount of space mysql would use to display it when returning query results. Moving forward, it will be used to indicate the number of bytes to use for storage. Rails will now effectively use tinyint (1), smallint (2), mediumint (3), int (4) and bigint (8). So, prepare yourselves accordingly.

Special thanks to Rob Sterner for spending lots of time today working through this with me.