<!-- 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
Found some of the remote join argument collection a little tricky to
follow, so changed it to be a little more explicit. It is still broken
for nested remote joins inside local ones, but at least is more explicit
about it's behaviour regarding returning joins.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 77d4717ee9d5effc1c08bcf5f4fbcf0af9f5d777
## Description
This PR adds the CORS layer last, as it otherwise does not affect the
/metadata endpoint.
V3_GIT_ORIGIN_REV_ID: 77792d6bc35fe7e1df4191c834026f5c8a335bb3
<!-- Thank you for submitting this PR! :) -->
## Description
JIRA: https://hasurahq.atlassian.net/browse/V3ENGINE-135
Introduce an option to enable CORS in engine's single tenant server.
- `--enable-cors` CLI flag or `ENABLE_CORS=true` env var to support
preflight CORS request and include relevant headers in responses.
- `--cors-allow-origin` CLI option or `CORS_ALLOW_ORIGIN=` env var that
accepts comma-separated list of allowed origin domains.
<!--
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)_
- [ ] community-edition
- [ ] 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
- [ ] 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
-->
_Replace with changelog entry_
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
---------
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: d562cde28898416cfbfd00ffd97e7b668ff3c953
The internals of `schemars` has recently changed, removing
`schemars::_private::apply_metadata`. We should not be using this
function. I have rewritten the code to modify the metadata through the
public API instead.
I have not actually bumped the version of schemars in this change; we
can do that separately.
V3_GIT_ORIGIN_REV_ID: 84a7d39cbd586d8486ae18f47ddc0a51270b8628
<!-- 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
<!-- Thank you for submitting this PR! :) -->
## Description
When trying to reproduce a remote relationships bug, I managed to find
this bug where remote relationships to commands ignore the argument
mappings. A command argument can be called one thing in the NDC itself
(ie, `id`), but we might want to expose it as `actor_id` in the engine
as that's nicer for the user. As we referred to everything with
`String`, we did not convert back to the NDC argument name when sending
information from a remote relationship, this PR fixes that.
We also add a `ConnectorArgumentName` newtype which replaces a bunch of
uses of `String`, and would have guided us towards not creating this bug
in the first place.
<!--
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
-->
Fix to correctly use argument mappings when resolving remote
relationships to commands.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 2219e50d6cb28456e60c6794dc163d9b90573f8e
<!-- Thank you for submitting this PR! :) -->
## Description
We'd like to split the engine into smaller crates where possible, to
enforce boundaries better. The next step is splitting `schema`, but it
uses things in `engine/utils`. This splits those utils into a `json_ext`
package, as they all seem like JSON helpers.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 44d93a7346dc83194abaa46158be2b8401905bd0
<!-- Thank you for submitting this PR! :) -->
## Description
We have a separate copy of the code for resolving type predicates that
we use for object types (when resolving BooleanExpressions), because the
previous code was heavily tied to the Model it used. We'd like to unify
that code again, so the first step is re-implementing relationships in
`resolve_model_predicate_with_type`.
<!--
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
-->
Allow boolean expressions to use relationships
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 6225a4ab752b71df3cdfd0982bf2107ca39f4940
<!-- Thank you for submitting this PR! :) -->
## Description
Much as per https://github.com/hasura/v3-engine/pull/524 for
`CommandWithPermission`, this removes the `Option` from
`ModelWithPermissions`. Again, select permissions are opt-in, so
`Some(HashMap::new())` is the same as `None`, so we can remove this
layer of indirection, which I believe was only there because we were
building up the `Model` type incrementally.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: fcb6479f32b001380ae24db6439e96339a868692
## Description
Introduce a newtype for data connector object type for the added
context.
V3_GIT_ORIGIN_REV_ID: b499d3a9cd2610fec05a4bc2e1b3cf522f198b9c
<!-- Thank you for submitting this PR! :) -->
## Description
This PR enables boolean expressions in command argument presets. This
allows users to provide an expression to do things like "when the `user`
role runs the `deleteUser` command they can only delete users with `id`
== `x-hasura-user-id`".
It's up to the data connector to interpret the expression as it sees
fit.
<!--
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
-->
Allow using boolean expressions in command arguments.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 302f62a266db9c090ba232fe9ab06db4953f38a6
<!-- Thank you for submitting this PR! :) -->
## Description
The getting starting instructions for Docker don't work because they use
the reference agent sample metadata from `open-dds` crate. I managed to
get the metadata building but for some reason I get connection errors
when running the queries (cannot reach the reference agent).
I would like to investigate this further, but in the meantime, this
updates the readme to use the metadata from the tests, which should at
least get them up and running with a working GraphiQL / Jaeger.
V3_GIT_ORIGIN_REV_ID: d0dc81560a068b960104228f89ee7e7d483a58d9
<!-- Thank you for submitting this PR! :) -->
## Description
We'd like to speed up creation of all these Docker images, so this adds
`dev-auth-webhook` to the Nix flake. Functional no-op.
---------
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: 384eb467b2fe7fba1644f5b4cc6224cdc043ce01
There were multiple locations where we were implementing
`derive_more::Display` with a fixed format string, mostly of
`"Display"`. This means that the `to_string` implementations of those
types would just return `"Display"`, which is quite unhelpful.
In all cases but one, I was simply able to remove the implementation.
In the last case, `QualifiedTypeReference` had a broken implementation.
I replaced it with something more meaningful: the type name, followed by
a `"!"` if the type is non-nullable. `derive_more` was unable to help me
here so I implemented it the old-fashioned way. (I think replacing it
with an `enum` could also work.)
V3_GIT_ORIGIN_REV_ID: 35cf573d1efab2bba0707b248ae8b74bd535d0ed
## Description
Checking my understanding by documenting some stuff. Today it is
resolved/graphql_config, which lets us change the names of hasura
features in the syntax of the graphql.
---------
Co-authored-by: Daniel Harvey <danieljamesharvey@gmail.com>
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: a7053e610a1f310dfc9bab2a31e79e7b0e5110c3
<!-- Thank you for submitting this PR! :) -->
## Description
Now that metadata resolve has a clear interface with the rest of the
engine, let's take it out into it's own crate. This will make it easier
to maintain a strong boundary between things.
To simplify imports etc, removed nested layers of modules, so now we
import `use metadata_resolve::Qualified` instead of `use
crate::metadata::resolved::Qualified`.
The changes in `engine` crate are all just updating imports.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: fb94304f7ed8883287c18bd6870045dfd69e3fe3
<!-- Thank you for submitting this PR! :) -->
## Description
We'd like to split metadata resolve into it's own crate to enforce
module boundaries better. In doing so, discovered that it's using a type
from the later schema stage called `PredicateRelationshipAnnotation`,
which isn't really an annotation type at all, just a data structure for
a resolved predicate.
This moves that types back into metadata resolve, renaming it to
`PredicateRelationshipInfo`.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 5b37ca77fb4ddf17093277e6727360d6077c4e06
The massive `Error` enum from `execute.rs` disintegrates into the
following independent error types.
- `RequestError`: All exceptions occurred before executing the root
field plans. Each variant in this error enum contains the error type
stemming from isolated steps in the pipeline involving parsing,
validation, IR conversion, and plan generation.
- `FieldError`: Exception occurred when resolving a field through its
plan. Multiple root fields are executed isolated, and field errors are
collected in a list.
Code paths for `explain` and `execute` query are split into two
functions. This is done to avoid few error variants and unburden the
function that previously does both.
V3_GIT_ORIGIN_REV_ID: 21f2f43ee4805a955fa0ce7d9b45c4b1902def63
<!-- Thank you for submitting this PR! :) -->
## Description
We named this stage after the least interesting thing about it, this
resolves that.
`data_connector_type_mappings` -> `object_types`.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 67c94356cc7207e94eb3b696abbd32efe31551ac
<!-- Thank you for submitting this PR! :) -->
## Description
`data_connector_type_mappings` is a map of data connector information
keyed by `CustomTypeName`. We create it when we resolve object types,
which are also keyed by `CustomTypeName`, however we pass them around
separately and it's not immediately obvious that they are related.
This PR stops passing `data_connector_type_mappings` around and instead
includes them with the object information.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 3ac1341907ea88c11fbc3639adf63140aa702262
## Description
1. I've moved the architecture information we had in `CONTRIBUTING.md`
to a separate document `docs/architecture.md` so we can evolve both
separately in the future.
2. I've introduced a couple of sub directories: `utils` and `auth`, for
supporting crates that are not the core functionality of the engine so
it is easier to find the most relevant crates.
New structure:
```
crates
├── auth
│ ├── dev-auth-webhook
│ ├── hasura-authn-core
│ ├── hasura-authn-jwt
│ └── hasura-authn-webhook
├── custom-connector
├── engine
├── lang-graphql
├── metadata-schema-generator
├── open-dds
└── utils
├── opendds-derive
├── recursion_limit_macro
└── tracing-util
```
V3_GIT_ORIGIN_REV_ID: e0e9394da2fcd911f329c48107a76f8492fa304c
## Description
To clarify the purpose of the `"source"` field, we've decided to rename
it to `"sourceType"`. This hopefully makes it clearer that the value
should be a type name.
`"source"` is still accepted as an alias in order to stop this from
being a breaking change.
I have added the aliasing capability for struct fields in
`opendds_derive`.
All test metadata has been updated to use `"sourceType"`, but I've added
one test case that uses `"source"` instead just to make sure that it
still works.
## 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
-->
- OpenDDS: The `"source"` field for relationships has been renamed to
`"sourceType"`. Metadata using `"source"` will continue to work as
usual, but new metadata should be authored with `"sourceType"` instead.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 305cbf7a62ee49a715e95ad892b8d00647f05cef
I found myself wanting to rewrite JSON files with `sed`. The problem is,
then I want to run a formatter over them afterwards, and this will
change the whole file, not just the area I touched.
I would like to propose the nuclear option in remedying this: format
everything now. This is a very large change that should make it easier
to keep files to a consistent format in the future.
I have chosen to use Prettier for this because (a) it has a useful
`--write` command and (b) it also does GraphQL, Markdown, YAML, etc.
I've elected to exclude two sets of files:
1. `crates/custom-connector/data/*.json`, because they are actually
multiple JSON objects, one per line, which Prettier cannot parse.
2. `crates/lang-graphql/tests/**/*.graphql`, because it contains invalid
GraphQL, and the parser is intended to work with strangely-formatted
GraphQL.
The main changes are standardizing whitespace, adding a newline at the
end of files, and putting JSON arrays on one line when they fit.
V3_GIT_ORIGIN_REV_ID: 92d4a535c34a3cc00721e8ddc6f17c5717e8ff76
By wrapping the errors we can work with both `syn` and `darling` errors,
allowing us to avoid `.unwrap` and `.expect`. This makes failures way
more useful.
V3_GIT_ORIGIN_REV_ID: bd7c4a4e7de4a2360b4533d9238199f098a09a8d
<!-- Thank you for submitting this PR! :) -->
## Description
This stacks on top of https://github.com/hasura/v3-engine/pull/526 and
is the tidying up step following it.
There is a lot going on here, none of it particularly interesting.
- We remove the old `resolve_metadata` function, so all of "the action"
for resolving metadata happens inside `resolved::stages::mod`.
- We move the remaining modules into two folders, `helpers` and `types`.
This is a pretty rough cut, and there are definitely better homes for
the things here, I just wanted the separation of stages and "other bits"
to be clearer.
- We split the `types` helpers into `types` and `type_mappings`, as the
`type_mappings` stuff was clearly defined and didn't belong with the
grab-bag of functions that remain in `types`.
- We explicitly export everything used outside metadata resolve, and
stop other modules dipping into it's internal structure. This will make
future changes (particularly refactors that change the stages etc) a lot
easier as we don't need the rest of the app concerning itself with it.
- I _think_ we may now be able to move metadata resolve into a separate
crate. I have not tried yet, this PR is already silly enough.
When given a choice between "fixing" something, and doing the most
mechanical obvious change, I have opted for the latter. That is to
derisk this big change, and to ensure it doesn't linger, collecting
awful merge conflicts.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 2b52403cbfddb0427b8a3e61ad2edaef9d1b3b46
<!-- Thank you for submitting this PR! :) -->
## Description
Following work in https://github.com/hasura/v3-engine/pull/523 and
friends, this resolves `model_permissions` in a fresh step, creating a
new `ModelWithPermissions` type to differentiate from the regular
`Model` which no longer has any notion of permissions.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: fdf928ae12159a6c4ef87effc4704193c5306e46
<!-- Thank you for submitting this PR! :) -->
## Description
Follow up to https://github.com/hasura/v3-engine/pull/523
This removes the `Option` from the Command permissions. Seperated from
the pure "moving things around" PR for clarity, it should be a
functional no-op though, as Command permissions are opt-in, so `None`
and `Some(HashMap::new())` are equivalent, and this layer can be
removed.
V3_GIT_ORIGIN_REV_ID: ebd8fbb54c0f771b7128ff499af2abea85f73808
<!-- Thank you for submitting this PR! :) -->
## Description
Following https://github.com/hasura/v3-engine/pull/522 and friends, this
breaks out the command permissions into a discreet metadata step. This
creates a new `CommandWithPermissions` with type which is available
after this step, and removes the `Option<CommandPermission>` from the
regular `Command` type.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: ac076a93257d25ec5f9367a5a0b280f8b63371fc
<!-- Thank you for submitting this PR! :) -->
## Description
This separates out the stage that resolves relationships. The most
important thing here is that we no longer have a `relationships` field
in `ObjectTypeRepresentation` that may or may not be populated, and
instead add a new wrapper type `ObjectTypeWithRelationships`, which is
used downstream of this stage.
Stacked on top of https://github.com/hasura/v3-engine/pull/521
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 1e6ca41e55b8cc470385c35bbd7999fa7a2bce6e
<!-- Thank you for submitting this PR! :) -->
## Description
Following https://github.com/hasura/v3-engine/pull/520, there are a
couple of loose things that occur in the big metadata resolve, given
them their own stages too. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 2b7454ce997411da7dd9551ac05a4180b137e0a0
<!-- Thank you for submitting this PR! :) -->
## Description
Following https://github.com/hasura/v3-engine/pull/519 here is the
equivalent change for `commands` which are fortunately, much simpler.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 24ec7107018ed29e251452c9ca19c5b0538cd0c6
<!-- Thank you for submitting this PR! :) -->
## Description
As per https://github.com/hasura/v3-engine/pull/483 and all PRs
proceeding it, this moves the resolving of Models into a discreet
metadata stage. The `resolve::model` module was a bit of a dumping
ground, so I have tried to find more sensible homes for a lot of things,
but some things remain (model permissions) and will be homed when
sorting later stages.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: b41bcc9f413a867f21dd72b5d7affee8d55e02df
<!-- Thank you for submitting this PR! :) -->
## Description
More metadata resolving into stages, this time the resolving of boolean
expressions. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 5b74f7cd17f919dc54b82c003b7dd937eb69b65e
<!-- Thank you for submitting this PR! :) -->
## Description
This implements the first part of passing boolean expressions as command
arguments. It adds a `BooleanExpression` arm to `ValueExpression`, and
allows them to be resolved in the context of an ObjectType rather than
an entire model.
This means that if a boolean expression is passed to a command argument
that uses a field that doesn't exist, this happens:
<img width="960" alt="Screenshot 2024-04-05 at 15 54 20"
src="https://github.com/hasura/v3-engine/assets/4729125/cd795bc1-9fda-4cfb-bad3-1e70dd6227a0">
The output of this PR is that we can resolve metadata for boolean
expressions in command arguments, and generate a GraphQL schema for
them, but will throw an error if one is actually used. This will be
resolved in the follow-up PR.
V3_GIT_ORIGIN_REV_ID: 20b8840c313d7ee1f56ebd5becdb28bbe7743350
