sqon doc #1012
sqon doc #1012
Conversation
|
Consider outlining performance/functionality gain versus using simpler and more familiar postgres queries. |
| | Operator | Description | Value Type | Example | | ||
| | -------- | ------------------------------------------------ | ------------------ | ------- | | ||
| | `"in"` | Field value must match one of the listed values | Array | `"value": ["Ontario", "Quebec"]` | | ||
| | `">="` | Field value must be greater than or equal to | Scalar (number) | `"value": 1640926800000` | | ||
| | `"<="` | Field value must be less than or equal to | Scalar (number) | `"value": 1672549199999` | |
There was a problem hiding this comment.
This is a good start. Arranger can support more operators than this. We should definitely make a standardized absolute list and ensure compatibility across all services that use SQONs.
|
|
||
| ```json showLineNumbers | ||
| { | ||
| "query": "query tableData($sqon: JSON, ...) { file { hits(filters: $sqon, ...) { ... } } }", |
There was a problem hiding this comment.
multiline query to maintain some readability
also, my suggested comment is optional, meant as an additional breadcrumb for people trying to figure out how things work under the hood
| "query": "query tableData($sqon: JSON, ...) { file { hits(filters: $sqon, ...) { ... } } }", | |
| "query": "query tableData($sqon: JSON, ...) { | |
| file { // Arranger's "document type" | |
| hits(filters: $sqon, ...) { ... } | |
| } | |
| }", |
| | SQON Component | Elasticsearch Equivalent | Notes | | ||
| |----------------|-------------------------|-------| | ||
| | `"op": "and"` | `"bool": { "must": [...] }` | AND logic requires all conditions to match | | ||
| | `"op": "in"` | `"terms": { "field": [...] }` | IN operation uses Elasticsearch's `terms` query | | ||
| | `"fieldName": "data.primary_site"` | `"data.primary_site": [...]` | Field name maps directly to the index mapping | | ||
| | `"first": 20` | `"size": 20` | Pagination size parameter | | ||
| | `"offset": 0` | `"from": 0` | Pagination offset parameter | | ||
|
|
There was a problem hiding this comment.
prettier generally does a good job at inserting spaces in md to make tables readable even without a md render. wonder if the settings in this repo need adjustment to make sure this tool is applied here
| | `"offset": 0` | `"from": 0` | Pagination offset parameter | | ||
|
|
||
| :::tip | ||
| This translation happens automatically ensuring users never interact directly with Elasticsearch. |
There was a problem hiding this comment.
adjusting this to sound more like it's a convenience feature, not a security concern or a limitation
| This translation happens automatically ensuring users never interact directly with Elasticsearch. | |
| This translation happens automatically ensuring users never need to interact directly with Elasticsearch. |
3 participants
Remaining Tasks:
Netlify Page Preview: https://deploy-preview-33--overturedocs.netlify.app/docs/core-software/Arranger/usage/query-processing
Linked to this docs PR: overture-stack/docs#33
Note
Lyric also uses SQON, this should be documented within the Lyric documentation when it is completed