Two alias_method_chain calls: first works second doesn't

In the example code in this Pastie Parked at Loopia, I’m
observing behavior I can’t explain. I’m making two calls to
alias_method_chain to extend create_table and drop_table. The
create_table alias chain works as expected. While debugging the
drop_table_with alias chained method is never entered.

Thanks in advance for your help.

Any chance it’s as simple as the placement of your requires?

On Apr 2, 10:09 am, AndyV [email protected] wrote:

Thanks in advance for your help.
I don’t think so. Both create_table_with and drop_table_with are in
the same file which is included from environment.rb’s last line

ActiveRecord::ConnectionAdapters::SchemaStatements.send(:include,
AuditingTables::ActiveRecord::ConnectionAdapters::SchemaStatements)

Okay,

I haven’t dug deep into this but I can give you a few pointers.

First of all, the alias_method_chain is being done to a module so your
methods only do stuff when they are actually included in a class.

With that in mind, what happens here?

module Failure
def failure_type
“everything is fine”
end

def failure_type_with_foo
puts “I intercepted it!”
failure_type_without_foo
end
alias_method_chain :failure_type, :foo
end

class SomethingThatFails
include Failure
def failure_type
“epic”
end
end

SomethingThatFails.new.failure_type #=> “epic”

This could be an explanation.

Regards,
Trevor

On 4/2/08, Jobu [email protected] wrote:

drop_table_with alias chained method is never entered.

Trevor S.
http://somethinglearned.com

On Apr 3, 10:14 am, AndyV [email protected] wrote:

thought they might provide something helpful.
drop_table_with_auditing_table doesn’t require the code in the
requires. Also, that function’s not even being entered.

Sorry I should have been more specific. Your pastie shows:

line 13: def drop_table_with_auditing_table

line 20 require ‘rails_generator’
line 21 require ‘rails_generator/scripts/generate’

line 23 def create_table_with_auditing_table

Since the code that works follows the requires at lines 20 and 21 I
thought they might provide something helpful.

On a side note, depending on what your audit code needs to accomplish
“acts_as_versioned” might be a good fit.

Thanks for looking, but I believe I’ve tried what you suggest.

  1. I believe the extension to the module is included in the extended
    module globally, because of the following line in environment.rb
    ActiveRecord::ConnectionAdapters::SchemaStatements.send(:include,AuditingTables::ActiveRecord::ConnectionAdapters::SchemaStatements)

  2. I’ve used a debugger and seen that the failure_type_with_foo (my
    drop_table_with_auditing_table) in your example is never entered.
    However my create_table_with_auditing_table, which is defined and
    included in an identical manner is always entered.

Could something be overriding or blocking my extension of drop_table?

On 4/6/08, Jobu [email protected] wrote:

  1. I’ve used a debugger and seen that the failure_type_with_foo (my
    drop_table_with_auditing_table) in your example is never entered.
    However my create_table_with_auditing_table, which is defined and
    included in an identical manner is always entered.

Could something be overriding or blocking my extension of drop_table?

Yeah, that’s the whole point of what I showed you. No amount of
monkeypatching in the Failure module can compensate for the fact that
the SomethingThatFails class defines its own failure_type() method.

Try to figure out the type of the object you are calling drop_table()
on, then look at the rails source to see whether that class in
question happens to define its own drop_table method.

If you’re impatient you can always just search for “def drop_table” in
the rails source.

Chances are, you’re going to have to monkeypatch that class rather
than SchemaStatements.

HTH
Trevor

Trevor S.
http://somethinglearned.com