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 > > Thanks, > Neil. > > On Feb 27, 1:52 am, Pat Allan <[email protected]> wrote: >> 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 >> >> On 26/02/2011, at 1:24 AM, NeilS wrote: >> >> >> >> >> >> >> >>> 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. >> >>> On Feb 25, 1:53 pm, Clemens Kofler <[email protected]> wrote: >>>> 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. >> >>>> On Feb 25, 2011, at 1:38 PM, NeilS wrote: >> >>>>> 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. >> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "Thinking Sphinx" group. >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]. >>>>> For more options, visit this group >>>>> athttp://groups.google.com/group/thinking-sphinx?hl=en. >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Thinking Sphinx" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group >>> athttp://groups.google.com/group/thinking-sphinx?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Thinking Sphinx" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/thinking-sphinx?hl=en. > -- You received this message because you are subscribed to the Google Groups "Thinking Sphinx" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/thinking-sphinx?hl=en.
