Unify and document search operators

[coeit]

Summary

This issue aims at standardizing and documenting the use of search operators in the zendro graphql schema. Currently there is little to no information on the operators exposed, what they implement and how to use them. Furthermore some operators need to be standardized for different storage types.

List of operators

Currently the following operators are exposed by default through the graphql schema.

Fill out the table below and add it to the Zendro API Documentation. Also have a look at the postgres operators and the sequelize documentation (Section Operators )for more details.

Also have a look at the spa models utility for a list of operators for each storageType.

operator	description	example	storage limitations
like
notLike
or
and
eq
between
notBetween
in
notIn
gt
gte
lt
lte
ne
regexp
notRegexp
contains
contained
not
all

If there are limitations to the storageType (e.g. cassandra doesn't support like) we do that in one of two possible implementations:

• only expose supported operators in the model schema, i.e. have a CassandraOperator, Neo4jOperator, ...
• always expose all operators and throw an Error while parsing the search-argument if not supported

Operators that need to be standardized / looked at

like

Like searches are a way of pattern matching supported by sql, presto and amazonS3. The standard here is to use % for multiple (or none) wildcard characters and _ for exactly one wildcard character.

To unify the behaviour regardless of the storageType we can implement it in neo4j and mongodb ourselves using regex. This is needed in case the model is remote and the user is not aware of the remote storageType. In case of distributed data-models a like search should work regardless of the storageTypes, if supported.

regexp / notRegexp

Regex and notRegexp searches are supported by sql, neo4j and mongodb.

contains

Currently contains has different implementations depending on the storageType. It can be either an array contains or a string contains. This needs to be standardized, probably by offering an arrayContains and stringContains. The latter could be implemented via like / regex. We can also just offer contains for arrays and if a user wants to do a string contains he/she can use like or regexp.

Make sure that the contains on arrays and the in operator are well defined and used correctly. While contains filters on array columns given a scalar value, in is the exact opposite and filters on scalar columns given an array.

contained

In postgres contained implements a filter for subset of an array column. Investigate if this is implemented for other storageTypes.

[asishallab]

contains

Split into two operators: str_contains and arr_contains or something similar.

in vs contains

Write integration tests to ensure the outlined behavior. Make sure, the Zendro documentation is up to date.

Regexp notRegexp

If necessary split into two operators, regexp and fullRegexp or something similar.

like in storage-types that do not support like

Implement the like operator for the storages, that do not have it but have regexp using regexp as like.

Data Model specific operators

Depending on the storage of the data model, in the schema define available operator lists. For generic data models use the SQL standard. Note in the Zendro manual that the programmer (Zendro user) needs to look into this.

[asishallab]

all operator

Investigate what id does and in what storages it is supported, please

Most likely this is a "Karteileiche" and needs to be removed.

[asishallab]

Update Zendro documentation about searches / queries / operators

• Make sure we have an exhaustive documentation, because our search API is one of Zendro's primary strengths. The documentation should celebrate this strength of Zendro.
• Add a brief section of how to "simulate" min and max operators with sorting and limiting results.
• Add a section about the limitations of Cassandra / Skylla

[coeit]

• 193

• gql-server: #74
• documentation:#23