Commit Graph

221 Commits

Author SHA1 Message Date
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
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
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
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
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
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
paritosh-08
ab71adc3a0 server, pro: event trigger auto cleanup (increment 3)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5823
Co-authored-by: pranshi06 <85474619+pranshi06@users.noreply.github.com>
Co-authored-by: Puru Gupta <32328846+purugupta99@users.noreply.github.com>
Co-authored-by: Karthikeyan Chinnakonda <15602904+codingkarthik@users.noreply.github.com>
GitOrigin-RevId: 3d4af905d5df4c05107ad46ef29f4c0a567ff754
2022-09-15 11:46:22 +00:00
David Overton
cbddcce26b Data connector cache invalidations
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5820
GitOrigin-RevId: ded80e378901cc0c0ca12eb67d9264756a8d6ff4
2022-09-14 13:00:47 +00:00
paritosh-08
db710d38b7 server, pro: event trigger auto cleanup (increment 2)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5746
Co-authored-by: pranshi06 <85474619+pranshi06@users.noreply.github.com>
Co-authored-by: Puru Gupta <32328846+purugupta99@users.noreply.github.com>
Co-authored-by: Karthikeyan Chinnakonda <15602904+codingkarthik@users.noreply.github.com>
GitOrigin-RevId: f4e5e06389ca57bdb5f7771f459c07418787111d
2022-09-13 08:34:52 +00:00
Antoine Leblanc
40db3d7eab Resolve source customization at schema cache building time.
### Description

This PR attempts to fix several issues with source customization as it relates to remote relationships. There were several issues regarding casing: at the relationship border, we didn't properly set the target source's case, we didn't have access to the list of supported features to decide whether the feature was allowed or not, and we didn't have access to the global default.

However, all of that information is available when we build the schema cache, as we do resolve the case of some elements such as function names: we can therefore resolve source information at the same time, and simplify both the root of the schema and the remote relationship border.

To do this, this PR introduces a new type, `ResolvedSourceCustomization`, to be used in the Schema Cache, as opposed to the metadata's `SourceCustomization`, following a pattern established by a lot of other types.

### Remaining work and open questions

One major point of confusion: it seems to me that we didn't set the case at all across remote relationships, which would suggest we would use the case of the LHS source across the subset of the RHS one that is accessible through the remote relationship, which would in turn "corrupt" the parser cache and might result in the wrong case being used for that source later on. Is that assesment correct, and was I right to fix it?

Another one is that we seem not to be using the local case of the RHS to name the field in an object relationship; unless I'm mistaken we only use it for array relationships? Is that intentional?

This PR is also missing tests that would show-case the difference, and a changelog entry. To my knowledge, all the tests of this feature are in the python test suite; this could be the opportunity to move them to the hspec suite, but this might be a considerable amount of work?

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5619
GitOrigin-RevId: 51a81b713a74575e82d9f96b51633f158ce3a47b
2022-09-12 16:07:26 +00:00
paritosh-08
d6970173c1 server, pro: event trigger auto cleanup (increment 1)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5612
Co-authored-by: pranshi06 <85474619+pranshi06@users.noreply.github.com>
Co-authored-by: Puru Gupta <32328846+purugupta99@users.noreply.github.com>
Co-authored-by: Karthikeyan Chinnakonda <15602904+codingkarthik@users.noreply.github.com>
GitOrigin-RevId: 6ce69ebb555e49439ae2b01fe42e39415ac53966
2022-09-09 08:28:31 +00:00
Auke Booij
c5d2b9bb18 Move parallelization from buildSchemaCacheRule to buildGQLContext
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5819
GitOrigin-RevId: bed79c598e5576f900e64419054b9b0882c605dd
2022-09-08 18:04:49 +00:00
David Overton
0b7353657c Push capabilities resolution code into BackendMetadata type class
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5738
GitOrigin-RevId: 5c8e8232b8db67584d3f0a03987b97f0cce53a97
2022-09-05 02:44:10 +00:00
awjchen
78cf1d544e server/pro: enable health check on data sources and report via logging and API
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4868
Co-authored-by: Rakesh Emmadi <12475069+rakeshkky@users.noreply.github.com>
Co-authored-by: Sean Park-Ross <94021366+seanparkross@users.noreply.github.com>
GitOrigin-RevId: b8d43e3f7d977c4bb37b8506ac87ce7bf289d542
2022-09-02 06:34:29 +00:00
David Overton
00aeb57adf Add data connector agent capabilities schema cache
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5689
GitOrigin-RevId: 86e18e92106e5e5b6543f17fc21e2ab65bdd69ed
2022-09-01 05:29:04 +00:00
Solomon
033b00d091 Replace BackendSourceMetadata type alias with a newtype
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5654
GitOrigin-RevId: 89697c8838a7cd6d6de7a2cced5c651bac63fc63
2022-08-29 00:59:18 +00:00
Philip Lykke Carlsen
0e921ca9a5 Define IR types for AggregationPredicates.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5258
GitOrigin-RevId: 172b9de69f44635c5700b3f75ce17304ec56c18a
2022-08-19 15:41:47 +00:00
Antoine Leblanc
3b7cfcd10a move strictness where it is needed
### Description

This PR moves some strictness annotations to a concrete use site, rather than putting `seq` in an helper function.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5436
GitOrigin-RevId: 1f279e05333ab80167ad2e18d09b8792eddc52c3
2022-08-11 07:53:44 +00:00
Tom Harding
178e452b6b Use witherable, remove catMaybes/mapMaybe
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5250
GitOrigin-RevId: 5f0a582b3a853d2dbcce20e88c17970290625fc6
2022-07-29 14:53:16 +00:00
Lyndon Maydwell
607497f82f Increase timeout for DC Agents
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5172
GitOrigin-RevId: 1d286447901e34a77518e062315b80f4f775eebf
2022-07-27 07:19:44 +00:00
Samir Talwar
c980af1b8f Move MkTypename and NamingCase into their own modules.
This moves `MkTypename` and `NamingCase` into their own modules, with the intent of reducing the scope of the schema parsers code, and trying to reduce imports of large modules when small ones will do.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4978
GitOrigin-RevId: 19541257fe010035390f6183a4eaa37bae0d3ca1
2022-07-12 14:01:28 +00:00
Daniel Chambers
728fcd011e Add Data Connector agent request logging, improve error messages, and add tracing support [GDW-83]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4987
GitOrigin-RevId: 71570d1656e0cd5be49c179740be81804a3ad05a
2022-07-11 08:05:40 +00:00
Karthikeyan Chinnakonda
edef724879 server: Create SQL trigger if not found while reloading metadata
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4716
GitOrigin-RevId: 5303477aa19257535e682e6cbd3e79d49aba1fa2
2022-07-04 10:10:54 +00:00
paritosh-08
3d001fedb8 server: respect experimental flag for naming convention of table column names
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4845
GitOrigin-RevId: f1347ec64ff883d1dcc87e588a063557d37cb968
2022-06-30 05:57:18 +00:00
awjchen
1db8ca4700 server: build event triggers earlier in the schema cache
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4597
GitOrigin-RevId: 2eb1d16fe1790fd4092c608d62beefb467e546f4
2022-06-27 00:37:57 +00:00
Antoine Leblanc
609cab89e6 Backend-agnostic custom scalars
### Description

This small clean-up PR makes one further step towards backend-agnostic actions: it makes all the code parsing custom types backend agnostic. Surprisingly, this could be done *without* the need to finish generalizing the column parser. The remaining sore point is async queries, that still target Postgres explicitly.

In theory, this is enough to start allowing non-Postgres scalars in custom types. In practice, however:
- no other backend exposes scalars in a way that would allow users to do that as of this PR;
- we currently have no strategy to avoid / detect scalar collisions across backends.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4691
GitOrigin-RevId: bfe63fb131e306663d4406697ce23c02736566c5
2022-06-22 13:14:40 +00:00
Antoine Leblanc
e3c2bf53a5 Move, document, and prune action types and custom types types.
### Description

This PR is a first step in a series of cleanups of action relationships. This first step does not contain any behavioral change, and it simply reorganizes / prunes / rearranges / documents the code. Mainly:
- it divides some files in RQL.Types between metadata types, schema cache types, execution types;
- it renames some types for consistency;
- it minimizes exports and prunes unnecessary types;
- it moves some types in places where they make more sense;
- it replaces uses of `DMap BackendTag` with `BackendMap`.

Most of the "movement" within files re-organizes declarations in a "top-down" fashion, by moving all TH splices to the end of the file, which avoids order or declarations mattering.

### Optional list types

One main type change this PR makes is a replacement of variant list types in `CustomTypes.hs`; we had `Maybe [a]`, or sometimes `Maybe (NonEmpty a)`. This PR harmonizes all of them to `[a]`, as most of the code would use them as such, by doing `fromMaybe []` or `maybe [] toList`.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4613
GitOrigin-RevId: bc624e10df587eba862ff27a5e8021b32d0d78a2
2022-06-07 15:45:00 +00:00
paritosh-08
e053ffe8ec server: hotfix for default naming convention issue
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4585
GitOrigin-RevId: 8e9e7eef0017e9c634167b08c4d2a61ee7ac1fdf
2022-05-31 09:09:04 +00:00
paritosh-08
fd30fb343b server: naming conventions for auto generated fields
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3982
Co-authored-by: Brandon Simmons <210815+jberryman@users.noreply.github.com>
GitOrigin-RevId: f90b2e8f394e7bd69780f003d2d980475f104f42
2022-05-26 11:55:29 +00:00
Auke Booij
cb67ad5e95 server: Clean up some deriving statements
By generalizing the instances, they can be written as attached instance derivations, rather than standalone ones.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4518
GitOrigin-RevId: 7a387911cf6ad46fe6acd36648275d6c2c68ffe3
2022-05-24 07:22:55 +00:00
Antoine Leblanc
04d8f068b6 Remove explicit case on the backend tag in Cache
### Description

As part of the cache building process, we create / update / migrate the catalog that each DB uses as a place to store event trigger information. The function that decides how this should be done was doing an explicit `case ... of` on the backend tag, instead of delegating to one of the backend classes. The downsides of this is that:
- it adds a "friction point" where the backend matters in the core of the engine, which is otherwise written to be almost entirely backend-agnostic
- it creates imports from deep in the engine to the `Backends`, which we try to restrict to a very small set of clearly identified files (the `Instances` files)
- it is currently implemented using a "catch all" default case, which might not always be correct for new backends

This PR makes the catalog updating process a part of `BackendMetadata`, and cleans the corresponding schema cache code.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4457
GitOrigin-RevId: 592f0eaa97a7c38f4e6d4400e1d2353aab12c97e
2022-05-05 13:44:56 +00:00
Daniel Chambers
970d69edd4 Added BackendConfig to allow sources to share configuration of Data Connectors [GDW-78]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4271
GitOrigin-RevId: 6990010bff622a424ca0bb9d24579bf121819fb0
2022-04-29 02:14:10 +00:00
Naveen Naidu
222419527f server: refactor MaintenanceMode datatype
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4298
GitOrigin-RevId: 0b88d040bd4b24c61c4ae91e18dc6edf67b3672e
2022-04-28 20:56:11 +00:00
Antoine Leblanc
3cbcbd9291 Remove RQL/Types.hs
## Description

This PR removes `RQL.Types`, which was now only re-exporting a bunch of unrelated modules.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4363
GitOrigin-RevId: 894f29a19bff70b3dad8abc5d9858434d5065417
2022-04-27 13:58:47 +00:00
Antoine Leblanc
9eca586655 Remove HasSystemDefined.
### Description

`HasSystemDefined` is defined in `RQL.Types`, but only used in one place, `LegacyCatalog`, to avoid passing a boolean around. It is easily replaced by an ad-hoc `ReaderT`.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4337
GitOrigin-RevId: 649d758bb2b18b39533429dda5ab71afde62fb53
2022-04-22 16:02:06 +00:00
Antoine Leblanc
ea32b8bf82 Move HasServerConfigCtx to Hasura.Server.Types.
### Description

Small PR that moves code out of `RQL.Types.hs`. Specifically, it moves `HasServerConfigCtx` to where `ServerConfigCtx` is defined. This removes code from `RQL.Types`, makes the dependency on `Server.Types` more explicit, and will make some further cleanups easier.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4336
GitOrigin-RevId: 95bb3467d741763892c4e68a38760497157ba1aa
2022-04-22 14:51:00 +00:00
paritosh-08
7f4565fad2 server: validate top level fragments in GQL query
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4299
GitOrigin-RevId: 70925779d41c5a9fe66577b941c674577a4a9a13
2022-04-20 07:33:21 +00:00
Philip Lykke Carlsen
fb5f016b1c Remove class IsPerm
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4040
GitOrigin-RevId: 2f022bab90ab06486358fde25f68be8ec0092d27
2022-04-06 12:48:37 +00:00
Antoine Leblanc
5920134dcb Decouple Analyse and OpenAPI from remote schema introspection and internal execution details.
### Motivation

#2338 introduced a way to validate REST queries against the metadata after a change, to properly report any inconsistency that would emerge from a change in the underlying structure of our schema. However, the way this was done was quite complex and error-prone. Namely: we would use the generated schema parsers to statically execute an introspection query, similar to the one we use for remote schemas, then parse the resulting bytestring as it were coming from a remote schema.

This led to several issues: the code was using remote schema primitives, and was associated with remote schema code, despite being unrelated, which led to absurd situations like creating fake `Variable`s whose type was also their name. A lot of the code had to deal with the fact that we might fail to re-parse our own schema. Additionally, some of it was dead code, that for some reason GHC did not warn about? But more fundamentally, this architecture decision creates a dependency between unrelated pieces of the engine: modifying the internal processing of root fields or the introspection of remote schemas now risks impacting the unrelated `OpenAPI` feature.

### Description

This PR decouples that process from the remote schema introspection logic and from the execution engine by making `Analyse` and `OpenAPI` work on the generic `G.SchemaIntrospection` instead. To accomplish this, it:
- adds `GraphQL.Parser.Schema.Convert`, to convert from our "live" schema back to a flat `SchemaIntrospection`
- persists in the schema cache the `admin` introspection generated when building the schema, and uses it both for validation and for generating the `OpenAPI`.

### Known issues and limitations

This adds a bit of memory pressure to the engine, as we persist the entire schema in the schema cache. This might be acceptable in the short-term, but we have several potential ideas going forward should this be a problem:
- cache the result of `Analyze`: when it becomes possible to build the `OpenAPI` purely with the result of `Analyze` without any additional schema information, then we could cache that instead, reducing the footprint
- caching the `OpenAPI`: if it doesn't need to change every time the endpoint is queried, then it should be possible to cache the entire `OpenAPI` object instead of the schema
- cache a copy of the `FieldParsers` used to generate the schema: as those are persisted through the GraphQL `Context`, and are the only input required to generate the `Schema`, making them accessible in the schema cache would allow us to have the exact same feature with no additional memory cost, at the price of a slightly slower and more complicated process (need to rebuild the `Schema` every time we query the OpenAPI endpoint)
- cache nothing at all, and rebuild the admin schema from scratch every time.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3962
Co-authored-by: paritosh-08 <85472423+paritosh-08@users.noreply.github.com>
GitOrigin-RevId: a8b9808170b231fdf6787983b4a9ed286cde27e0
2022-03-22 07:37:49 +00:00
Karthikeyan Chinnakonda
a2d4724ae4 server: optimization of recreating event triggers only when needed
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3980
GitOrigin-RevId: ac882489d125436423315ee0e055198e96d0998c
2022-03-15 13:01:36 +00:00
Antoine Leblanc
74513e351f Use an enum for EndpointMethod and fix incorrect response aggregation.
### Description

This small PR improves the representation of an endpoint method from `Text` to an enum of the supported methods. Additionally, it cleans some of the instances defined on surrounding types (such as Postgres-specific instances on Endpoint types).

Due to a name conflict, this makes `RQL.Types.Endpoint` impossible to re-export from `RQL.Types`, which in turn forces several other modules to import it explicitly, which I think is fine since we want to ultimately get rid of `RQL.Types`.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3965
GitOrigin-RevId: 33869007d0d818ddf486fb61d1f6099f9dad7570
2022-03-13 07:41:02 +00:00
Brandon Simmons
9a96e7d165 server: parallelize buildGQLContext to improve replace_metadata perfo…
…rmance

It makes sense to try to utilize multiple threads for metadata
operations since we expect them to come one at a time (and likely at
lower load periods anyway).

As noted, although we build roles in parallel now, the admin role is
still a bottleneck. For replace_metadata on huge_schema, on my machine
I get:

  BEFORE: 22.7 sec
   AFTER: 13.5 sec

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3911
GitOrigin-RevId: 4d4ee6ac8b5506603e70e4fc666a3aacc054d493
2022-03-09 02:27:42 +00:00
Rakesh Emmadi
aa19f1e0d0 server/postgres: improve fetching tables' and functions' metadata (from database)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3778
GitOrigin-RevId: 13bb97bdb7afad265db899f368c74d9f240b214a
2022-03-08 13:03:14 +00:00
paritosh-08
0775c00b0d server: add validation for query collections
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3658
GitOrigin-RevId: 3c644da15c92cac16356985d0fe0c6adb7001862
2022-03-08 09:49:18 +00:00
Antoine Leblanc
f96b889401 Replace all occurrences of mapMaybe id by catMaybes.
### Description

Several libraries define `catMaybes` as `mapMaybe id`. We had it defined in `Data.HashMap.Strict.Extended` already. This small PR also defines it in `Extended` modules for other containers and replaces every occurrence of `mapMaybe id` accordingly.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3884
GitOrigin-RevId: d222a2ca2f4eb9b725b20450a62a626d3886dbf4
2022-03-03 20:13:10 +00:00
Karthikeyan Chinnakonda
a3e6b1c741 server/mssql: add support for creating event triggers (incremental PR #2)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2634
Co-authored-by: Naveen Naidu <30195193+Naveenaidu@users.noreply.github.com>
GitOrigin-RevId: 29567fa336c22d1812dfcfa6294f54e74a741f0c
2022-03-03 09:53:49 +00:00
Karthikeyan Chinnakonda
bea650b3e0 server/mssql: source catalog initialization for event triggers (Incremental PR - I)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2505
Co-authored-by: Naveen Naidu <30195193+Naveenaidu@users.noreply.github.com>
GitOrigin-RevId: 56681f90cfbfcf2f99c27f08c01d32790bd03c4d
2022-02-24 08:14:10 +00:00
Auke Booij
f026d44438 Role-invariant schema constructors
We build the GraphQL schema by combining building blocks such as `tableSelectionSet` and `columnParser`. These building blocks individually build `{InputFields,Field,}Parser` objects. Those object specify the valid GraphQL schema.

Since the GraphQL schema is role-dependent, at some point we need to know what fragment of the GraphQL schema a specific role is allowed to access, and this is stored in `{Sel,Upd,Ins,Del}PermInfo` objects.

We have passed around these permission objects as function arguments to the schema building blocks since we first started dealing with permissions during the PDV refactor - see hasura/graphql-engine@5168b99e46 in hasura/graphql-engine#4111. This means that, for instance, `tableSelectionSet` has as its type:
```haskell
tableSelectionSet ::
  forall b r m n.
  MonadBuildSchema b r m n =>
  SourceName ->
  TableInfo b ->
  SelPermInfo b ->
  m (Parser 'Output n (AnnotatedFields b))
```

There are three reasons to change this.

1. We often pass a `Maybe (xPermInfo b)` instead of a proper `xPermInfo b`, and it's not clear what the intended semantics of this is. Some potential improvements on the data types involved are discussed in issue hasura/graphql-engine-mono#3125.
2. In most cases we also already pass a `TableInfo b`, and together with the `MonadRole` that is usually also in scope, this means that we could look up the required permissions regardless: so passing the permissions explicitly undermines the "single source of truth" principle. Breaking this principle also makes the code more difficult to read.
3. We are working towards role-based parsers (see hasura/graphql-engine-mono#2711), where the `{InputFields,Field,}Parser` objects are constructed in a role-invariant way, so that we have a single object that can be used for all roles. In particular, this means that the schema building blocks _need_ to be constructed in a role-invariant way. While this PR doesn't accomplish that, it does reduce the amount of role-specific arguments being passed, thus fixing hasura/graphql-engine-mono#3068.

Concretely, this PR simply drops the `xPermInfo b` argument from almost all schema building blocks. Instead these objects are looked up from the `TableInfo b` as-needed. The resulting code is considerably simpler and shorter.

One way to interpret this change is as follows. Before this PR, we figured out permissions at the top-level in `Hasura.GraphQL.Schema`, passing down the obtained `xPermInfo` objects as required. After this PR, we have a bottom-up approach where the schema building blocks themselves decide whether they want to be included for a particular role.

So this moves some permission logic out of `Hasura.GraphQL.Schema`, which is very complex.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3608
GitOrigin-RevId: 51a744f34ec7d57bc8077667ae7f9cb9c4f6c962
2022-02-17 08:17:17 +00:00
paritosh-08
4d2a5dba51 server: fix multiple calls to database on startup
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3569
GitOrigin-RevId: 820d56a7af7faa05292ef65734d5d40fe3dd4641
2022-02-09 05:14:29 +00:00
Swann Moreau
8bd34b4a51 server, pro: add support for per-role allowlists
spec: https://github.com/hasura/graphql-engine-mono/pull/2278

Briefly:
- extend metadata so that allowlist entries get a new scope field
- update `add_collection_to_allowlist` to accept this new scope field,
  and adds `update_scope_of_collection_in_allowlist` to change the scope
- scope can be global or role-based; a collection is available for every
  role if it is global, and available to every listed role if it is role-based
- graphql-engine-oss is aware of role-based allowlist metadata; collections
  with non-global scope are treated as if they weren't in the allowlist

To run the tests:
- `cabal run graphql-engine-tests -- unit --match Allowlist`
- py-tests against pro:
  - launch `graphql-engine-pro` with `HASURA_GRAPHQL_ADMIN_SECRET` and `HASURA_GRAPHQL_ENABLE_ALLOWLIST`
  - `pytest test_allowlist_queries.py --hge-urls=... --pg-urls=... --hge-key=... --test-allowlist-queries --pro-tests`

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2477
Co-authored-by: Anon Ray <616387+ecthiender@users.noreply.github.com>
Co-authored-by: Robert <132113+robx@users.noreply.github.com>
GitOrigin-RevId: 01f8026fbe59d8701e2de30986511a452fce1a99
2022-02-08 16:54:49 +00:00
paritosh-08
b75706dd12 server: validate REST endpoint queries after metadata change
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2338
Co-authored-by: Sameer Kolhar <6604943+kolharsam@users.noreply.github.com>
GitOrigin-RevId: 9cd6bb940ba74fe41bdf2db3c4f35e89c4fb0577
2022-02-08 04:47:52 +00:00
Antoine Leblanc
aaadd2c81f Build schema cache for relationships from remote schemas
## Description

This PR is a subset of #3069, that does roughly that #3031 was aiming to do: add the schema cache building phase for relationships from remote servers. This PR does not change any of the code that *uses* remote relationships, meaning we ignore the added schema cache information. It also contains dependency-tracking code, which was originally missing from #3031; in turn, this pulls some of the metadata API as well, since we identify remote relationships by how they were created.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3540
GitOrigin-RevId: ed962b6d07fd4adbf0a71e0d79736a4e8b422fea
2022-02-03 18:59:32 +00:00
paritosh-08
40678855d0 server: add support for nested object type in action
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2788
Co-authored-by: David Overton <7734777+dmoverton@users.noreply.github.com>
GitOrigin-RevId: f8ed9741e95b6864a48af7db338f3f619617483a
2021-12-15 23:52:43 +00:00
Naveen Naidu
3773ba98b0 multitenant: support for starting multitenant in read only mode
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2993
Co-authored-by: Anon Ray <616387+ecthiender@users.noreply.github.com>
GitOrigin-RevId: e598d340d81aa96a85bd1ec043f9b7ed847934ef
2021-12-08 06:27:49 +00:00
Auke Booij
caf9957aca Remove Unique from Definition
GraphQL types can refer to each other in a circular way. The PDV framework used to use values of type `Unique` to recognize two fragments of GraphQL schema as being the same instance. Internally, this is based on `Data.Unique` from the `base` package, which simply increases a counter on every creation of a `Unique` object.

**NB**: The `Unique` values are _not_ used for knot tying the schema combinators themselves (i.e. `Parser`s). The knot tying for `Parser`s is purely based on keys provided to `memoizeOn`. The `Unique` values are _only_ used to recognize two pieces of GraphQL _schema_ as being identical. Originally, the idea was that this would help us with a perfectly correct identification of GraphQL types. But this fully correct equality checking of GraphQL types was never implemented, and does not seem to be necessary to prevent bugs.

Specifically, these `Unique` values are stored as part of `data Definition a`, which specifies a part of our internal abstract syntax tree for the GraphQL types that we expose. The `Unique` values get initialized by the `SchemaT` effect.

In #2894 and #2895, we are experimenting with how (parts of) the GraphQL types can be hidden behind certain permission predicates. This would allow a single GraphQL schema in memory to serve all roles, implementing #2711. The permission predicates get evaluated at query parsing time when we know what role is doing a certain request, thus outputting the correct GraphQL types for that role.

If the approach of #2895 is followed, then the `Definition` objects, and thus the `Unique` values, would be hidden behind the permission predicates. Since the permission predicates are evaluated only after the schema is already supposed to be built, this means that the permission predicates would prevent us from initializing the `Unique` values, rendering them useless.

The simplest remedy to this is to remove our usage of `Unique` altogether from the GraphQL schema and schema combinators. It doesn't serve a functional purpose, doesn't prevent bugs, and requires extra bookkeeping.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2980
GitOrigin-RevId: 50d3f9e0b9fbf578ac49c8fc773ba64a94b1f43d
2021-12-01 16:21:35 +00:00
Antoine Leblanc
90d3192df2 Unified remote relationship metadata
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2903
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 11fd6efe8cea246471e525cfb5bad66fa53ccaf9
2021-12-01 04:54:30 +00:00
Naveen Naidu
5cd6c5e43d multitenant: support for event disabling
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2900
GitOrigin-RevId: b2844fa433cfd8f8a29b7e98c6ec44773fd44a57
2021-11-30 12:32:26 +00:00
Karthikeyan Chinnakonda
5d1733519c server: provide option to recreate event triggers of specific or all sources in reload_metadata
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2723
GitOrigin-RevId: 5f18021f4892632c1823543595a26ec7f3d8bc32
2021-11-10 14:35:21 +00:00
Karthikeyan Chinnakonda
adb20d1d7c server: log DB locking queries during source catalog migration
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2676
GitOrigin-RevId: f01574a30d3a6bf95467ce69bb8b5e69ce4cc057
2021-11-09 14:22:44 +00:00
Karthikeyan Chinnakonda
04527bca4f server:don't recreate event triggers unnecessarily when the metadata is reloaded
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2740
GitOrigin-RevId: 4888e2f3a69a5eb72440ca50da0b8cd5e3b2b29e
2021-11-03 01:20:39 +00:00
David Overton
aac64f2c81 Source typename customization (close graphql-engine#6974)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/1616
GitOrigin-RevId: f7eefd2367929209aa77895ea585e96a99a78d47
2021-10-29 14:43:14 +00:00
Solomon Bothwell
ce052f0b1b Move Request Transform into the Action Definition
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2717
GitOrigin-RevId: 7c17fa41e5df2cfbc49e0ce2a1f78b3627de7051
2021-10-29 04:13:29 +00:00
Robert
71af68e9e5 server: drop HasVersion implicit parameter (closes #2236)
The only real use was for the dubious multitenant option
--consoleAssetsVersion, which actually overrode not just
the assets version. I.e., as far as I can tell, if you pass
--consoleAssetsVersion to multitenant, that version will
also make it into e.g. HTTP client user agent headers as
the proper graphql-engine version.

I'm dropping that option, since it seems unused in production
and I don't want to go to the effort of fixing it, but am happy
to look into that if folks feels strongly that it should be
kept.

(Reason for attacking this is that I was looking into http
client things around blacklisting, and the versioning thing
is a bit painful around http client headers.)

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2458
GitOrigin-RevId: a02b05557124bdba9f65e96b3aa2746aeee03f4a
2021-10-13 16:39:58 +00:00
Karthikeyan Chinnakonda
64e2201179 server: enable inherited roles by default
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2325
Co-authored-by: Nicolas Beaussart <7281023+beaussan@users.noreply.github.com>
GitOrigin-RevId: 8ad6fe25a3788892128c1d56b8fa0e8feed2caca
2021-10-05 12:29:32 +00:00
Sameer Kolhar
4ca2c7554c server: support user comments for trackable functions
https://github.com/hasura/graphql-engine-mono/pull/2290

GitOrigin-RevId: 3d7cf89b7e1d545475bad44ccc233b6f11145a01
2021-09-24 09:19:40 +00:00
Robert
11a454c2d6 server, pro: actually reformat the code-base using ormolu
This commit applies ormolu to the whole Haskell code base by running `make format`.

For in-flight branches, simply merging changes from `main` will result in merge conflicts.
To avoid this, update your branch using the following instructions. Replace `<format-commit>`
by the hash of *this* commit.

$ git checkout my-feature-branch
$ git merge <format-commit>^    # and resolve conflicts normally
$ make format
$ git commit -a -m "reformat with ormolu"
$ git merge -s ours post-ormolu

https://github.com/hasura/graphql-engine-mono/pull/2404

GitOrigin-RevId: 75049f5c12f430c615eafb4c6b8e83e371e01c8e
2021-09-23 22:57:37 +00:00
Naveen Naidu
3d95c67748 server/query-tags: implement new metadata specification and API
https://github.com/hasura/graphql-engine-mono/pull/2203

GitOrigin-RevId: 6169fcce0c6dccaec055bf8e723e9aa7c19a7f0c
2021-09-23 12:38:56 +00:00
Karthikeyan Chinnakonda
5f79b5f102 server: generalize the event triggers codepath for all backends
https://github.com/hasura/graphql-engine-mono/pull/2189

Co-authored-by: hasura-bot <30118761+hasura-bot@users.noreply.github.com>
Co-authored-by: Martin Mark <74692114+martin-hasura@users.noreply.github.com>
Co-authored-by: Vishnu Bharathi <4211715+scriptnull@users.noreply.github.com>
Co-authored-by: Sameer Kolhar <6604943+kolharsam@users.noreply.github.com>
Co-authored-by: Antoine Leblanc <1618949+nicuveo@users.noreply.github.com>
Co-authored-by: Matt Hardman <28978422+mattshardman@users.noreply.github.com>
Co-authored-by: Vijay Prasanna <11921040+vijayprasanna13@users.noreply.github.com>
Co-authored-by: Divi <32202683+imperfect-fourth@users.noreply.github.com>
GitOrigin-RevId: 97c71571656c6e0c57d06f2d38193833180901c0
2021-09-20 07:35:49 +00:00
Solomon Bothwell
af5ff07614 Request Transformations
https://github.com/hasura/graphql-engine-mono/pull/1984

Co-authored-by: jkachmar <8461423+jkachmar@users.noreply.github.com>
GitOrigin-RevId: 1767d6bdde48c156fe171b5a9b7e44d7f2eb4869
2021-09-16 11:03:57 +00:00
Robert
fe035125f4 server: drop LazyTxT newtype
This is a follow-up to #1959.

Today, I spent a while in review figuring out that a harmless PR change didn't do anything,
because it was moving from a `runLazy...` to something without the `Lazy`. So let's get
that source of confusion removed.

This should be a bit easier to review commit by commit, since some of the functions had
confusing names. (E.g. there was a misnamed `Migrate.Internal.runTx` before.)

The change should be a no-op.

https://github.com/hasura/graphql-engine-mono/pull/2335

GitOrigin-RevId: 0f284c4c0f814482d7827e7732a6d49e7735b302
2021-09-15 20:46:45 +00:00
Karthikeyan Chinnakonda
3247c8bd71 server: generalize event triggers - incremental PR 2
https://github.com/hasura/graphql-engine-mono/pull/2270

GitOrigin-RevId: d7644b25d3ee57ffa630de15ae692c1bfa03b4f6
2021-09-09 11:55:11 +00:00
Karthikeyan Chinnakonda
94f3ad041c server: generalize event triggers - incremental PR 1
https://github.com/hasura/graphql-engine-mono/pull/2269

GitOrigin-RevId: c4ea0cc41a1c66d418219cc1d41bf95656426733
2021-09-06 11:16:32 +00:00
Robert
c9481d4599 server: remove align, These(..) from Prelude
This removes the module re-exports of [Data.Align](https://hackage.haskell.org/package/semialign-1.2/docs/Data-Align.html) and [Data.These](https://hackage.haskell.org/package/these-1.1.1.1/docs/Data-These.html) from `Hasura.Prelude`. The reasoning being that they're not used widely and reasonably obscure, and that being explicit about the imports makes for an easier to understand codebase.

(I spent longer than I'd have liked earlier today figuring out where `align` in multitenant came from.
The right one not showing up on the first hoogle page doesn't help. Yes, better tool use could have
avoided that, but still...)

Do feel free to shoot this down, I won't insist on the change.

https://github.com/hasura/graphql-engine-mono/pull/2194

GitOrigin-RevId: 10f887b74538b17623bee6d6451c5aba11573fbd
2021-08-24 17:42:13 +00:00
Lyndon Maydwell
9a1c7d5ea0 server: Adding support for TLS allowlist by domain and service id (port)
https://github.com/hasura/graphql-engine-mono/pull/2153

Co-authored-by: Sameer Kolhar <6604943+kolharsam@users.noreply.github.com>
GitOrigin-RevId: 473a29af97236fc879ae178b0c2a6c31c1f12563
2021-08-24 07:37:25 +00:00
Karthikeyan Chinnakonda
06f5e4fb77 server: inherited roles for mutations, remote schemas, actions and custom functions
https://github.com/hasura/graphql-engine-mono/pull/1715

GitOrigin-RevId: 4818292cff8c3a5b264968e7032887a1e98b6f79
2021-08-09 10:21:05 +00:00
Lyndon Maydwell
d483109443 Revert "Disable TLS checks for actions services with self-signed certificates"
Reverts hasura/graphql-engine-mono#1595

https://github.com/hasura/graphql-engine-mono/pull/2036

GitOrigin-RevId: b32adde77b189c14eef0090866d58750d1481b50
2021-08-06 17:06:55 +00:00
Lyndon Maydwell
f6987ca4ff Disable TLS checks for actions services with self-signed certificates
https://github.com/hasura/graphql-engine-mono/pull/1595

GitOrigin-RevId: 3834e7d005bfaeaa7cc429c9d662d23b3d903f5c
2021-08-06 03:01:24 +00:00
David Overton
1abb1dee69 Remote Schema Customization take 2 using parser tranformations
https://github.com/hasura/graphql-engine-mono/pull/1740

GitOrigin-RevId: e807952058243a97f67cd9969fa434933a08652f
2021-07-30 11:33:59 +00:00
Auke Booij
3607f472b5 server: build graphql schema without arrows
https://github.com/hasura/graphql-engine-mono/pull/1827

GitOrigin-RevId: 8099ea708283647221973fbfc2c50e89d751efdb
2021-07-29 10:32:02 +00:00
Naveen Naidu
f49e13c890 server: SQL query tags for GQL operations (closes #400)
https://github.com/hasura/graphql-engine-mono/pull/1393

GitOrigin-RevId: f867c16d8281865dac38c91f7dfcbf5815de898c
2021-07-29 08:30:10 +00:00
Antoine Leblanc
49f40a44f0 Enforce that backends use the properly resolved environment variables.
## Description

This PR fixes an oversight in the implementation of the resolvers of different backends. To implement resolution from environment variables, both MSSQL and BigQuery were directly fetching the process' environment variables, instead of using the careful curated set we thread from main. It was working just fine on OSS, but is failing on Cloud.

This PR fixes this by adding an additional argument to `resolveSourceConfig`, to ensure that backends always use the correct set of variables.

https://github.com/hasura/graphql-engine-mono/pull/1891

GitOrigin-RevId: 58644cab7d041a8bf4235e2acfe9cf71533a92a1
2021-07-23 12:26:10 +00:00
Antoine Leblanc
0aaf006c25 server: add metadata for DB-DB remote joins
### Description

This PR is the first of several PRs meant to introduce Generalized Joins. In this first PR, we add non-breaking changes to the Metadata types for DB-to-DB remote joins. Note that we are currently rejecting the new remote join format in order to keep folks from breaking their metadata (in case of a downgrade). These issues will be tackled (and JSON changes reverted) in subsequent PRs.

This PR also changes the way we construct the schema cache, and breaks the way we process sources in two steps: we first resolve each source and construct a cache of their tables' raw info, then in a second step we build the source output. This is so that we have access to the target source's tables when building db-to-db relationships.

### Notes

- this PR contains a few minor cleanups of the schema
- it also fixes a bug in how we do renames in remote schema relationships
- it introduces cross-source schema dependencies

https://github.com/hasura/graphql-engine-mono/pull/1727

Co-authored-by: Evie Ciobanu <1017953+eviefp@users.noreply.github.com>
GitOrigin-RevId: f625473077bc5fff5d941b70e9a116192bc1eb22
2021-07-22 23:07:10 +00:00
Karthikeyan Chinnakonda
6bddaa7564 server: inherited roles improvements for select permissions only
https://github.com/hasura/graphql-engine-mono/pull/1539

GitOrigin-RevId: 7444973e9cc7e0598eeb1bd7951ad45dd37ec550
2021-07-16 21:19:58 +00:00
Vamshi Surabhi
96104ec1a8 Revert "remote schema typename customisation"
This reverts the remote schema type customisation and namespacing feature temporarily as we test for certain conditions.

GitOrigin-RevId: f8ee97233da4597f703970c3998664c03582d8e7
2021-06-10 09:57:16 +00:00
David Overton
4a69fdeb01 Dmoverton/5863 prefix namespacing
GitOrigin-RevId: 108e8b25e745cb4f74d143d316262049cef62b70
2021-06-09 22:42:05 +00:00
Karthikeyan Chinnakonda
cd509a0036 server: recreate event triggers while migrating source catalog
GitOrigin-RevId: 9a07fec31fcdbe6ef3b96bb61c95e0dd544e7f50
2021-06-07 13:58:16 +00:00
Karthikeyan Chinnakonda
f1f56ccf75 server: source initialization fix
GitOrigin-RevId: fcb94ca743a99ee3ffe30d40717bb1f0a13cf751
2021-05-31 13:54:59 +00:00
Swann Moreau
b825af9a96 server: fix error propagation in initCatalogForSource
GitOrigin-RevId: 679bca324dfa7728ebcff5862782f29f538bee20
2021-05-28 08:57:46 +00:00
Swann Moreau
d3611af58d server: lazy event catalog initialisation
event catalog:
- `hdb_catalog` is no longer automatically created
- catalog is initialised when the first event trigger is created
- catalog initialisation is done during the schema cache build, using `ArrowCache` so it is only run in response to a change to the set of event triggers

event queue:
- `processEventQueue` thread is prevented from starting when `HASURA_GRAPHQL_EVENTS_FETCH_INTERVAL=0`
- `processEventQueue` thread only processes sources for which at least one event trigger exists in some table in the source

Co-authored-by: Anon Ray <616387+ecthiender@users.noreply.github.com>
GitOrigin-RevId: 73f256465d62490cd2b59dcd074718679993d4fe
2021-05-25 06:51:03 +00:00
Abby Sassel
3ba5d1e540 server: include more detail in inconsistent metadata error messages (fix #6684)
GitOrigin-RevId: 1a0d8fa2b465320e9ab4ea43259d0e8d92364473
2021-05-19 05:02:53 +00:00
Antoine Leblanc
2152911e24 server: introduce Hasura.Base (take 2)
GitOrigin-RevId: 0dd10f1ccd338b1cf382ebff59b6ee7f209d39a1
2021-05-11 15:19:33 +00:00
Karthikeyan Chinnakonda
4702ba514a pro server: disable GraphQL schema introspection for specified roles
GitOrigin-RevId: 36ceb1852bc7779092cfb59c92035dd9635b2e3f
2021-05-05 12:26:23 +00:00
Antoine Leblanc
ba70ca427a server: switch to a sub-backend approach
GitOrigin-RevId: 660126d5f65620fb58a3ffcbed564e9e35f59938
2021-04-21 21:45:32 +00:00
Karthikeyan Chinnakonda
d09b00040f server: V2 maintenance mode fixes
GitOrigin-RevId: dcd69fb217a4e976523f1bc8e7b2693111091002
2021-04-21 10:56:13 +00:00
Sameer Kolhar
b274a2d240 server: disable caching for actions with forward client headers enabled
Co-authored-by: Lyndon Maydwell <92299+sordina@users.noreply.github.com>
Co-authored-by: Antoine Leblanc <1618949+nicuveo@users.noreply.github.com>
Co-authored-by: Abby Sassel <3883855+sassela@users.noreply.github.com>
Co-authored-by: hasura-bot <30118761+hasura-bot@users.noreply.github.com>
Co-authored-by: Rikin Kachhia <54616969+rikinsk@users.noreply.github.com>
Co-authored-by: Ikechukwu Eze <22247592+iykekings@users.noreply.github.com>
Co-authored-by: Aleksandra Sikora <9019397+beerose@users.noreply.github.com>
Co-authored-by: Rishichandra Wawhal <27274869+wawhal@users.noreply.github.com>
Co-authored-by: Naveen Naidu <30195193+Naveenaidu@users.noreply.github.com>
Co-authored-by: Vishnu Bharathi <4211715+scriptnull@users.noreply.github.com>
GitOrigin-RevId: c9a8be3cb607f7767e9d6791717106adf123e3a8
2021-04-13 07:01:34 +00:00
Lyndon Maydwell
c737ce992d Schema-Sync Improvements for Cloud, Pro, and OSS - Version Checking for Metadata (#738)
Modifying schema-sync implementation to use polling for OSS/Pro. Invalidations are now propagated via the `hdb_catalog.hdb_schema_notifications` table in OSS/Pro. Pattern followed is now a Listener/Processor split with Cloud listening for changes via a LISTEN/NOTIFY channel and OSS polling for resource version changes in the metadata table. See issue #460 for more details.

GitOrigin-RevId: 48434426df02e006f4ec328c0d5cd5b30183db25
2021-04-06 03:25:53 +00:00
Antoine Leblanc
9672cc9b32 sever: clean extension types
GitOrigin-RevId: 43f48f90dc96bec87b94a69ca1825511ec9b7507
2021-03-24 02:56:36 +00:00