Option 2 sounds good to me - it's not too complex, it helps the user understand
more if they need to, and there's no fiddly string gsubbing.
Feel free to take a stab at implementation, or create a ticket and and I'll get
to it when I have a chance.
Cheers
--
Pat
On 18/02/2010, at 8:06 PM, Tom Stuart wrote:
> Hi Pat,
>
> On 18 Feb 2010, at 08:04, Pat Allan wrote:
>> As you've alluded to at the end, the other match modes make assumptions
>> tricky... and so I'm hesitant to run everything through Riddle.escape...
>> I don't want to presume that the user wants every custom character escaped
>> automatically (because what if they're using boolean logic?)
>
> Yeah, I was only suggesting Riddle.escape as a solution for the simplest case
> where the user was explicitly (or implicitly by default) asking for
> :match_mode => :all. For :boolean you'd have to do something (significantly?)
> more complex, but even issuing a warning ("Warning: you've specified both
> :conditions and :match_mode => :boolean, which are incompatible; using
> :match_mode => :extended instead, which may change the meaning of your
> query") would be better than silently switching the match mode and
> potentially making a nonsense of the intended query.
>
>> maybe we can have conditions automatically have @'s escaped?
>> So, does this sound like a decent solution?
>
> It would deal with my specific case -- I sent my initial message exactly
> because I'd spotted that searches for email addresses weren't working right
> -- but it seems like a dodge for the real problem, and might cause other
> hassles that I haven't thought of. From my perspective the available options
> are:
>
> * Do nothing (i.e. rely on the docs to explain this situation);
> * Emit a warning whenever :conditions is supplied but :match_mode is anything
> other than :extended;
> * Automatically fix up any conditions with Riddle.escape when :match_mode is
> :all (or should that be :any?), and emit a warning whenever :conditions is
> supplied but :match_mode is anything other than :all (:any?) or :extended; or
> * Write a parser which, given a query string and its intended match mode, can
> construct an internal representation of the query and then "serialize" that
> representation back out into an extended mode query string, and then use this
> parser/serializer to convert each condition into its extended mode equivalent.
>
> Feel free to choose option 1. :-) But if you're interested in any of the
> other options, I'd be happy to try implementing something.
>
> Cheers,
> -Tom
>
> --
> 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.
