Year: 2006

I recently read ‘Getting Real‘, a book (only available as pdf) by 37 signals. 37 signals are the people behind the much hyped Ruby on Rails and a bunch of webapps based on this RoR (=Ruby on Rails) framework.

Why I wanted to read this book
I use RoR with success for an ongoing project at my daytime job and also used it for an ‘after-hours’ sideproject of which at least the development was a success thanks to Rails. I’ve also used Ruby (it works without Rails too) for more little projects and ‘glue’ than I can count.
Seeing that Getting Real is almost as hyped as RoR itself I figured I’d shell out the $19 and check what Getting Real is all about. After all, Rails has turned out to be a very productive and really quite fun web development framework. (but then, after years of doing VC++/MFC development even a lobotomy would seem ‘fun’… or even cobol… nah… just kidding about the cobol)
Continue reading

El Problemo
When issuing a ‘rake db:schema:dump’ (or a simple ‘rake test’ since it uses db:schema:dump) on the legacy oracle db mentioned in the previous post the schema.rb contained some weird entries like:

t.column "timestamp", :datetime, :default => #<date : 4903089/2,0,2299161>, :null => false

The culprits were basically field defaults (like the above, using ‘sysdate’ as default) that aren’t handled properly (not even sure if they should). Since this is a legacy db accessed by tons of mainly C/C++ code on which I’m tacking a web ui, changing this to something that suits Rails is usually not possible.

Any other rake tasks using the schema.rb stumbled over these entries so I was basically unable to do a simple ‘rake test’.

Unfortunately I only found the occasional mention of this issue but not a real solution (yet).

El (hack’n’slash) Solution
Basically all I needed db:schema:dump to work correctly for was being able to run tests. For a variety of accidental reasons I choose to run these tests on a mysql db on a w2k box. (at work I’m using xwin under cygwin on a wxp installation to connect to a CentOS server for my rails development… so this might not seem a logical decision… but explaining the reason behind choosing mysql to run the tests is really totally out of scope of this post)

Easiest solution was to filter the badies (renegades and outlaws) out of schema.rb before it was used for something else.

I made an extra db:schema:clean task to read/filter/write schema.rb, called it from db:schema:dump and put these in a file called ‘databases.rake’ in my Rails lib/tasks folder.

databases.rake:

namespace :db do
namespace :schema do
desc "Create a db/schema.rb file that can be portably used against any DB supported by AR"
task :dump => :environment do
require 'active_record/schema_dumper'
File.open(ENV['SCHEMA'] || "db/schema.rb", "w") do |file|
ActiveRecord::SchemaDumper.dump(ActiveRecord::Base.connection, file)
end
Rake::Task["db:schema:clean"].invoke
end
desc "Fix the sysdate timestamps from an oracle schema.rb"
task :clean => :environment do
File.open(ENV['SCHEMA'] || "db/schema.rb", 'r+') do |f|
lines = f.readlines
lines.each do |it|
it.gsub!(/:default => #<date : 4903089\/2,0,2299161>,/, '')
it.gsub!(/:default => "EMPTY_BLOB\(\)",/, '')
end
f.pos = 0
f.print lines
f.truncate(f.pos)
end
end
end
end


(blame WordPress for losing indentation… at least I do!)

Ok… probably really basic stuff for the harcore Railsers out there, but I hope this will help some ‘nuby’ Railsers save some time hunting for where/what/how with this great framework.

(2nd post today, I’ve got another one up my sleeve but will stop now before someone asks me to take a ‘doping test’)

Situation
A Ruby on Rails project I’m working on during my day-time job (as if I have a night-time one) has a couple of tables with fields that are changed by external processes. (note: it’s a legacy oracle database that’s had some slight mods where possible to make it more Rails-y). The bulk of fields in these tables however contain data that can be changed using a Rails interface I’ve build. These not to be updated fields need to be initialized when writing a new record and should be read (to be displayed) as normal fields.

So what’s the problem then?
Normally you’d just issue an update to only modify the needed fields, but at the moment ActiveRecord can only alter records by doing a read followed by an update of all fields (please correct me if I’m wrong).

This poses the problem that some fields might be changed by an external process after the read and before the write, resulting in ActiveRecord writing the old data back to the table. (resulting in a whole bunch of unwanted, very evil things of which I really don’t even want to think about fixing)

Solution
I found a workaround by overriding update_attributes in my model as
follows:


def update_attributes(attributes)
@attributes.delete('fieldthatshouldnotbechanged1')
@attributes.delete('fieldthatshouldnotbechanged2')
@attributes.delete('fieldthatshouldnotbechanged3')
super(attributes)
end

This effectively deletes the fields from the hash that’s used to construct the update statement. You’ll see in your development.log that the issued update statement doesn’t contain the deleted fields anymore.

I only tried it with update_attributes since that’s what I used to update the fields.

I hope this doesn’t cause any unwanted issues, but if it does I’ll post about it here.