Search not working after upgrade

Hi,

I just upgrade to the latest AAF release and my searches are no longer
working.

The following find does no longer work but used to work with the older
version

Product.find_by_contents("*",{:limit=>:all},:conditions =>
search_conditions,:include => [:supplier],:order =>“products.id” )

This produces a MYSQL error:
ActiveRecord::StatementInvalid: Mysql::Error: You have an error in your
SQL syntax; check the manual that corresponds to your MySQL server
version for the right syntax to use near ‘all’ at line 1:

The SQl line has an invalid limit statement at the end:

ORDER BY products.id LIMIT all

I played around a bit and noticed that if I change my find to:
Product.find_by_contents("*",{:limit=>:all},:include =>
[:supplier],:order =>“products.id” )

it now works but I loose my additional sql conditional search I need.

Is this a bug ?

Hi.
I do not think that this is a bug, they have just changed some methods
there.

In class_methods.rb:
used to be:

    def retrieve_records(id_arrays, find_options = {})
      result = []
      # get objects for each model
      id_arrays.each do |model, id_array|
        next if id_array.empty?
        begin
          model = model.constantize
        rescue
          raise "Please use ':store_class_name => true' if you want to 
use multi_search.\n#{$!}"
        end

        # check for include association that might only exist on some 
models in case of multi_search
        filtered_include_options = []
        if include_options = find_options[:include]
          include_options.each do |include_option|
            filtered_include_options << include_option if 
model.reflections.has_key?(include_option.is_a?(Hash) ? 
include_option.keys[0].to_sym : include_option.to_sym)
          end
        end
        filtered_include_options=nil if filtered_include_options.empty?

        # fetch
        tmp_result = nil
        model.send(:with_scope, :find => find_options) do
          tmp_result = model.find( :all, :conditions => [
            "#{model.table_name}.#{model.primary_key} in (?)", 
id_array.keys ],
            :include => filtered_include_options)
        end

and now it is:

       def retrieve_records(id_arrays, find_options = {})
          result = []
          # get objects for each model
          id_arrays.each do |model, id_array|
            next if id_array.empty?
            begin
              model = model.constantize
            rescue
              raise "Please use ':store_class_name => true' if you want 
to use multi_search.\n#{$!}"
            end

            # merge conditions
            conditions = combine_conditions([ 
"#{model.table_name}.#{model.primary_key} in (?)",
            id_array.keys ],
            find_options[:conditions])

            # check for include association that might only exist on 
some models in case of multi_search
            filtered_include_options = []
            if include_options = find_options[:include]
              include_options = [ include_options ] unless 
include_options.respond_to?(:each)
              include_options.each do |include_option|
                filtered_include_options << include_option if 
model.reflections.has_key?(include_option.is_a?(Hash) ? 
include_option.keys[0].to_sym : include_option.to_sym)
              end
            end
            filtered_include_options = nil if 
filtered_include_options.empty?

            # fetch
            tmp_result = model.find(:all, find_options.merge(:conditions 
=> conditions,
                                                             :include => 
filtered_include_options))

            # set scores and rank
            tmp_result.each do |record|
              record.ferret_rank, record.ferret_score = 
id_array[record.id.to_s]
            end
            # merge with result array
            result.concat tmp_result
          end

You got the error, because of this difference:
old way to generate SQL query:

    model.send(:with_scope, :find => find_options) do
      tmp_result = model.find( :all, :conditions => [
        "#{model.table_name}.#{model.primary_key} in (?)", 

id_array.keys ],
:include => filtered_include_options)
end

new way to generate the SQL query:

tmp_result = model.find(:all, find_options.merge(:conditions =>
conditions,
:include => filtered_include_options))

You have to put the options and find_options in separate hash when
passing them to search, as is described here:
http://projects.jkraemer.net/rdoc/acts_as_ferret/classes/ActsAsFerret/ClassMethods.html#M000023

I also spotted a bug into next method (count_records) that will generate
an invalid SQL query if you use :select => “articles.*” in find_options
with a :join option to select only records for articles table. So, for
now I stick with the old version.
I haven’t yet spotted all other changes, so for now I stick with the
other version

I ran into the same issue trying to put AAF into production last night.
Our setup for one part of the site is overcomplicated because we’re
using geokit and ferret together.

My shortcut to get a working system going was to go back to the
deprecated “:num_docs => :all”. If throws a warning, but at least it’s
not tacking “limit all” to the end of all my sql queries.

I’m sure there’s a better way to do things, but sometimes you need the
shortcut too.

I take back what I said. The find_by_contents was mad about putting
things in brackets, and wasn’t passing the find_options. I was watching
the ferret_server.log file and could tell what was and wasn’t getting
passed.

So this didn’t work:

find_by_contents(query, {:limit => :all}, {:conditions =
actual_conditions})

This fixed everything:

find_by_contents(query, :limit => :all, :conditions = actual_conditions)

I changed the request to :

Product.find_by_contents("*",:limit=>:all,:conditions
=>search_conditions,:include => [:supplier],:order =>“products.id” )

and it now works.

Andre Robitaille wrote:

I ran into the same issue trying to put AAF into production last night.
Our setup for one part of the site is overcomplicated because we’re
using geokit and ferret together.

My shortcut to get a working system going was to go back to the
deprecated “:num_docs => :all”. If throws a warning, but at least it’s
not tacking “limit all” to the end of all my sql queries.

I’m sure there’s a better way to do things, but sometimes you need the
shortcut too.

Izit I. wrote:

Correction on my previous post.

The correct way to do it is:

Product.find_by_contents(“*”,{},:conditions =>search_conditions,:include
=> [:supplier],:order =>“products.id” )

Leave out the :limit=>:all that is put in by default.

Exactly - I tried to make aaf a bit more clever by letting it assume
:limit => :all whenever sql conditions are given, but messed it up
somehow :wink:

It’s fixed in trunk
(http://projects.jkraemer.net/acts_as_ferret/changeset/286), or just
apply the attached patch.

Btw, this whole thread hasn’t come through to the mailing list (yet?), I
discovered it by pure chance. Please subscribe to the ferret mailing
list (http://rubyforge.org/mail/?group_id=1028) and post there directly
to make sure your posting gets actually read.

Cheers,
Jens

On Nov 26, 2007, at 4:11 PM, Jens Krämer wrote:

Btw, this whole thread hasn’t come through to the mailing list
(yet?), I
discovered it by pure chance. Please subscribe to the ferret mailing
list (http://rubyforge.org/mail/?group_id=1028) and post there
directly
to make sure your posting gets actually read.

Jens-

I see this happy a lot on rubyforge-- is it because it only brings
email in from the web interface when the poster is subscribed? Or is
it just flakey software? Do you have any insight into how we might be
able to get rubyforge to either address or document this issue?

John

On Tue, Nov 27, 2007 at 09:11:35PM -0500, John B. wrote:

I see this happy a lot on rubyforge-- is it because it only brings
email in from the web interface when the poster is subscribed? Or is
it just flakey software? Do you have any insight into how we might be
able to get rubyforge to either address or document this issue?

I’m not sure why this happens, maybe some spam prevention kicks in, or
it’s the way you said, that it only accepts messages from people
subscribed to the mailing list. I’ll try and ask Andreas S.,
the creator of ruby-forum.com, about this.

Cheers,
Jens


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
[email protected] | www.webit.de

Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa

Correction on my previous post.

The correct way to do it is:

Product.find_by_contents("*",{},:conditions =>search_conditions,:include
=> [:supplier],:order =>“products.id” )

Leave out the :limit=>:all that is put in by default.

Izit I. wrote:

I changed the request to :

Product.find_by_contents("*",:limit=>:all,:conditions
=>search_conditions,:include => [:supplier],:order =>“products.id” )

and it now works.

Andre Robitaille wrote:

I ran into the same issue trying to put AAF into production last night.
Our setup for one part of the site is overcomplicated because we’re
using geokit and ferret together.

My shortcut to get a working system going was to go back to the
deprecated “:num_docs => :all”. If throws a warning, but at least it’s
not tacking “limit all” to the end of all my sql queries.

I’m sure there’s a better way to do things, but sometimes you need the
shortcut too.

Hello,

I have some major problems on installing ferret on Leopard. While I
know its already installed when you install Leopard I want to do it
manually as I am not using the installed version of ruby (since I
migrated from Tiger).
When the native extensions are compiled I get some linker problems.
Can anyone reproduce that?

I have an older version of ferret installed (which I installed while
being on Tiger) and this works fine, but I want to upgrade.

Regards
Till

On 28.11.2007, at 10:25, Till V. wrote:

I have some major problems on installing ferret on Leopard.

Interestingly, the words “major problems” and “Leopard” coincide a lot
lately.

Here’s my advice:

  • get rid of the probably buggiest piece of software that apple has
    ever shipped
  • go back to tiger and stay there for at least a couple of major updates
  • oh and if you made the same mistake and updated tiger instead of a
    fresh install, I’m very sorry for you :wink:

When the native extensions are compiled I get some linker problems.

If you can’t resist the temptation of leopard’s amazingly great
feature set

  • make sure you install the latest ruby version as well as any other
    package via macports

  • have apple’s developer tools installed in advance (includes gcc +
    build tools)

  • a talisman might probably be helpful

      Best of luck,
      Andy

On Nov 28, 2007, at 7:36 AM, Andreas K. wrote:

  • get rid of the probably buggiest piece of software that apple has
    ever shipped

If you can’t resist the temptation of leopard’s amazingly great
feature set

  • make sure you install the latest ruby version as well as any other
    package via macports
  • have apple’s developer tools installed in advance (includes gcc +
    build tools)
  • a talisman might probably be helpful

For what it’s worth, I’ve had zero problems with the Apple-supplied
ruby, rails, etc… I updated some gems but ferret is running great
(better than on our Linux servers, in fact – no end of problems on
Ubuntu 7.04 x64). I would recommend sticking with the Apple-supplied
ruby; for once they’ve gotten it right, and everything seems to work
beautifully.

On 28.11.2007, at 19:36, Noah M. Daniels wrote:

Interestingly, the words “major problems” and “Leopard” coincide a
lot
lately.

For what it’s worth, I’ve had zero problems with the Apple-supplied
ruby, rails, etc…

Frankly, knowing that everything works well for others isn’t worth
much to people who are having problems :wink:

But it appears to be a common reaction – especially in the Apple
community.

I would recommend sticking with the Apple-supplied
ruby; for once they’ve gotten it right, and everything seems to work
beautifully.

You must have a different understanding of ‘getting it right’. Here’s
what I got when I entered ‘ruby -v’ or ‘gems’ into the console of a
fresh 10.5 install:

-bash: ruby: command not found

After getting it to work eventually, a ‘gem update --system’ just
wrecked the whole Ruby installation. At that point I just gave up and
installed Ruby/Gems and Rails via Macports.

One thing I’d really like to know is how one is supposed to update the
Ruby/Rails packages which shipped with Leopard. I had no chance to
check, but are they still shipping Rails 1.1.2? I bet that Apple isn’t
going to update Ruby during the whole lifetime of Leopard. Anything
else would be a big surprise.

So here goes my advice again: Use Macports. Do not use whatever Apple
ships.

       Cheers,
       Andy

On Nov 29, 2007, at 7:01 AM, Andreas K. wrote:

Frankly, knowing that everything works well for others isn’t worth
much to people who are having problems :wink:

But it appears to be a common reaction – especially in the Apple
community.

Point taken, but I was responding to the poster’s statement that
they’d avoided the apple-supplied Ruby.

You must have a different understanding of ‘getting it right’.
Here’s what I got when I entered ‘ruby -v’ or ‘gems’ into the
console of a fresh 10.5 install:

-bash: ruby: command not found

That’s very strange, but just sounds like a path issue.

After getting it to work eventually, a ‘gem update --system’ just
wrecked the whole Ruby installation. At that point I just gave up
and installed Ruby/Gems and Rails via Macports.

Yes, this one is a known issue. See these links:

http://discussions.apple.com/thread.jspa?threadID=1200950&tstart=0

http://discussions.apple.com/thread.jspa?threadID=1202925&tstart=0

One thing I’d really like to know is how one is supposed to update
the Ruby/Rails packages which shipped with Leopard. I had no chance
to check, but are they still shipping Rails 1.1.2? I bet that Apple
isn’t going to update Ruby during the whole lifetime of Leopard.
Anything else would be a big surprise.

It comes with rails 1.2.3, and gem update rails updates it to 1.2.5
(well, now 1.2.6) just fine.

So here goes my advice again: Use Macports. Do not use whatever
Apple ships.

I disagree in the most friendly way possible :slight_smile:

On Nov 29, 2007, at 4:01 AM, Andreas K. wrote:

Here’s what I got when I entered ‘ruby -v’ or ‘gems’ into the
console of a fresh 10.5 install:

-bash: ruby: command not found

Curious. Did you install the developer tools? Here’s what I get in
Terminal with a fresh install of 10.5 and XCode 3.0:

/Users/marvin/ $ ruby -v
ruby 1.8.6 (2007-06-07 patchlevel 36) [universal-darwin9.0]
/Users/marvin/ $ which ruby
/usr/bin/ruby

Marvin H.
Rectangular Research
http://www.rectangular.com/