#1783746: Add support for "between" operator introduced the following change to search_api_views.views.inc:
elseif (in_array($inner_type, array('integer', 'decimal', 'duration', 'string'))) {
$table[$id]['filter']['handler'] = 'SearchApiViewsHandlerFilterNumeric';
}
This causes the numeric filter handler to be used for fields of type "string" and "
string".
The attached patch removes "string" from the list of checked types, so that the fallthrough to SearchApiViewsHandlerFilter applies.
| Comment | File | Size | Author |
|---|---|---|---|
| search_api-views-filter-numeric-string.patch | 693 bytes | ciss |
Comments
Comment #2
ciss commentedComment #3
drunken monkeyCould you give some reasoning for why you want that change?
Comment #4
ciss commented@drunken monkey The change treats string properties as numeric values if no options list callback is defined. Among these are:
- custom alterations
- the country property of an address field
- search_api_et_id
I've just read your remark in #1783746: Add support for "between" operator that the numeric handler is used for strings in D8. Respectfully, the decision to apply *Numeric to strings in D7 seems arbitrary since a generic filter handler already exists. Also, now any change to the numeric handler needs to also consider non-numeric values.
Comment #5
drunken monkeyOK, asked another way: Is there anything actually broken, or is this just about strings not being numbers conceptually?
Comment #6
ciss commentedCan't say for certain yet, unfortunately. We still have to reintegrate breaking search_api changes into a project, but won't get to that for at least another month.
I'll have to fix some other issues first (with regard to this comment) to check which incompatibilities remain. Please feel free to keep this postponed until then.
Comment #7
drunken monkeyClosed due to long time without response.
Please re-open with the requested information if still relevant.