Help

Is there a way to ensure at_exit will always be ran regardless of how the program exits without wrapping all code in an ensure block?

Ideas included:

1. Use a runner class to execute the program and wrap that in an ensure block.

2. trap("EXIT") { block } should get triggered no matter how the program terminates (sigint, exception, etc)

What are the likely causes of RangeError exceptions during test runs?

<RangeError: 0x23513ec is recycled object>

1. This is generally caused by C extensions.

2. Their appearance coincided with a Darwin ports update — perhaps you're running native gems against different versions of libraries than they were compiled against.

Are there any techniques out there to take a series of bytes and run some heuristics on them to determine the likely encoding of the string it represents?

Anybody out there have any ideas? Please let us know in the comments!

Interesting

• Passing :multiple => false or nil to the select helpers causes unpredictable results — the helper still builds input element names assuming an array of items will be passed back. The helper checks only that the key is present in the options hash and not the value which means if you need to conditionally render a multiple, you'll have to make sure you don't specify the :multiple key at all.

• Using $('textarea').val() causes unpredictable results as a textarea doesn't keep its data in a value attribute. Use text()) instead.

• IE 7 and 8 (and more than likely 6) seem to have a problem with jQuery selectors that match links based upon the href attribute — changing the href of the matched elements does not get reflected in the document.

• From a Blabs comment: Taps is a Sinatra web service from Heroku that's used to move data from one database to another. It transmits data as serialized arrays and loads them using ActiveRecord so it's DB agnostic.

• Disabling a label via jQuery will not disable the input that it refers to in the for attribute as the label is not a container.

Happy Thanksgiving!

One of our projects had a pending chore in Tracker to move its backend to PostgreSQL from MySQL. This project has about a quarter of a million rows of production data and around a hundred tables in its schema which needed to be exactly migrated into PostgreSQL.

Forklifting the data proved more complicated than expected due to incompatibilities in the two DBMS' syntax such as in the way string escaping worked, how booleans were represented and a bunch of other small but painful differences. Despite MySQL's mysqldump utility including a command-line option to write statements in PostgeSQL format, it became clear that it wasn't going to be simple to create a repeatable procedure to do this work across our environments.

There's a bunch of information out there about how to approach this problem but none felt right. Most are multi-step manual procedures that require altering a dump file using sed or perl and others require the data to be loaded into an intermediary database and massaged prior to import. After testing some of these approaches, Todd and I decided to timebox ourselves to an hour to test the viability of a Ruby script using the DBI gem to move the data. We came up with:

require 'dbi'
require 'dbd/mysql'
require 'dbd/pg'

begin
  mysql = DBI.connect("DBI:Mysql:source:localhost", "username", "password")
  postgres = DBI.connect("DBI:Pg:destination:localhost", "username", "password")

  mysql.select_all("SHOW TABLES") do |table|
    next if ['schema_migrations', 'sessions'].include?(table.to_s)
    select = mysql.execute("SELECT * FROM #{table}")
    columns = select.column_names.map { |key| "\"#{key}\"" }.join(', ')
    placeholders = (['?'] * select.column_names.size).join(', ')
    insert = postgres.prepare("INSERT INTO #{table} (#{columns}) VALUES(#{placeholders})")
    select.each { |row| insert.execute(*row) }
    insert.finish
  end
rescue DBI::DatabaseError => e
  puts "Error #{e.err}: #{e.errstr}"
ensure
  mysql.disconnect if mysql
  postgres.disconnect if postgres
end

Our antiquely Perl-like script worked better than we expected — our application started right up with all of its data intact.

Has anybody out there encountered this need before? What kinds of solutions did you come up with?