Neutron Flux

Migrations Without a Restart on Heroku

I ran into a situation today where I had 10 long running background processes that were getting bogged down because we were missing an index. The app is running on Heroku on a shared database, so I don’t have the luxury of using psql to add the needed index. However, I wanted to figure out a way to add the index without restarting the long-running processes.

My solution was to log in via the console, and create the migration by hand.

Once complete, I added a new migration within the source code that has the option :quiet => true (_updated: see note below), so that all environments/developers get the manually created index that resides in production. Had I just done a git push to heroku, the background processes would have restarted. The results of adding the needed index can be seen in our New Relic stats below:

Note: I thought :quiet was a valid option for add_index, but it is actually a patch that you will need to add for your specific database. The following article describes a patch for MySQL. See mine for PostGreSQL.

Emacs Configuration

I’ve had my emacs configuration under version control for the better part of the last decade, cvs then svn, and for the last 3 years git. I finally bit the bullet, and purged it of private data. Since I doubt the history is that interesting to most people, I kept a local historical branch, and then truncated the master branch which is now available in my github repos.

I used to use a monolithic .emacs file. When I declared .emacs bankruptcy a few years ago, I followed @rmm5t’s and @defunkt’s conventions… albeit probably not as nicely.

Forcing :before_validations to run and save the updated data

I meant to write this up awhile ago, but just want to get it out… Have you ever decided to massage incoming data in a :before_validation. I ran into an issue recently where I added a change to a before_validation to remove extraneous characters from phone numbers. I already had a ton of numbers in the system, so I thought I would then be able to just iteration through the list of phone numbers and resave them, and voila… my data would be updated and I could then enable additional validation checks.

Nothing happened. After a bit of digging I realized that Rails was assuming that nothing was changing because the new phone number value was the same as the old value so no save was occurring and validations (and before_validation hooks) were not being run. Turning off partial updates temporarily in the console allowed me to resave my data and have the new before_validation hook massage my data.

Shoulda Snippets For Emacs

I have just updated my Shoulda snippets for the Emacs YASnippets templating package. Shoulda is a ruby-based testing framework that consists of test macros, assertions, and helpers added on to the Test::Unit ruby framework. The snippets are based, and in many cases copied from the TextMate Shoulda snippet bundle, and modified where needed to work with the YASnippets package. New features in the recently released 0.6beta of YASnippet allow support for more of the TextMate-based snippets. The new YASnippet functionality is discussed in more detail in a post I did on Emacs Blog.

In order to port many of the snippets over from the TextMate bundle I wrote a script that automates the process. There is a Python script that does something very similar. The writing of my script was more of just a code kata for me, so take a look at both. One may be more suitable for your needs.

Better Oracle Support For db:structure:dump

If you have tried

$ rake db:structure:dump

in a rails app when using Oracle as your database, then you have probably been slightly disappointed. The same rake task for MySQL and Postgres dumps everything you need to recreate the database. The task for Oracle only dumps SQL for the table creation (no constraints), and for the sequences. The “active_record_oracle_extensions”:http://github.com/eyestreet/active_record_oracle_extensions/tree/master plug now supports dumping sql for the following:

• primary keys
• indexes
• foreign keys
• synonyms

I have added enough functionality to scratch my itch. If you need something else or find a bug let me know.

active_record_oracle_extensions Plugin

The “active_record_oracle_extensions plugin”:http://github.com/eyestreet/active_record_oracle_extensions/tree/master provides support for adding foreign keys to migrations, adding synonyms to migrations, and disabling foreign key constraints during fixture loading. These are features that I needed in my applications, but either did not exist in other plugins, or the plugins seem to have been abandoned.

Installing into a Rails app

$ script/plugin install git://github.com/eyestreet/active_record_oracle_extensions.git 

Adding Foreign Keys In a Migration

The example below shows a snippet from a migration that adds a foreign key.

def self.up
    create_table :assets, :force => true do |t|
      t.integer :media_record_id
      t.string  :media_file_name
      t.string  :media_content_type
      t.integer :media_file_size
      t.datetime :media_updated_at
      t.timestamps
    end
    add_foreign_key_constraint :assets, :media_record_id, 
                                        :media_records, :id
 end

Adding a Synonym in Migration

The example below shows the creation of a synonym named events for other_user.events. The force option adds “or replace” to the sql that generates the synonym. It is assumed that the user under which your are creating the synonym already has the needed grants to allow the creation of the synonym on other_user.

add_synonym :events, :other_user, :events, :force => true

Disabling Constraints During Fixture Loading

If you are using sys or system as your user for your rails application, then do not use this plugin, or use it at your own risk. During fixture loading, this plugin disables constraints for the user that has established the connection to oracle, and then re-enables the constraints after the load.