Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Standup 5/9/2008


  • attr_readonly marks an attribute as, ah, read only — use it to tell ActiveRecord that an attribute should not be a part of update operations. Rails uses attr_readonly internally with counter caches (search for “counter_cache” under ActiveRecord::Associations::ClassMethods) since counter caches are incremented/decremented directly in the database with sql. Without attr_readonly, subsequent updates of the counter_cache’d model would revert the counter to the value of the counter at the time the model was loaded.

Note: attr_readonly was either buggy or not exposed prior to 1.2.3. If you are using a version of rails prior to 1.2.3 you can do this instead:

def attributes_with_quotes(include_primary_key = true)
  attributes.inject({}) do |quoted, (name, value)|
    if column = column_for_attribute(name)
      # original:
      # quoted[name] = quote_value(value, column) unless !include_primary_key && column.primary
      quoted[name] = quote_value(value, column) unless !include_primary_key &&
          (column.primary || ["your_attributes", "listed_here"].include?(

Ask for Help

  • help: Looking for recommendations on converting an existing schema to a new schema. We are considering dumping the existing schema to yaml (using ar_fixtures) and making the transformations there.
    • answer #1: One recent project had a “liberate” script that extracted information from the legacy database via sql statements and constructed AR model objects as necessary. The liberate script grew to some 1500 lines of code and was refactored many times.
    • answer #2: Another project did the data migration by first importing the legacy database and then using rails migrations as needed to transform the data to the new schema. Most of the migrations used sql for the transformations. These migrations did not have associated unit tests.
    • Please offer your suggestions in the comments.

  1. Gerrit Kaiser says:

    We used something like #2 on a current project. But because the legacy database was in active use on a live site and was only periodically ported over to the new app and the schema of the app was evolving we decided to create an extra stream of migrations for the legacy import using this:

  2. Scott Tamosunas says:

    I had to migrate a M$SQL DB to a MySQL DB about a year ago. Not finding a suitable driver for M$SQL at the time for AR, I did the following:

    1. Wrote an ETL process in Java that dumped date from M$SQL into a MySQL tmp schema, preserving the current schema structure.

    2. Exported the current data into yml, doing all the transformations I wanted at this point.

    3. The DB was small enough that I actually didn’t dump out to yml files but held the info in memory. Using key_list and value_list from fixtures.rb (I had to slightly adapt them) I wrote a small method to execute insert statements (assume objects is your yml hash). I ran into some trouble trying to import directly with yml but honestly cannot remember what it was.

    objects.each {|key, value|
    ActiveRecord::Base.connection.execute “INSERT INTO #{table_name} (#{key_list(value)}) VALUES (#{value_list(value)})”

    Hope it helps,


Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *