Commit Graph

811 Commits

Author SHA1 Message Date
Puru Gupta
698190894f server: use kriti template to generate query param from list
## Description ✍️
This PR adds support to generate query params directly using a kriti template which can be used to flatten a list of parameter arguments as well.

### Changes in the Metadata API
Earlier the `query_params` key inside `request_transform` used to take in an object of key/value pairs where the `key` represents the query parameter name and `value` points to the value of the parameter or a kriti template which could be resolved to the value.

With this PR, we provide the user with more freedom to generate the complete query string using kriti template. The  `query_params` can now take in a string as well which will be a kriti template. This new change needs to be incorporated on the console and CLI metadata import/export as well.
- [x] CLI: Compatible, no changes required
- [ ] Console

## Changelog ✍️

__Component__ : server

__Type__: feature

__Product__: community-edition

### Short Changelog

use kriti template to generate query param from list of arguments

### Related Issues ✍
https://hasurahq.atlassian.net/browse/GS-243

### Solution and Design ✍
We use a kriti template to generate the complete query parameter string.

| Query Template | Output |
|---|---|
| `{{ concat ([concat({{ range _, x := [\"apple\", \"banana\"] }} \"tags={{x}}&\" {{ end }}), \"flag=smthng\"]) }}`| `tags=apple&tags=banana&flag=smthng`  |
| `{{ concat ([\"tags=\", concat({{ range _, x := $body.input }} \"{{x}},\" {{ end }})]) }}` | `tags=apple%2Cbanana%2C` |

### Steps to test and verify ✍
- start HGE and make the following request to `http://localhost:8080/v1/metadata`:
```json
{
    "type": "test_webhook_transform",
    "args": {
        "webhook_url": "http://localhost:3000",
        "body": {
            "action": {
                "name": "actionName"
            },
            "input": ["apple", "banana"]
        },
        "request_transform": {
            "version": 2,
            "url": "{{$base_url}}",
            "query_params": "{{ concat ([concat({{ range _, x := $body.input }} \"tags={{x}}&\" {{ end }}), \"flag=smthng\"]) }}",
            "template_engine": "Kriti"
        }
    }
}
```
- you should receive the following as output:
```json
{
    "body": {
        "action": {
            "name": "actionName"
        },
        "input": [
            "apple",
            "banana"
        ]
    },
    "headers": [],
    "method": "GET",
    "webhook_url": "http://localhost:3000?tags=apple&tags=banana&flag=smthng"
}
```

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6961
Co-authored-by: Tirumarai Selvan <8663570+tirumaraiselvan@users.noreply.github.com>
GitOrigin-RevId: 712ba038f03009edc3e8eb0435e723304943399a
2022-11-29 20:27:41 +00:00
Karthikeyan Chinnakonda
32a316aef7 server: provide an option to enable event triggers on logically replicated tables
## Description ✍️
This PR introduces a new feature to enable/disable event triggers during logical replication of table data for PostgreSQL and MS-SQL data sources. We introduce a new field `trigger_on_replication` in the `*_create_event_trigger` metadata API. By default the event triggers will not fire for logical data replication.

## Changelog ✍️

__Component__ : server

__Type__: feature

__Product__: community-edition

### Short Changelog

Add option to enable/disable event triggers on logically replicated tables

### Related Issues ✍

https://github.com/hasura/graphql-engine/issues/8814
https://hasurahq.atlassian.net/browse/GS-252

### Solution and Design
- By default, triggers do **not** fire when the session mode is `replica` in Postgres, so if the `triggerOnReplication` is set to `true` for an event trigger we run the query `ALTER TABLE #{tableTxt} ENABLE ALWAYS TRIGGER #{triggerNameTxt};` so that the trigger fires always irrespective of the `session_replication_role`
- By default, triggers do fire in case of replication in MS-SQL, so if the `triggerOnReplication` is set to `false` for an event trigger we add a clause `NOT FOR REPLICATION` to the the SQL when the trigger is created/altered, which sets the `is_not_for_replication` for the trigger as `true` and it does not fire during logical replication.

### Steps to test and verify ✍
- Run hspec integration tests for HGE

## Server checklist ✍

### Metadata ✍

Does this PR add a new Metadata feature?
-  Yes
  - Does `export_metadata`/`replace_metadata` supports the new metadata added?
    - 

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6953
Co-authored-by: Puru Gupta <32328846+purugupta99@users.noreply.github.com>
Co-authored-by: Sean Park-Ross <94021366+seanparkross@users.noreply.github.com>
GitOrigin-RevId: 92731328a2bbdcad2302c829f26f9acb33c36135
2022-11-29 17:43:13 +00:00
awjchen
badad573f6 server: implement resource attributes for the OpenTelemetry exporter
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6891
GitOrigin-RevId: 2c7b4767160e9fb976be4b5e656ef70cd19e4e0e
2022-11-29 07:35:09 +00:00
Auke Booij
cca0b6e81a Further schema cache cleanups
Mostly trying to avoid tricky `Arrows` syntax, and unnecessary use of the `Hasura.Incremental` framework.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6997
GitOrigin-RevId: 9a2f5883e7e29af164e1581049ae003afec2cbe4
2022-11-29 01:02:09 +00:00
Auke Booij
7928179024 Delete SourceM type class
I encountered this dead code while doing other things: it's a type class with a single method which is never called. Deleting the type class allows us to simplify `TableCoreCacheRT` and `TableCacheRT`

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7075
GitOrigin-RevId: 121320349c478a93717b0706037553d8406cbfa9
2022-11-28 20:20:32 +00:00
Auke Booij
b0d4493b5c Replace non-canonical Select instance with a canonical one
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7066
GitOrigin-RevId: ef65253ad816d669d109cf45662817b3115b37c3
2022-11-28 09:50:18 +00:00
Daniel Harvey
79b50add5e [server] regularly ping selected sources
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6945
GitOrigin-RevId: cad67b121090d4100330067d3d50f575292b4584
2022-11-23 16:41:46 +00:00
awjchen
339e19048b server: update metadata api for the OpenTelemetry exporter
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6844
GitOrigin-RevId: 3d808215fc46a79caf85a1c4d964ac874f905029
2022-11-23 07:54:53 +00:00
Auke Booij
67b922bac1 Avoid GraphQL schema rebuild when changing irrelevant Metadata
This increases the speed of `create_query_collection` and `add_collection_to_allowlist` by a factor ~~10~~ 65, by caching the in-memory GraphQL schema. This speedup also applies more broadly to Metadata changes relating to:
- allowlists
- query collections
- cron triggers
- REST endpoints
- API limits
- metrics config
- GraphQL introspection options
- TLS allow lists
- OpenTelemetry

When is construction of the in-memory GraphQL schema cached between Metadata operations?

Before this PR, **never**! It's rebuilt fully, for every role, on every Metadata operation.

However, there are many Metadata operations that don't influence the GraphQL schema. So we should be caching its construction.

The `Hasura.Incremental` framework allows us to cache such constructions: whenever we have an arrow `Rule m a b`, where `a` is the input to the arrow and `b` the output, we can use the `Inc.cache` combinator to obtain a new arrow which is only re-executed when the input `a` changes in a material way. To test this, `a` needs an `Eq` instance. (Before hasura/graphql-engine-mono#6877, this was a `Cacheable` type class which has now been removed.)

We can't simply apply `Inc.cache` to the "Steps 3 and 4" in `buildSchemaCacheRule`, because the inputs (components of `BuildOutputs` such as `SourceCache`) don't have an `Eq` instance.

So the changes to `buildSchemaCacheRule` restructure the code so that the input to "Step 1", namely the Metadata, can be used as a caching key instead, so that `Inc.cache` can be applied to the whole sequence of steps.

That works to cache construction of the GraphQL schema, but it means that now only those Metadata operations that _don't_ influence any of the products of steps 1-4 can use a cached build of the GraphQL schema. The most important intermediate product is `BuildOutputs`. So now the exercise becomes to minimize the amount of stuff stored in `BuildOutputs`, so that as many Metadata operations as possible can be handled outside of the codepath that produces a GraphQL schema.

Per hasura/graphql-engine-mono#6609, the `BuildOutputs` structure is too big, and stores things unnecessarily. Refer to the PR description there for reasoning - the same logic applies to this PR, and simply goes a few steps further. In doing so, it can benefit from hasura/graphql-engine-mono#6765, which allows us to verify at compile time that certain Schema Cache building steps _don't_ generate "Metadata dependencies". If a certain Metadata dependency is never generated, we don't need to handle that case in `deleteMetadataObject`. Thus such intermediate products don't need to be passed through `resolveDependencies`, and thus they don't need to be stored in `BuildOutputs`, and thus their rebuild won't trigger a GraphQL schema rebuild.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6613
GitOrigin-RevId: 27d2e69d3461bd4c32f08febef9995c0369fab3a
2022-11-23 07:54:01 +00:00
Brandon Simmons
378817d05a server: memoize in tableSelectColumnsEnum and mkNumericAggFields for more sharing
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6789
GitOrigin-RevId: 744600d42b497b77f2eca5fc46715e0df3e1fc8e
2022-11-23 07:53:11 +00:00
Auke Booij
cdac24c79f server: delete the Cacheable type class in favor of Eq
What is the `Cacheable` type class about?
```haskell
class Eq a => Cacheable a where
  unchanged :: Accesses -> a -> a -> Bool
  default unchanged :: (Generic a, GCacheable (Rep a)) => Accesses -> a -> a -> Bool
  unchanged accesses a b = gunchanged (from a) (from b) accesses
```
Its only method is an alternative to `(==)`. The added value of `unchanged` (and the additional `Accesses` argument) arises _only_ for one type, namely `Dependency`. Indeed, the `Cacheable (Dependency a)` instance is non-trivial, whereas every other `Cacheable` instance is completely boilerplate (and indeed either generated from `Generic`, or simply `unchanged _ = (==)`). The `Cacheable (Dependency a)` instance is the only one where the `Accesses` argument is not just passed onwards.

The only callsite of the `unchanged` method is in the `ArrowCache (Rule m)` method. That is to say that the `Cacheable` type class is used to decide when we can re-use parts of the schema cache between Metadata operations.

So what is the `Cacheable (Dependency a)` instance about? Normally, the output of a `Rule m a b` is re-used when the new input (of type `a`) is equal to the old one. But sometimes, that's too coarse: it might be that a certain `Rule m a b` only depends on a small part of its input of type `a`. A `Dependency` allows us to spell out what parts of `a` are being depended on, and these parts are recorded as values of types `Access a` in the state `Accesses`.

If the input `a` changes, but not in a way that touches the recorded `Accesses`, then the output `b` of that rule can be re-used without recomputing.

So now you understand _why_ we're passing `Accesses` to the `unchanged` method: `unchanged` is an equality check in disguise that just needs some additional context.

But we don't need to pass `Accesses` as a function argument. We can use the `reflection` package to pass it as type-level context. So the core of this PR is that we change the instance declaration from
```haskell
instance (Cacheable a) => Cacheable (Dependency a) where
```
to
```haskell
 instance (Given Accesses, Eq a) => Eq (Dependency a) where
```
and use `(==)` instead of `unchanged`.

If you haven't seen `reflection` before: it's like a `MonadReader`, but it doesn't require a `Monad`.

In order to pass the current `Accesses` value, instead of simply passing the `Accesses` as a function argument, we need to instantiate the `Given Accesses` context. We use the `give` method from the `reflection` package for that.
```haskell
give :: forall r. Accesses -> (Given Accesses => r) -> r

unchanged :: (Given Accesses => Eq a) => Accesses -> a -> a -> Bool
unchanged accesses a b = give accesses (a == b)
```
With these three components in place, we can delete the `Cacheable` type class entirely.

The remainder of this PR is just to remove the `Cacheable` type class and its instances.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6877
GitOrigin-RevId: 7125f5e11d856e7672ab810a23d5bf5ad176e77f
2022-11-21 16:35:37 +00:00
Lyndon Maydwell
7228d0327f Add display_name, release_name fields to MD Agent APIs - GDC-626
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6849
GitOrigin-RevId: 0ab90aaf281cc1c043f73fd6d63c4c18d58c7c92
2022-11-18 04:19:08 +00:00
Antoine Leblanc
42e5205eb5 server: reduce schema contexts to the bare minimum
### Description

This monster of a PR took way too long. As the title suggests, it reduces the schema context carried in the readers to the very strict minimum. In practice, that means that to build a source, we only require:
  - the global `SchemaContext`
  - the global `SchemaOptions` (soon to be renamed `SchemaSourceOptions`)
  - that source's `SourceInfo`

Furthermore, _we no longer carry "default" customization options throughout the schema_. All customization information is extracted from the `SourceInfo`, when required. This prevents an entire category of bugs we had previously encountered, such as parts of the code using uninitialized / unupdated customization info.

In turn, this meant that we could remove the explicit threading of the `SourceInfo` throughout the schema, since it is now always available through the reader context.

Finally, this meant making a few adjustments to relay and actions as well, such as the introduction of a new separate "context" for actions, and a change to how we create some of the action-specific postgres scalar parsers.

I'll highlight with review comments the areas of interest.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6709
GitOrigin-RevId: ea80fddcb24e2513779dd04b0b700a55f0028dd1
2022-11-17 10:35:54 +00:00
paritosh-08
3a79fdbfcc server: fix template validation behaviour
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6870
GitOrigin-RevId: e55ec0a39c68e960665d59f6c1824f5ba115f84d
2022-11-16 16:37:34 +00:00
Gil Mizrahi
12dea92a92 CockroachDB version check
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6900
GitOrigin-RevId: 07d417c7bb49b7f41900d24f543ff531362f9741
2022-11-16 15:42:30 +00:00
Auke Booij
5b93014ee8 Make Schema Cache building code slightly more readable
- Avoid a few banana brackets `(| ... |)`, often by just using local `let` bindings
- Use proper `Arrows` syntax rather than helpers like `>->`
- Use monadic `do` syntax instead of `Arrows` syntax where possible
- Avoid `traverseA @Maybe`, in favor of a `case`

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6751
GitOrigin-RevId: c07b22a1a259db6d135486ec71a716705e280717
2022-11-15 20:14:22 +00:00
Auke Booij
6ac67a5566 Allow collecting metadata dependencies and inconsistencies separately
`CollectedInfo` was just an awkward sum type. By using an explicit `Either` instead, we can guarantee at the type level that certain methods only write inconsistencies, or only write dependencies. This is useful, because if we can guarantee that no dependencies are written, then we don't need to run `resolveDependencies` on that part of the Metadata. In other words, we can keep it out of `BuildOutputs`, which greatly benefits performance - see e.g. hasura/graphql-engine-mono#6613.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6765
GitOrigin-RevId: 9ce099d2eee2278dbb6e5bea72063e4b6e064b35
2022-11-15 17:00:11 +00:00
Auke Booij
2d055df2a4 server: Simplify BuildOutputs
A bunch of configurations are retrieved from the Metadata, then stored in the `BuildOutputs` structure, only to then be forwarded to the `SchemaCache`, with extremely little processing in between.

So this simplifies the build pipeline for some parts of the metadata: just construct those things from `Metadata` directly, and store them in the `SchemaCache` without any intermediate container.

Why did we have the detour via `BuildOutputs` in the first place? Parts of the Metadata (codified by `MetadataObjId`) can generate _metadata inconsistencies_ and/or _schema dependencies_, which are related.

- Metadata inconsistencies are warnings that we show to the user, indicating that there's something wrong with their configuration, and they have to fix it.
- Schema dependencies are an internal mechanism that allow us to build a consistent view of the world. For instance, if we have a relationship from DB tables `books` to `authors`, but the `authors` table is inconsistent (e.g. it doesn't exist in the DB), then we have schema dependencies indicating that. The job of `resolveDependencies` is to then drop the relationship, so that we can at least generate a legal GraphQL schema for `books`.

If we never generate a schema dependency for a certain fragment of Metadata, then there is no reason to call `resolveDependencies` on it, and so there is no reason to store it in `BuildOutputs`.

---

The starting point that allows this refactor is to apply Metadata defaults before it reaches `buildAndCollectInfo`, so that metadata-with-defaults can be used elsewhere.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6609
GitOrigin-RevId: df0c4a7ff9451e10e02a40bf26304b26584ba483
2022-11-15 12:04:13 +00:00
Gil Mizrahi
15b3ac0aee ghc 9.2.5
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6777
Co-authored-by: Samir Talwar <47582+SamirTalwar@users.noreply.github.com>
GitOrigin-RevId: 916abab76446cf7c4e1e63dc112ba4994ab4d23d
2022-11-15 11:26:42 +00:00
Solomon
d0a77a9f28 Prevents creation of duplicate GDC agent source kinds.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6865
GitOrigin-RevId: e3b3c68e91b22307ef4a9f215e34234b875d802f
2022-11-15 00:40:56 +00:00
paritosh-08
ec13a55fd5 server: add validation for response transforms
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6821
GitOrigin-RevId: 88abcc408d0a1b73024356d9b32881bc3d4d746c
2022-11-14 15:19:23 +00:00
Lyndon Maydwell
6f9f44a441 Data Connectors API 400 error response - GDC-619
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6839
GitOrigin-RevId: 813ea5e976ff41754e7500abf6bcd0c8b70c960e
2022-11-14 05:26:16 +00:00
Abby Sassel
8726236a9d NDAT-316 Improve askSourceInfo error reporting _even more_
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6835
GitOrigin-RevId: c15bea414176878c6ec96674376858294e48255b
2022-11-10 19:24:34 +00:00
Jesse Hallett
31e402e767 server: remaining codecs for function metadata
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6654
GitOrigin-RevId: a9d24c72078d2a2b0c8a62a6084d5ab86518fdeb
2022-11-10 16:17:13 +00:00
Abby Sassel
63ec04493a NDAT-316 Improve askSourceInfo error reporting
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6807
GitOrigin-RevId: b27e642079915c3f0ca85d88195fe323e18800c1
2022-11-10 11:48:02 +00:00
awjchen
ebb28ad4c9 pro-server: add support for exporting traces over OTLP
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5862
GitOrigin-RevId: fd80a59a1459095716f94cea7b2e54f9b5d19a98
2022-11-07 06:56:08 +00:00
Jesse Hallett
de6e5d71b0 server: codecs for table, function, and remote relationship types
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6608
GitOrigin-RevId: 9c91edec06e49b8d44960e322459ba7a05f26b5a
2022-11-04 21:44:41 +00:00
Lyndon Maydwell
4db9941b32 Prohibit underscores in dataconnector names [GDC-586]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6681
GitOrigin-RevId: 5335208fc4c8f0d1b16a45415329ef390a269b4c
2022-11-03 14:00:52 +00:00
Karthikeyan Chinnakonda
d7609233c4 Rename get_event_invocations to get_scheduled_event_invocations
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6513
Co-authored-by: Varun Choudhary <68095256+Varun-Choudhary@users.noreply.github.com>
GitOrigin-RevId: 172ba6152ed77b90eeec9183a3fb4c6f177e45b3
2022-11-03 10:23:11 +00:00
Samir Talwar
342391f39d Upgrade Ormolu to v0.5.
This upgrades the version of Ormolu required by the HGE repository to v0.5.0.1, and reformats all code accordingly.

Ormolu v0.5 reformats code that uses infix operators. This is mostly useful, adding newlines and indentation to make it clear which operators are applied first, but in some cases, it's unpleasant. To make this easier on the eyes, I had to do the following:

* Add a few fixity declarations (search for `infix`)
* Add parentheses to make precedence clear, allowing Ormolu to keep everything on one line
* Rename `relevantEq` to `(==~)` in #6651 and set it to `infix 4`
* Add a few _.ormolu_ files (thanks to @hallettj for helping me get started), mostly for Autodocodec operators that don't have explicit fixity declarations

In general, I think these changes are quite reasonable. They mostly affect indentation.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6675
GitOrigin-RevId: cd47d87f1d089fb0bc9dcbbe7798dbceedcd7d83
2022-11-02 20:55:13 +00:00
Samir Talwar
dbc027424b Rename relevantEq to (==~) for Ormolu's sake.
Ormolu v0.5 tries to reformat code using operators according to fixity. Unfortunately, it doesn't really understand backticked functions (even when they have an associated `infix` declaration), and so messes up the formatting.

This is probably a bug in Ormolu, but we can work around it by using a symbol operator.

Happy to bikeshed on `==~` (which I am reading as "pretty much equal to"). Please yell at me if you prefer something else.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6651
GitOrigin-RevId: 79af427422194460200b2b48339cdb9ee9b33c33
2022-11-02 10:43:48 +00:00
Karthikeyan Chinnakonda
9177335c31 Source catalog migrations minor enhancements
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6531
Co-authored-by: paritosh-08 <85472423+paritosh-08@users.noreply.github.com>
GitOrigin-RevId: 51dd55692f59d6ad0fd54674fb7d3ce00d5d83dd
2022-11-01 22:42:40 +00:00
David Overton
9921823915 GDC-189 custom aggregations
>

## Description
->

This PR allows DC agents to define custom aggregate functions for their scalar types.

### Related Issues
->

GDC-189

### Solution and Design
>

We added a new property `aggregate_functions` to the scalar types capabilities. This allows the agent author to specify a set of aggregate functions supported by each scalar type, along with the function's result type.

During GraphQL schema generation, the custom aggregate functions are available via a new method `getCustomAggregateOperators` on the `Backend` type class.
Custom functions are merged with the builtin aggregate functions when building GraphQL schemas for table aggregate fields and for `order_by` operators on array relations.

### Steps to test and verify
>

• Codec tests for aggregate function capabilities have been added to the unit tests.
• Some custom aggregate operators have been added to the reference agent and are used in a new test in `api-tests`.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6199
GitOrigin-RevId: e9c0d1617af93847c1493671fdbb794f573bde0c
2022-10-27 00:44:06 +00:00
paritosh-08
b8bbb8a621 server: optional query params in REST connector
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6381
Co-authored-by: Rob Dominguez <24390149+robertjdominguez@users.noreply.github.com>
GitOrigin-RevId: b777b373b2fbe19ceb32f812d4eaba45ef0a5a58
2022-10-21 18:40:48 +00:00
Vamshi Surabhi
a01d1188f2 scaffolding for remote-schemas module
The main aim of the PR is:

1. To set up a module structure for 'remote-schemas' package.
2. Move parts by the remote schema codebase into the new module structure to validate it.

## Notes to the reviewer

Why a PR with large-ish diff?

1. We've been making progress on the MM project but we don't yet know long it is going to take us to get to the first milestone. To understand this better, we need to figure out the unknowns as soon as possible. Hence I've taken a stab at the first two items in the [end-state](https://gist.github.com/0x777/ca2bdc4284d21c3eec153b51dea255c9) document to figure out the unknowns. Unsurprisingly, there are a bunch of issues that we haven't discussed earlier. These are documented in the 'open questions' section.

1. The diff is large but that is only code moved around and I've added a section that documents how things are moved. In addition, there are fair number of PR comments to help with the review process.

## Changes in the PR

### Module structure

Sets up the module structure as follows:

```
Hasura/
  RemoteSchema/
    Metadata/
      Types.hs
    SchemaCache/
      Types.hs
      Permission.hs
      RemoteRelationship.hs
      Build.hs
    MetadataAPI/
      Types.hs
      Execute.hs
```

### 1. Types representing metadata are moved

Types that capture metadata information (currently scattered across several RQL modules) are moved into `Hasura.RemoteSchema.Metadata.Types`.

- This new module only depends on very 'core' modules such as
  `Hasura.Session` for the notion of roles and `Hasura.Incremental` for `Cacheable` typeclass.

- The requirement on database modules is avoided by generalizing the remote schemas metadata to accept an arbitrary 'r' for a remote relationship
  definition.

### 2. SchemaCache related types and build logic have been moved

Types that represent remote schemas information in SchemaCache are moved into `Hasura.RemoteSchema.SchemaCache.Types`.

Similar to `H.RS.Metadata.Types`, this module depends on 'core' modules except for `Hasura.GraphQL.Parser.Variable`. It has something to do with remote relationships but I haven't spent time looking into it. The validation of 'remote relationships to remote schema' is also something that needs to be looked at.

Rips out the logic that builds remote schema's SchemaCache information from the monolithic `buildSchemaCacheRule` and moves it into `Hasura.RemoteSchema.SchemaCache.Build`. Further, the `.SchemaCache.Permission` and `.SchemaCache.RemoteRelationship` have been created from existing modules that capture schema cache building logic for those two components.

This was a fair amount of work. On main, currently remote schema's SchemaCache information is built in two phases - in the first phase, 'permissions' and 'remote relationships' are ignored and in the second phase they are filled in.

While remote relationships can only be resolved after partially resolving sources and other remote schemas, the same isn't true for permissions. Further, most of the work that is done to resolve remote relationships can be moved to the first phase so that the second phase can be a very simple traversal.

This is the approach that was taken - resolve permissions and as much as remote relationships information in the first phase.

### 3. Metadata APIs related types and build logic have been moved

The types that represent remote schema related metadata APIs and the execution logic have been moved to `Hasura.RemoteSchema.MetadataAPI.Types` and `.Execute` modules respectively.

## Open questions:

1. `Hasura.RemoteSchema.Metadata.Types` is so called because I was hoping that all of the metadata related APIs of remote schema can be brought in at `Hasura.RemoteSchema.Metadata.API`. However, as metadata APIs depended on functions from `SchemaCache` module (see [1](ceba6d6226/server/src-lib/Hasura/RQL/DDL/RemoteSchema.hs (L55)) and [2](ceba6d6226/server/src-lib/Hasura/RQL/DDL/RemoteSchema.hs (L91)), it made more sense to create a separate top-level module for `MetadataAPI`s.

   Maybe we can just have `Hasura.RemoteSchema.Metadata` and get rid of the extra nesting or have `Hasura.RemoteSchema.Metadata.{Core,Permission,RemoteRelationship}` if we want to break them down further.

1. `buildRemoteSchemas` in `H.RS.SchemaCache.Build` has the following type:

   ```haskell
   buildRemoteSchemas ::
     ( ArrowChoice arr,
       Inc.ArrowDistribute arr,
       ArrowWriter (Seq CollectedInfo) arr,
       Inc.ArrowCache m arr,
       MonadIO m,
       HasHttpManagerM m,
       Inc.Cacheable remoteRelationshipDefinition,
       ToJSON remoteRelationshipDefinition,
       MonadError QErr m
     ) =>
     Env.Environment ->
     ( (Inc.Dependency (HashMap RemoteSchemaName Inc.InvalidationKey), OrderedRoles),
       [RemoteSchemaMetadataG remoteRelationshipDefinition]
     )
       `arr` HashMap RemoteSchemaName (PartiallyResolvedRemoteSchemaCtxG remoteRelationshipDefinition, MetadataObject)
   ```

   Note the dependence on `CollectedInfo` which is defined as

   ```haskell
   data CollectedInfo
     = CIInconsistency InconsistentMetadata
     | CIDependency
         MetadataObject
         -- ^ for error reporting on missing dependencies
         SchemaObjId
         SchemaDependency
     deriving (Eq)
   ```

   this pretty much means that remote schemas is dependent on types from databases, actions, ....

   How do we fix this? Maybe introduce a typeclass such as `ArrowCollectRemoteSchemaDependencies` which is defined in `Hasura.RemoteSchema` and then implemented in graphql-engine?

1. The dependency on `buildSchemaCacheFor` in `.MetadataAPI.Execute` which has the following signature:

   ```haskell
   buildSchemaCacheFor ::
     (QErrM m, CacheRWM m, MetadataM m) =>
     MetadataObjId ->
     MetadataModifier ->
   ```

   This can be easily resolved if we restrict what the metadata APIs are allowed to do. Currently, they operate in an unfettered access to modify SchemaCache (the `CacheRWM` constraint):

   ```haskell
   runAddRemoteSchema ::
     ( QErrM m,
       CacheRWM m,
       MonadIO m,
       HasHttpManagerM m,
       MetadataM m,
       Tracing.MonadTrace m
     ) =>
     Env.Environment ->
     AddRemoteSchemaQuery ->
     m EncJSON
   ```

   This should instead be changed to restrict remote schema APIs to only modify remote schema metadata (but has access to the remote schemas part of the schema cache), this dependency is completely removed.

   ```haskell
   runAddRemoteSchema ::
     ( QErrM m,
       MonadIO m,
       HasHttpManagerM m,
       MonadReader RemoteSchemasSchemaCache m,
       MonadState RemoteSchemaMetadata m,
       Tracing.MonadTrace m
     ) =>
     Env.Environment ->
     AddRemoteSchemaQuery ->
     m RemoteSchemeMetadataObjId
   ```

   The idea is that the core graphql-engine would call these functions and then call
   `buildSchemaCacheFor`.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6291
GitOrigin-RevId: 51357148c6404afe70219afa71bd1d59bdf4ffc6
2022-10-21 03:15:04 +00:00
Lyndon Maydwell
37c65d4395 Support MetadataDefaults Options - GDC-108
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6286
GitOrigin-RevId: ef861e6070e667322fb2657166d3d343d6cab4bc
2022-10-20 12:46:45 +00:00
Rakesh Emmadi
1c745959b9 relocate 'ServerReplicas' and 'ResizePoolStrategy' types
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6448
GitOrigin-RevId: 2d317fd004db63e2830dfb8def92acb51bb576a0
2022-10-20 01:34:17 +00:00
Daniel Chambers
5c51ff4288 Fix conflicting data connector comparison exp GraphQL types
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6394
GitOrigin-RevId: c272e8aad426a18ccadfec005e03d5b2669e035c
2022-10-18 04:19:12 +00:00
Rakesh Emmadi
5666161ac9 server/multitenant: resize sources' connection pools when a cloud project is scaled, global connection pooling
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5708
Co-authored-by: Naveen Naidu <30195193+Naveenaidu@users.noreply.github.com>
Co-authored-by: pranshi06 <85474619+pranshi06@users.noreply.github.com>
Co-authored-by: Puru Gupta <32328846+purugupta99@users.noreply.github.com>
Co-authored-by: Rikin Kachhia <54616969+rikinsk@users.noreply.github.com>
Co-authored-by: Anon Ray <616387+ecthiender@users.noreply.github.com>
GitOrigin-RevId: 513d497548d89b397d4a299355b11607daec3c7e
2022-10-17 08:06:12 +00:00
Solomon
4700ac44fb Webhook Transforms: Move RequestCtx into a type family
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5975
GitOrigin-RevId: 08ad528b2600379deb4cef9d39968126c7c745d8
2022-10-16 03:55:06 +00:00
Jesse Hallett
c6bcf1cd76 server: codecs for object & array relationships, and computed fields
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5923
GitOrigin-RevId: e0c7584539998f5af16795f023640aa5c659b783
2022-10-13 17:57:23 +00:00
Krushan Bauva
63f90cc93c server: add api limit - batch limit
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6183
Co-authored-by: Naveen Naidu <30195193+Naveenaidu@users.noreply.github.com>
Co-authored-by: Sean Park-Ross <94021366+seanparkross@users.noreply.github.com>
GitOrigin-RevId: 517766e10a3e94a54b754df69c47c61232d8dbb2
2022-10-13 16:54:26 +00:00
Samir Talwar
96a768e526 Upgrade HLint to v3.4.1.
This upgrades CI and anyone using Nix to HLint v3.4.1.

If you're not using Nix, this doesn't actually _do_ anything on your
local machine; it's just a suggestion.

It also applies a bunch of simple HLint refactors, using
`make lint-hs-fix`.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6324
GitOrigin-RevId: de8267e4909d6dcd3f83543188517f3aaeebc5f3
2022-10-12 19:14:56 +00:00
Jesse Hallett
332faabc24 server: codecs for remaining database configuration types
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6062
GitOrigin-RevId: f1ba9fa30267d1825ba36480103cd973616f3079
2022-10-12 16:30:05 +00:00
paritosh-08
5c774cf839 server,pro: fix batch_size behaviour for auto event trigger log cleanup
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6279
GitOrigin-RevId: 20b8e6a22a26d97cd78655027aa2f30b7838462d
2022-10-11 19:27:53 +00:00
Tom Harding
4fdbda05ec Enable Postgres enums for Cockroach
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6232
GitOrigin-RevId: cc29e4932c3a24039efaf28f890a3dad97b51c3e
2022-10-11 09:09:26 +00:00
Lyndon Maydwell
d54bb30d3b Structured Error Protocol for Data Connectors Agents - GDW-137
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6061
Co-authored-by: Vishnu Bharathi <4211715+scriptnull@users.noreply.github.com>
GitOrigin-RevId: 855d96378030f4e01b0c74b00e20e592e51e7a49
2022-10-11 00:26:24 +00:00
Auke Booij
6f6177db38 Remove some unnecessary OPTIONS_GHC pragmas
I didn't track why these were left behind. Presumably GHC 9.2 has an improved redundant constraint checker, so that explains a few. Otherwise, perhaps code got refactored along the way.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6256
GitOrigin-RevId: b6275edf3e867f8e33bdec533ce9932381d36bbb
2022-10-07 17:27:08 +00:00
Auke Booij
4c016b4c42 Clean up pg-client-hs
- Remove a few unnecessary helper functions
- Delete kind annotations
- Bring GHC warnings and language extensions more in line with those of the `graphql-engine` library
- Constrain unconstrained dependency on `hasql-pool`

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6251
GitOrigin-RevId: 10c2530f007f70cf1464cec36566ee2264589881
2022-10-07 11:56:55 +00:00
Brandon Simmons
823babe885 server: switch to ghc 9.2 (2nd try)
## Migrating, for server devs

You will need the fork of 9.2.4 that we're using (for now):

```
ghcup -c -n install ghc --force -u "https://storage.googleapis.com/graphql-engine-cdn.hasura.io/ghc-bindists/ghc-x86_64-deb10-linux-9.2.4-hasura-fix.tar.xz" 9.2.4
```

or for m1 mac:

```
ghcup -c -n install ghc --force -u  "https://storage.googleapis.com/graphql-engine-cdn.hasura.io/ghc-bindists/ghc-arm64-apple-darwin-9.2.4-hasura-fix.tar.xz"
```

Samir is working on a nix build for nix folx

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6154
GitOrigin-RevId: 6716e3f2ee19f0281c8ad25383a1241fc362d616
2022-10-06 09:09:01 +00:00