## Description
This PR continues on from #725 and adds the metadata resolve logic to
validate the usage of aggregates applied to relationships. The metadata
resolve logic is gated behind a new `enable_aggregate_relationships`
flag and disabled by default.
The new resolve logic lives in
`crates/metadata-resolve/src/stages/relationships/mod.rs`, however, most
of the actual logic that validates the usage of the aggregate expression
with the relationship has been reused from the model aggregate resolve
code. Subsequently, that code
(`crates/metadata-resolve/src/stages/models/aggregation.rs`) was
refactored to return a distinct error type
`ModelAggregateExpressionError` that can be composed with the
`RelationshipError` type, so the same errors can be returned with the
additional context of the relationship they were found in.
New metadata resolve error tests have been added in
`crates/metadata-resolve/tests/failing/aggregate_expression_in_relationship/*`.
Also, two new passing metadata resolve tests have been added to cover
the happy case of root field and relationship aggregate expressions:
`crates/metadata-resolve/tests/passing/aggregate_expressions/*`
JIRA: [V3ENGINE-160](https://hasurahq.atlassian.net/browse/V3ENGINE-160)
[V3ENGINE-160]:
https://hasurahq.atlassian.net/browse/V3ENGINE-160?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
V3_GIT_ORIGIN_REV_ID: 8cd7040cc9277940641d5ac239d7b34f8c1462c5
This keeps versions in one place so we can more easily ensure we upgrade
crates together.
V3_GIT_ORIGIN_REV_ID: 6a929bb6196c19a1f66a768585b669127035e9be
<!-- Thank you for submitting this PR! :) -->
## Description
We cannot validate `BooleanExpressionType`s much until they are used.
This adds checks for when they are used as model `where` clauses. We
ensure the data connector in question is allowed to use nested filtering
(if we try and do any), and ensure that every scalar field has mappings
for the appropriate data connector.
Hidden behind a feature flag, so technically a no-op.
V3_GIT_ORIGIN_REV_ID: ab54f913157954e8197798febafc70012bfad9ad
### TODO
- [x] Validate the presence of arguments in the data connector schema
- [x] Add test for IR
- [x] Add test using custom connector
## Description
JIRA: https://hasurahq.atlassian.net/browse/V3ENGINE-148
This is part 2 of the field arguments.
This will add the field arguments to the graphql schema and also handles
the execution part.
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes
in this PR have any user-facing impact. See
[changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [x] community-edition
- [x] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [x] enhancement
- [ ] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
Add support for field arguments
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
---------
Co-authored-by: Anon Ray <ecthiender@users.noreply.github.com>
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: ea06b896feaca30419f81cd070fd4cfd608ef35b
<!-- Thank you for submitting this PR! :) -->
## Description
Doing some work on the `models` section and it's a bit big and
confusing, so doing a tidy-up to get my head around it all. Splits the
large module into separate files (`ordering`, `source`, `graphql`,
`filter` etc).
Only actual changes are:
- Move filter resolving to after model source is checked, so we can
refer to it. This will be useful for the thing I actually want to do.
- Make steps like `graphql` and `source` return the values they create
rather than mutating `Model` directly.
- Move some filter checks into `filter` rather than `source`, now we are
able to. This logic was all over the place.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 540db16d34590ed9e481c36d251ab5e1886f2c81
<!-- Thank you for submitting this PR! :) -->
## Description
Because we globbed for folders, we had to put a test in the root of each
folder which is messy. If we glob for files instead, like the `failing`
tests do, we can have a better time. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 381f5a44d9ae6100198bd28a286493bc3a2ba98e
Return a `T` instead of a `Result<T, E>` when we never return an error
(`E`) case.
I also enabled some more warnings. `unnecessary_box_returns` has been
suppressed where appropriate, and `unused_async` doesn't seem to be
violated anywhere any more.
I got rid of some calls to `.unwrap()` too.
V3_GIT_ORIGIN_REV_ID: 015ebd05978cf8c2d87474a90e0cd4333779a761
<!-- Thank you for submitting this PR! :) -->
## Description
This implements local relationships in the new `BooleanExpressionType`.
We copy all the existing tests for this and reimplement them using the
new types.
Things currently missing:
- a `BooleanExpressionType` can be specified to overwrite the target
model's `where` clause when defining. Currently we ignore this, there is
a follow up ticket for this:
https://hasurahq.atlassian.net/browse/V3ENGINE-209
This work is behind a feature flag, so this is a no-op for the user.
V3_GIT_ORIGIN_REV_ID: 6ae87e1ffb2ad0ebd27c6097e8ea87aca1a4c299
## Description
This PR moves all the tests that were added to
`crates/engine/tests/validate_metadata_artifacts/aggregate_expressions`
to the metadata-resolve `metadata_golden_tests`.
All the `error.txt` files got renamed to `expected_error.txt` and the
`metadata is not consistent:` bit on the front of the error got trimmed
off.
I had to change the way that `test_failing_metadata` works so that
instead of looking for directories under `failing/` it looks for
`metadata.json` files under `failing/`. This is because not every
directory has a test in it, some directories are just used for grouping
(eg `failing/aggregate_expressions/`). This doesn't change what tests
get run. The only side effect is that every test name has `_metadata`
suffixed to it (the filename). 😢 `test-each` doesn't appear to offer a
way to disable this behaviour.
V3_GIT_ORIGIN_REV_ID: dece7cd3bb4623c51050d12471d2c0990fd69bfd
This is Part 2 in a stacked PR set that delivers aggregate root field
support.
* Part 1: OpenDD: https://github.com/hasura/v3-engine/pull/683
* Part 3: GraphQL API: https://github.com/hasura/v3-engine/pull/685
JIRA: [V3ENGINE-159](https://hasurahq.atlassian.net/browse/V3ENGINE-159)
## Description
This PR implements the metadata resolve phase of the engine and adds
support for resolving `AggregateExpression`s and validates their use
when linked to a `Model`.
The bulk of the changes can be found in:
* `crates/metadata-resolve/src/stages/aggregates/*` - This is where the
`AggregateExpression`s are resolved
* `crates/metadata-resolve/src/stages/models/mod.rs` - This is where we
validate the `AggregateExpression` specified for use in the model is
actually compatible with the model and its data connector
The `ndc-spec` version used has been lifted to the latest version that
adds support for aggregates over nested objects
(https://github.com/hasura/ndc-spec/pull/144). This necessitated changes
in the Custom Connector, but actual functionality to implement
aggregation over nested objects is implemented in Part 3.
There are also some changes in
`crates/metadata-resolve/src/types/subgraph.rs` where the `Display`
trait for the various `Qualified<T>`, `QualifiedTypeReference`, etc
types has been reworked so that they print more cleanly, with the
subgraph being put outside the type syntax, and array types getting
formatted correctly. For example, previous an array of Varchars would
have printed as `Varchar (in subgraph default)!`, now it properly
formats as `[Varchar!]! (in subgraph default)`.
This was necessary to make useful error messages using these types.
A tonne of tests have been added in
`crates/engine/tests/validate_metadata_artifacts/aggregate_expressions`
to test every error condition of the metadata resolve process.
[V3ENGINE-159]:
https://hasurahq.atlassian.net/browse/V3ENGINE-159?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
V3_GIT_ORIGIN_REV_ID: ffd859127a3f1560707f06ef01906c9d1b183d31
<!-- Thank you for submitting this PR! :) -->
## Description
<!--
Questions to consider answering:
1. What user-facing changes are being made?
2. What are issues related to this PR? (Consider adding `(close
#<issue-no>)` to the PR title)
3. What is the conceptual design behind this PR?
4. How can this PR be tested/verified?
5. Does the PR have limitations?
6. Does the PR introduce breaking changes?
-->
This PR reverts the changes to `FieldMapping` and introduces the
`argument_mapping` in `ColumnMapping` instead.
V3_GIT_ORIGIN_REV_ID: badca2416b1a1b82d1a596aa60bf7a39b3b6152a
<!-- Thank you for submitting this PR! :) -->
## Description
<!--
Questions to consider answering:
1. What user-facing changes are being made?
2. What are issues related to this PR? (Consider adding `(close
#<issue-no>)` to the PR title)
3. What is the conceptual design behind this PR?
4. How can this PR be tested/verified?
5. Does the PR have limitations?
6. Does the PR introduce breaking changes?
-->
JIRA: https://hasurahq.atlassian.net/browse/V3ENGINE-148
This is part 1 of supporting field arguments in the engine.
Part 2 is here: https://github.com/hasura/v3-engine/pull/695
It adds the OpenDD types according to the RFC and resolves them.
V3_GIT_ORIGIN_REV_ID: f7736c968489e35c9133f2c6e276d05baf84d4be
If a function doesn't return a value, terminate with a semicolon.
I also moved `implicit_hasher` and `return_self_not_must_use` to the
"definitely keep disabling this" list, and installed
[Bacon](https://dystroy.org/bacon/) in the Nix shell to make it easier
to run Clippy.
V3_GIT_ORIGIN_REV_ID: ffb17b42d982518aec433a1676dba0a0dd0ad95d
<!-- Thank you for submitting this PR! :) -->
## Description
We have a set of tests in `metadata-resolve` that uses globs to find
files in either `passing` or `failing` folders and check them. This
allows those files to live in nested folders for tidyness. Functional
no-op.
V3_GIT_ORIGIN_REV_ID: 22d42e986676a110f455c59c3df9e6946c5d996c
<!-- Thank you for submitting this PR! :) -->
## Description
This adds the ability to describe nested object boolean expressions,
which become `fieldPath` items in the generated
`ndc_models::ComparisonTarget::Column` items. This allows us to describe
filtering a `User` based on some element in their nested `address` field
(like `postcode`, for example).
Like the other `BooleanExpressionType` work, this remains behind a
feature flag so should make no user-facing changes.
It is also missing a whole heap of metadata resolve checks, going to
follow with these after doing the happy path to unblock other work.
V3_GIT_ORIGIN_REV_ID: c89e2942a651d349fca97706affcf40d91afeefb
## Description
This PR implements argument presets for `DataConnectorLink`, which can
be used to forward request headers as function/procedure arguments to
NDC. This PR implements the execution part.
**Note**: response header forwarding is not implemented yet.
V3_GIT_ORIGIN_REV_ID: ff69129aee3e3052367ca42acdec3922cbc2cb0c
## Description
This PR implements argument presets and response headers for
`DataConnectorLink`, which can be used to forward request headers as
function/procedure arguments to NDC, and also forward response headers
from NDC back to the client. This PR implements only the OpenDD changes
and metadata resolving part.
V3_GIT_ORIGIN_REV_ID: 2b7f20af7c2f192c0103553bccb000114dcba916
Previously we required an operator called `_eq` to be called `_eq` in
all data connectors that used it.
Now we can give them nice names, and map each one to a different
operator name per data connector.
V3_GIT_ORIGIN_REV_ID: 1d2f678e25d932e5ea45d34999cf5709ef0038b4
## Description
JIRA: https://hasurahq.atlassian.net/browse/V3ENGINE-180
Fix an edge case where the function
`build_annotations_from_input_object_type_permissions` produce infinite
recursions
when an input object type contains fields with self-referential types.
Note: This PR doesn't contain any tests. They'll be added in a separate
PR ([JIRA](https://hasurahq.atlassian.net/browse/V3ENGINE-188)). This
fix needs to be done quickly and merged as other teams (graphql
connector) are blocked by this.
V3_GIT_ORIGIN_REV_ID: 4cc09cb96871804d4daf83d7e49a6f4529c1943d
<!-- Thank you for submitting this PR! :) -->
## Description
This makes the absolute happiest path `BooleanExpressionType` work.
Caveats:
- We ignore operator mappings, so we assume that the OpenDD operator
name (ie, `_eq`) is the same as the data connector's name for it.
- We have not tried to implement `comparisonRelationships` in any way
yet.
- Have not tried nested objects yet.
All functionality here is behind a feature flag so has no user-facing
impact.
V3_GIT_ORIGIN_REV_ID: 5edb706c6d8b03b9fa59433ce24f05f37a69729a
## Description
There is a bug in NDC validation of command where it returns early
without validating. This is because we perform the NDC validation right
after resolving the command source, but haven't attached the "resolved
command source" to the command yet. As a result the command's source is
`None`, and the validation does an early return.
This PR fixes it by taking the command source directly. If there is no
source to resolve, we don't have to perform any NDC validation of the
command.
Note: this is not the case with models. Model's source resolving
attaches the "resolved source", then performs the validation.
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes
in this PR have any user-facing impact. See
[changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [x] community-edition
- [x] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [ ] enhancement
- [x] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
Fix skipping of NDC validation of commands due to wrong assumption.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 5b9f4c922ee83394f1b6fe840cd934b6e138e2e9
<!-- Thank you for submitting this PR! :) -->
## Description
We were using `String` for these, and making some assumptions about NDCs
and OpenDD operator names being the same. This uses newtypes and
documents where these assumptions are being made. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 195e55db6fadf48c956684130e23f647eaa17fb1
Calling `.to_owned()` on a reference, `.to_vec()` on a vector reference,
etc. are just synonyms for `.clone()` which are less explicit about
cloning. Let's be explicit.
This also removes some unnecessary clones.
V3_GIT_ORIGIN_REV_ID: 1bc00c4106f0346303d73e4268c89030c0ce93fc
## Description
Tiny PR to add some comments and clarifications to the data connector
resolve types.
Also, rearranges the types and functions to make the flow clearer.
V3_GIT_ORIGIN_REV_ID: db5b18cbd7c79670c9dfc68c80950ccf5105f9ce
1. Use `map_or(…, …)` instead of `.map(…).unwrap_or(…)`.
2. Use `.is_some_and(…)` instead of `.map(…).unwrap_or_default(…)`.
3. Nest `|` patterns where possible.
4. Be more specific about match patterns.
I found I could also simplify `typecheck_qualified_type_reference`
considerably.
V3_GIT_ORIGIN_REV_ID: 6a3b1a4c525c0187c2fdb6df0c979ca0b7b3016c
<!-- Thank you for submitting this PR! :) -->
## Description
We pass around `scalar_type_name` but never need it, removing it makes
boolean expressions easier to implement, so split into a fresh PR.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 0e4df8da4cb15d90a7f7be068b40c47936b70734
1. Always name the struct when calling `default()`.
2. Sort construction according to the definitions.
3. Approve allowing `struct_field_names` because it doesn't seem to be
helpful.
4. Enable `manual_string_new`; nothing seems to be triggering it now.
V3_GIT_ORIGIN_REV_ID: 868742114b0bf27bc3ea03cdf1e63a0f710ebe33
<!-- Thank you for submitting this PR! :) -->
## Description
Broke this out of new bool exps work, breaks this big function into
smaller functions with clearer dependencies. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 4f85132f9c381977b1cd406bb71e278c45866691
<!-- Thank you for submitting this PR! :) -->
## Description
This somewhat resolves the `BooleanExpressionType` metadata type.
There is a lot that is missing, but everything is behind a feature so I
want to merge what is here before moving onto getting it working with
the later parts of the pipeline. We'll start with a lot of duplication
and then work to remove as much as we can.
Functional no-op for users, the feature flag is not exposed to the
actual binary.
How to review this PR:
- Check that any changes to existing code are cosmetic and naming-only
to ensure this is a no-op
- Look through the new resolve step and compare it to the
[RFC](https://github.com/hasura/v3-engine/blob/main/rfcs/open-dd-expression-type-changes.md)
and see if it is doing roughly what you might expect.
- Don't get too bogged down in missing things / style stuff, there are
definitely missing things and bad style.
V3_GIT_ORIGIN_REV_ID: 24e3b3e72e62d0094db3b461cb8c6d359982755d
<!-- Thank you for submitting this PR! :) -->
## Description
The field mappings for an object type are the mappings between the
OpenDD field name (`FieldName`) and whatever the NDC column name
(`DataConnectorColumnName`) are.
Type mappings is a map from OpenDD type names
(`Qualified<CustomTypeName>`) to the field mappings for that type.
Previously, Boolean Expressions were attached to a single data connector
and object type. Now we are generalising them so that they can be used
across any of the multiple data connectors that their attached
ObjectType might have type mappings for.
To do this, we stop including them in the resolved
`ObjectBooleanExpressionType`, and instead fetch the relevant type
mappings from whichever thing is using the boolean expression type,
usually the `ModelSource` for a `Model`.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 4a251473b4aecedf4ede0e79aa7b577e25207cb8
Just because it's fewer lines of code.
1. Invert `if`/`else` blocks with negative conditions.
2. Unwrap redundant `else` blocks.
3. Simplify a few branches to `let … else`.
4. Replace a `match` with `if let`.
V3_GIT_ORIGIN_REV_ID: 4f10730b688d21c1fc86a45ee5fb4adf008b3d94
## Description
This avoids a query to `/capabilities` when explaining.
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes
in this PR have any user-facing impact. See
[changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [x] community-edition
- [x] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [ ] enhancement
- [ ] bugfix
- [x] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
The engine no longer makes a request to NDC capabilities when explaining
a query or mutation, instead using the stored capabilities from the
build.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: f38867e0f5a832c45a857c5e58d7a44c1c05d71f
<!-- Thank you for submitting this PR! :) -->
## Description
Once again I found myself getting confused as to what a `String` meant
so I wrapped it up in a newtype and then found a bug and fixed it as a
result.
(nearly) functional no-op.
<!--
Questions to consider answering:
1. What user-facing changes are being made?
2. What are issues related to this PR? (Consider adding `(close
#<issue-no>)` to the PR title)
3. What is the conceptual design behind this PR?
4. How can this PR be tested/verified?
5. Does the PR have limitations?
6. Does the PR introduce breaking changes?
-->
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes
in this PR have any user-facing impact. See
[changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [X] community-edition
- [X] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [ ] enhancement
- [X] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
Use field mappings more consistently when following remote joins.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: dd4fff5c4c8f5d1e50742c046b62cb7ddec3f467
<!-- Thank you for submitting this PR! :) -->
## Description
This doesn't do anything. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 4a9e35bae95ef3bf9c11de6d15f93031d0976311
## Description
We use few HTTP types (URL, http header name, value, header map etc.) in
the resolved metadata, which needs to be serialized. We have newtype
wrappers around them to implement serialization/deserialization.
This PR moves them to a separate helper module.
And also introduces a new type `SerializableHeaderName` which is
required in an upcoming PR of forwarding request headers to NDC.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 4f907a652a9826bc52996fa37d2a7590f24ee30a
Fix some warnings flagged by Clippy.
1. Elide `.into_iter()` where it's unnecessary.
2. Favor `&` over `.iter()`.
3. Use `.values()` on maps instead of discarding keys by destructuring.
4. Avoid `::from_iter(…)` in favor of `.collect()`.
I also replaced a call to `.cloned()` with `.copied()`.
V3_GIT_ORIGIN_REV_ID: 7d39665b0cd04f5bae9405c0ff5f044f57433f32
Got confused by more `String` types, turns out we already had more
accurate types for these things. Functional no-op.
V3_GIT_ORIGIN_REV_ID: a9c73024ab23233a73934bb2cd3741b3b4d7a378
<!-- Thank you for submitting this PR! :) -->
## Description
In https://github.com/hasura/v3-engine/pull/599 we added new
`BooleanExpressionType` to OpenDD. It included a number of helpful
newtypes such as `DataConnectorScalarType` that replace uses of raw
string and make intent inside engine code easier to follow. This change
uses that newtype everywhere in `metadata-resolve`.
<!--
Questions to consider answering:
1. What user-facing changes are being made?
2. What are issues related to this PR? (Consider adding `(close
#<issue-no>)` to the PR title)
3. What is the conceptual design behind this PR?
4. How can this PR be tested/verified?
5. Does the PR have limitations?
6. Does the PR introduce breaking changes?
-->
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes
in this PR have any user-facing impact. See
[changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [X] community-edition
- [X] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [X] enhancement
- [ ] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
Use `DataConnectorScalarType` string newtype internallly and in OpenDD
types.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: b44709f39b30f25908106110f62c72e3d13b4eb6
`test_each::path` always gives us a `PathBuf` even if we don't want one,
so we need to suppress the associated warning.
V3_GIT_ORIGIN_REV_ID: 4f2bb29122df6979ad378227fb88e4632d3551f7
## Description
If the user specified their orderings in their GraphqlConfig in a
different order, they would be presented with an error.
```yaml
enumTypeNames:
- directions: # Reversed ordering of this list
- Desc
- Asc
typeName: OrderBy
```
> ERR Code=opendds-validation Message="invalid metadata: error building
schema: unable to build schema: metadata is not consistent: invalid
directions: Desc,Asc defined in orderByInput of GraphqlConfig ,
currenlty there is no support for partial directions. Please specify a
type which has both 'asc' and 'desc' directions"
7:56PM ERR Supergraph Build failed.
This has been fixed.
## Changelog
### Product
_(Select all products this will be available in)_
- [x] community-edition
- [x] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [ ] enhancement
- [x] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
Fixed arbitrary ordering of directions in GraphqlConfig causing invalid
error
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: b27a0dd3b5c665f54ea58a40af8b2b1bfb0d2434
## Description
With #613 merged, it is safe to create an `__globals` subgraph into
which we can sort all supergraph config. This PR gives supergraph
objects a qualified name (using the `__globals` subgraph). Note that
outside of debugging/tracing, this is functionally a no-op: we strip the
subgraph from the objects as soon as we use them, because the global
nature of the config means that this is irrelevant information.
<!--
Questions to consider answering:
1. What user-facing changes are being made?
2. What are issues related to this PR? (Consider adding `(close
#<issue-no>)` to the PR title)
3. What is the conceptual design behind this PR?
4. How can this PR be tested/verified?
5. Does the PR have limitations?
6. Does the PR introduce breaking changes?
-->
## Changelog
### Product
_(Select all products this will be available in)_
- [x] community-edition
- [x] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [ ] enhancement
- [ ] bugfix
- [x] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
Metadata config declared under the `supergraph` field will now appear as
part of an `__globals` subgraph in tracing. Note that the field can also
be omitted and the config placed in a user-named subgraph.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 84d2beed98f843df246c8562188cdf7de63643fc
