Ferret talk - Jun 2006 - 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?

-- 
Posted via http://www.ruby-forum.com/.

On Thu, Jun 29, 2006 at 04:00:14PM +0200, Charlie wrote:
> 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?
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       kraemer at webit.de
Schnorrstra?e 76                         Tel +49 351 46766  0
D-01069 Dresden                          Fax +49 351 46766 66

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

What''s wrong?

Charlie

-- 
Posted via http://www.ruby-forum.com/.

On Thu, 2006-06-29 at 16:11 +0200, Jens Kraemer 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 Kraemer 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       kraemer at webit.de
Schnorrstra?e 76                         Tel +49 351 46766  0
D-01069 Dresden                          Fax +49 351 46766 66

On Thu, 2006-06-29 at 19:04 +0200, Jens Kraemer wrote:
> 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 Kraemer 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
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 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       kraemer at webit.de
Schnorrstra?e 76                         Tel +49 351 46766  0
D-01069 Dresden                          Fax +49 351 46766 66

On 6/30/06, Jens Kraemer <kraemer at webit.de>
wrote:
> 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
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

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 Balmain <dbalmain.ml at gmail.com>
wrote:
> On 6/30/06, Jens Kraemer <kraemer at webit.de> wrote:
> > 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
>
> 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
> _______________________________________________
> Ferret-talk mailing list
> Ferret-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ferret-talk
>

-- 
Tom Davies

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

On 7/7/06, Tom Davies <atomgiant at gmail.com>
wrote:
> 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.
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 Balmain
wrote:
> On 7/7/06, Tom Davies <atomgiant at gmail.com> wrote:
[..]
> 
> 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|
+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       kraemer at webit.de
Schnorrstra?e 76                         Tel +49 351 46766  0
D-01069 Dresden                          Fax +49 351 46766 66

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 Kraemer <kraemer at webit.de>
wrote:
> On Fri, Jul 07, 2006 at 10:52:20PM +0900, David Balmain wrote:
> > On 7/7/06, Tom Davies <atomgiant at gmail.com> wrote:
> [..]
> >
> > 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|
>
> +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       kraemer at webit.de
> Schnorrstra?e 76                         Tel +49 351 46766  0
> D-01069 Dresden                          Fax +49 351 46766 66
> _______________________________________________
> Ferret-talk mailing list
> Ferret-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ferret-talk
>

-- 
Tom Davies

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

On 7/7/06, Tom Davies <atomgiant at gmail.com>
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?
> Tom
>
> On 7/7/06, Jens Kraemer <kraemer at webit.de> wrote:
> > On Fri, Jul 07, 2006 at 10:52:20PM +0900, David Balmain wrote:
> > > On 7/7/06, Tom Davies <atomgiant at gmail.com> wrote:
> > [..]
> > >
> > > 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|
> >
> > +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       kraemer at webit.de
> > Schnorrstra?e 76                         Tel +49 351 46766  0
> > D-01069 Dresden                          Fax +49 351 46766 66
> > _______________________________________________
> > Ferret-talk mailing list
> > Ferret-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ferret-talk
> >
>
>
> --
> Tom Davies
>
> http://atomgiant.com
> http://gifthat.com
> _______________________________________________
> Ferret-talk mailing list
> Ferret-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ferret-talk
>

On Sat, Jul 08, 2006 at 12:57:33AM +0900, David Balmain
wrote:
> On 7/7/06, Tom Davies <atomgiant at gmail.com> 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?
nope, sounds perfect that way :-)

Jens


-- 
webit! Gesellschaft f?r neue Medien mbH          www.webit.de
Dipl.-Wirtschaftsingenieur Jens Kr?mer       kraemer at webit.de
Schnorrstra?e 76                         Tel +49 351 46766  0
D-01069 Dresden                          Fax +49 351 46766 66