<!-- The PR description should answer 2 important questions: -->
### What
Operator mappings in boolean expressions allow us to override the name
of an operator, so we can call some database's `_eq` operator the much
more attractive `equals`. If not override is provided we can just use
the database's name directly. We make this a newtype with a `get`
function to encode this logic and make doing the right thing the easiest
thing.
V3_GIT_ORIGIN_REV_ID: e47f4e291494562ed1551d0d7469259198862a0a
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
Disallow duplicate root fields in a model GraphQL config. This is a
backward incompatible change which could break any existing builds with
duplicate root fields. Hence, this check is guarded behind a
compatibility date. However, warnings are thrown during a build if
metadata contains duplicate graphql root fields.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
Add a check while resolving the graphql metadata of a model definition.
V3_GIT_ORIGIN_REV_ID: d083c62fa359df8742bbc16df821d46275d29e79
<!-- The PR description should answer 2 important questions: -->
### What
Our Nix build was building all the workspace crates as part of it's deps
step. This means when any library crate is changed, we throw away all
the caching, which isn't ideal. This filters the source files out of
those builds, so that we get more cache hits. We also move all Cargo
features into the workspace, which I've been meaning to do for ages, so
things are more consistent, and again, we get more cache hits generally.
V3_GIT_ORIGIN_REV_ID: c724b152692575edf6c00ab426e48ecca13aa998
<!-- The PR description should answer 2 important questions: -->
### What
We only resolve boolean expression fields if there is a `graphql` name
defined, which is not helpful for using them in JSONAPI or SQL. This
makes the validation happen earlier.
This means users that have broken boolean expressions that did not have
a `graphql` field would have been allowed to sit broken, but now those
will error, so this is behind a new compatibility config flag.
### How
Move `scalar_fields` and `object_fields` resolve into `object` steps
instead of the `graphql` steps of resolve for
`ObjectBooleanExpressionType` and `BooleanExpressionType`.
Note: we really need to get `ObjectBooleanExpressionType` deprecated and
deleted, it causes so much extra work and complexity everywhere.
V3_GIT_ORIGIN_REV_ID: c6f0849d412b40f3484fb44c1b36ebdf77ac60c1
We get a 17% reduction in size for chinook.json, 14% for our big schema.
Benchmark is 8% faster for chinook.json
<!-- The PR description should answer 2 important questions: -->
### What
reduce artifact size
### How
remove certain common "default" fields on serialization, to be
repopulated on deserialization. Since this works at the serde level we
should still benefit if we manage to switch to e.g. bincode
I attempted to create a macro for this, but decided it wasn't worth it.
Fields were chosen by sorting and counting json fields, and adding these
annotations for the heaviest ones.
V3_GIT_ORIGIN_REV_ID: 4605016021fa6aafb97759e3bd5346116413a0ef
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
No-op refactor. Just updates the error message.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
Define a type to track root fields and report error if the field is
already in use.
V3_GIT_ORIGIN_REV_ID: 91533ee0dd48087617e1950f1aeb42a1787edc16
### What
This PR updates the engine to use the NDC Spec v0.2.0-rc.1 version. This
is very likely to be the final RC before release.
### How
The `ndc_models` crate got updated, which then resulted in the schema
migration code in `metadata_resolve` being updated. This affected a lot
of test results because connectors that used deprecated type
representations got migrated to other representations, and if a type
representation was missing then JSON was used instead.
The NDC request-sending code in `execute` was updated to send the
`X-Hasura-NDC-Version` header depending on the version of request
getting sent.
The custom connector was updated to be compatible with the new NDC
0.2.0-rc.1 types. This resulted in the schema changing, so a lot of
tests that contained the connector's schema were updated.
---------
Co-authored-by: Daniel Harvey <danieljamesharvey@gmail.com>
V3_GIT_ORIGIN_REV_ID: b1c7081eb1ee6cffdead08328a857903102332c6
<!-- The PR description should answer 2 important questions: -->
### What
These are no longer used since
https://github.com/hasura/v3-engine/pull/1301, let's remove them from
the metadata.
V3_GIT_ORIGIN_REV_ID: 17194f7fa30860738e99de6098fa84d212fee0d2
<!-- The PR description should answer 2 important questions: -->
### What
JSONAPI builds iterate over `roles` in metadata, and one was very slow,
realised it was because it was calculating for `admin` over and over.
This changes the `roles` in `metadata-resolve` to be collected in a
`BTreeSet` to remove duplicates, which fixes the problem.
### How
Change `Vec` to `BTreeSet`, fix type errors and snapshots.
V3_GIT_ORIGIN_REV_ID: c61ef9e490c3cde9d004c08ef71dc73e92cd6e7e
Bumps [derive_more](https://github.com/JelteF/derive_more) from 0.99.18
to 1.0.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/JelteF/derive_more/releases">derive_more's
releases</a>.</em></p>
<blockquote>
<h2>v1.0.0 - Finally a stable release</h2>
<p><code>derive_more</code> is a library that adds derives for many of
the standard library traits. By using this library the following code
just works:</p>
<pre lang="rust"><code>use derive_more::{Add, Display, From, Into};
<p>#[derive(PartialEq, From, Add)]
struct MyInt(i32);</p>
<p>#[derive(PartialEq, From, Into)]
struct Point2D {
x: i32,
y: i32,
}</p>
<p>#[derive(PartialEq, From, Add, Display)]
enum MyEnum {
#[display("int: {_0}")]
Int(i32),
Uint(u32),
#[display("nothing")]
Nothing,
}</p>
<p>assert!(MyInt(11) == MyInt(5) + 6.into());
assert!((5, 6) == Point2D { x: 5, y: 6 }.into());
assert!(MyEnum::Int(15) == (MyEnum::Int(8) + 7.into()).unwrap());
assert!(MyEnum::Int(15).to_string() == "int: 15");
assert!(MyEnum::Uint(42).to_string() == "42");
assert!(MyEnum::Nothing.to_string() == "nothing");
</code></pre></p>
<p>Now, more than 8 years after the first commit and almost 5 years
after the 0.99.0 release, <code>derive_more</code> has finally reached
its 1.0.0 release. This release contains a lot of changes (including
some breaking ones) to make it easier to use the derives and make it
possible to extend them without having to break backwards compatibility
again. There are five major changes that I would like to call out, but
there are many more changes that are documented below:</p>
<ol>
<li>There is a new <code>Debug</code> derive that can be used to easily
customize <code>Debug</code> formatting.</li>
<li>A greatly improved <code>Display</code> derive, which allows you to
do anything that <a
href="https://github.com/dtolnay/thiserror"><code>thiserror</code></a>
provides, but it works for any type not just errors. And by combining
the <code>Display</code> derive with the <code>Error</code> and
<code>From</code> derives, there shouldn't really be any need to use
<code>thiserror</code> anymore (if you are missing a feature/behaviour
from <code>thiserror</code> please report an issue).</li>
<li>Traits that can return errors now return a type that implements
<code>Error</code> when an error occurs instead of a <code>&'static
str</code>.</li>
<li>When using <code>use derive_more::SomeTrait</code> the actual trait
is also imported not just the derive macro. This is especially useful
for <code>Error</code> and
<code>Display</code></li>
<li>The docs are now rendered on docs.rs and are much better
overall.</li>
</ol>
<h3>Breaking changes</h3>
<ul>
<li>The minimum supported Rust version (MSRV) is now Rust 1.75.</li>
<li>Add the <code>std</code> feature which should be disabled in
<code>no_std</code> environments.</li>
<li>All Cargo features, except <code>std</code>, are now disabled by
default. The <code>full</code> feature can be used to get the old
behavior of supporting all possible derives.</li>
<li>The <code>TryFrom</code>, <code>Add</code>, <code>Sub</code>,
<code>BitAnd</code>, <code>BitOr</code>, <code>BitXor</code>,
<code>Not</code> and <code>Neg</code> derives now return a dedicated
error type instead of a <code>&'static str</code> on error.</li>
<li>The <code>FromStr</code> derive now uses a dedicated
<code>FromStrError</code> error type instead of generating unique one
each time.</li>
<li>The <code>Display</code> derive (and other <code>fmt</code>-like
ones) now uses <code>#[display("...",
(<expr>),*)]</code> syntax instead of <code>#[display(fmt =
"...", ("<expr>"),*)]</code>, and
<code>#[display(bound(<bound>))]</code> instead of
<code>#[display(bound = "<bound>")]</code>. So without
the double quotes around the expressions and bounds.</li>
<li>The <code>Debug</code> and <code>Display</code> derives (and other
<code>fmt</code>-like ones) now transparently delegate to the inner type
when <code>#[display("...", (<expr>),*)]</code>
attribute is trivially substitutable with a transparent call. (<a
href="https://redirect.github.com/JelteF/derive_more/pull/322">#322</a>)</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/JelteF/derive_more/blob/master/CHANGELOG.md">derive_more's
changelog</a>.</em></p>
<blockquote>
<h2>1.0.0 - 2024-08-07</h2>
<p>More than 8 years after the first commit and almost 5 years after the
0.99.0
release, <code>derive_more</code> has finally reached its 1.0.0 release.
This release
contains a lot of changes (including some breaking ones) to make it
easier to
use the derives and make it possible to extend them without having to
break
backwards compatibility again. There are five major changes that I would
like
to call out, but there are many more changes that are documented
below:</p>
<ol>
<li>There is a new <code>Debug</code> derive that can be used to easily
customize <code>Debug</code>
formatting.</li>
<li>A greatly improved <code>Display</code> derive, which allows you to
do anything that
<a
href="https://github.com/dtolnay/thiserror"><code>thiserror</code></a>
provides, but it works
for any type not just errors. And by combining the <code>Display</code>
derive with the
<code>Error</code> and <code>From</code> derives, there shouldn't really
be any need to use
<code>thiserror</code> anymore (if you are missing a feature/behaviour
from <code>thiserror</code>
please report an issue).</li>
<li>Traits that can return errors now return a type that implements
<code>Error</code>
when an error occurs instead of a <code>&'static str</code>.</li>
<li>When using <code>use derive_more::SomeTrait</code> the actual trait
is also imported
not just the derive macro. This is especially useful for
<code>Error</code> and
<code>Display</code></li>
<li>The docs are now rendered on docs.rs and are much better
overall.</li>
</ol>
<h3>Breaking changes</h3>
<ul>
<li>The minimum supported Rust version (MSRV) is now Rust 1.75.</li>
<li>Add the <code>std</code> feature which should be disabled in
<code>no_std</code> environments.</li>
<li>All Cargo features, except <code>std</code>, are now disabled by
default. The <code>full</code>
feature can be used to get the old behavior of supporting all possible
derives.</li>
<li>The <code>TryFrom</code>, <code>Add</code>, <code>Sub</code>,
<code>BitAnd</code>, <code>BitOr</code>, <code>BitXor</code>,
<code>Not</code> and <code>Neg</code>
derives now return a dedicated error type instead of a
<code>&'static str</code> on
error.</li>
<li>The <code>FromStr</code> derive now uses a dedicated
<code>FromStrError</code> error type instead
of generating unique one each time.</li>
<li>The <code>Display</code> derive (and other <code>fmt</code>-like
ones) now uses
<code>#[display("...", (<expr>),*)]</code> syntax
instead of
<code>#[display(fmt = "...",
("<expr>"),*)]</code>, and
<code>#[display(bound(<bound>))]</code>
instead of <code>#[display(bound = "<bound>")]</code>.
So without the double quotes
around the expressions and bounds.</li>
<li>The <code>Debug</code> and <code>Display</code> derives (and other
<code>fmt</code>-like ones) now transparently
delegate to the inner type when <code>#[display("...",
(<expr>),*)]</code> attribute is
trivially substitutable with a transparent call.
(<a
href="https://redirect.github.com/JelteF/derive_more/pull/322">#322</a>)</li>
<li>The <code>DebugCustom</code> derive is renamed to just
<code>Debug</code> (gated now under a separate
<code>debug</code> feature), and its semantics were changed to be a
superset of <code>std</code> variant
of <code>Debug</code>.</li>
<li>The <code>From</code> derive doesn't derive
<code>From<()></code> for enum variants without any
fields anymore. This feature was removed because it was considered
useless in</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="d7f5b9e94d"><code>d7f5b9e</code></a>
chore: Release</li>
<li><a
href="40201b1e2e"><code>40201b1</code></a>
Update release date to be correct</li>
<li><a
href="88863ca4e6"><code>88863ca</code></a>
Update changelog wording</li>
<li><a
href="b713835894"><code>b713835</code></a>
Improve error when not enabling any features</li>
<li><a
href="330e4252fb"><code>330e425</code></a>
Order features in Cargo.toml alphabetically</li>
<li><a
href="84f2cbb05f"><code>84f2cbb</code></a>
Update README and CHANGELOG in preparation of 1.0.0</li>
<li><a
href="e8d60cf0e5"><code>e8d60cf</code></a>
Add compile_fail test for on purpose limited bounds (<a
href="https://redirect.github.com/JelteF/derive_more/issues/393">#393</a>,
<a
href="https://redirect.github.com/JelteF/derive_more/issues/392">#392</a>)</li>
<li><a
href="f665d18125"><code>f665d18</code></a>
Make anyhow reference a bit less strong</li>
<li><a
href="6d632b2db2"><code>6d632b2</code></a>
Add release announcement (<a
href="https://redirect.github.com/JelteF/derive_more/issues/390">#390</a>)</li>
<li><a
href="e87ab1315f"><code>e87ab13</code></a>
Don't create git tags for derive_more-impl (<a
href="https://redirect.github.com/JelteF/derive_more/issues/391">#391</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/JelteF/derive_more/compare/v0.99.18...v1.0.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Daniel Harvey <danieljamesharvey@gmail.com>
V3_GIT_ORIGIN_REV_ID: 2a5d2033a90d16d5bf2096db5a717e31128b8c00
<!-- The PR description should answer 2 important questions: -->
### What
Move `lang-graphql`, `graphql-ws` and `frontends/graphql` into the
`graphql` folder. Functional no-op.
V3_GIT_ORIGIN_REV_ID: c9d6c5db6693dbe9213569443a102a3b3b2e39f6
<!-- The PR description should answer 2 important questions: -->
### What
Release `OrderByExpression` and version 2 of `Model`. These have been
working behind feature flags for a while.
### How
Remove feature flags, remove `hidden` pragmas on `open-dds` metadata.
V3_GIT_ORIGIN_REV_ID: dfb7e9316171c11d2605dfbf01552db093d81d63
<!-- The PR description should answer 2 important questions: -->
### What
Previously we stored scalar values for `OrderByExpression` inline, now
we break them out into their own discreet metadata items.
### How
Mostly fixing tests.
V3_GIT_ORIGIN_REV_ID: e3ee1c1c9c5ae05113cf82c10627cc89b8b9894c
<!-- The PR description should answer 2 important questions: -->
### What
Now when resolving `orderableRelationship` in `order_by_expressions` we
check the relationship name refers to a real relationship on that type,
and throw an error if not.
If we lookup the relationship and it refers to an unknown subgraph, we
exclude it but do not error.
V3_GIT_ORIGIN_REV_ID: 4d310c6e800cf830860efce30e28fc5f258bf39b
<!-- The PR description should answer 2 important questions: -->
### What
Adds response types for JSONAPI endpoints. They look OK!
<img width="733" alt="Screenshot 2024-10-23 at 17 48 05"
src="https://github.com/user-attachments/assets/cbd52523-3511-404a-9716-eed142847158">
V3_GIT_ORIGIN_REV_ID: 72050f3d0accf57c3c77e83aed4bd684da46786b
### What
If a connector defined a function/procedure/collection argument that
took a predicate type, but made it a nullable predicate type, then
metadata-resolve would fail to bind an argument preset for that argument
in ModelPermissions and CommandPermissions.
This has been fixed.
### How
The code that bound a boolean expression to the argument wasn't stepping
through nullable types properly. This has been fixed by reusing a
nullable type unwrapping function from another module (and moving it
into a shared location for reuse).
New metadata resolve tests have been added to verify that this works,
for both the nullable and non-nullable cases.
---------
Co-authored-by: Brandon Martin <brandon@codedmart.com>
V3_GIT_ORIGIN_REV_ID: 4d33d53522551a6217e618451041aa3b1cf89e52
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: 894ba81666bb441e71b8e204b89e5732ac4f1c83
<!-- The PR description should answer 2 important questions: -->
### What
To generate JSONAPI OpenAPI spec we need to know the underlying type
representation of custom types. This is (optionally) provided by a data
connector in it's `scalar_types` section. It's really annoying to look
up, so let's collect them all and store them on the
`ScalarTypeRepresentation`, keyed by `Qualified<DataConnectorName>`.
No functional change, this will be used in JSONAPI OpenAPI generation
shortly.
V3_GIT_ORIGIN_REV_ID: 084304a580aca977e1f8c39b16938205a49b1b0e
I am sorry @rakeshkky , we will merge this again once we've done a
release, I promise.
Reverts hasura/v3-engine#1254
V3_GIT_ORIGIN_REV_ID: 74236d25d4e84658717531a55d87c8d3371b553c
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: 3458ea1e5ebe2d7387a7e503f957e5d55f225599
<!-- The PR description should answer 2 important questions: -->
### What
This PR adds a check to disallow defining boolean expression of array
fields with scalar boolean type while resolving the boolean expression
`comparable_fields`.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: e9fd2feaff5a20d05b51b9ccd2a460f2b7e767dc
Reverts hasura/v3-engine#1225
According to @danieljharvey, websockets don't currently work in
multitenant and we want to do a release using a commit after this one.
V3_GIT_ORIGIN_REV_ID: 2d9239ab3203d5acbedef1cd86644861a99c99b2
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
- Remove `enable-subscriptions` from unstable features.
- Expose the subscriptions related opendd metadata in the json schema
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
- Update unstable feature related types by dropping subscriptions.
- Remove `hidden=true` opendd attribute and other related on
subscription opendd metadata.
- Update json schema files
V3_GIT_ORIGIN_REV_ID: 0aa763f516d394aab2e375da0817d0e60228c9b2
<!-- The PR description should answer 2 important questions: -->
### What
Allows JSON arrays in session variables.
### How
If the type of a session variable isn't special (custom scalar, string,
or ID), then we parse the header as JSON, and switch into
type-_checking_ mode, returning the JSON wholesale if the type matches.
V3_GIT_ORIGIN_REV_ID: 386558898a188c06b73270a90020a20ff963f5a0
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
---------
Co-authored-by: Abhinav Gupta <127770473+abhinav-hasura@users.noreply.github.com>
V3_GIT_ORIGIN_REV_ID: 05adb2015efda4d5244b93cfe337991370f0b27e
<!-- The PR description should answer 2 important questions: -->
### What
Previously we were doing the business of calculating which arguments
(and parts of arguments) were preset in the GraphQL `schema` crate. This
meant we would have to reimplement the logic for each backend. Now we
move it into `metadata-resolve` so the results can be shared by all
frontends.
### How
Move argument preset resolve into `metadata-resolve`. What's left in
`graphql-schema` is all the stuff relating to `Annotation`s of various
kinds.
A lot of the diff is changing `ModelWithPermissions` and
`CommandWithPermissions` to `ModelWithArgumentPresets` and
`CommandWithArgumentPresets` in crates after `metadata-resolve`.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: b1b0983abb9f6282652c8689b02e0796026752f5
<!-- The PR description should answer 2 important questions: -->
### What
This PR adds two new operand types for `BooleanExpressionType` in
OpenDD: `objectAggregate` and `scalarAggregate`. These two operand types
are then validated in metadata resolve to ensure their correctness.
Their design is based on [this
RFC](https://github.com/hasura/v3-engine/pull/945#issuecomment-2325652794).
They are hidden from the OpenDD JSON Schema and their usage is blocked
by default via a new unstable feature flag.
They are also currently not "usable", as the metadata resolve code that
would use an `objectAggregate` operand-ed `BooleanExpressionType` to
satisfy an aggregate predicate over an array relationship does not
exist. This will be added in a future PR; this PR is big enough!
### How
A new unstable feature `enable_aggregation_predicates` has been added to
gate this feature behind while it is in development.
The new OpenDD types have been added to
`crates/open-dds/src/boolean_expression.rs`.
A new metadata resolve stage `aggregate_boolean_expressions` has been
added that specifically resolves these two new operand types. Most of
the new code changes in this PR exist in this new stage.
The output of this stage is composed into the `boolean_expressions`
stage afterwards, but other than just being consumed and included there,
it is unused for now. In a future PR it will be used when resolving
object-operanded `BooleanExpressionTypes`.
An exhaustive set of metadata resolve tests has been added to test all
the error, warning and passing cases for both object and scalar
aggregate operands
(`crates/metadata-resolve/tests/failing/aggregate_boolean_expressions/`
and
`crates/metadata-resolve/tests/passing/aggregate_boolean_expressions/`).
These files make up the vast majority of the file count in this PR.
V3_GIT_ORIGIN_REV_ID: e0e030b322d05212a0e2630acc9f4db7b05000c1
### What
Like #1192, this PR adds a context to another error raised during the
`models` resolution step. Specifically, `UnknownModelCollection`.
### How
These PRs are extremely simple, it's just that there are going to be
dozens of them. When an error refers to a thing, you wrap that thing in
`Spanned`, and then try to extract the `path` at the error site. Most of
the time, it's pretty straightforward.
---------
Co-authored-by: Daniel Chambers <daniel@hasura.io>
V3_GIT_ORIGIN_REV_ID: d3ea71d3d9a42cbf804add54f5f6e75ab68c6765
### What
Currently if you want v3-engine to accept metadata that is only a
partial supergraph (ie missing some subgraphs), you must set the
PARTIAL_SUPERGRAPH env var. Builds sent to MBS get sent to a special
endpoints `/validate/partial` and `/build/partial` that runs the engine
build process with that configuration option set.
This results in a terrible user experience for local builds, because MBS
will accept a partial supergraph and yield build artifacts, but
v3-engine will refuse to run them unless you set that env var.
This PR removes that env var and creates a new OpenDD flag called
`allow_partial_supergraph`. When MBS's `/validate/partial` endpoint is
used, that flag is set in the build artifacts. v3-engine then looks at
that flag to enable partial supergraph mode. This means a
`/build/partial` build via MBS just works when you run it locally via
v3-engine.
### How
`metadata_resolve`'s `Configuration.allow_unknown_subgraphs` has been
removed, and `metadata_resolve` now looks at OpenDD's new
`Flags.allow_partial_supergraph` instead.
In MBS, usage of `ValidationMode` (the enum that enables partial builds)
previously used to set `Configuration.allow_unknown_subgraphs`; now it
is used in `compute_open_dds_flags` in order to set
`Flags.allow_partial_supergraph`.
The existing metadata_resolve test that tested partial supergraphs has
been modified to use the flags rather than the removed configuration
option
(`crates/metadata-resolve/tests/passing/missing_subgraph_when_ignoring_unknown_subgraphs`).
A new `metadata_resolve` test has been added that checks that comparable
relationships in `BooleanExpressionType` properly respects the
`allow_partial_subgraphs` flag (this functionality was added in #1182).
V3_GIT_ORIGIN_REV_ID: 2c984eb791263a1fb0606c6c44a2a1ae4a5e7370
<!-- The PR description should answer 2 important questions: -->
### What
Functional no-op towards making `graphql_ir` less central and breaking
some import cycles.
### How
Move the function.
V3_GIT_ORIGIN_REV_ID: 53ea007964f5ab79cb546821cfb76f542ea3b486
<!-- The PR description should answer 2 important questions: -->
### What
Previously when we used a string from a session variable as a passed
through header it would become double escaped like `\"the string\"`.
This is because we were encoding to JSON, going back to
`reqwest::header::HeaderValue` and then back to JSON. Instead, let's
stay in JSON.
### How
Instead we stay in JSON for the session variable encoding, and
explicitly do the `reqwest::header::HeaderValue` -> JSON encoding. We
take the string in `HeaderValue` and make it a
`serde_json::Value::String`.
V3_GIT_ORIGIN_REV_ID: 3fd4df7c4aac5eadedd2d533cdf8e20dfa718060
<!-- The PR description should answer 2 important questions: -->
### What
In #1168 we checked for duplicate command names. However this made a
project build fail, so we instead put this behind a flag and raise a
warning.
V3_GIT_ORIGIN_REV_ID: 41e3dcfda1d3f2da1e7ca672c9d20e0a3917d868
### What
This PR allows MBS errors to provide a larger "context". Our notion of
context is an ordered list of annotated paths. An example would be for a
name conflict, where we want to say `["this name was used here", "...
and also here"]`, so reporting two paths would be helpful.
Note that the actual format of `path` is a structured data type, not a
string. An example of the first instance introduced by this PR can be
seen here:
```json
{
"errors": [
{
"context": [
{
"message": "Data connector name given here",
"path": [
{ "Index": 11 },
{ "Key": "definition" },
{ "Key": "source" },
{ "Key": "dataConnectorName" }
]
}
],
"code": "opendds-validation",
"message": "invalid metadata: error building schema: invalid metadata: the source data connector b (in subgraph default) for model Artists (in subgraph default) has not been defined",
"path": null
}
]
}
```
The `path` key is already generated by other parts of the MBS process,
so we preserve it for now to avoid breaking changes.
### How
* A new crate, `error-context`, to hold the type of the context
structure.
* Otherwise essentially the same as the path mechanism.
V3_GIT_ORIGIN_REV_ID: 0bb529542ba0a7f6774c08fa6adb7d7c608d6c5b
### What
This PR completes step 2 on the plan in #1153. With this PR, an attempt
to call MBS to build metadata containing a model referencing an unknown
data connector should result in a path to the model.
### How
#1179 introduced the polymorphic version of the error type introduced by
#1170. Unfortunately, due to Rust not having an apartness constraint, we
can't write `impl<T, S: From<T> From<WithContext<T>> for
WithContext<S>`, so we introduce the `coerce` function to allow us to
cast between `WithContext<ChildError>` and `WithContext<ParentError>`.
This means that we can return a `WithContext<ModelsError>` from the
models stage, coerce it to a `WithContext<Error>`, and propagate that
path throughout the system. This PR also extends the `path` function
inside MBS to detect these paths if present, so MBS API errors will
contain any available path.
V3_GIT_ORIGIN_REV_ID: a47c565b792fefb99294c9e21ba526424ddf7cb7
### What
When the engine is run in `PARTIAL_SUPERGRAPH` mode, any relationship
that targets an unknown subgraph should be silently dropped. This was
being done when resolving relationship navigation fields on the
`ObjectType`, but not for `comparableRelationships` on
`BooleanExpressionType`. In that case we were erroring as we tried to
resolve the relationship and couldn't find the target subgraph.
### How
The `relationships` metadata resolve step has been enhanced to capture
if a relationship is targeting an unknown subgraph. The
`object_boolean_expressions` step already used this, so it was tweaked
to skip relationships targeting unknown subgraphs.
The `object_relationships` step, however, did not use `relationships`
and instead went back to metadata_accessor for relationships. It then
had special logic that skipped unknown subgraph relationships. The step
has now been refactored to use `relationships` instead and the special
skipping logic has been discarded, and it now just uses the unknown
subgraph information from `relationships`.
In addition, the `object_relationships` step now _consumes_ the output
of the `type_permissions` step, rather than cloning it. This reduces
unnecessary cloning and makes sense since `object_relationships` is
simply a further enriched version of `type_permissions`.
The test of whether the source object type of a relationship actually
exists has also been moved from `object_relationships` to
`relationships`, and the index built by `relationships` has been
reordered to group by type first and then name, since that is more
useful, especially in the `object_relationships` step.
V3_GIT_ORIGIN_REV_ID: e5d18343f5ce24532a3258e88751bc3183692c50
### What
To do this iteratively, we want to be able to make e.g. models throw
contextualised errors while other stages don't. To do this, we want to
update the models code to return its own version of `ErrorWithContext`
with its own logic for propagating paths. To avoid the mess, I've made
this polymorphic.
V3_GIT_ORIGIN_REV_ID: 8ff2082e3ac8eea908727cffac93fd9cf58ddcce
<!-- The PR description should answer 2 important questions: -->
### What
Another incremental step towards metadata-resolve paths. This PR wraps
the current error type with `ErrorWithContext`, a type that can
optionally contain a path. The PR should be a functional no-op as we
still ignore these paths when displaying the error; the next PR will
surface them in the error responses.
### How
We wrap the type and then do a _lot_ of hand-holding to get Rust
inference to work.
V3_GIT_ORIGIN_REV_ID: c1384cb1e8700c9b7e3aa643b7d0fbd4c8471098
<!-- The PR description should answer 2 important questions: -->
### What
This PR adds the pre-response plugins to the engine and engine
multitenant. We have also added a new flag/env var to get the
pre-response plugin artifacts:
- `PRE_RESPONSE_PLUGIN_CONFIG_ARTIFACT_URL_TEMPLATE`
A sample metadata for pre-response plugin is:
```json
{
"kind": "LifecyclePluginHook",
"version": "v1",
"definition": {
"name": "logging",
"url": {
"value": "http://localhost:5001/log"
},
"pre": "response",
"config": {
"request": {
"headers": {
"additional": {
"hasura-m-auth": {
"value": "your-strong-m-auth-key"
}
}
},
"session": {},
"rawRequest": {
"query": {},
"variables": {}
},
"rawResponse": {}
}
}
}
}
```
Please note that the execution of pre-response plugins happens on a new
tokio thread
([tokio::spawn](https://docs.rs/tokio/latest/tokio/task/fn.spawn.html))
which will run in the background. We will NOT wait for any of the task
to complete before sending the response to the user.
An example of the trace with 5 pre-response plugin calls:
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
We have added this in the plugin middleware.
V3_GIT_ORIGIN_REV_ID: 270d77c45d5e8cc85a5f281f59f981f210eb4547
Linear:
https://linear.app/hasura/issue/APIPG-395/query-usage-analytics-report-relationship-fields
### What
This PR adds mappings to the relationship usage analytics. The goal is
to improve the tracking of relationships between models in the system by
mapping relationship fields (source to target fields) and relationship
arguments, ensuring that analytics around these mappings can be
accurately captured.
No changelog entry is required as the change is not user-facing.
### How
The implementation introduces the following changes:
- Added `get_relationship_model_mappings` and
`get_relationship_command_mappings` functions to extract mappings of
relationship fields and arguments.
- Updated the `RelationshipUsage` structure to include the new
`mappings` field for both model and command mappings.
These changes affect various components handling relationships within
the analytics system, as seen in files such as
`query_usage_analytics.rs`, where mappings are now tracked across
different relationship types.
### Example analytics:
For the following query:
```graphql
query MyQuery {
ArticleMany {
# relationship to command
AuthorFromCommand {
id
}
# relationship to a model
Author {
id
}
}
}
```
The query usage analytics looks something like:
- For relationship to model:
```yaml
used:
- relationship:
name: article
source:
subgraph: default
name: commandArticle
target:
model:
model_name:
subgraph: default
name: Articles
opendd_type:
subgraph: default
name: article
relationship_type: Object
mapping:
- source_field: article_id
target_field: article_id
deprecated: false
deprecated_reason:
```
- For relationship to command:
```yaml
used:
- relationship:
name: AuthorFromCommand
source:
subgraph: default
name: article
target:
command:
command_name:
subgraph: default
name: get_author_by_id
opendd_type:
subgraph: default
name: commandAuthor
mapping:
- source_field: author_id
target_argument: author_id
deprecated: false
deprecated_reason:
```
V3_GIT_ORIGIN_REV_ID: e26d30af7a2b77156d1120bd1a51f8d44b9dc443
### What
In order to talk about artifacts in MBS, we pull in the entirety of
engine-multitenant, which pulls in the entirety of engine, which is
quite a big dependency tree. This PR factors that code out into a
separate package, `build-artifacts`, to lighten the MBS dependency
burden.
---------
Co-authored-by: Daniel Harvey <danieljamesharvey@gmail.com>
V3_GIT_ORIGIN_REV_ID: ad60badb5b793a80cf60cf4b040501eb6abc6bb2
### What
Previously, MBS would not complain if two commands had the same root
field name, and would instead just keep whichever was resolved last.
This has now been fixed.
### How
We do precisely what we do with all the other steps: check a running
list of graphql names that have already been used. We've added a test
that does indeed fail on `main`, which now works.
V3_GIT_ORIGIN_REV_ID: fdf8f73acc62abf315125636c0010b01f6cdb96b
<!-- The PR description should answer 2 important questions: -->
### What
The references are making multiple frontends difficult to implement,
let's wrap them with `Arc` instead and have an easier time.
### How
Change the types, follow the errors. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 8baea2bd6c0e56e8bfb1f899b8d15731eebfa976
<!-- The PR description should answer 2 important questions: -->
### What
We would like to show error paths for `metadata-resolve` so that
debugging these errors is a little less painful, both for us and end
users. To this end, #1147 introduced a type wrapper that would be
deserialised to contain its own JSON path, so we could then pass this
path to errors. This PR does precisely this for the
`UnknownModelDataConnector` error.
I chose this error because... it was the first one on the list, not for
any reason beyond that. Right now, this is an extremely simple case
whereby only one path is required, however other errors may need two
("name at path X conflicts with name at path Y", for example). This PR
also changes the default engine error stdout to show the `Debug`
instance rather than the `Display` instance, as the error path is
discarded by the `Display` instance. Unfortunately, we use `Display` for
both stdout and user responses, which is maybe something we'd want to
change eventually, but for now this means we can't just add the error
path to the `Display` instance.
### How
I started by making `Model` a `Spanned` element within the metadata
structure. I then added the `path` key to the resolved `Model` type. I
then found the first error type that included a model name, and added
the `path` key to that error variant. Then, I just did the wiring.
You'll note that this error doesn't _alway_ return a path because it
isn't always raised by a model-first code path, but this is probably the
first PR of many.
### Next steps
* Next step is to make the output a little neater, probably by creating
an actual structured error type (most likely a lot like `Spanned`, with
a `path` and a `value`). Then, we can use a `Display` instance again to
print this nicely in the stdout, but ignore the path in the MBS API
response.
* After that, the plan is to stop ignoring it in the MBS API response,
with a new key to hold an error path.
* Step three is to allow for errors to produce multiple error paths in a
list, hopefully such that they tell a story ("I found this... but then I
found this... and those two things conflict")
* Step four will be a wave of PRs that look quite similar to this one,
wiring up paths to as many errors as possible.
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: 2d8dda018055f65711e66b08aa15188b516e2ddc
<!-- The PR description should answer 2 important questions: -->
### What
This PR adds the `Spanned` type: an OpenDD wrapper that can be placed
inside the Metadata. It's basically a pair of the value and the path to
the value in the original metadata. This allows us to do things like
source maps.
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
### How
It's almost exactly what @danieljharvey proposed originally.
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
---------
Co-authored-by: Daniel Harvey <danieljamesharvey@gmail.com>
V3_GIT_ORIGIN_REV_ID: 4f037686b6981fffc4b0a8ac8f95c2f9c623af67
<!-- The PR description should answer 2 important questions: -->
### What
We need less lifetimes in our plan, particular those that are connected
to graphql-specific IR. This makes this reference a copy and fixes call
sites. Functional no-op.
V3_GIT_ORIGIN_REV_ID: beb05a09a30cd33240e916255265c41db17c0c78
### What
We want to be able to reference the path within parsers even if the
parser succeeds. This allows us to do things like generate source spans
to help users make updates.
### How
We add `path` as a currently ignored argument to `deserialize`, and then
every time we want to decorate the error path, we replace that call with
a bidirectional decorator.
V3_GIT_ORIGIN_REV_ID: 18ddede2db84801f995b64f17bfb29893acb4657
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
- Extend the `default` attribute in `opendd` to accept a custom default
value. It is used for polling interval field to specify `1000` as
default (in ms).
- Introduce `polling_interval_ms` (defaults to `1000`) field in
`SubscriptionGraphQlDefinition` OpenDD type.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
- Update the opendd-derive macro to enhance the `#[opendd(derive)]`
attribute.
- Plumb the `polling_interval_ms` value till subscription plan type.
V3_GIT_ORIGIN_REV_ID: 2300c781cf2777e5089820bf7d3448b2942c59d0
