Verbose Migrations (plugin)

Rails
1

DESCRIPTION

Verbose Migrations is a plugin that causes migrations to report what
they are doing, verbosely, to the console. By default, each migration
will report it’s name, and whether it is being migrated (up) or
reverted (down). Also, each method missing call will be reported,
with the name and arguments, so that things like create_table and
add_index are printed.

Benchmarks are also displayed, showing how long each operation took.

You can use the “say” method to report your own events, such as if
you are manipulating data directly using your own model classes:

say “migrating data”
Finances.update_all “amount=0”, “account_id=7”

If you want to also show the benchmark for a custom event like this,
you can use “say_with_time”:

say_with_time “migrating data” do
Finances.update_all “amount=0”, “account_id=7”
end

The output looks something like this:

== NormalizeLineItems: migrating

– create_table(:account_line_items)
→ 0.0091s
– add_index(:account_line_items, :financial_transaction_id)
→ 0.0054s
– add_index(:account_line_items, :account_id)
→ 0.0049s
– create_table(:budget_line_items)
→ 0.0064s
– add_index(:budget_line_items, :financial_transaction_id)
→ 0.0057s
– add_index(:budget_line_items, :budget_id)
→ 0.0195s
– migrate line items to budget and account line items
→ 0.0059s
– drop_table(:line_items)
→ 0.0053s
== NormalizeLineItems: migrated (0.0717s)

INSTALLATION

script/plugin source http://svn.jamisbuck.org/rails-plugins/
script/plugin install verbose_migrations

2

On Nov 18, 2005, at 11:44 AM, Blair Z. wrote:

Jamis,
ALTER TABLE post
-> 0.0087s
That’s a good idea, though I don’t think it’s as straightforward as
just removing whitespace. How should, for instance, whitespace in
string literals be handled?

execute <<-SQL
UPDATE somethings
SET foo = ‘first second third’
WHERE id=5
SQL

Would it be sufficient to just do

str.sub(/^\s*/, “”).sub(/\s*$/, “”).gsub(/[\r\n]\s*/, " ")

?

  • Jamis
3

Jamis B. wrote:

DESCRIPTION

Verbose Migrations is a plugin that causes migrations to report what
they are doing, verbosely, to the console. By default, each migration
will report it’s name, and whether it is being migrated (up) or
reverted (down). Also, each method missing call will be reported, with
the name and arguments, so that things like create_table and add_index
are printed.

Jamis,

Ahh, this is perfect! Just what I was looking for.

Could the logging of the execute task clean up the SQL to remove
leading,
trailing and embedded whitespace?

I have this in my migration’s up method to have it look nice (and fit in
my
standard 80 character wide ssh terminal):

 execute <<-SQL
   ALTER TABLE post
     ADD CONSTRAINT fk_post_pk_author
       FOREIGN KEY (pk_author)
       REFERENCES author(pk_author)
 SQL

This ends up looking like

– execute(" ALTER TABLE post\n ADD CONSTRAINT
fk_post_pk_author\n
FOREIGN KEY (pk_author)\n REFERENCES
author(pk_author)\n")
-> 0.0087s

Regards,
Blair

4

Jamis B. wrote:

That’s a good idea, though I don’t think it’s as straightforward as
just removing whitespace. How should, for instance, whitespace in
string literals be handled?

Agreed. You’d have to parse the SQL.

execute <<-SQL
UPDATE somethings
SET foo = ‘first second third’
WHERE id=5
SQL

Would it be sufficient to just do

str.sub(/^\s*/, “”).sub(/\s*$/, “”).gsub(/[\r\n]\s*/, " ")

Yes, that would work.

Maybe to be safe, in case people insert text in their migrations which
have
[\r\n], is just to trim the leading and trailing whitespace.

The other solution is to have an execute_compress_whitespace or
something named
like that function that people can use that can sub(/\s{2,}/, “”).

Regards,
Blair