Find_by_contents not returning SearchResults?

The acts_as_ferret documentation says find_by_content returns an
instance of SearchResults, but I see this error when I try to use the
results.

undefined method `total_hits’ for []:Array

Here is the link to the documentation:

http://projects.jkraemer.net/acts_as_ferret/rdoc/classes/FerretMixin/Acts/ARFerret/ClassMethods.html#M000010

But here is the actual code:

        result = []
        hits = index_searcher.search(query, options)
        hits.each do |hit, score|
          id = index_searcher.reader.get_document(hit)[:id]
          begin
            res = self.find(id)
            result << res if res
            logger.debug "result id: #{id}, result: #{res}"
          rescue
            logger.debug "no data for id #{id}"
          end
        end
        return result

What’s wrong? Do I need another version of the plugin?

On Thu, Jun 29, 2006 at 04:00:14PM +0200, Charlie wrote:

But here is the actual code:
logger.debug “no data for id #{id}”
end
end
return result

What’s wrong? Do I need another version of the plugin?

yes, this feature is only in svn trunk at this time. The API docs are
generated from trunk automatically, maybe we should fix this and keep
the docs for each version we release.

Jens


webit! Gesellschaft für neue Medien mbH www.webit.de
Dipl.-Wirtschaftsingenieur Jens Krämer [email protected]
Schnorrstraße 76 Tel +49 351 46766 0
D-01069 Dresden Fax +49 351 46766 66

On Thu, 2006-06-29 at 16:11 +0200, Jens K. wrote:

yes, this feature is only in svn trunk at this time. The API docs are
generated from trunk automatically, maybe we should fix this and keep
the docs for each version we release.

Are you also going to fix this for the next version? There’s a patch
attatched that I am using, although the code is a little hackish.
Without it sorting results seems impossible.

http://projects.jkraemer.net/acts_as_ferret/ticket/9

Pedro.

On Thu, Jun 29, 2006 at 03:44:40PM +0100, Pedro Côrte-Real wrote:

On Thu, 2006-06-29 at 16:11 +0200, Jens K. wrote:

yes, this feature is only in svn trunk at this time. The API docs are
generated from trunk automatically, maybe we should fix this and keep
the docs for each version we release.

Are you also going to fix this for the next version? There’s a patch
attatched that I am using, although the code is a little hackish.
Without it sorting results seems impossible.

http://projects.jkraemer.net/acts_as_ferret/ticket/9

I think you speak of this one -
http://projects.jkraemer.net/acts_as_ferret/ticket/20

this will be fixed in the soon-to-be-released next version.

Jens


webit! Gesellschaft für neue Medien mbH www.webit.de
Dipl.-Wirtschaftsingenieur Jens Krämer [email protected]
Schnorrstraße 76 Tel +49 351 46766 0
D-01069 Dresden Fax +49 351 46766 66

On Thu, Jun 29, 2006 at 06:19:48PM +0100, Pedro Côrte-Real wrote:
[…]

this will be fixed in the soon-to-be-released next version.

Cool. I hate having non-standard patches to stuff. It would also be cool
to have a cleaner API to do sorting than the ferret one. One that uses
the field names passed to acts_as_ferret. Ferret is great but it’s API
seems to be too much like Java and not like most ruby API’s. I ended up
building a small class to encapsulate searching for my rails model to
hide all that away.

Good point, but I’d rather wait for ferret’s upcoming API changes before
doing such changes in acts_as_ferret.

Jens


webit! Gesellschaft für neue Medien mbH www.webit.de
Dipl.-Wirtschaftsingenieur Jens Krämer [email protected]
Schnorrstraße 76 Tel +49 351 46766 0
D-01069 Dresden Fax +49 351 46766 66

On 6/30/06, Jens K. [email protected] wrote:

Good point, but I’d rather wait for ferret’s upcoming API changes before
doing such changes in acts_as_ferret.

Jens

That’s a very good plan. While we are on the subject, how do you think
the sort API should look? Once we get to a 1.0 release we are going to
be stuck with that API for a while so I want to get it right before
then and the sooner the better. Also, what other areas of the API do
you feel need work. For starters, I’ll be getting rid of the Parameter
class. Instead of Field::Index::TOKENIZED it’ll just be :index => :yes
or :index => :untokenized etc. Anyway, I’d love to hear any feed back
on any part of the API. Let’s start with the Sort API.

Cheers,
Dave

On Thu, 2006-06-29 at 19:04 +0200, Jens K. wrote:

http://projects.jkraemer.net/acts_as_ferret/ticket/9

I think you speak of this one -
http://projects.jkraemer.net/acts_as_ferret/ticket/20

Yes, although the one I posted was a similar issue. Messed up when
looking for my bugreport.

this will be fixed in the soon-to-be-released next version.

Cool. I hate having non-standard patches to stuff. It would also be cool
to have a cleaner API to do sorting than the ferret one. One that uses
the field names passed to acts_as_ferret. Ferret is great but it’s API
seems to be too much like Java and not like most ruby API’s. I ended up
building a small class to encapsulate searching for my rails model to
hide all that away.

Pedro.

On 7/7/06, Tom D. [email protected] wrote:

sort_fields << Ferret::Search::SortField.new('url')

simple datastructures such as symbols, strings and arrays.
Thanks for your feedback Tom. I couldn’t agree more. In the version
I’m working on now for example, Documents are going to basically be
Hashes with a boost attribute. So everything you normally do with a
Hash, you’ll be able to do with a Document.

By the way, did you already know you could do this in the current
version of Ferret?:

num = INDEX.search_each(query, :sort => ['created_at', 'url']) do

|doc, score|

The only problem with this is that it doesn’t allow you to reverse the
sort. You have to do this;

url_sorter = Ferret::Search::SortField.new('url', :reverse => true)
num = INDEX.search_each(query, :sort => ['created_at',

url_sorter]) do |doc, score|

Maybe your sql sort string idea is a good one. Which do you think is
better?

num = INDEX.search_each(query, :sort => 'created_at, url_sorter

DESC’) do |doc, score|

or

num = INDEX.search_each(query, :sort => ['created_at',

‘url_sorter’, DESC]) do |doc, score|

On Fri, Jul 07, 2006 at 10:52:20PM +0900, David B. wrote:

On 7/7/06, Tom D. [email protected] wrote:
[…]
url_sorter = Ferret::Search::SortField.new(‘url’, :reverse => true)
num = INDEX.search_each(query, :sort => [‘created_at’,
url_sorter]) do |doc, score|

Maybe your sql sort string idea is a good one. Which do you think is better?

num = INDEX.search_each(query, :sort => 'created_at, url_sorter

DESC’) do |doc, score|

+1

using :order instead of :sort would make it even more Rails-like.

Jens


webit! Gesellschaft für neue Medien mbH www.webit.de
Dipl.-Wirtschaftsingenieur Jens Krämer [email protected]
Schnorrstraße 76 Tel +49 351 46766 0
D-01069 Dresden Fax +49 351 46766 66

Hi Dave,

I currently only use a small subset of the Ferret API so this may not
work universally for all areas you support sorting. One simple
sorting solution would be to just support SQL style string expressions
for sorting. It should be relatively easy to implement. So this
code:

sort_fields = []
sort_fields << Ferret::Search::SortField.new('created_at')
sort_fields << Ferret::Search::SortField.new('url')
num = INDEX.search_each(query, :sort => sort_fields)  do |doc, 

score|

Could be rewritten as:
num = INDEX.search_each(query, :sort => ‘created_at, url’) do |doc,
score|

And perhaps it could also support ASC DESC syntax as well.

In general I think anywhere the Ferret API requires us to create
internal Ferret classes and pass them in it would be nice if there was
a way to abstract this from the caller as much as possible using
simple datastructures such as symbols, strings and arrays.

Tom

On 6/30/06, David B. [email protected] wrote:

hide all that away.
you feel need work. For starters, I’ll be getting rid of the Parameter


Tom D.

http://atomgiant.com
http://gifthat.com

On 7/7/06, Tom D. [email protected] wrote:

I am leaning towards the first version, so all in one string. That
way you can have mixed sortings too such as “name ASC, created_at
DESC”. I also agree with Jens comment that calling it :order would
make it more rails like.

Ok, string it is. And :order I can do too, although it won’t hurt to
leave :sort as an option.

While we are at it, it would also be nice to use :limit for :num_docs,
and :offset for :first_doc.

+1
This sounds better to me too. Anyone disagree?

I am leaning towards the first version, so all in one string. That
way you can have mixed sortings too such as “name ASC, created_at
DESC”. I also agree with Jens comment that calling it :order would
make it more rails like.

While we are at it, it would also be nice to use :limit for :num_docs,
and :offset for :first_doc.

Tom

On 7/7/06, Jens K. [email protected] wrote:

The only problem with this is that it doesn’t allow you to reverse the

Schnorrstraße 76 Tel +49 351 46766 0
D-01069 Dresden Fax +49 351 46766 66


Ferret-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ferret-talk


Tom D.

http://atomgiant.com
http://gifthat.com

On Sat, Jul 08, 2006 at 12:57:33AM +0900, David B. wrote:

and :offset for :first_doc.

+1
This sounds better to me too. Anyone disagree?

nope, sounds perfect that way :slight_smile:

Jens


webit! Gesellschaft für neue Medien mbH www.webit.de
Dipl.-Wirtschaftsingenieur Jens Krämer [email protected]
Schnorrstraße 76 Tel +49 351 46766 0
D-01069 Dresden Fax +49 351 46766 66

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs