<!-- Thank you for submitting this PR! :) -->
## Description
We'd like not to tie our boolean expressions to one particular data
connector, we were doing this in relationships and had no need to.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 0af16ad92117a45ac1f424b49d9f13184787f63f
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
<!-- 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
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
This PR refactors the schema crate to enable overriding the
interpretation of roles at runtime.
By providing a `NamespacedGetter` that ignores roles entirely (i.e.
`GDSNamespacedGetterAgnostic`) to schema generation functions it is
possible to derive a GraphQL schema that ignores permissions and
presets.
This PR leaves back a few opportunities to improve code clarity, which I
hope to address in follow-up PRs.
For instance, it seems superfluous to make sense for generic code
parametrised `<S: SchemaContext>` to carry around both a `S::Namespace`
and a `S::NamespaceGetter`, when all that code could ever do with that
`S::Namespace` value anyway is apply it to the `S::NamespaceGetter`.
Taking this line of reasoning to its conclusion suggests that we can
reduce the complexity of `trait SchemaContext` and its associated types
and kit.
---------
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: c84555fd88279582670919faa5a62bbd00b714bd
<!-- 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
<!-- Thank you for submitting this PR! :) -->
## Description
We'd like to be able to test new WIP experimental features. This adds a
`UNSTABLE_FEATURES` env var / command line arg that can be passed a
comma separated list of names.
Currently we accept `UNSTABLE_FEATURES=enable-boolean-expression-types`
but in future users could pass
`UNSTABLE_FEATURES=some-fancy-feature,other-feature,great`.
<!--
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
-->
Add `UNSTABLE_FEATURES` environment variable
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 3562c1341d4ea3a512626110dbd2b055425c1d60
Add the ability to render field input-arguments and default values in
sdl.
Also add a small CLI tool to help inspect the GraphQL schemas that
result from a piece of engine metadata.
V3_GIT_ORIGIN_REV_ID: ddb7315f12d24eafbf57782f37f840ca44d94789
<!-- 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
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
The new `BooleanExpressionType` for objects is not tied to a single data
connector. As we'll be attempting to compile both input kinds into the
same resolved metadata types, let's make sure we depend on this
information as little as possible.
Mostly this is absolutely fine, the only time we now use this
information (other than still checking it for user errors) is when
juggling relationships when generating GraphQL schema items for a
boolean expression. We will have to cross this bridge when we come to
it.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 9550217e253fb71df09251928ab9b30750617c9e
<!-- Thank you for submitting this PR! :) -->
## Description
This adds the smallest possible changes to allow the use of different
options when resolving metadata. The concrete idea is this:
- each crate (`metadata-resolve`, `schema` etc) will have a type for
their flags (if any), but don't care where they come from
- when we need to expose these experimental features through the engine
(ie, to test requests in e2e tests or something), the engine will parse
an env var such as
`EXPERIMENTAL_FEATURES=allow_boolean_expression_types` and then use it
to construct `MetadataResolveFlags`, `SchemaFlags`, etc.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 64ac66569f4e31829a9117c64d2e0e265d7a7303
Bumps [serde](https://github.com/serde-rs/serde) from 1.0.201 to
1.0.202.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/serde-rs/serde/releases">serde's
releases</a>.</em></p>
<blockquote>
<h2>v1.0.202</h2>
<ul>
<li>Provide public access to RenameAllRules in serde_derive_internals
(<a
href="https://redirect.github.com/serde-rs/serde/issues/2743">#2743</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="9e32a40b1c"><code>9e32a40</code></a>
Release 1.0.202</li>
<li><a
href="87f635e54d"><code>87f635e</code></a>
Release serde_derive_internals 0.29.1</li>
<li><a
href="d4b2dfbde2"><code>d4b2dfb</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/serde/issues/2743">#2743</a>
from dtolnay/renameallrules</li>
<li><a
href="f6ab0bc56f"><code>f6ab0bc</code></a>
Provide public access to RenameAllRules in serde_derive_internals</li>
<li><a
href="48cc2a6327"><code>48cc2a6</code></a>
Replace use of a syn From impl</li>
<li><a
href="3202a6858a"><code>3202a68</code></a>
Skip rerunning build script on library code changes</li>
<li>See full diff in <a
href="https://github.com/serde-rs/serde/compare/v1.0.201...v1.0.202">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: Anon Ray <ecthiender@users.noreply.github.com>
V3_GIT_ORIGIN_REV_ID: f6b8f6681b607a89712676456bd688a4b3cb89c3
## Description
As advertised.
Now you can run the following to browse our internal code
```
cargo doc --no-deps --document-private-items --open
```
V3_GIT_ORIGIN_REV_ID: 5b7091a00ed6148b8a91168807b07aa6a925cac9
<!-- Thank you for submitting this PR! :) -->
## Description
We're adding some tests that compare the output of metadata resolve.
Unfortunately, the results are nondeterministic because we use `HashMap`
/ `HashSet` in a lot of places. This replaces those uses with `BTreeMap`
and `BTreeSet` in `metadata-resolve`, and in a few places in `schema`
that rely on those types.
Some light reading around suggests that as well as giving us consistent
ordering, `BTree-` versions are better in terms of memory usage, esp
with < 1000 items (which I'm pretty sure most metadata items are)
https://www.reddit.com/r/rust/comments/xbkuc7/btreemap_vs_hashmap/https://users.rust-lang.org/t/hashmap-vs-btreemap/13804/2https://iq.opengenus.org/hashmap-and-btreemap-rust/
Functional no-op.
V3_GIT_ORIGIN_REV_ID: dbf49aefef0cd7084a3a37ef4fe9fc61257e1305
<!-- Thank you for submitting this PR! :) -->
## Description
There is about to be a separate thing called `boolean_expression_type`,
so let's have a nice time and make the two things explicitly different.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 0035e39a2ca8657a6ded5d5f0a4f284c3e72126d
<!-- Thank you for submitting this PR! :) -->
## Description
This PR splits the GraphQL schema generation into the `schema` crate.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 4f1a91387305d88e9b5fbe4bc8df0575292cf878
