Hi Sven, >From what I can remember of TS v2, the MVA string attributes were actually >transformed under the hood to CRC32 values, which was quite hawkish, hence TS >v3 onwards taking the simpler approach, as you’ve found.
Especially given you’re going through a has_many association, I would recommend using the primary key from that association as the facet value (thus, integers), and then translate ids to strings in your interface as required. I realise that means more work for you, but I think skipping around the transformation and related challenges is a better way to go overall. Good luck with the rest of the updating! — Pat > On 21 Mar 2017, at 7:30 am, 'Sven Riedel' via Thinking Sphinx > <[email protected] <mailto:[email protected]>> > wrote: > > Hi, > yes you read correctly, this is one for the archeologists :). > > I've inherited a project at work where the current state of the code is a tad > on the dated side, and unfortunately none of the original team members are > around to bug with questions. Since I'm a Sphinx novice, I'm at a bit of a > loss when it comes to non-trivial issues. > > So far I've extracted the index definition of the model in question to > app/indices according to > http://freelancing-gods.com/thinking-sphinx/indexing.html#attributes > <http://freelancing-gods.com/thinking-sphinx/indexing.html#attributes> . > However, there are some attribute definitions that work fine with TS 2.0 (and > 2.1) but TS 3 complains about them being string typed MVAs. I haven't been > able to figure out if TS2 supported string MVAs and that feature got cut in > TS3, or if some transformation of the attribute definition took place in the > background that doesn't happen anymore. > > The offending attribute definitions have the following format in TS2: > > has <has_many association>(:<column_name>), facet: true, type: :string, as: > <alias> > > I've transformed them to the TS3 syntax accordingly: > ThinkingSphinx::Index.define ... > has <has_many association>.<column_name>, facet: true, type: :string, as: > <alias> > end > > Excluding the string type, the definition itself looks ok to me. > > Are there any workaround for these situations beyond transforming all the > attribute values with CRC32() and handing the queries appropriately? Since I > don't know the application logic in detail and more importantly the actual > reasoning behind it, I'm hesitant to make big changes in the code base that > could have behavioural changes as a side effect. > > We're running Sphinx 2.1.9 on the server side, if that makes any difference. > > Any help is appreciated. > > Thanks, > Sven > > -- > You received this message because you are subscribed to the Google Groups > "Thinking Sphinx" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/thinking-sphinx > <https://groups.google.com/group/thinking-sphinx>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Thinking Sphinx" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/thinking-sphinx. For more options, visit https://groups.google.com/d/optout.
