update ndc-spec to 0.1.0-rc14 #283
Conversation
| /// | ||
| /// This function implements the [mutation/explain endpoint](https://hasura.github.io/ndc-spec/specification/explain.html) | ||
| /// from the NDC specification. | ||
| async fn mutation_explain( |
There was a problem hiding this comment.
new endpoint and capability - explaining mutation requests.
| @@ -3,7 +3,6 @@ | |||
| pub mod capabilities; | |||
| pub mod configuration; | |||
| pub mod connector; | |||
| pub mod explain; | |||
There was a problem hiding this comment.
replaced by a query::explain and mutation::explain modules.
| @@ -50,15 +53,15 @@ pub async fn mutation<'a>( | |||
| timer.complete_with(result) | |||
| } | |||
|
|
|||
| fn plan_mutation( | |||
| pub fn plan_mutation( | |||
There was a problem hiding this comment.
used in the explain module
| @@ -108,6 +108,11 @@ pub enum From { | |||
| alias: TableAlias, | |||
| column: ColumnAlias, | |||
| }, | |||
| Unnest { | |||
There was a problem hiding this comment.
Used for fancy queries like in <variable> or in <column>, which are converted to a subquery of unnest.
| @@ -67,116 +68,153 @@ pub fn translate_expression( | |||
| column, | |||
| operator, | |||
| value, | |||
| } => { | |||
| } if operator == "in" => { | |||
There was a problem hiding this comment.
Operators are now strings, and BinaryArrayComparisonOperator is gone.
There was a problem hiding this comment.
the old binary array comparisons was only between a column and a vector of values. This new formulation lets us compare against scalar arrays, columns and variables. These are implemented below.
| )?, | ||
| vec![], | ||
| )), | ||
| } => match predicate { |
There was a problem hiding this comment.
predicates are now optional instead of being an equivalence of true when they are omitted.
| "type": "column", | ||
| "column": { | ||
| "type": "column", | ||
| "name": "series", |
There was a problem hiding this comment.
new capability: filter by "in column"
| "operator": "in", | ||
| "value": { | ||
| "type": "variable", | ||
| "name": "array" |
There was a problem hiding this comment.
new capability: filter by "in variable"
| let timer = state.metrics.time_query_total(); | ||
| let timer = state.metrics.time_mutation_total(); |
| value: models::ComparisonValue, | ||
| typ: &database::ScalarType, | ||
| typ: database::Type, |
There was a problem hiding this comment.
These could probably both be some references to avoid clones at the call sites.
| "operator": { | ||
| "type": "equal" | ||
| }, | ||
| "operator": "eq", |
There was a problem hiding this comment.
Why is this one "eq" but others are "_eq"?
There was a problem hiding this comment.
eq refers to the built-in equals operator from ndc-spec, _eq refers to the operator defined in the metadata of some tests (in tables.json). Most tests will use eq, but some tests might have wanted to test a metadata-defined operator? I wouldn't mind changing everything to eq.
There was a problem hiding this comment.
I honestly don't understand this well enough to agree or disagree, so I am going to pretend I didn't ask and trust that you know what you're doing.
There was a problem hiding this comment.
ndc-spec defines two standard operators that a connector should implement - equal (eq) and in (in). Any other operator is a custom operator defined by the connector.
So for us we implement in and eq as built-in operators that do not need to be defined in the ndc-metadata, and we also allow users to define their own operators in the ndc-metadata using the comparisonOperators field. Example.
In most tests (like this one), we use the built-in eq operator. In other tests where we use the _eq operator, we have to define it like in the example I linked.
Tests that use _eq also test custom comparison operators, tests that use eq test the built-in operator.
|
I think I made a big merge conflict for you. Sorry. |
What
We are updating connector to support the latest ndc-connector spec (0.1.0-rc14).
While fixing some breaking changes, such as renaming
wheretopredicate, we also support new capabilities:/mutation/explainendpointinby columns and variablesHow
<operation_name> SQL Mutationand a field named<operation_name> Execution Planfor each operation.(select value from unnest(<column-or-variable>) as table(value)).