-
Notifications
You must be signed in to change notification settings - Fork 469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inheritance and indexing #1038
Comments
Hi Chris, I've just quickly mocked up an example on my own machine, and I think this should work fine? Can you let me know which versions of Thinking Sphinx and Rails you're using, so I can double-check my local example. Also: it sounds like you've got an index on the parent model as well? |
Yes that is correct. Here is an example from my Rails console: Notice the first query does not produce an error but calling a method on the Search object does.
|
Okay, I've found the cause of the problem. Thinking Sphinx is written to handle single-table inheritance, but there's some inconsistencies when it comes to multi-table inheritance (which is what you're doing). I've just pushed a fix to the gem 'thinking-sphinx', '~> 3.3.0',
:git => 'git://github.com/pat/thinking-sphinx.git',
:branch => 'develop',
:ref => '2831ec9bf6' |
Pat, once again you are the man! I can query successfully now but it seems that filtering might not be working.. I will investigate and either close or update this issue. Thanks again |
Pat, For example,
There error here is because Did |
Hi Chris, yes, there has been a change. The issue is two-fold:
So, the future release will be 3.4.0 due to the change in behaviour… I'll ponder whether there's a neat way to add some kind of deprecation warning in to help people avoid such problems. |
Thanks Pat! |
Okay, so I've just pushed 839d480 to the develop branch. This adds a search middleware that checks attribute filters against known names/types, casts values as needed and outputs a deprecation warning. I'm sure it's not perfect, but it should catch most situations. The configuration parsing is done once per thread, and is from the generated Sphinx file rather than |
For single table inheritance, are we supposed to create separate indies for each sub-model or just one for the parent? Because it seems like defining only for the parent does not work. I would like to setup parent and all children to be handled automatically. |
Hi @akostadinov - STI models with an index on the parent should work (there are tests for it) - but if you're having problems, can you create a new issue with some details, including the index definition and the searches that you're finding aren't working? Thanks! |
Yes, it works. In fact in the project I'm working on, there is logic to do the updates in background jobs. And figuring out callbacks reference names for child models is tricky. Would be really useful if sphinx can register the callbacks as background jobs as well or make easy to register as such. I will create an issue (see #1215). |
Hi Pat,
I was wondering if it's possible to index a child model and if so, what configurations and "gotchas" should I look out for?
Example:
I'm attempting this but getting this message:
(notice both class tables are being referenced)
The text was updated successfully, but these errors were encountered: