Rebecca’s Ramblings

Hmmm, after lots of time spent writing things like

item = Item.new
item.date = "#{params[:item]['date(1i)']}-#{params[:item]['date(2i)']}-#{params[:item]['date(3i)']}"

I’ve accidentally found out that Item.new(params[:item]) is clever enough to see these 3 parameters, know that they’re from a date_select, and combine them to form a date.

The Rails API for the date_select method specifies this now. I’m fairly sure it didn’t a while back…

I’ve finally worked out why Eclipse has been crashing with out-of-memory errors all the time since I upgraded to Ubuntu Feisty.

Before this release, I was using a version of Eclipse I had installed manually. This time, I’m using the version packaged by Ubuntu.

The application launcher provided by Ubuntu calls /usr/bin/eclipse, which is a shell script wrapping the call to /usr/lib/eclipse/eclipse (which is what actually launches Eclipse). This wrapper adds some -vmargs to the call, which means that Eclipse ignores any -vmargs you’ve specifed in your eclipse.ini file… such as the ones to increase the Java heap size so as to stop Eclipse crashing with out-of-memory errors if you’re working on a large project.

Simple solution - change the launcher to call /usr/lib/eclipse/eclipse instead of /usr/bin/eclipse.

More complicated solution available in this Ubuntu bug report.

If you’ve been using the online version of the Pickaxe book as your ruby reference, you won’t know about this very useful little method in the Enumerable module. It allows you to do something cumulative with each item in your Enumerable object.

For example, to sum prices in an array of items ordered:

order = [item0, item1, item2]
total_price = order.inject(0) {|sum, item| sum + item.price}

instead of:

order = [item0, item1, item2]
total_price = 0
order.each {|item| total_price += item.price}


Notes:

• The method parameter is the starting value for whatever the cumulative value is - in this case, sum.
• The first block parameter is the cumulative value, the second is the current object from the Enumerable.
• The value returned by the statement in the block is set as the starting value for the next object from the Enumerable.

For more details, see this article on ruby arrays on thinkvitamin.com.

So… you’re writing a migration, you think you’ve got it right - time to try it out. You run
rake db:migrate
to apply your migration, and it doesn’t work.

Your database has some of the changes from the migration in it, and the rest aren’t there. How do you get it back into the state it was in before you attempted the migration?

You might think that
rake db:migrate VERSION=nn
(where nn is the migration number before the one that failed)
would do the job, presuming that your failed migration’s self.down method runs the statements to rollback your changes in the same order as the self.up method makes the changes.

Unfortunately, nothing happens. Rails knows it didn’t complete the migration, so has left the current schema version number as at the end of the last migration which did complete.

At this point, you are faced with opening up your database and reverting the changes that did get made manually…

There is, however, a patch in rails-trac to fix this issue - if you are using a database that supports transactions round data definition statements (such as Postgres). Once installed, your migration is wrapped in a transaction, which is rolled back if any errors occur. Yippee!