I’ve been working with Ruby on Rails intensively for several months, and I’ve finally found a place where Rails can’t readily be extended to do what I want. It’s ActiveRecord, which is probably the most controversial part of Rails.
I’m reminded of a James Gosling quote disparaging Microsoft tools, particularly Visual Basic: “The easy stuff is easy, but the hard stuff is impossible.” There’s a parallel between VB and Rails in this instance, in that if you only let yourself use the high level tools, the hard stuff is impossible, but the designers specifically tell you to do the hard stuff using a lower level toolset. The controversy that surrounds “X can’t do everything, therefore it sucks” should really be focusing on the feasibility of going through that trapdoor to do things “the hard way”. This is what Delphi did, which is why so many folks chose it over VB; it made the hard stuff easier.
Continue reading “ActiveRecord: the Visual Basic of Object Relational Mappers”
acts-as-tsearch is pretty cool, except for the fact that it uses Ruby (app layer) instead of PL/pgSQL (DB layer) to update the tsvectors that are indexed for full text search. That means that fixture data gets inserted without being full text indexed. D’oh!
Here’s some code that changes that.
Continue reading “Making the Rails acts_as_tsearch plugin work with fixtures”
Let’s say you’re using Rails with PostgreSQL and the TSearch2 built-in full text search engine.
Did you notice that every time you run
rake test, that depends on
db:test:prepare, which depends on
db:test:clone, which depends on
db:test:purge, which drops the database and creates it again?
Along with your dropped database goes the TSearch2 functions that wrap the C libraries that do the actual work. So, in effect, you no longer have TSearch2 installed. (“Uh… I kinda needed those…”) Presumably if you have tests that exercise search functionality, they will always fail because the TSearch2 functions are gone by the time the tests run.
Continue reading “Making Rails’ rake:test not drop your PGSQL database”
From what I’ve seen, Rails’ weakest features lie in the way it prepares the test database and test data, and Ruby’s Test::Unit isn’t much better than the awful but ubuiquitous JUnit that Java developers are accustomed to. I set out this week to impose my preferences on Rails in this area, and that took some effort. Here’s what I did.
Continue reading “Rails, Fixtures, the Test DB, and Test::Unit”
For the last few days I’ve been struggling to bend Rails to my will regarding the proper way to assure data consistency. Today I made some progress. This builds upon some research I did a few months ago, and hopefully this is a more or less complete solution to the problem of making Rails work the way I want it to regarding test databases.
Continue reading “Rails and the notion of Stupid Databases Being a Good Idea”