Safe data migrations

Published at: 9.IV.2008 05:02 CEST
Categories: english, plugin, rails
Comments: 4 pieces

Something ago I wrote about the problems which arise when using models in your Rails migrations. Meanwhile I developed a really simple solution to this problem and today I wrapped it up in to a plugin called SafeDataMigrations.

How to use it? Install it in your Rails application:

ruby script/plugin install http://svn.remvee.net/plugins/safe_data_migrations

and apply it in your migration:

class DowncaseUserNames < ActiveRecord::Migration
  models :user
  
  def self.up
    User.find(:all).each do |user|
      user.update_attributes(:names, user.name.downcase)
    end
  end

Look at the README file for a more elaborate example.

So how does it work? It simply undefines the models your referring to and redefines an empty ActiveRecord class;

Object.send :remove_const, :User rescue nil
class User < ActiveRecord::Base; end

Now you are sure to have a User model available in your migration without any validations which may make data manipulations impossible. The undefining of an already available model also ensures you don’t need to use ActiveRecord::Base.reset_column_information before updating new fields, unless you use your model before altering the table of course.

Update: As coderrr points out you don’t need to clobber the global scope model class because a nested model works fine too. I wrongly assumed introducing a new model class in side (!) a migration class would only reopen my original model class and keep validations intact. To illustrate:

class User; def top; end; end

class Migration
  class User; def nested; end; end
  
  def self.go
    p User.instance_methods - Object.instance_methods
  end
end

Migration.go

yields ["nested"] and not ["top", "nested"] as I suspected. Apparently I was bitten too hard by a problem which arose when I used an original model class to even try the above. I’ll pull the plugin because it’s pointless.. Bad me, thanks coderrr!

Laat je JavaScript zichzelf schrijven

Gepubliceerd op: 20.I.2008 03:46 CET
Categorieën: javascript, programming
Reacties: 3 stuks

Laatst werd me gevraagd wat mooier of beter is:

obj.getItem('Status')
obj.getItem('Status') == 'Completed'

of

obj.getStatus()
obj.isStatusCompleted()

Het laatste voorbeeld is beter omdat het minder foutgevoelig is; een tiepfoutje in het eerste geval kan heel lang blijven sluimeren terwijl in de tweede versie de foutmeldingen meteen om je oren vliegen. Daarbij vind ik de tweede variant ook beter leesbaar.

Drawing Hands, 1948, M.C. Escher De degene die de vraag stelde, gaf me schoorvoetend gelijk. Maar zou dit niet betekenen dat hij deze methoden voor alle 10 statussen uit zou moeten schrijven en is dat dan niet ook weer foutgevoelig? Voorzichtig vroeg ik om welke taal het eigenlijk ging; “JavaScript”. Maar natuurlijk hoef je dat niet helemaal zelf uit te schrijven! JavaScript is, net als Ruby, Lisp en vele andere, een moderne taal en stelt je in staat te meta-programmeren, ofwel programma’s zichzelf te laten schrijven.

Dus geen gedonder met een preprocessor en/of rare annotaties meteen aan de slag met de programmeertaal waar je toch al mee bezig was!

Lees verder →