Thinking Sphinx and Devise routes not working together in production mode?

[NeilS]

Hi,

I have what seems (to me) a very odd conflict between Thinking Sphinx
(1.4.3) and Devise (1.0.10) on a Rails 2.3.10 app. (Both gems are
configured in my environment.rb file using config.gem.)

Individually, everything works as expected - Devise works fine for
registering and logging in etc., Thinking Sphinx returns search
results happily.

However, in production mode (or with cache_classes=true in development
mode), running both together makes all my devise routes apparently
disappear.

In my routes file I have a very simple "map.devise_for :customers",
and I can hence access "/customers/sign_up" fine. At this point, I
have the Thinking Sphinx gem installed, but no indices defined.

Now, as soon as I go to my Product model, and add a very simple index
set-up, like:

define_index do
indexes name
end

then the /customers/sign_up page 404s, with:

ActionController::RoutingError (No route matches "/customers/
sign_up" with {:method=>:get})

If I then remove the define_index block, everything works fine. As I
said, everything also works fine with cache_classes set to false.

This is a moderately complex project, so it's possible that something
else is causing the problem that's manifesting itself in this way, but
if anyone has any suggestions or advise as to how to try to debug or
resolve this, I'd be very appreciative.

Many thanks,
Neil.

[Clemens Kofler]

I think I remember having a similar issue some time ago and solving it by moving the devise call in the user model above or beneath TS' indexes block – can't remember exactly.

> --
> You received this message because you are subscribed to the Google Groups "Thinking Sphinx" group.
> To post to this group, send email to thinkin...@googlegroups.com.
> To unsubscribe from this group, send email to thinking-sphi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/thinking-sphinx?hl=en.
>

[NeilS]

Thanks for your comment. Here, though, the Devise 'devise' call is in
a Customer model, and the Thinking Sphinx 'define_index' call in a
Product model - so I can't try changing the declaration order in that
manner.

I've been investigating further, and have found that TS seems to cause
my Customer model to get loaded twice in production.

So, without a define_index block in Products, I see:

* Loading product.rb
* Loading customer.rb

... and the Devise page works. Adding the define_index block into
products, I see:

* Loading product.rb
* Loading customer.rb
* Loading customer.rb

... and the Devise page doesn't work.

I'm currently not sure what to make of this - and it could be a red
herring - but am including the information here in case it rings any
bells with anyone!

Many thanks,
Neil.

[Pat Allan]

Hmm, this is an odd one, because I have used Devise and TS together on a client app recently. However, that was Rails 3... I guess Rails is a bit better with the double-loading now?

Neil, what happens if you add the following to your config/sphinx.yml file:

development:
indexed_models:
- Product
- AnyOtherIndexedModels

Of course, manually maintaining a list of indexed models is annoying... and I'm surprised that customer is being loaded twice, but not product. Still, let's see if we can at least get it working happily.

--
Pat

[NeilS]

Hi Pat,

Yes! This gets things working as expected.

So I assume that TS is working through the models searching for ones
which define indices, but using the config file method allows it to
skip that search?

Anyway, this workaround is perfectly good enough, so thank you so much
for your advice, it's very much appreciated.

Thanks,
Neil.

[Pat Allan]

On 28/02/2011, at 7:10 PM, NeilS wrote:

> Yes! This gets things working as expected.

Fantastic.

> So I assume that TS is working through the models searching for ones
> which define indices, but using the config file method allows it to
> skip that search?

Exactly right.

> Anyway, this workaround is perfectly good enough, so thank you so much
> for your advice, it's very much appreciated.

No worries... I think I might put this issue aside for the moment. If someone else comes across it, I hope they'll let me know, and I can dig deeper. I'm just surprised it hasn't cropped up before...

--
Pat