On Jul 27, 2:23 am, jd <[email protected]> wrote:
> Hi.
>
> I'm currently writing a plugin, which "could" be a patch in that it
> must override a private method of ActiveRecord API, in
> ActiveRecord::Dirty, to work smoothly. To make a long story short,
> this plugin aims at enabling serialization with Marshal instead of
> YAML (it actually works fine :)) -- the private update_with_dirty()

(you 'll want to make sure that the column is a blob one rather than
text/string. Depending on database and column settings the database
might just truncate your data (eg if the column is marked as being
utf8 text but you try and store a byte sequence which is not legal
utf8.

> method, defined by an "alias_method_chain :update, :dirty", has to be
> edited. Not really stable, but hey, it fits my needs ;)
>
> In my vendor/plugins/marshalize/lib/marshalize.rb, I defined a
> Marshalization module, with some submodules which are included by
> ActiveRecord::Base in vendor/plugins/marshalize/rails/init.rb using
> send(). In the submodules I overrided several public class and
> instance methods from several ActiveRecord submodules, all is fine.
>

> But I did not manage to override the private method update_with_dirty
> () from ActiveRecord::Dirty submodule directly from the plugin. Notice
> thatthis method eventually becomes an instance private method of
> ActiveRecord::Base since Dirty is "instance_evaled" by Base (at the
> bottom of base.rb). For the sake of the tests, I created another
> private method in my Marshalization::Dirty submodule and it eventually
> gets included in ActiveRecord::Base as an instance private method; but
> when it comes to using update_with_dirty(), Rails keeps using the old
> one from the system active_record/lib/dirty.rb file and not the new
> one defined in marshalize.rb -- and I don't figure out why :)

Are you sure the problem is the privateness ? My hunch is that the
following happens

- update_with_dirty is defined
- that method is aliased to update
- you define a new update_with_dirty, but by then it's too late: the
aliasing has already happen

for example:

class Foo
  def original
    puts "Original"
  end

  alias_method :newname, :original
end

Foo.new.newname #=> "Original"
Foo.new.original #=> "Original"

class Foo
  def original
    puts "new code"
  end
end

Foo.new.newname #=> "Original"
Foo.new.original #=> "new code"

Another way of looking at it is that alias_method isn't just storing a
new name for a method, it is actually copying it.

Fred

>
> Here's a gist for this implementation:http://gist.github.com/155990
> Feel free to push if needed ;)
>
> Thank you for your help !
> jd
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to