Hi Steve Sorry for the delay. I'll try to explain the STI issue clearly, and hopefully without too much confusion :)
Each document in Sphinx requires an absolutely unique integer id. To ensure this, Thinking Sphinx has an offset of ActiveRecord's normal ids, based on the number of indexed models. And that's all well and good, and works nicely. The catch is that TS recognises STI child classes as separate classes, and so if there's an index on both the parent and the child, then the child will end up in the indexes twice, with different unique ids. The ideal approach here would be to have it twice, but with the same id, so Sphinx knows it is the same document. This has also led to issues with facets in the double-up indexing situation, because the counts get confused. I do plan to fix this, it's just not been yelled about enough (and I've not had the time, and no one has submitted a patch). It remains on my list though. -- Pat On 18/06/2009, at 6:54 PM, steve wrote: > > I suppose if single table inheritance is bad, I could just use a > simple dummy relationship. > > class ProxyUser > belongs_to :user > > define_index do > user.stuff > . > . > . > > > end > > On Jun 18, 10:15 am, steve <[email protected]> wrote: >> Thanks Pat, been a bit, because I thought I had a solution. I was >> going to put the index on a related model, but that create's a whole >> lot of essentially duplicate entries in the index. >> >> So the first question is kind of a general performance question, just >> talking out loud, hopefully you have some thoughts on. Since a bunch >> of the records would be indexing the same set of words, and we are >> talking about less than a million records, how bad would it really >> be? >> >> Secondly can you further describe the issues with using STI here? >> >> Much appreciated. >> Steve >> >> On Jun 12, 11:54 am, Pat Allan <[email protected]> wrote: >> >>> Yeah, TS isn't built to handle that neatly either. >> >>> You're not the first to request it, it's just a matter of me finding >>> time to make it all play nicely with Sphinx. >> >>> Sphinx itself has certain expectations around fields that refer to >>> the >>> same documents to exist in all relevant indexes, so it makes >>> things a >>> little tricky. >> >>> -- >>> Pat >> >>> On 12/06/2009, at 2:51 PM, Greg Weber wrote: >> >>>> That should work unless thinking sphinx has a problem with >>>> subclasses >>>> (You will be able to tell by looking at the sphinx config). A >>>> different class will be a different index, and they will be >>>> searched >>>> independently. >> >>>> On Jun 12, 10:56 am, steve <[email protected]> wrote: >>>>> Despite being a bit ugly, if I created a new model that inherited >>>>> from >>>>> that model, would I run into any issues that you foresee? >> >>>>> On Jun 11, 8:55 pm, Greg Weber <[email protected]> wrote: >> >>>>>> I don't think there is a way with sphinx (not just thinking >>>>>> sphinx) to >>>>>> specify an index source in a search. One thing to keep in mind is >>>>>> that >>>>>> every document must have a unique id. So if you have multiple >>>>>> sources >>>>>> on the same model, you have to make sure that the same row does >>>>>> not >>>>>> occur in both indexes, or you must merge the sources together >>>>>> (not >>>>>> supported by thinking sphinx). >> >>>>>> You may be best of creating an attribute that is a custom SQL IF >>>>>> statement. Other options not supported by thinking sphinx are >>>>>> multiple >>>>>> indexes or id mangling (add 1 billion to the id of every row in >>>>>> the >>>>>> second index). >> >>>>>> On Jun 11, 3:59 pm, steve <[email protected]> wrote: >> >>>>>>> So I successfully created a second index on the same model by >>>>>>> using >>>>>>> another define_index block. However I would like to invoke >>>>>>> those >>>>>>> searches separately as I need to do different filtering on the >>>>>>> results. Is there some way to pass the intended source (i.e >>>>>>> user_core_0 or user_core_1) into the search call? >> >>>>>>> Thanks for your help. >> >>>>>>> Steve >> >> > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
