hasura/graphql-engine
1
0
Fork 0
mirror of https://github.com/hasura/graphql-engine.git synced 2025-01-07 08:13:18 +03:00
Code Issues Projects Releases Wiki Activity
a13cd55056
graphql-engine/v3/crates/open-dds/Cargo.toml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

39 lines
995 B
TOML
Raw Normal View History

v3: open-source hasura v3 engine Hasura V3 Engine v3.alpha.12-19-2023 V3-GitOrigin-RevId: 6605575a52b347b5e9a14ecd1cc736f113c663b3 PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10567 Co-authored-by: Vishnu Bharathi <4211715+scriptnull@users.noreply.github.com> GitOrigin-RevId: 38c98a4b1971efe3ac724c2371c43ceb7d31f140
2023-12-19 12:04:02 +03:00
[package]
name = "open-dds"
Set the crate properties once, to improve the Nix build. (#334) V3_GIT_ORIGIN_REV_ID: ec5f3d968306a64ad5c63df324ca5c524838c598
2024-03-06 20:14:24 +03:00
version.workspace = true
edition.workspace = true
license.workspace = true
v3: open-source hasura v3 engine Hasura V3 Engine v3.alpha.12-19-2023 V3-GitOrigin-RevId: 6605575a52b347b5e9a14ecd1cc736f113c663b3 PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10567 Co-authored-by: Vishnu Bharathi <4211715+scriptnull@users.noreply.github.com> GitOrigin-RevId: 38c98a4b1971efe3ac724c2371c43ceb7d31f140
2023-12-19 12:04:02 +03:00
Disable benchmarks in unit tests. (#376) This means that we can pass arguments to the Criterion benchmarks because the test binaries do not try and run. For example, if you run this: ``` cargo bench -- --warm-up-time=1 --measurement-time=1 ``` … it will currently fail, because it will also pass these arguments to the tests. Disabling the benchmarks for the tests fixes this. V3_GIT_ORIGIN_REV_ID: 10fe0683b82c506e1a11b24ca0a0a4041e37b655
2024-03-21 15:41:31 +03:00
[lib]
bench = false
v3: open-source hasura v3 engine Hasura V3 Engine v3.alpha.12-19-2023 V3-GitOrigin-RevId: 6605575a52b347b5e9a14ecd1cc736f113c663b3 PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10567 Co-authored-by: Vishnu Bharathi <4211715+scriptnull@users.noreply.github.com> GitOrigin-RevId: 38c98a4b1971efe3ac724c2371c43ceb7d31f140
2023-12-19 12:04:02 +03:00
[dependencies]
Remove duplicate JSON Schema entries (#692) <!-- Thank you for submitting this PR! :) --> ## Description When we generate a JSON schema via `schemars`, we end up with duplicate types in the schema, which get names like `ValueExpression2`, `Role2`, and so on. This isn't ideal, and seems to arise for two reasons: 1. The type is polymorphic, and is monomorphised in two ways, and thus the types can't be unified. 2. The type is monomorphic, but is used inside and outside of its home module. The first problem was fixed previously by splitting polymorphic types, but the second has proven to be a bit more work. This PR finally solves the problem by introducing a new library, `jsonschema-tidying`: * First, we search the definitions within the JSON schema for any whose names end in a number, such as `ValueExpression2` or `MetadataV2`. * Then, we look for types whose names match everything up to the final numeric digits, and discard any types for whom we can't find a match (so we keep `ValueExpression2` because `ValueExpression` exists, but discard `MetadataV2` because `MetadataV` does not). * Next, we remove the duplicate definition from the definitions map, potentially breaking links in both the schema _and_ the rest of the definitions map. * Finally, we traverse the entirety of the tree looking for any references to the duplicate entry, and replace them with references to the original entry. This PR has no direct user-facing change, however it _will_ have an effect on the docs generation code, which will hopefully result in tidier documentation. <!-- Questions to consider answering: 1. What user-facing changes are being made? 4. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 5. What is the conceptual design behind this PR? 6. How can this PR be tested/verified? 7. Does the PR have limitations? 8. 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 - [x] 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 --> _Replace with changelog entry_ <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> V3_GIT_ORIGIN_REV_ID: fe73acf7d9df0b9867852e673e53cb086e3725d3
2024-06-11 11:27:42 +03:00
jsonschema-tidying = { path = "../utils/jsonschema-tidying" }
create auth and utils subdirectories in crates, and move architecture information to a separate doc. (#534) ## 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
2024-05-01 12:04:24 +03:00
opendds-derive = { path = "../utils/opendds-derive" }
Remove unused dependencies using `cargo machete`. (#413) `cargo machete` is a very useful tool that figures out when you aren't using a dependency. I have run this locally to remove unused dependencies. I've also added a CI job to make sure we catch these in the future. Sometimes it reports false positives, e.g. when a dependency isn't used directly but in macro-generated code (e.g. with `strum`). I have added `"ignored"` clauses to the `Cargo.toml` files where appropriate. V3_GIT_ORIGIN_REV_ID: ed015089b695cec8eeb03ce455d6dd3cd312a016
2024-03-28 12:16:54 +03:00
Move all dependency versions into the workspace file. (#734) This keeps versions in one place so we can more easily ensure we upgrade crates together. V3_GIT_ORIGIN_REV_ID: 6a929bb6196c19a1f66a768585b669127035e9be
2024-06-20 15:25:06 +03:00
derive_more = { workspace = true }
indexmap = { workspace = true, features = ["serde"] }
ndc-models = { workspace = true }
Add support for multiple versions of ndc-spec to Open DD and metadata-resolve (#781) This PR introduces support for multiple versions of the ndc-spec by adding a new `VersionedSchemaAndCapabilities` enum variant under the `DataConnectorLink` in OpenDD. This allows the capture of both ndc v0.1.* and v0.2.* schema and capabilities. This is achieved by referencing the `ndc-models` crate twice, once for `v0.1.4` and once for the first commit after `v0.1.4`. That commit was chosen to avoid actual v0.2.0 breaking changes for now, while we lay in this multiple version support plumbing. Future PRs will use a newer commit and adopt the breaking changes where necessary. The `VersionedSchemaAndCapabilities::V02` variant uses the the v0.2 reference of `ndc-models`. Then, during metadata resolve, when we resolve the `DataConnectorContext` from `DataConnectorLink`, we perform a migration of v0.1 types to v0.2 types and store and use the v0.2 types during metadata resolve. This migration is performed in the new module `ndc_migration`. We also record the `NdcVersion` (either `V01` or `V02`) in the `DataConnectorLink`. The `execute` crate will need to use this to determine which version to send to the connector at runtime (to be implemented in a future PR). The new changes to OpenDD are hidden from the JSON Schema via a new `UnstableFeatures` flag, and the use of the new variant is gated behind it in metadata resolve, since we don't yet support it upstream in the `execute` crate. V3_GIT_ORIGIN_REV_ID: d6d8a768ea3537c0b5e620799e94d3dd1e529526
2024-06-28 14:56:52 +03:00
ndc-models-v01 = { workspace = true }
Move all dependency versions into the workspace file. (#734) This keeps versions in one place so we can more easily ensure we upgrade crates together. V3_GIT_ORIGIN_REV_ID: 6a929bb6196c19a1f66a768585b669127035e9be
2024-06-20 15:25:06 +03:00
ref-cast = { workspace = true }
schemars = { workspace = true, features = ["smol_str", "preserve_order"] }
serde = { workspace = true }
serde_json = { workspace = true, features = ["preserve_order"] }
serde_path_to_error = { workspace = true }
Use `SubgraphIdentifier` in the metadata accessor, and `SmolStr` internally. (#768) ### What Using `String` everywhere to represent subgraph identifiers is definitely going to cause problems at some point. We can avoid this by using `open_dds::identifier::SubgraphIdentifier` instead. `Identifier` and `SubgraphIdentifier` were wrappers around `String`. I have also changed them to wrap `SmolStr` instead, for better performance as they're cloned a lot. ### How First of all, I hid the innards of `Identifier` and `SubgraphIdentifier`, instead exposing certain behaviors as methods. Mostly, this means exposing `as_str()` and `to_string()`. Then I replaced the internals with `SmolStr`. I had to change one place where `RefCast` was used, but that was pretty much it. Finally, I switched out `String` for `SubgraphIdentifier` in `QualifiedObject`. This necessitated a couple of constants for the two "magic" subgraphs, `__globals` and `__unknown_namespace`, but was otherwise fine. I didn't touch `Qualified` for now. V3_GIT_ORIGIN_REV_ID: 28664609c3173b181c3789093cb9796896642eb7
2024-06-27 01:03:31 +03:00
smol_str = { workspace = true }
Move all dependency versions into the workspace file. (#734) This keeps versions in one place so we can more easily ensure we upgrade crates together. V3_GIT_ORIGIN_REV_ID: 6a929bb6196c19a1f66a768585b669127035e9be
2024-06-20 15:25:06 +03:00
strum = { workspace = true }
strum_macros = { workspace = true }
thiserror = { workspace = true }
v3: open-source hasura v3 engine Hasura V3 Engine v3.alpha.12-19-2023 V3-GitOrigin-RevId: 6605575a52b347b5e9a14ecd1cc736f113c663b3 PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10567 Co-authored-by: Vishnu Bharathi <4211715+scriptnull@users.noreply.github.com> GitOrigin-RevId: 38c98a4b1971efe3ac724c2371c43ceb7d31f140
2023-12-19 12:04:02 +03:00
[dev-dependencies]
Move all dependency versions into the workspace file. (#734) This keeps versions in one place so we can more easily ensure we upgrade crates together. V3_GIT_ORIGIN_REV_ID: 6a929bb6196c19a1f66a768585b669127035e9be
2024-06-20 15:25:06 +03:00
goldenfile = { workspace = true }
pretty_assertions = { workspace = true }
Remove unused dependencies using `cargo machete`. (#413) `cargo machete` is a very useful tool that figures out when you aren't using a dependency. I have run this locally to remove unused dependencies. I've also added a CI job to make sure we catch these in the future. Sometimes it reports false positives, e.g. when a dependency isn't used directly but in macro-generated code (e.g. with `strum`). I have added `"ignored"` clauses to the `Cargo.toml` files where appropriate. V3_GIT_ORIGIN_REV_ID: ed015089b695cec8eeb03ce455d6dd3cd312a016
2024-03-28 12:16:54 +03:00
[package.metadata.cargo-machete]
ignored = [
"strum", # used by strum_macros
]
use clippy settings in Cargo workspace (#441) <!-- Thank you for submitting this PR! :) --> ## Description Following the approach taken here: https://github.com/hasura/ndc-postgres/pull/402 This moves the `clippy` settings into the Cargo workspace file instead of passing them for each invocation. We enable all pedantic settings, run `cargo clippy --fix` to auto fix a few things, and then manually disable all other lints. Plenty of them are worth enabling and fixing in future IMO. --------- Co-authored-by: Samir Talwar <samir.talwar@hasura.io> V3_GIT_ORIGIN_REV_ID: aa0e6ccb8d72a7393e14b5c58b82077a67d9cb15
2024-04-08 13:13:26 +03:00
[lints]
workspace = true
Reference in New Issue Copy Permalink