RCBC-422: Remove extra attributes, fix bugs and add to_h #89
Conversation
|
Can one of the admins verify this patch? |
DemetrisChr
changed the title
| data[:analyzer] = analyzer if analyzer | ||
| data[:operator] = operator if operator | ||
| data[:fuzziness] = fuzziness if fuzziness | ||
| data[:prefix_length] = prefix_length if prefix_length |
There was a problem hiding this comment.
prefix_length should not be checked if fuzziness was not specified
There was a problem hiding this comment.
The RFC says that prefix_length requires fuzziness to be specified for TermQuery, it doesn't mention this requirement for MatchQuery. I think it could make sense to have a prefix length for MatchQuery since it does stemming and other preprocessing, where you could end up matching words that don't have the same prefix as the query token, unless you use prefix_length. In TermQuery since it doesn't do any pre-processing it doesn't make sense to use prefix_length without fuzziness.
There was a problem hiding this comment.
Nervermind, the spec does not say it. I don't know why I did it initially
There was a problem hiding this comment.
Probably because it is not used with zero fuzziness:
There was a problem hiding this comment.
Interesting, I guess in that case it doesn't really make a difference
3 participants
to_hmethods that have the logic that used to be into_json(This is helpful for the protostellar SDK). Theto_jsonmethod is now defined in the base class and just converts to JSON what is returned byto_hoperatorattribute from all search queries apart fromMatchQueryas per the RFCMatchAllQuery)prefix_lengthwithoutfuzzinessinMatchQueryDocIdQuery(doc_idhad to be renamed toid, otherwise the server returns an error) + added a test for this