improve schema management when horizontally scaled #1182
Assignees
Labels
c/server
Related to server
e/intermediate
can be wrapped up in a week
k/enhancement
New feature or improve an existing feature
k/production
Related to production use-cases
p/urgent
Immediate action required
Milestone
Comments
0x777
added
c/server
|
The current workaround is documented here: #940 |
rakeshkky
added a commit
to rakeshkky/graphql-engine
that referenced
this issue
Feb 7, 2019
rakeshkky
added a commit
to rakeshkky/graphql-engine
that referenced
this issue
Feb 8, 2019
21 tasks
shahidhk
pushed a commit
that referenced
this issue
Mar 12, 2019
…loses #1182) (#1574) 1. Haskel library `pg-client-hs` has been updated to expose a function that helps listen to `postgres` notifications over a `channel` in this [PR](hasura/pg-client-hs#5) 2. The server records an event in a table `hdb_catalog.hdb_cache_update_event` whenever any `/v1/query` (that changes metadata) is requested. A trigger notifies a `cache update` event via `hasura_cache_update` channel 3. The server runs two concurrent threads namely `listener` and `processor`. The `listener` thread listens to events on `hasura_cache_update` channel and pushed into a `Queue`. The `processor` thread fetches events from that `Queue` and processes it. Thus server rebuilds schema cache from database and updates.
hasura-bot
pushed a commit
that referenced
this issue
Oct 1, 2024
…t handled correctly in partial supergraph mode (#1182) ### 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
hasura-bot
pushed a commit
that referenced
this issue
Oct 7, 2024
…var (#1205) ### 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, when applying schema changes there should only be one instance running. We can get rid of this limitation by listening to changes on tables in
hdb_catalogand reload the metadata when needed.The text was updated successfully, but these errors were encountered: