Operators
Operators in Optimizely Graph let you control exactly how a query matches each field, so you can pick the best match strategy for site search, exact lookups, ranges, and wildcards. Choose the operator that fits the field type and the user experience you want to deliver.
For every field, add an operator to match the content of that field in a particular way.
Note When null is used as a value with an operator, the query ignores the matching. For example, exist:null is ignored.
Optimizely Graph supports the following operators:
- match – Optimized for returning the most relevant results and applying common text-matching techniques. It works on searchable string fields, which contain large chunks of text. It returns more relevant results than contains and returns more results in general, offering a better user experience for site visitors. Use the match operator as a default operator for site search.
- contains – Performs a full-text search on a word or phrase, with support for language stemming when you add the locale parameter. It matches on terms tokenized by word boundaries according to UAX #29: Unicode Text Segmentation. When matching on a term with a leading or trailing punctuation character, Optimizely Graph ignores these characters. It is the recommended operator for full-text search. It is available on searchable fields only.
- eq – Matches an exact literal value. The value is case-insensitive, but results matching cases are ranked higher.
- notEq – Retrieves results not matching with an exact literal (but case-insensitive) value.
- gt – Retrieves results with matches that have a value that is greater than the value.
- gte – Retrieves results with matches that have a value that is greater than or equal to the value.
- lt – Retrieves results with matches with a value of less than the value.
- lte – Retrieves results with matches with a value of less than or equal to the value.
- exist – Matches results that have this field with a value.
- startsWith – Retrieves matches that start with a certain value (prefix). It is case-insensitive. Example: startsWith: "eng" matches "English" or "english", and also "engineering".
- endsWith – Retrieves matches that end with a certain value (suffix). It is case-insensitive. It is available on queryable fields only. Example: endsWith: "lish" matches "English" or "bullish".
- in – Matches with one or more exact literal (case-sensitive) values in a list. Example: in: ["word1", "word2", "this is a phrase"]
- notIn – Returns results that do not match with one or more exact literal (case-sensitive) values in a list. Example: notIn: ["word1", "word2", "this is a phrase"]
- like – Matches with wildcard support. Use % to match zero or more characters and _ to match any single character. The matching semantics differ by indexing type. On queryable fields (StringFilterInput), like matches a substring anywhere in the value. On searchable fields (SearchableStringFilterInput), like matches the start of a token. Go to How like differs by indexing type.
How like differs by indexing type
like is the one operator whose meaning changes with the indexing type of the field. A query that works on a queryable field can return no results on a searchable field, without an error. Check the indexing type of the field before you rely on like.
Important A searchable field is not a superset of a queryable field. Searchable fields add match and contains, drop endsWith, and change what like matches. To learn which indexing type to choose, go to Control field indexing.
Operator | Queryable (StringFilterInput) | Searchable (SearchableStringFilterInput) |
|---|---|---|
like: "%x%" | Matches x anywhere in the value, including inside a word. | Matches only tokens that start with x. Never matches inside a word. |
match, contains | Not available. The query returns a schema error. | Available. |
endsWith | Available. | Not available. The query returns a schema error. |
like on queryable fields
For fields with the type StringFilterInput, like matches a substring anywhere in the value, including the middle of a word. A leading wildcard is supported.
- like: "%pp%" – Matches "app", "applications", and "whopper".
- like: "%ears" – Matches "ears", "bears", and "years".
like on searchable fields
For fields with the type SearchableStringFilterInput, Graph analyzes the value into tokens, and like matches the start of a token. A term wrapped in a leading and a trailing % becomes a prefix match against each token. It does not match a sequence of characters in the middle of a word.
- like: "%pp%" – Matches none of "app", "applications", or "whopper". Each value contains "pp", but no token in them starts with "pp". The same filter on a queryable field matches each of these values.
- like: "%app%" – Matches tokens that start with "app", such as "app", "applications", and "apple". It matches the value "Optimizely apps are the most awesome!", because the token "apps" starts with "app".
- like: "%ChangR%" – Matches the token "ChangRyul".
- like: "%Ryul%" – Does not match the token "ChangRyul", because "Ryul" is in the middle of the token.
- like: "Course %ollaboration Mad% Simple" – Matches "Course Collaboration Made Simple". When you do not wrap the phrase in a leading and a trailing %, a wildcard inside a word is supported.
- like: "%ears" – Returns an error. A single term with a leading wildcard and no trailing wildcard is not supported.
- like: "%_ourse %ollaboration Mad% Simple%" – Returns an error. When you wrap a phrase in a leading and a trailing %, no word inside the phrase can start with a wildcard.
Note No indexing type gives you substring matching and full-text search on one field. If you need the two behaviors on the same property, go to Control field indexing and read the companion field pattern.