Hoping to improve performance, we changed a query to use the :include condition like this:
Project.find(id, :include => :stories)
and we noticed two things:
- ActiveRecord decided to turn that into a LEFT OUTER JOIN. Egads! This drastically slowed things down (although we didn’t notice until several days later, when we ran a real load test with production data).
- acts_as_paranoid did not manage to stick it’s little “and deleted_at = nil” phrase into the query. This meant that “deleted” stories showed up when they weren’t supposed to.
So that’s two gotchas for the price of one.
In email, Nick pointed out that the joining behavior is documented and appropriate (”otherwise if there is a nil association (eg a project without any stories) you wouldn’t get a project back even though it exists!”) and Miho rejoined that AR can be dangerous because it changes what looks like beautiful, elegant Ruby into nasty, ugly, hard-to-understand SQL under the hood.
Only project updates today.
Never be afraid to refactor. It may seem scary right now, but it will only become more daunting as the code base increases in size.
The right time to refactor is NOW… grasshopper
And now that my pair and I have rallied around this post, to the refactoring!
- Subversion Tip: We were reminded of a handy tip: when saving shell scripts in subversion, you can save them as both executable and also in a ‘native’ end-of-line style, which will run on any platform.
$> svn propset svn:executable ON somescript.sh
$> svn propset svn:eol-style native somescript.sh
- Another handy plugin we’ve used many times: QueryTrace. It helps you find slow database queries, but it really floods your logs with data, so make sure to turn it off in production!
- We’re using appable_plugins for several projects but having problems with dependencies between the plugins, especially in fixtures. This might be caused by our fancy-dancy fixture loading extensions.
Ask for Help
ruby -r profile, and our own custom ruby test benchmarker, amongst others.
- One project is seeing a very strange memory leak that causes 100MB of memory loss per second (guh! guh!). It started when they begin using
ActiveRecord.connection.execute("some sql") to build some reporting statistics, but it seems too early to blame that. Coincidental, though.
Brown Bag Lunch Topic: Rails 1.2 features, ideas, and gotchas.
Total Stand-up Meeting Time: 25:00 minutes
- We’ll be sending 6 people to RailsConf, so say ‘hi’ if you see the Pivots!
- We have a fix to our Amazon S3-causing-mongrel-to-hang problem: you can tell the connection not to be persistent by passing in
:persistent => false:
:access_key_id => access_key,
:secret_access_key => access_key,
:persistent => false
Ask for Help
Total Stand-up Meeting Time: 14:00 minutes
Not much of interest today beyond project updates.
Total Stand-up Meeting Time: 17:00
Ever do “
less log/development.log” and see the following?
ESC[4;35;1mSQL (0.001084)ESC[0m ESC[0mSET character_set_results = utf8;ESC[0m
ESC[4;36;1mSQL (0.001792)ESC[0m ESC[0;1mSHOW TABLESESC[0m
Wouldn’t it be nicer to see the colorization like when you’re tailing the log with
tail -f? Try using -R:
less -R log/development.log
Then you’ll see
SQL (0.001084) SET character_set_results = utf8;
SQL (0.001792) SHOW TABLES
A bit more legible, eh wot old chaps?
Works on Mac and Cygwin too.
And -X makes it not clear the screen when you stop less, so you get to keep seeing what you were just seeing.
So that means you may want to put
alias less="less -RX"
Also, if you don’t want the fancy colors at all, specify
ActiveRecord::Base.colorize_logging = false
in your environment file (e.g.
test.rb.) We’re doing that in our
test.rb so we can more clearly read the output from our CruiseControl build.