Throwing in for my sixpence of opinion, I think this is not a good idea:
I think it's too specific to be useful for clients.
- what reasonable behaviour should a client do when getting a
130: too many terms matched by masked query term ???
how should it manipulate a query to take down the count of OR's (if it
implemented like that in your DB ??
How should this be presented to the end user ??
- It is much better to send back a more generic error message -
a) sorry, I can not do this type of query at all, or
b) sorry, this query is too complex - for whatever reasons.
in case of a) you are forbidding queries which can not always be
dealt with - i.e. disabeling a shaky server implementation feature, and
in b) you are telling that a feature, which is normally working, did
fail due to exceptional circumstances.
Then it is up to the human to figure out how a better query can be
Marc Cromme, Index Data
Robert Sanderson wrote:
>> No, the problem is that too many terms were generated to be OR'd
>> The result set might end up with only one record in it.
> Do intermediate stages count as result sets? I guess not.
> It's also not that the number of records in the intermediate stage is too
> large (as there could be only one record per term).
> Okay, I'm convinced.
> 130: Too many terms matched by masked query term ?
> With Ralph's example as the note and an unspecified details format?
> (As knowing the maximum number of terms that a mask can match is for all
> intents and purposes useless to the client)