# Undefined method \`add'

**URL:** <https://www.ruby-forum.com/t/undefined-method-add/119867>\
**Category:** Ferret\
**Created:** [November 11, 2007, 4:38pm UTC](https://www.ruby-forum.com/t/undefined-method-add/119867 "2007-11-11T16:38:48Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![morten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/cdc98d/32.png) [@morten](https://www.ruby-forum.com/u/morten)\
**Post date:** [November 11, 2007, 4:38pm UTC](https://www.ruby-forum.com/t/undefined-method-add/119867/1 "2007-11-11T16:38:48Z")

</div>

We’ve been running into problems with ferret indexing lately. The  
problem is intermittent and some times it persists. Just got this after  
wiping the index and redeploying:

NoMethodError (undefined method `add' for Solution:Class): (druby://10.1.65.87:9009) /data/releases/20071111152414/vendor/rails/activerecord/lib/active_record/base.rb:1238:in`method\_missing’  
(druby://10.1.65.87:9009)  
/data/releases/20071111152414/vendor/plugins/acts\_as\_ferret/lib/ferret\_server.rb:71:in  
`send' (druby://10.1.65.87:9009) /data/releases/20071111152414/vendor/plugins/acts_as_ferret/lib/ferret_server.rb:71:in`method\_missing’

/data/releases/20071111152414/vendor/plugins/acts\_as\_ferret/lib/remote\_index.rb:31:in  
`\<\<’

/data/releases/20071111152414/vendor/plugins/acts\_as\_ferret/lib/instance\_methods.rb:73:in  
`ferret\_create’

I’m running the latest stable version of AAF. Any tips or work arounds  
much appreciated.

Morten

---

<div class="post-metadata">

**Author:** ![morten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/cdc98d/32.png) [@morten](https://www.ruby-forum.com/u/morten)\
**Post date:** [November 11, 2007, 11:25pm UTC](https://www.ruby-forum.com/t/undefined-method-add/119867/2 "2007-11-11T23:25:22Z")

</div>

Hi,

I _think_ I’m getting closer to what’s going on with this problem.

Basically, the models that we’re experiencing this with, are subclasses  
(Rails STI), such that:

class Entry \< AR::Base  
acts\_as\_ferret  
end

class Solution \< Entry  
end

class Notice \< Entry  
end

The problem may appear intermittently, because the subclassed models  
have not been loadeded correctly somehow, and thus confusing ferret. If  
I reload the page that causes the problem a few times, things usually  
begin working.

I suppose one way to do a quick fix would be to explicity require the  
models in one of the initialization files (eg. environment.rb) such that  
entry gets required first, and then each of the sub-classes.

I’ll see if I can reproduce this outside of production.

Br,

Morten

---

<div class="post-metadata">

**Author:** ![morten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/cdc98d/32.png) [@morten](https://www.ruby-forum.com/u/morten)\
**Post date:** [November 12, 2007, 10:00am UTC](https://www.ruby-forum.com/t/undefined-method-add/119867/3 "2007-11-12T10:00:48Z")

</div>

Well, that wasn’t it. It appears to happen for top level classes in the  
inheritance hierarchy as well and for classes that are not even  
subclassed.

It only happens once per class type immediatly after restarting the  
Ferret backgroundrb process, after which things begin working.

It does not help to require the classes in environment.rb

Any suggestions?

Thanks.

Morten

---

<div class="post-metadata">

**Author:** ![morten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/cdc98d/32.png) [@morten](https://www.ruby-forum.com/u/morten)\
**Post date:** [November 12, 2007, 2:28pm UTC](https://www.ruby-forum.com/t/undefined-method-add/119867/4 "2007-11-12T14:28:57Z")

</div>

On the first request, which breaks, the following gets written to the  
ferret\_server.log:

call index method: add with [#\<DRb::DRbUnknown:0x2a97fd97a8  
@name=“Solution”,  
@buf="\004\bIC:\025Ferret::Document{\023:\022is\_syndicatedF:\

On subsequent requests, the logging looks like this:

call index method: add with [{:account\_id=\>127, :type=\>Solution,  
:is\_syndicated=\>false, :submitter\_id=\>-1

This means, that the ferret server does not know the type of the object  
being indexed on the first request. Is this correct? As far as I can  
tell, the object getting sent is a “Ferret::Document” (from the gem). Is  
there a way to make AAF always send a hash? Would that make sense?

Morten

---

<div class="post-metadata">

**Author:** ![morten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/cdc98d/32.png) [@morten](https://www.ruby-forum.com/u/morten)\
**Post date:** [November 12, 2007, 4:24pm UTC](https://www.ruby-forum.com/t/undefined-method-add/119867/5 "2007-11-12T16:24:35Z")

</div>

Hi Morten,

glad you could make this work for you.

I’m not sure why you’re seeing this strange behaviour, I’ve never seen  
this happen before.

Cheers,  
Jens

On Mon, Nov 12, 2007 at 03:22:33PM +0100, Morten wrote:

> output, reveals:  
> logger.warn(“Reloaded DRb::DRbUnknown to #{record.class.name}”)  
> before the relevant classes get loaded in the initial request?
> 
> * * *
> 
> Ferret-talk mailing list  
> removed\_email\_address@domain.invalid  
> [http://rubyforge.org/mailman/listinfo/ferret-talk](http://rubyforge.org/mailman/listinfo/ferret-talk)

–  
Jens Krämer  
webit! Gesellschaft für neue Medien mbH  
Schnorrstraße 76 | 01069 Dresden  
Telefon +49 351 46766-0 | Telefax +49 351 46766-66  
removed\_email\_address@domain.invalid | [www.webit.de](http://www.webit.de)

Amtsgericht Dresden | HRB 15422  
GF Sven Haubold, Hagen Malessa

---

<div class="post-metadata">

**Author:** ![morten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/cdc98d/32.png) [@morten](https://www.ruby-forum.com/u/morten)\
**Post date:** [November 12, 2007, 3:23pm UTC](https://www.ruby-forum.com/t/undefined-method-add/119867/6 "2007-11-12T15:23:35Z")

</div>

The underlying problem is bad unmarshalling of the Ferret::Document that  
gets sent to the DRb server.

In ferret\_server.rb:

rescue NoMethodError  
@logger.debug “no luck, trying to call class method instead”

Using rescue NoMethodError =\> e and then include e.message in the debug  
output, reveals:

undefined method `to\_doc’ for #DRb::DRbUnknown:0x2a9808f3f0

I’m pretty blank as to why Ferret::Document does not get properly  
unmarshalled on the initial request. If I change the add method to  
attempt a DRb reload in local\_index.rb (line ~139):

def add(record)  
if record.is\_a?(DRb::DRbUnknown)  
record = record.reload  
logger.warn(“Reloaded DRb::DRbUnknown to #{record.class.name}”)  
end

record = record.to\_doc unless Hash === record || Ferret::Document ===  
record  
ferret\_index \<\< record  
end

Then I do indeed get a Document instance back, ie. I have a work around.

But why does this work around work? Does the unmarshalling process occur  
before the relevant classes get loaded in the initial request?

I’ll patch up my local AAF to use this work around, but as it does not  
solve the actual root problem, I guess it’s not interesting as a patch  
submission.

Br,

Morten

---

<div class="post-metadata">

**Author:** ![morten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/cdc98d/32.png) [@morten](https://www.ruby-forum.com/u/morten)\
**Post date:** [June 20, 2008, 9:08am UTC](https://www.ruby-forum.com/t/undefined-method-add/119867/7 "2008-06-20T09:08:38Z")

</div>

This fix did not work for me as the problem was different, but I’m  
putting my fix here in case anyone else finds it useful. Our problem  
lay with the interaction between acts\_as\_ferret and  
acts\_as\_taggable\_on\_steroids:

Putting an object with binary data into:

acts\_as\_ferret :fields =\> { :title =\> {:boost =\> 10},  
:something\_binary =\> {:boost =\> 3}}

will cause aaf to throw the same error. Using  
acts\_as\_taggable\_on\_steroids, putting :tag\_list into the :fields hash  
gave this error. However, putting :tag\_list.collect {|tag| tag} works.  
Looking in to the aaf code, it attempts to treat the object as a hash  
first (which is where it got binary data from for us) and if that  
doesn’t work it treats it as an iterable. The change forces it to act  
as an iterable. See acts\_as\_ferret/lib/act\_methods.rb lines 240-250.

Cameron.

Jens K. wrote:

> Hi Morten,
> 
> glad you could make this work for you.
> 
> I’m not sure why you’re seeing this strange behaviour, I’ve never seen  
> this happen before.
> 
> Cheers,  
> Jens
> 
> On Mon, Nov 12, 2007 at 03:22:33PM +0100, Morten wrote:
> 
> > output, reveals:  
> > logger.warn(“Reloaded DRb::DRbUnknown to #{record.class.name}”)  
> > before the relevant classes get loaded in the initial request?
> > 
> > * * *
> > 
> > Ferret-talk mailing list  
> > removed\_email\_address@domain.invalid  
> > [http://rubyforge.org/mailman/listinfo/ferret-talk](http://rubyforge.org/mailman/listinfo/ferret-talk)
> 
> –  
> Jens Kr�mer  
> webit! Gesellschaft f�r neue Medien mbH  
> Schnorrstra�e 76 | 01069 Dresden  
> Telefon +49 351 46766-0 | Telefax +49 351 46766-66  
> removed\_email\_address@domain.invalid | [www.webit.de](http://www.webit.de)
> 
> Amtsgericht Dresden | HRB 15422  
> GF Sven Haubold, Hagen Malessa