Commit Graph

769 Commits

Author SHA1 Message Date
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
Philip Lykke Carlsen
135c56eaa3 Simplify getRolePermInfo
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4348
GitOrigin-RevId: a8973624ae3100e5ca12f7c05962d1442c226750
2022-04-27 12:17:15 +00:00
Antoine Leblanc
8b0b4e5c35 Remove all functions from RQL.Types.hs
## Description

This small PR moves all functions in `RQL.Types.hs` to better locations. Most `askX` functions are moved alongside the `unsafe` functions they use. Several other functions are moved closer to their call site. `MetadataM` is moved alongside `Metadata`. This PR also documents the `ask` functions.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4355
GitOrigin-RevId: 0498a7e8f98e7a94af911dd375cad84ace7ddffa
2022-04-26 15:13:57 +00:00
Karthikeyan Chinnakonda
2325755954 server: streaming subscriptions schema generation and tests (incremental PR - 3)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4259
Co-authored-by: Rikin Kachhia <54616969+rikinsk@users.noreply.github.com>
Co-authored-by: Brandon Simmons <210815+jberryman@users.noreply.github.com>
Co-authored-by: paritosh-08 <85472423+paritosh-08@users.noreply.github.com>
GitOrigin-RevId: 4d1b4ec3c01f3a839f4392d3b77950fc3ab30236
2022-04-22 19:54:11 +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
Philip Lykke Carlsen
9a557ceeee Split up module Hasura.Backend.Postgres.Translate.Select into sub-modules
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4334
GitOrigin-RevId: d083512f3c4e534a10e571eeab10308ad45cc7a0
2022-04-22 13:39:40 +00:00
Philip Lykke Carlsen
df36cdac09 Refactor insert mutations IR use of "default values"
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4316
GitOrigin-RevId: 91f80902a2dc2a782821033f455c70c4e96f0950
2022-04-21 16:34:04 +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
Vamshi Surabhi
1ca0cb9c74 Fixes remote relationships on actions
Fixes: https://github.com/hasura/graphql-engine/issues/8399. See [this comment](https://github.com/hasura/graphql-engine-mono/pull/4297/files#r853259983) for an explanation.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4297
Co-authored-by: Brandon Martin <40686+codedmart@users.noreply.github.com>
GitOrigin-RevId: accc85a77cb108224b1c78da709dc96d0e4e298d
2022-04-19 17:49:57 +00:00
Solomon
c945b2d391 Replaces litName splices with name quasiquotes
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4267
GitOrigin-RevId: 2d93c35a7e34dbada3b72aabcae5fc2858bbfc29
2022-04-18 19:44:04 +00:00
hasura-bot
22120a026c don't drop nested typed null fields in actions (fix #8237)
GITHUB_PR_NUMBER: 8238
GITHUB_PR_URL: https://github.com/hasura/graphql-engine/pull/8238

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4272
Co-authored-by: Jesse Jaara <294363+Huulivoide@users.noreply.github.com>
Co-authored-by: Lyndon Maydwell <92299+sordina@users.noreply.github.com>
GitOrigin-RevId: 810ec935a1e1c75a06a1ad1427dedb179eb60d5e
2022-04-18 09:59:16 +00:00
Sibi Prabakaran
74328156c5 Fix Decimal serialization for BigQuery backend
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4168
GitOrigin-RevId: 16072ce326ede22ba8be05f92fcfa0aaa2a7a644
2022-04-13 17:09:45 +00:00
paritosh-08
4e0a0a5804 server: add custom table name in EnumReference
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4177
GitOrigin-RevId: 569b4e450aabe11296b7a43fe4aca1883f221790
2022-04-13 10:08:21 +00:00
Naveen Naidu
d10b862b61 server: fix bugs in clear_metadata code path
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3927
Co-authored-by: Divi <32202683+imperfect-fourth@users.noreply.github.com>
Co-authored-by: Karthikeyan Chinnakonda <15602904+codingkarthik@users.noreply.github.com>
Co-authored-by: Vishnu Bharathi <4211715+scriptnull@users.noreply.github.com>
GitOrigin-RevId: 6f3457698029af94e9157c23b552ac2034f9c740
2022-04-11 11:25:13 +00:00
Solomon
e9436c5d97 Initial GDW Query Generation
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4039
GitOrigin-RevId: ac01773c390876cd41733c8ebf7199d2d445d921
2022-04-08 06:49:40 +00:00
Karthikeyan Chinnakonda
362aca9db3 server: streaming subscriptions execution (Incremental PR - 2)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4016
GitOrigin-RevId: 778300dd5ea094bc76b8f96c046313132863f832
2022-04-07 14:43:01 +00:00
Auke Booij
d6d5c55c13 Add more "conflicting types" checks
In hasura/graphql-engine@7547786b2b, we made the logic that does a specific correctness check on the GraphQL schema runnable _post_-startup. However, in order to error out as early as possible, we explicitly do it on startup anyway.

Unfortunately a few instances of that logic were forgotten: until now we only executed it for non-relay authenticated GraphQL schemas.

This re-implements the "conflicting types" check for both the Relay schema, and for the unauthenticated schemas.

One key point where it does _not_ re-implement it is in `buildFullestDBSchema`, which is a very sketchy method that builds a GraphQL schema that is _only_ used internally in order to mark parts of the schema as inconsistent. There are two reasons I do not add the check here:
- This logic should get replaced entirely - see hasura/graphql-engine-mono#3882.
- Having conflicting types in `buildFullestDBSchema` does not imply there is actually a user-facing issue. The only "conflicting types" which are problematic are the ones which result in illegal _user-facing_ GraphQL schemas. `buildFullestDBSchema` is _never_ user-facing.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3885
GitOrigin-RevId: 49517dcbf51bcd97a3890514ec5e47499f770f32
2022-04-05 20:13:19 +00:00
Auke Booij
dfd09159ec Fix JSON encoding issue (fix hasura/graphql-engine#7543 and hasura/graphql-engine#8200)
`encJFromAssocList` is broken since it does not appropriately escape the keys of the JSON dictionaries. Presumably it should.

This is a hotfix for a JSON encoding issue. Longer-term solutions are being discussed in hasura/graphql-engine-mono#3736.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4139
GitOrigin-RevId: 27afff319d268a4ec017c8eafd694cc17c2fd7f0
2022-04-05 19:11:30 +00:00
Karthikeyan Chinnakonda
b9b5c3dafe server: fix bug in rate limiting
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3904
Co-authored-by: Naveen Naidu <30195193+Naveenaidu@users.noreply.github.com>
GitOrigin-RevId: d78180b675955c6bb9c118f9839857380175093d
2022-04-05 07:19:21 +00:00
Antoine Leblanc
b4f7e96665 Rewrite GraphQL.Analysis
### Motivation

While we strive to write clear code, we have historically struggled at Hasura with having very different styles and standards across the codebase. There's been efforts to standardize our coding style, we have an official styleguide that isn't maintained as closely as it should... We still have some work in front of us.

However, in the last ~year or so, there's been a huge push towards incrementally improving the situation. As part of this we've been blocking PRs that don't add enough comments, or don't improve the files that they touch.

While looking at `Hasura.GraphQL.Analyse`, it became apparent that this file did not meet the engineering standards that I would expect to see addressed during a code review. Some ways in which I think it falls short:
- lack of documentation
- no clear distinction between public / internal components
- "unidiomatic" Haskell code (such as using `Either Result Error`)

While there's no problem with a file looking like this during development, those issues should have been caught at review time. The fact that they weren't indicates a problem in our process that we will need to address: code quality and maintainability is paramount, and we all need to do our part.

### Description

This PR rewrites all of `Hasura.GraphQL.Analyze`, and adapts `Hasura.Server.OpenAPI` accordingly where needed. I've attempted to clarify names and add documentation based on my understanding of the code, and to clean what was unused (such as field variables). I don't think this PR is good enough as is, and I welcome criticism where I got my comments wrong / am happy to help y'all add more.

This PR makes one small change in the way error messages are reported (and adjusts the corresponding test accordingly); each error message is now prefixed with the path within the selection set:
```
⚠️ $.test.foo.bar.baz.mizpelled: field 'mizpelled' not found in object 'Baz'
```

### Note

This PR is currently **on top of #3962**. You can preview the changes in isolation by [diffing the branches](https://github.com/hasura/graphql-engine-mono/compare/nicuveo/clean-rest-endpoint-inconsistency-check..nicuveo/rewrite-analysis).

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3963
Co-authored-by: paritosh-08 <85472423+paritosh-08@users.noreply.github.com>
GitOrigin-RevId: 5ec38e0e753f0c12096a350db0737658495e2f15
2022-04-04 05:54:59 +00:00
Rakesh Emmadi
546f4994b6 server/gardening: rename IR insert mutation types
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4116
GitOrigin-RevId: ca3dd951dff7ee840eb3787900fcc32ada7d8879
2022-04-01 06:44:08 +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
a13ed140e8 server: refactor the term "live query" to "subscription"
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4001
GitOrigin-RevId: 78a7ff5c88ac3751baa5e2b3ac6ee73b94c50051
2022-03-21 10:40:49 +00:00
jkachmar
647231b685 Yeet some default-extensions
Manually enables:
* EmptyCase
* ExistentialQuantification
* QuantifiedConstraints
* QuasiQuotes
* TemplateHaskell
* TypeFamilyDependencies

...in the following components:
* 'graphql-engine' library
* 'graphql-engine' 'src-test'
* 'graphql-engine' 'tests/integration'
* 'graphql-engine' tests-hspec'

Additionally, performs some light refactoring and documentation.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3991
GitOrigin-RevId: 514477d3466b01f60eca8935d0fef60dd0756838
2022-03-16 00:40:17 +00:00
Antoine Leblanc
f1ef8338ee Fix not detecting collisions between remote relationships for the unauthenticated context.
### Description

This very small PR fixes an error introduced in #3811, when changing the collision detection code: we were properly doing collision detection for remote schemas for the unauthenticated context, and also removing remote relationships... but then we were not using the result to build the schema.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3986
GitOrigin-RevId: 26a5553bf82574f2764fd594b0616dfea95a4757
2022-03-15 15:14:07 +00:00
Antoine Leblanc
376c7d48f1 Add remote relationships from remote schemas in schema parser generators
### Description

This PR extends the `RemoteSchema` parsers to also include remote relationships. This include a significant refactoring of the top level schema building blocks, since remote schemas can no longer be built in isolation: they have to be built within the same run of `MonadSchema` as the sources. It is originally taken from the changes in #3069 and was slightly adapted.

I highly recommend turning OFF whitespace in the Github UI for `Schema.hs`, since I've adjusted the indentation of two large functions.

### Warning

Given the lack of a feature flag, this PR technically **enables the feature**. While the metadata API is not plugged in, a savvy user could use `replace_metadata` to set a metadata that contains remote joins from remote schemas, and they would be enabled. Is this acceptable?

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3811
GitOrigin-RevId: a5b00f865cdb8890b0fc02b139c2ebd48929f138
2022-03-14 16:22:50 +00:00
David Overton
ac87eff905 Document ActionFieldsG
<!-- Thank you for ss in the Title above ^ -->

## Description ✍️
<!-- Please fill this se-->
<!-- Describe the changes from a user's perspective -->

Add some documentation on `ActionFieldG` type.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3945
GitOrigin-RevId: d9543ed7a8fe3ccfe9f5267c3a2ac71fb040f4db
2022-03-12 01:38:19 +00:00
Antoine Leblanc
effde675aa Clean RemoteJoin.Join by introducing RemoteJoin.Source
### Description

This PR cleans `processRemoteJoins` by splitting the code, introducing comments, and applied the same strategies than #3810 did. Most importantly, it introduces a new module `RemoteJoin.Source`, made to be very similar to `RemoteJoin.RemoteSchema`, that exposes the required tooling to make a join call to a source, which decluters `Join`. Furthermore, this PR uses the same "dependency injection" to make the core of `Join` free from IO: this opens the door to testing the join engine in the unit tests.

None of the functions were modified when moved from their old module to the new one, but there's no way to easily see this in a diff.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3894
GitOrigin-RevId: 1e7c43006f092326e061f9ba12674e207b628bef
2022-03-10 15:26:24 +00:00
Antoine Leblanc
80243a5c34 Remove MonadTableInfo and MonadRole.
### Description

This PR moves Hasura-specific schema functions from `Hasura.GraphQL.Parser.Class` into `Hasura.GraphQL.Schema.Common`. It also removes the two corresponding monad aliases, and consequently harmonizes several parts of the code to use the same common constraint.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3947
GitOrigin-RevId: 40985a7d86da97a311bd480f9a57cc18c350c2a8
2022-03-10 12:13:35 +00:00
Antoine Leblanc
b9ee669ee1 Improve remote joins collect
### Description

This PR improves the `Collect` module by re-ordering the functions to make clear what is public API and what is internal implementation. Furthermore, it makes use of `traverseOf` and `traverseFields` to reduce duplication. To do so, it also introduces a few more lenses in the rest of the codebase, and uses this opportunity to harmonize some structures that were not following our naming convention.

While the diff is massive, a lot of it is just code moving around; the file is now divided into separate sections:
- entry points: IR types for which we want to run the collection
- internal monadic structure
- internal traversals: functions that do nothing but drill down further
- actual transformations: the three cases where we do actually have work to do: selection sets on which we do want to insert join columns, extract remote relationships... those functions are left unchanged by this PR
- internal helpers

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3863
GitOrigin-RevId: f7cbecfae9eed9737b62acfa5848bfcf9d4651f6
2022-03-10 06:18:48 +00:00
Antoine Leblanc
85b8753fde Cleanup post #3810
### Description

#3810 was merged with comments still open; this small PR does a few minute clean-ups to address some remaining nits.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3941
GitOrigin-RevId: 3d15eb399828123640a73247b848bc4ddff02c38
2022-03-10 02:13:49 +00:00
Antoine Leblanc
553ecf628b Prevent impure errors with monadic map union
### Description

This very small PR introduces `unionWithM`, to allow hashmap union that might fail, and uses it to transform an `error` into a `throw500`. It also reorders `HashMap.Strict.Extended` to group all "union" functions together.

There is, however, a broader question of whether we should encourage the proliferation of such functions. If so, we might also want to consider:
- `mapWithKeyM`, to remove the `unsafeMkName` of `RemoteJoin.Collect`
- `forWithKey`, as a flipped version of `traverseWithKey`

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3917
GitOrigin-RevId: a488d5bf04a73878b9e42f27ede36199bb4c920a
2022-03-09 23:27:13 +00:00
Antoine Leblanc
6e1761f8f9 Enable remote joins from remote schemas in the execution engine.
### Description

This PR adds the ability to perform remote joins from remote schemas in the engine. To do so, we alter the definition of an `ExecutionStep` targeting a remote schema: the `ExecStepRemote` constructor now expects a `Maybe RemoteJoins`. This new argument is used when processing the execution step, in the transport layer (either `Transport.HTTP` or `Transport.WebSocket`).

For this `Maybe RemoteJoins` to be extracted from a parsed query, this PR also extends the `Execute.RemoteJoin.Collect` module, to implement "collection" from a selection set. Not only do those new functions extract the remote joins, but they also apply all necessary transformations to the selection sets (such as inserting the necessary "phantom" fields used as join keys).

Finally in `Execute.RemoteJoin.Join`, we make two changes. First, we now always look for nested remote joins, regardless of whether the join we just performed went to a source or a remote schema; and second we adapt our join tree logic according to the special cases that were added to deal with remote server edge cases.

Additionally, this PR refactors / cleans / documents `Execute.RemoteJoin.RemoteServer`. This is not required as part of this change and could be moved to a separate PR if needed (a similar cleanup of `Join` is done independently in #3894). It also introduces a draft of a new documentation page for this project, that will be refined in the release PR that ships the feature (either #3069 or a copy of it).

While this PR extends the engine, it doesn't plug such relationships in the schema, meaning that, as of this PR, the new code paths in `Join` are technically unreachable. Adding the corresponding schema code and, ultimately, enabling the metadata API will be done in subsequent PRs.

### Keeping track of concrete type names

The main change this PR makes to the existing `Join` code is to handle a new reserved field we sometimes use when targeting remote servers: the `__hasura_internal_typename` field. In short, a GraphQL selection set can sometimes "branch" based on the concrete "runtime type" of the object on which the selection happens:

```graphql
query {
  author(id: 53478) {
    ... on Writer {
      name
      articles {
        title
      }
    }
    ... on Artist {
      name
      articles {
        title
      }
    }
  }
}
```

If both of those `articles` are remote joins, we need to be able, when we get the answer, to differentiate between the two different cases. We do this by asking for `__typename`, to be able to decide if we're in the `Writer` or the `Artist` branch of the query.

To avoid further processing / customization of results, we only insert this `__hasura_internal_typename: __typename` field in the query in the case of unions of interfaces AND if we have the guarantee that we will processing the request as part of the remote joins "folding": that is, if there's any remote join in this branch in the tree. Otherwise, we don't insert the field, and we leave that part of the response untouched.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3810
GitOrigin-RevId: 89aaf16274d68e26ad3730b80c2d2fdc2896b96c
2022-03-09 03:18:22 +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
Daniel Chambers
f481507595 server: add metric for the metadata resource version
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3687
Co-authored-by: awjchen <13142944+awjchen@users.noreply.github.com>
GitOrigin-RevId: ae217690ee0371f6fc696fc2e18c72e087dcaff2
2022-03-08 23:00:27 +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
David Overton
2792f515d4 Traverse variables in action remote joins
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3864
GitOrigin-RevId: 0fb624260db46474056ee323638d9be7d074b3fc
2022-03-08 08:23:20 +00:00
Solomon
d67d4e2310 Webhook Transform Cleanup / Refactor
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3624
GitOrigin-RevId: 849e6dd70d6fe3d84056a485b20928ff813881d4
2022-03-08 00:43:08 +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
Auke Booij
2abe02c672 Fix #3635
In hasura/graphql-engine#5144, we noticed that having remote relationships in the schema is problematic for Relay. In particular, we don't support remote schemas in Relay at all, and because of this, remote relationships were also broken.

The fix was easy: when we're building the schema for Relay, whenever we encounter a remote relationship in our configuration, we simply skip building that field. The implementation was easy: (see hasura/graphql-engine#5145)
```diff
-    SFRemoteRelationship info -> pure $ mkRemoteRelationshipFld info
+    SFRemoteRelationship info ->
+      -- https://github.com/hasura/graphql-engine/issues/5144
+      if isRelay then [] else pure $ mkRemoteRelationshipFld info
```
A test case was added in that PR to prevent us from accidentally re-including remote relationships in the Relay schema. (However, it now looks like that test case does not function correctly.)

The above code was later refactored in #3037, making use of the `MaybeT` effect. However, this effect was not used correctly, so that the result of the check was ignored.

This fixes the code to use the `MaybeT` effect correctly.

CC @0x777 @rakeshkky

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3868
GitOrigin-RevId: e528303e01eacf60173cba1eec1898986cf12359
2022-03-03 15:01:25 +00:00
David Overton
1eb7fe5999 Nested action joins
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3613
GitOrigin-RevId: 95fdb317a1052bdc440865f2dc8c5897e8531539
2022-03-03 03:44:20 +00:00
Antoine Leblanc
0e3beb028d Extract generic containers from the codebase
### Description

There were several places in the codebase where we would either implement a generic container, or express the need for one. This PR extracts / creates all relevant containers, and adapts the relevant parts of the code to make use of said new generic containers. More specifically, it introduces the following modules:
- `Data.Set.Extended`, for new functions on `Data.Set`
- `Data.HashMap.Strict.Multi`, for hash maps that accept multiple values
- `Data.HashMap.Strict.NonEmpty`, for hash maps that can never be constructed as empty
- `Data.Trie`, for a generic implementation of a prefix tree

This PR makes use of those new containers in the following parts of the code:
- `Hasura.GraphQL.Execute.RemoteJoin.Types`
- `Hasura.RQL.Types.Endpoint*`

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3828
GitOrigin-RevId: e6c1b971bcb3f5ab66bc91d0fa4d0e9df7a0c6c6
2022-03-01 16:04:22 +00:00
Daniel Chambers
0f9f2192a0 server: Customize root field GraphQL schema descriptions
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3719
GitOrigin-RevId: b0a9bb6a0f65aac72ca95b66219eec16b2f5a0dd
2022-02-28 07:50:12 +00:00
Antoine Leblanc
a1886b3729 Generalize remote schemas IR
### Description

This PR is one further step towards remote joins from remote schemas. It introduces a custom partial AST to represent queries to remote schemas in the IR: we now need to augment what used to be a straightforward GraphQL AST with additional information for remote join fields.

This PR does the minimal amount of work to adjust the rest of the code accordingly, using `Void` in all places that expect a type representing remote relationships.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3794
GitOrigin-RevId: 33fc317731aace71f82ad158a1951ea93350d6cc
2022-02-25 20:38:46 +00:00
jkachmar
dc73b7b7d5 server: Renames the experimental backend modules
No logic in this PR, just tidying things up (renaming the backend from `Experimental` to `DataWrapper`).

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3779
GitOrigin-RevId: f11acf563ccd8b9f16bc23c5e92da392aa4cfb2c
2022-02-25 16:09:17 +00:00
Robert
5e7018b424 server: remove redundant LANGUAGE pragmas
These are all enabled as default-extensions.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3800
GitOrigin-RevId: ab9f4b900df53d66221095c02d6b12a930ff5873
2022-02-25 12:40:00 +00:00
kodiakhq[bot]
1181625173 server: optimize collectTypeDefinitions and refactor
Numbers from CI for the new (currently noisy) `replace_metadata` adhoc benchmark:

    chinook:      0.19s  ->  0.16
    huge_schema: 36.98s  ->  29.89

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3685
GitOrigin-RevId: be79b666858b03e8407c0d89765e9aac0af8d40a
2022-02-24 18:56:22 +00:00
Philip Lykke Carlsen
b9ad721ea6 Reduce boolean blindness by promoting data type StringifyNumbers
I discovered and removed instances of Boolean Blindness about whether json numbers should be stringified or not.

Although quite far-reaching, this is a completely mechanical change and should have no observable impact outside the server code.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3763
GitOrigin-RevId: c588891afd8a6923a135c736f6581a43a2eddbc7
2022-02-23 20:19:24 +00:00
Auke Booij
7547786b2b Build introspection Schema ad-hoc at parsing time
In order to respond to GraphQL queries that make use of the introspection fields `__type` or `__schema`, we need two things:
- an overview of the relevant GraphQL type information, stored in a `Schema` object, and
- to have included the `__type` and `__schema` fields in the `query_root` that we generate.

It used to be necessary to do the above items in that order, since the `__type` and `__schema` fields (i.e. the respective `FieldParser`s) were generated _from_ a `Schema` object.

Thanks to recent refactorings in `Hasura.GraphQL.Schema.Introspect` (see hasura/graphql-engine-mono#2835 or hasura/graphql-engine@5760d9289c), the introspection fields _themselves_ are now `Schema`-agnostic, and simply return a function that takes a `Schema` object after parsing. For instance, the type of `schema`, corresponding to the `__schema` field, has literally changed as follows:
```diff
-schema :: MonadParse n => Schema -> FieldParser n (          J.Value)
+schema :: MonadParse n =>           FieldParser n (Schema -> J.Value)
 ```

This means that the introspection fields can be included in the GraphQL schema *before* we have generated a `Schema` object. In particular, rather than the current architecture of generating `Schema` at startup time for every role, we can instead generate `Schema` ad-hoc at query parsing time, only for those queries that make use of the introspection fields. This avoids us storing a `Schema` for every role for the lifetime of the server.

However: this introduces a functional change, as the code that generates the `Schema` object, and in particular the `accumulateTypeDefinitions` method, also does certain correctness checks, to prevent exposing a spec-incompliant GraphQL schema. If these correctness checks are being done at parsing time rather than startup time, then we catch certain errors only later on. For this reason, this PR adds an explicit run of this type accumulation at startup time. For efficiency reasons, and since this correctness check is not essential for correct operation of HGE, this is done for the admin role only.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3231
GitOrigin-RevId: 23701c548b785929b28667025436b6ce60bfe1cd
2022-02-21 20:23:55 +00:00
Auke Booij
557a3d4b6e Derive a few Semigroup+Monoid instances
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3717
GitOrigin-RevId: 9bc7f64754a8461a006d9b633a712124f828166e
2022-02-18 14:58:04 +00:00
jkachmar
d50aae87a5 Updates cabal freeze file
#### TODO

- [x] fix `hashable >= 1.3.1` serialization ordering issue [^1]
  - `test_graphql_mutations.py::TestGraphQLMutateEnums` was failing
- [x] fix `unordered-containers` serialization ordering issue [^2]
  - `test_graphql_queries.py` was failing on Citus
- [ ] verify that no new failures have been introduced
- [ ] open issues to fix the above
  - identify test cases that "leak" implementation details by depending on `hashable` instance ordering
  - bump `hashable >= 1.3.1` and update test cases with new ordering OR modify them so that ordering is stable
  - bump `unordered-containers >= 0.2.15.0` and update test cases with new ordering OR modify them so that ordering is stable
    - one of the test cases was failing on string equality comparison for a generated Citus query
    - we probably don't want to _actually_ do this unless there are _very specific_ guarantees we want to make about generated query structure
---

Just what it says on the tin.

https://github.com/hasura/graphql-engine-mono/pull/3538 updated the freeze file a few weeks ago, but it looks like the index state hadn't been updated since December so a lot of stuff that had newer versions didn't get updated.

---

EDIT: I should add, the motivation for doing this in the first place is that `hspec > 2.8.4` now supports specifying filtering spec trees based on patterns provided by the `HSPEC_MATCH` environment variable.

For example, one could have a script that executes the following:
```
HSPEC_MATCH="PostgreSQL" \
  ghcid \
    --command \
      'cabal repl graphql-engine:test:tests-hspec \
         --repl-option -O0 \
         --repl-option -fobject-code' \
    --test "main"
```
...which will loop on typechecking the `tests-hspec` component, and then as soon as it passes (i.e. no warnings or errors) will run _only_ the `PostgreSQL` sub-components.

[^1]: `hashable >= 1.3.1.0` [updated its default salts](https://github.com/haskell-unordered-containers/hashable/pull/196), which [broke serialization ordering](https://github.com/haskell/aeson/issues/837)
[^2]: `unordered-containers >= 0.2.16.0` [introduced changes to some of its internal functions](https://hackage.haskell.org/package/unordered-containers-0.2.16.0/changelog) which seem like they could have affected serialization stability

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3672
GitOrigin-RevId: bbd1d48c73db4021913f0b5345b7315a8d6525d3
2022-02-18 05:32:08 +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
Naveen Naidu
2e823234f9 server/remote-schema: Include OperationName in the request sent to remote schemas
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3581
Co-authored-by: Puru Gupta <32328846+purugupta99@users.noreply.github.com>
GitOrigin-RevId: 2db21d0df158a5a3229b883ee426b2f38f864f80
2022-02-16 07:55:19 +00:00
Robert
1ff3723ed8 server: assorted minor clean-up around HTTP managers
- consistent qualified imports
- less convoluted initialization of pro logging HTTP manager
- pass pro HTTP manager directly instead of via Has
- remove some dead healthcheck code

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3639
GitOrigin-RevId: dfa7b9c62d1842a07a8514cdb77f1ed86064fb06
2022-02-16 07:09:47 +00:00
Daniel Chambers
2c7a4e3a16 Customization of computed field GraphQL schema descriptions
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3615
GitOrigin-RevId: f51590d4cfc0412be9baa371353f9b9f3b908f84
2022-02-15 23:17:27 +00:00
pranshi06
582d78110f server: Support returning scalar types in actions
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3453
GitOrigin-RevId: 59fee1460c5571322988b1f558a91ebeb2d55d22
2022-02-15 14:40:34 +00:00
Auke Booij
47315b78d6 Add Note explaining type collection
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3588
GitOrigin-RevId: f46d06e9476b22fe7abc699a5236ffefd23c1935
2022-02-10 18:14:01 +00:00
Daniel Chambers
dd403f92e2 Customization of table GraphQL schema descriptions
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3570
GitOrigin-RevId: f642a4d9efdd26a344951fcab6c1bbbc1253dfa3
2022-02-10 06:32:44 +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
Auke Booij
c4cdacf989 First attempt at deduplicating permission filters
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3362
Co-authored-by: Chris Parks <592078+cdparks@users.noreply.github.com>
GitOrigin-RevId: 802c099c26ff024e6cf594ea0317480e260486e9
2022-02-03 16:14:44 +00:00
Philip Lykke Carlsen
e1918adb52 Replace "identity column" with "column mutability" data for all backends
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3373
GitOrigin-RevId: bf08cc9008a4b0b3ece4952528c15c45e57fc74c
2022-02-03 14:15:35 +00:00
Antoine Leblanc
3525e60021 Deploy server documentation to github page in CI
_(This PR is on top of #3352.)_

## Description

This PR overhauls our documentation CI steps to push all generated server documentation to the `gh-pages` branch of the OSS repo. The goal of this PR is to arrive in the situation where `https://hasura.github.io/graphql-engine/server/` is automatically populated to contain the following:
  - all the markdown files from `server/documentation`, copied verbatim, no transformation applied
  - all the notes, collected from the code by the `extract-notes.sh` script, in `server/notes`
  - the generated haddock documentation for each major release or branch in `server/haddock`.

To do so, this PR does the following:
  - it includes the script to extract notes from #3352,
  - it rewrites the documentation checking CI step, to generate the notes and publish the resulting "server/documentation" folder,
  - it includes a new CI step to deploy the documentation to the `gh-pages` branch

Of note:
  - we will generate a different haddock folder for each main branch and release; in practice, that means the _main_, _stable_, _alpha_, _beta_ branches, and every build tagged with a version number
  - the step that builds the haddock documentation checks that ALL projects in the repo build, including pro, but the deploy only deploys the graphql-engine documentation, as it pushes it to a publicly-accessible place

## Required work

**DO NOT MERGE THIS PR IT IS NOT READY**. Some work needs to go into this PR before it is ready.

First of all: the `gh-pages` branch of the OSS repo does NOT yet contain the documentation scaffolding that this new process assumes. At the bare minimum, it should be a orphan branch that contains a top-level README.md file, and a _server_ folder. An example of the bare minimum required can be previewed [on my fork](https://nicuveo.github.io/graphql-engine/server/).

The content of the `server/documentation` folder needs to be adjusted to reflect this; at the very least, a `README.md` file needs to be added to do the indexing (again, see the placeholder [on my fork](https://nicuveo.github.io/graphql-engine/server/) for an example).

This way of publishing documentation must be validated against [proposed changes to the documentation](https://github.com/hasura/graphql-engine-mono/pull/3294). @marionschleifer what do you think?

~~The buildkite code in this branch is currently untested, and I am not sure how to test it.~~

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3380
GitOrigin-RevId: b24f6759c64ae29886c1f1b481b172febc512032
2022-01-31 13:16:29 +00:00
Daniel Chambers
3c74f91a1c Add default User-Agent header for Action requests
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3505
GitOrigin-RevId: fe74349d1ca699dc0edca1e5a829fd658226a5ee
2022-01-31 06:50:13 +00:00
Antoine Leblanc
d66d2d81fd server: use placeholder to prevent empty query roots
### Description

The GraphQL spec has to conflicting requirements:
1. an object must contain at least one field: the schema may not contain empty objects
2. the _query_root_ must always be present

Given _1_, the schema generation code removes from the schema all fields that would result in empty objects, such as a table for which a user does not have select permissions. But, as a result, our code also potentially removes _query_root_ if it is empty, breaking _2_.

This PR introduces a dummy "placeholder" field in the query root if it's empty, to ensure we never remove it from the schema.

### Remaining work

- [x] changelog entry
- [x] tests

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/148
GitOrigin-RevId: bfd6bfcc2f3de92900b6ba566012f093399ca037
2022-01-27 18:08:11 +00:00
Antoine Leblanc
a023a3259d Prevent uses of unsafeMkName whenever possible.
### Description

This PR is the result of a discussion in #3363. Namely, we would like to remove all uses of `unsafeMkName`, or at the very least document every single one of them, to avoid similar issues. To do so, this PR does the following:
- it adds a hlint suggestion not to use that function:
  - suggestions don't mark the PR as failed, but will be shown at review time
  - it is possible to disable that hint with `{- HLINT ignore myFunction "unsafe" -}`
- wherever possible, it removes uses of `unsafeMkName` in favour of `mkName`
- it adds a comment with a tracking issue for the two remaining uses:
  - #3478
  - #3479

### Remaining work

- discuss whether this hint should make the linter step fail, since the linter step isn't required to merge anyway, and there is a way to disable the hint wherever we think the use of that function is acceptable
- check that none of those uses were load-bearing and result in errors now

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3480
GitOrigin-RevId: 0a7e3e9d1a48185764c04ab61e34b58273af347c
2022-01-27 15:13:37 +00:00
Daniel Chambers
bd6f7cd756 Fixed GQL aliases not being respected in the OpenAPI schema
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3484
GitOrigin-RevId: 0f49dd7f64e80dfe6940d673afa76f12f6599126
2022-01-27 05:55:55 +00:00
David Overton
8eca322b94 Fix for customized remote schema input object types in query variables
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3417
GitOrigin-RevId: a4d3e59f5177f971a64a2b9e62fd1acaa8079a6b
2022-01-24 04:46:46 +00:00
paritosh-08
00558666b1 server: add analyzeGraphqlQuery
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3288
GitOrigin-RevId: a5fd39acc8039f2e6ec5090adfc984ac09281d6b
2022-01-21 05:40:20 +00:00
Rakesh Emmadi
34c2fb2b66 server: cleanup references to "pgCol" in common and non-postgres backend code
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3393
GitOrigin-RevId: b45cd83f7c3fbc1656011ee888968743b0bbb736
2022-01-19 08:38:48 +00:00
Solomon
4b792abdcc Feature/webhook response transforms
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3074
Co-authored-by: David Overton <7734777+dmoverton@users.noreply.github.com>
Co-authored-by: Lyndon Maydwell <92299+sordina@users.noreply.github.com>
Co-authored-by: Tirumarai Selvan <8663570+tirumaraiselvan@users.noreply.github.com>
GitOrigin-RevId: 006c5c9b71cdca1c2f47962230e6189e09557fab
2022-01-19 04:47:36 +00:00
Rakesh Emmadi
fbfdf9a04d server/mssql: restrict "count" aggregate query on multiple columns
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3354
GitOrigin-RevId: d9890782ff8e3ea40ec52c0da82e43ecf5c36d2b
2022-01-18 14:54:46 +00:00
Gil Mizrahi
fe41fbabbd mssql: Test upserts with permissions
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3280
GitOrigin-RevId: 861d4db59f75c83daef975fb3471b3c07889c9bc
2022-01-11 13:36:56 +00:00
Philip Lykke Carlsen
33a107d371 Improvements to Update Operators api docs
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3225
GitOrigin-RevId: 8f8123353249efb5acaab00681988171e44fae02
2021-12-29 03:52:01 +00:00
David Overton
02aef27a75 Add request body to OpenAPI
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2632
Co-authored-by: Lyndon Maydwell <92299+sordina@users.noreply.github.com>
Co-authored-by: paritosh-08 <85472423+paritosh-08@users.noreply.github.com>
GitOrigin-RevId: 067e182effaed255ff047abeee309d65a9fb191c
2021-12-22 08:31:14 +00:00
jkachmar
63cff8b731 Experimental backend adapter
This commit introduces an "experimental" backend adapter to the GraphQL Engine.

It defines a high-level interface which will eventually be used as the basis for implementing separate data source query generation & marshaling services that communicate with the GraphQL Engine Server via some protocol.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2684
Co-authored-by: awjchen <13142944+awjchen@users.noreply.github.com>
Co-authored-by: Chris Parks <592078+cdparks@users.noreply.github.com>
GitOrigin-RevId: 4463b682142ad6e069e223b88b14db511f634768
2021-12-22 00:11:28 +00:00
Vamshi Surabhi
cca3831180 simplified schema cache representation of remote relationships
This PR pretty much does the same thing to remote relationship types in schemacache as what #2979 did to remote relationship types in the IR. On main remote relationships are represented by types of form `T from to`.  This PR changes it to `T from` which makes it a lot more reusable.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3037
GitOrigin-RevId: 90a5c9e2346c8dc2da6ec5b8c970d6c863d2afb8
2021-12-21 23:15:50 +00:00
Swann Moreau
5760d9289c server: introspection cleanups
this pr modifies the representation chosen for introspection parsers, "pushing down" the `Schema` input so it is not required to build the parser anymore. instead, the value produced when the parser is evaluated becomes a function that consumes a schema:
```diff
-schema :: MonadParse n => Schema -> FieldParser n (          J.Value)
+schema :: MonadParse n =>           FieldParser n (Schema -> J.Value)
 ```

this addresses points (1) and (2) of #2833 and is intended to make #2799 easier: we will need to enforce permissions when generating introspection objects, hiding fields the user is not allowed to see, so if we can pass the schema _later_, we can build this parser once, evaluate it once to (morally) obtain a function `Schema -> Value`, and simply run that single `Schema -> Value` function on different role-based schemas.

(we really need some terminology to be fixed here: "parser" is already not the best name, and then we have parser vs value/function "returned" by parser vs...)

however, we have immediate benefits: we no longer _need_ a `Schema` object to build the introspection parsers! this means we can remove the bogus "degenerate case" schema that is currently constructed in `emptyIntrospection` (and indeed we remove that binding altogether).

(fun fact: the diff for this pull request has a negative line count despite adding a lot of comments. @abooij says i have bragging rights in perpetuity now, à la @nicuveo)

changes:
- internal changes to the operation of the server, invisible outside of a small number of `GraphQL.Schema.*` modules
- no user-facing changes

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2835
Co-authored-by: Auke Booij <164426+abooij@users.noreply.github.com>
Co-authored-by: Brandon Simmons <210815+jberryman@users.noreply.github.com>
GitOrigin-RevId: 9990f53b8f5c733424c4d71a24d94c13dee842ba
2021-12-21 17:29:54 +00:00
Auke Booij
e805fc01f3 Avoid NonNullableType
This refactors the AST of GraphQL types so that we don't need `NonNullableType`.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3178
GitOrigin-RevId: 6513c8ea0a3cf4ad3ca7d8ef9ca996912fd5eedc
2021-12-20 17:03:28 +00:00
Auke Booij
2c3277e0a7 Refactor InputFieldInfo
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3143
GitOrigin-RevId: a374e07216f3f7d7dee61b222a2758d3ebeb98bb
2021-12-20 15:53:45 +00:00
Abby Sassel
6c6bb678f8 server: Include column mutability data in the schema generation code
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3182
Co-authored-by: Philip Lykke Carlsen <358550+plcplc@users.noreply.github.com>
GitOrigin-RevId: ba9d31f5443aa936b1d5b58b0f4e10abf0064a7e
2021-12-17 17:26:51 +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
Philip Lykke Carlsen
37ecb0e3b2 server/mssql: Generate upsert mutation schema
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3056
GitOrigin-RevId: 8d58ae983c4d3ad55dfeff744c891d77c7c6de1a
2021-12-15 17:08:26 +00:00
Chris Parks
038a6113c3 Remove Identifier associated type family from Backend class (close #1758)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3096
GitOrigin-RevId: 03f218a76c5f333a77646a60c8c69767e2286ea6
2021-12-13 16:49:09 +00:00
Philip Lykke Carlsen
2fbcd783e7 Refactor XOnConflict and ExtraInsertData
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3055
GitOrigin-RevId: 06f7f92f0e09695f5f7bc02df457d3b96ac9f5f6
2021-12-09 09:06:56 +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
Vamshi Surabhi
23e1cb218a simplification of generalized joins execution
This PR simplifies the types that represent a remote relationship in IR so that they can be reused in other parts (in remote schema types) which could have remote relationships.

The comments on the PR explain the main changes.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2979
GitOrigin-RevId: 559c51d9d6ae79e2183ce4347018741b9096ac74
2021-12-07 13:12:57 +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
Philip Lykke Carlsen
4c1f3d0140 Adding ColumnMutability to column metadata
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2962
GitOrigin-RevId: ee2687e84842dc5dd647ce9aa017c6051556d0e5
2021-12-01 11:34:16 +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
Antoine Leblanc
f7071b3c93 Changed RemoteSchemaIntrospection's internal representation from a list to a hashmap.
### Description

This PR changes the internal representation of a parsed remote schema. We were still using a list of type definitions, meaning every time we were doing a type lookup we had to iterate through a linked list! 🙀 It was very noticeable on large schemas, that need to do a lot of lookups. This PR consequently changes the internal representation to a HashMap. Building the OneGraph schema on my machine now takes **23 seconds**, compared to **367 seconds** before this patch.

Some important points:
- ~~this PR removes a check for type duplication in remote schemas; it's unclear to me whether that's something we need to add back or not~~ (no longer true)
- this PR makes it obvious that we do not distinguish between "this remote schema is missing type X" and "this remote schema expects type X to be an object, but it's a scalar"; this PR doesn't change anything about it, but adds a comment where we could surface that error (see [2991](https://github.com/hasura/graphql-engine-mono/issues/2991))

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2963
GitOrigin-RevId: f5c96ad40f4e0afcf8cef635b4d64178111f98d3
2021-11-30 14:47:50 +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
Auke Booij
29158900d8 Refactor type name customization
Source typename customization (hasura/graphql-engine@aac64f2c81) introduced a mechanism to change certain names in the GraphQL schema that is exposed. In particular it allows last-minute modification of:
1. the names of some types, and
2. the names of some root fields.

The above two items are assigned distinct customization algorithms, and at times both algorithms are in scope. So a need to distinguish them is needed.

In the original design, this was addressed by introducing a newtype wrapper `Typename` around GraphQL `Name`s, dedicated to the names of types. However, in the majority of the codebase, type names are also represented by `Name`. For this reason, it was unavoidable to allow for easy conversion. This was supported by a `HasName Typename` instance, as well as by publishing the constructors of `Typename`.

This means that the type safety that newtypes can add is lost. In particular, it is now very easy to confuse type name customization with root field name customization.

This refactors the above design by instead introducing newtypes around the customization operations:
```haskell
newtype MkTypename = MkTypename {runMkTypename :: Name -> Name}
  deriving (Semigroup, Monoid) via (Endo Name)

newtype MkRootFieldName = MkRootFieldName {runMkRootFieldName :: Name -> Name}
  deriving (Semigroup, Monoid) via (Endo Name)
```
The `Monoid` instance allows easy composition of customization operations, piggybacking off of the type of `Endo`maps.

This design allows safe co-existence of the two customization algorithms, while avoiding the syntactic overhead of packing and unpacking newtypes.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2989
GitOrigin-RevId: da3a353a9b003ee40c8d0a1e02872e99d2edd3ca
2021-11-30 09:52:53 +00:00
David Overton
5bfce057c6 Refactor remote schema customization
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2771
GitOrigin-RevId: 0c90136f956df3f4552140e6ca3d2f4766f8b3f5
2021-11-30 00:38:27 +00:00
Philip Lykke Carlsen
4f6831d76e Defining the MSSQL update schema using said components
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2923
GitOrigin-RevId: 732988f666f00b3c5eebf6089f9887ee5d679c11
2021-11-26 13:48:09 +00:00
Philip Lykke Carlsen
63ee663626 Excise query tags from backend schema
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2960
GitOrigin-RevId: ff6418609117abc8e0410c0897f2af9779cecf16
2021-11-25 21:08:54 +00:00
Abby Sassel
3166010ac1 server: belatedly address #2889 feedback
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2945
GitOrigin-RevId: 8ccb6479391c2b38af6a4c9ac209e29d4e26f65c
2021-11-24 21:40:44 +00:00
Kirill Zaborsky
a2afe4116b BigQuery remote joins
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2874
Co-authored-by: Abby Sassel <3883855+sassela@users.noreply.github.com>
GitOrigin-RevId: 24b0304716795a28038629775238996c28b312a3
2021-11-24 16:22:55 +00:00
Philip Lykke Carlsen
84027dad04 Breaking up the Postgres implementation of the update-schema into reusable components
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2889
GitOrigin-RevId: 49c5d59a6f817832f11b1773b078aa24cc650ab5
2021-11-18 18:03:57 +00:00
David Overton
ec60386f9c Allow "extensions" field in remote schema response
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2818
GitOrigin-RevId: 505e8bae6d3e11199c229bd2b86af09161eb8b66
2021-11-10 02:34:56 +00:00
Philip Lykke Carlsen
984955d194 (Fix #2795) Add haddock documentation to schema generation and helpers
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2806
GitOrigin-RevId: 24005d471d469076f03390ca32442a6a3ebbce44
2021-11-10 00:38:40 +00:00
Puru Gupta
504f13725f server: forward auth webhook set-cookies header on response
>

High-Level TODO:

* [x] Code Changes
* [x] Tests
* [x] Check that pro/multitenant build ok
* [x] Documentation Changes
* [x] Updating this PR with full details
* [ ] Reviews
* [ ] Ensure code has all FIXMEs and TODOs addressed
* [x] Ensure no files are checked in mistakenly
* [x] Consider impact on console, cli, etc.

### Description
>
This PR adds support for adding set-cookie header on the response from the auth webhook. If the set-cookie header is sent by the webhook, it will be forwarded in the graphQL engine response.

Fixes a bug in test-server.sh: testing of get-webhook tests was done by POST method and vice versa. To fix, the parameters were swapped.

### Changelog

- [x] `CHANGELOG.md` is updated with user-facing content relevant to this PR.

### Affected components

- [x] Server
- [ ] Console
- [ ] CLI
- [x] Docs
- [ ] Community Content
- [ ] Build System
- [x] Tests
- [ ] Other (list it)

### Related Issues
->
Closes [#2269](https://github.com/hasura/graphql-engine/issues/2269)

### Solution and Design
>

### Steps to test and verify
>
Please refer to the docs to see how to send the set-cookie header from webhook.

### Limitations, known bugs & workarounds
>
- Support for only set-cookie header forwarding is added
- the value forwarded in the set-cookie header cannot be validated completely, the [Cookie](https://hackage.haskell.org/package/cookie) package has been used to parse the header value and any unnecessary information is stripped off before forwarding the header. The standard given in [RFC6265](https://datatracker.ietf.org/doc/html/rfc6265) has been followed for the Set-Cookie format.

### Server checklist

#### Catalog upgrade

Does this PR change Hasura Catalog version?
- [x] No
- [ ] Yes
  - [ ] Updated docs with SQL for downgrading the catalog

#### Metadata

Does this PR add a new Metadata feature?
- [x] No

#### GraphQL
- [x] No new GraphQL schema is generated
- [ ] New GraphQL schema is being generated:
   - [ ] New types and typenames are correlated

#### Breaking changes

- [x] No Breaking changes

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2538
Co-authored-by: Robert <132113+robx@users.noreply.github.com>
GitOrigin-RevId: d9047e997dd221b7ce4fef51911c3694037e7c3f
2021-11-09 12:01:31 +00:00
Philip Lykke Carlsen
3f8013abcb Fix #2741: Mechanically excise updateOperators from class BackendSchema
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2743
GitOrigin-RevId: c1e56bf66e5e0743e3c5b53a23a5b8a7d85ddf85
2021-11-08 18:13:16 +00:00
Brandon Simmons
b167120f96 server: add explicit export lists in OSS server and enforce with warning
We'll see if this improves compile times at all, but I think it's worth
doing as at least the most minimal form of module documentation.

This was accomplished by first compiling everything with
-ddump-minimal-imports, and then a bunch of scripting (with help from
ormolu)

**EDIT** it doesn't seem to improve CI compile times but the noise floor is high as it looks like we're not caching library dependencies anymore

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2730
GitOrigin-RevId: 667eb8de1e0f1af70420cbec90402922b8b84cb4
2021-11-04 16:09:38 +00:00
hasura-bot
a886da2f21 server: address recent graphql-ws related bugs
GITHUB_PR_NUMBER: 7730
GITHUB_PR_URL: https://github.com/hasura/graphql-engine/pull/7730

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2685
Co-authored-by: Sameer Kolhar <6604943+kolharsam@users.noreply.github.com>
GitOrigin-RevId: 55bafd4eb1576e95803350f3ba9c7920a21de037
2021-11-04 12:40:02 +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
503c220840 server: refactor GraphQL.Transport.HTTP.runGQ for readability
I was trying to figure out how to pipe some information from query
execution to the http log recently, and once again stumbled over the
mess that is `runGQ`. Here's an attempt to break it apart a little bit.

The result should by no means be considered final, but I hope it makes it
somewhate easier to understand what's going on in this function. E.g. now it's
once again somewhat visible how execution of queries and mutations differs.
Had to stop somewhere...

The PR is intended to have no functional change. It consists of individual
commits which should be "obviously" such.

Some thoughts and possible follow-up:
- It'd be good to get rid of the ad hoc `Result` data type again eventually,
  but for the moment I think it's better than the tuples that used to be.
- I think we're quite close to reducing the duplication with WebSocket. E.g.
  executeQueryStep and executeMutationStep might be reusable.
- It's tempting to change the caching API slightly, so that the uncached
  response headers don't have to be pulled from the cache lookup result.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2669
GitOrigin-RevId: ea414d24194509ce29469d74c62fd060b750488d
2021-10-26 11:45:27 +00:00
Rakesh Emmadi
8e88e73a52 server/mssql: add cascade to mssql_run_sql
<!-- Thank you for ss in the Title above ^ -->

## Description
<!-- Please fill thier. -->
<!-- Describe the changes from a user's perspective -->
We don't have dependency reporting mechanism for `mssql_run_sql` API i.e when a database object (table, column etc.) is dropped through the API we should raise an exception if any dependencies (relationships, permissions etc.) with the database object exists in the metadata.

This PR addresses the above mentioned problem by
-> Integrating transaction to the API to rollback the SQL query execution if dependencies exists and exception is thrown
-> Accepting `cascade` optional field in the API payload to drop the dependencies, if any
-> Accepting `check_metadata_consistency` optional field to bypass (if value set to `false`) the dependency check

### Related Issues
<!-- Please make surt title -->
<!-- Add the issue number below (e.g. #234) -->
Close #1853

### Solution and Design
<!-- How is this iss -->
<!-- It's better if we elaborate -->
The design/solution follows the `run_sql` API implementation for Postgres backend.

### Steps to test and verify
<!-- If this is a fehis is a bug-fix, how do we verify the fix? -->
- Create author - article tables and track them
- Defined object and array relationships
- Try to drop the article table without cascade or cascade set to `false`
- The server should raise the relationship dependency exists exception

## Changelog

-  `CHANGELOG.md` is updated with user-facing content relevant to this PR.
  If no changelog is required, then add the `no-changelog-required` label.

## Affected components
<!-- Remove non-affected components from the list -->

-  Server
-  Console
-  CLI
-  Docs
-  Community Content
-  Build System
-  Tests
-  Other (list it)

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2636
GitOrigin-RevId: 0ab152295394056c4ca6f02923142a1658ad25dc
2021-10-22 14:50:13 +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
Lyndon Maydwell
9ecb3ebf31 Using escaped string for URL transform
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2520
Co-authored-by: Solomon Bothwell <24038+ssbothwell@users.noreply.github.com>
GitOrigin-RevId: 9a0bccb8f5fcfc33306dca27f057d0e1e8dca1dc
2021-10-13 03:38:01 +00:00
Lyndon Maydwell
788e5cb0c2 Include transformed request in errors
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2543
Co-authored-by: Solomon Bothwell <24038+ssbothwell@users.noreply.github.com>
GitOrigin-RevId: 1432a215cfc2c3e8345941b8072925f115f9259f
2021-10-13 00:29:49 +00:00
pranshi06
be1395de31 [server] Allow Nullable action response
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2379
GitOrigin-RevId: eae2b0b401737ceb4e4885ba47c342e26f2026a1
2021-10-11 06:56:01 +00:00
Gil Mizrahi
42cd2e69c0 Add support for customising function root field names
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2468
Co-authored-by: Philip Lykke Carlsen <358550+plcplc@users.noreply.github.com>
GitOrigin-RevId: 5ff85bb02e4e651376a40914b7ae0aabc8524a05
2021-10-07 13:03:22 +00:00
Rakesh Emmadi
09ae6af337 server/mssql: insert SQL generation and execution
>

### Description
>
Insert mutations for MSSQL backend. This PR implements execution logic.

### Changelog

- [x] `CHANGELOG.md` is updated with user-facing content relevant to this PR. If no changelog is required, then add the `no-changelog-required` label.

### Affected components

- [x] Server
- [x] Tests

### Related Issues
->
Close https://github.com/hasura/graphql-engine-mono/issues/2114

### Steps to test and verify
>
Track a MSSQL table and perform the generated insert mutation to test.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2248
Co-authored-by: Abby Sassel <3883855+sassela@users.noreply.github.com>
Co-authored-by: Philip Lykke Carlsen <358550+plcplc@users.noreply.github.com>
GitOrigin-RevId: 936f138c80d7a928180e6e7b0c4da64ecc1f7ebc
2021-10-01 12:53:15 +00:00
Robert
fbd1262ea6 server: operation timeout with postgres cancelling
### Description

This PR implements operation timeouts, as specced in #1232.

RFC: [rfcs/operation-timeout-api-limits.md](c025a90fe9/rfcs/operation-timeout-api-limits.md)

There's still some things to be done (tests and docs most notably), but apart from that it can
be reviewed. I'd still appreciate feedback on the RFC!

TODO:
- [x] break out the `ApiLimits` refactoring into a separate PR: #2103
- [x] finish the `pg-client-hs` PR: https://github.com/hasura/pg-client-hs/pull/39
- [x] remove configurability, after testing, prior to merging
- [ ] tests: #2390 has some tests that I've run locally to confirm things work on a fundamental level
- [x] changelog
- [x] documentation
- [x] fill in the detailed PR checklist

### Changelog

- [x] `CHANGELOG.md` is updated with user-facing content relevant to this PR. If no changelog is required, then add the `no-changelog-required` label.

### Affected components

- [x] Server
- [ ] Console
- [ ] CLI
- [x] Docs
- [ ] Tests

### Related Issues

Product spec: #1232.

### Solution and Design

Compare `rfcs/operation-timeout-api-limits.md`.

### Steps to test and verify

Configure operation timeouts, e.g. by posting

```
{
  "type": "set_api_limits",
  "args": {
    "operation_timeout": {
      "global": 3
    }
  }
}
```

to `v1/metadata` to set an operation timeout of 3s. Then verify that
1. non-admin queries that take longer than 3s time out with a nice error message
2. that those queries return after ~3s (at least for postgres)
3. also that everything else still works as usual

### Limitations, known bugs & workarounds
- while this will cause slow queries against any backends to fail, it's only verified to actually interrupt queries against postgres
- this will only successfully short-cut (cancel) queries to postgres if the database server is responsive

#### Catalog upgrade
Does this PR change Hasura Catalog version?
- [x] No

#### Metadata

Does this PR add a new Metadata feature?
- [x] Yes
  - Does `run_sql` auto manages the new metadata through schema diffing?
    - [x] Not required
  - Does `run_sql` auto manages the definitions of metadata on renaming?
    - [x] Not required
  - Does `export_metadata`/`replace_metadata` supports the new metadata added?
    - [x] Yes

#### GraphQL
- [x] No new GraphQL schema is generated

#### Breaking changes

- [x] No Breaking changes

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/1593
GitOrigin-RevId: f0582d0be3ed9fadf89e0c4aaf96344d18331dc4
2021-09-29 16:21:05 +00:00
Lyndon Maydwell
22bc0e09df Ignore unexpected fields in action responses
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2459
GitOrigin-RevId: 9269fa6e71770cb31183d917595b704c5dee9713
2021-09-29 09:54:36 +00:00
Solomon Bothwell
4e05bdcaec Feature/request transform string interpolation
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2443
Co-authored-by: Tirumarai Selvan <8663570+tirumaraiselvan@users.noreply.github.com>
GitOrigin-RevId: d7d68984d0ae1403bb414572e9704c01ed27deab
2021-09-29 08:14:29 +00:00
Antoine Leblanc
636960787e Fix haddock generation and introduce PR check
On `main`, currently, haddock generation is broken, due to some unrecognized comments. This PR fixes this, and changes our `build_oss_server` CI job to ensure that future PRs do not break haddock.

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

GitOrigin-RevId: 909bbcdc7b2d31c9a3e947ce6b7691e23f59b916
2021-09-24 17:02:33 +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
Robert
bdacf1bd23 server: remove ApplicativeDo from default extensions
I spent half the day reducing a weird compile failure here https://github.com/hasura/graphql-engine-mono/pull/1593/files#r713102990 to this https://gitlab.haskell.org/ghc/ghc/-/issues/17768#note_378004. Seems ApplicativeDo makes a mess of non-applicative monadic do in some cases. Given our rather localized use of ApplicativeDo, seemed a good idea to remove it from the list of default extensions.

It appears that ApplicativeDo also buries some unused return value warnings, so this PR also silences those. We should check that none of those warnings were warranted though.

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

GitOrigin-RevId: 1874c1a82230431849265755b1407beebc947041
2021-09-22 15:35:54 +00:00
jkachmar
112d206fa6 Adds Remote Source Join Execution
https://github.com/hasura/graphql-engine-mono/pull/2038

Co-authored-by: Phil Freeman <630306+paf31@users.noreply.github.com>
GitOrigin-RevId: 0843bd0610822469f727d768810694b748fec790
2021-09-22 10:44:01 +00:00
pranshi06
e77b79ae02 [server] Add GraphQL query in the payload for Synchronous Actions
https://github.com/hasura/graphql-engine-mono/pull/2224

GitOrigin-RevId: 9eb1ab612f1a6cc8fe8490272be3d5a997b5b097
2021-09-20 18:20:33 +00:00
Rakesh Emmadi
9ca0bc1e5c server: remove identity notion from table columns
>

### Description
>
While adding [insert mutation schema parser for MSSQL backend](https://github.com/hasura/graphql-engine-mono/pull/2141) I also included [identity](https://en.wikipedia.org/wiki/Identity_column) notion to table columns across all backends. In MSSQL we cannot insert any value (even `DEFAULT` expression) into Identity columns. This behavior of identity columns is not same in Postgres as we can insert values. This PR drops the notion of identity in the column info. The context of identity columns for MSSQL is carried in `ExtraTableMetadata` type.

### Changelog

- [x] `CHANGELOG.md` is updated with user-facing content relevant to this PR. If no changelog is required, then add the `no-changelog-required` label.

### Affected components

- [x] Server
- [ ] Console
- [ ] CLI
- [ ] Docs
- [ ] Community Content
- [ ] Build System
- [x] Tests
- [ ] Other (list it)

### Related Issues
->
Fix https://github.com/hasura/graphql-engine/issues/7557

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

GitOrigin-RevId: c18b5708e2e6107423a0a95a7fc2e9721e8a21a1
2021-09-17 09:03:06 +00:00
Swann Moreau
8bfcd9a55c server: add "extensions" field to action webhook error schema
https://github.com/hasura/graphql-engine-mono/pull/1698

GitOrigin-RevId: c3b6f1048b6702a53ebe6c49f23dedc0f1d88090
2021-09-17 07:44:37 +00:00
Robert
d900a65399 server: Reduce and localize CPP usage
Some of our use of CPP causes trouble for ormolu, compare https://github.com/tweag/ormolu/issues/774.
Specifically, for understandable reasons, it can't deal well with `#ifdef` use that is not at the top-level.

This PR removes the problematic usage in ways that I hope are also a net non-loss regardless of helping
out ormolu (or other tooling).

- The default value for enabled APIs moves to the top level, next to the command line help, so
  they'll stay in sync more easily.
- All the CPP around using `assertNFHere` is moved to one module.

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

GitOrigin-RevId: ed6e039e6d8960322fd8d1312df762ad197c29b1
2021-09-16 18:52:37 +00:00
Antoine Leblanc
07fd7324c3 server: enable StrictData by default (fix hasura/graphql-engine#3941)
## Description

Almost all our data structures use strictness annotations, following [our styleguide's principle](https://github.com/hasura/graphql-engine/blob/master/server/STYLE.md#dealing-with-laziness) of "by default, use strict data types and lazy functions". The very few cases where we actually need laziness were already explicitly labelled as lazy with the `~` prefix operator.

This PR simply globally enables `StrictData`, allowing us to express records without `!()` on every field, but makes no attempt at cleaning existing code.

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

Co-authored-by: Philip Lykke Carlsen <358550+plcplc@users.noreply.github.com>
GitOrigin-RevId: e65c6e2f89413188da250122f64c2173615946ec
2021-09-16 12:23:15 +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
David Overton
7c77c81cf9 return original schema in introspect_remote_schema
https://github.com/hasura/graphql-engine-mono/pull/2364

GitOrigin-RevId: 99698aa977bf8ff85e29d67a0956ff1509cd30be
2021-09-16 09:07:18 +00:00
Antoine Leblanc
e2ce1972f6 Prevent empty subscription roots (fix hasura/graphql-engine#6898)
### Description

We always build a subscription root, even when there was no possible fields. This breaks some third party clients, as the spec does not allow empty types in the schema. This PR fixes this by changing the `buildSubscriptionParser` helper to return a `Maybe` value, and harmonizes / cleans places where we build the subscription root.

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

GitOrigin-RevId: 1aeae25e321eee957e7645c436d17e69207309fd
2021-09-16 07:42:46 +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
Antoine Leblanc
a5589c185b Fix nullability of nested objrel inserts (fix hasura/graphql-engine#7484)
### Description

During the PDV refactor that led to 2.0, we broke an undocumented and untested semantic of inserts: accepting _explicit_ null values in nested object inserts.

In short: in the schema, we often distinguish between _explicit_ null values `{id: 3, author: null}` and _implicit_ null values that correspond to the field being omitted `{id: 3}`. In this particular case, we forgot to accept explicit null values. Since the field is optional (meaning we accept implicit null values), it was nullable in the schema, like it was in pre-PDV times. But in practice we would reject explicit nulls.

This PR fixes this, and adds a test. Furthermore, it does a bit of a cleanup of the Mutation part of the schema, and more specifically of all insertion code.

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

GitOrigin-RevId: 895cfeecef7e8e49903a3fb37987707150446eb0
2021-09-15 13:11:48 +00:00
Karthikeyan Chinnakonda
982b5a3d15 server: log operation details for each query in a batch query execution
https://github.com/hasura/graphql-engine-mono/pull/2306

GitOrigin-RevId: 066a02fc57711b1faad447e6e448e3e004376c74
2021-09-15 08:30:32 +00:00
Anon Ray
dc1ac69dac server: add parameterized query hash for websocket logs
https://github.com/hasura/graphql-engine-mono/pull/2061

Co-authored-by: Naveen Naidu <30195193+Naveenaidu@users.noreply.github.com>
GitOrigin-RevId: bf26b804d93b19ef7fc15c71fec80fb6d6632e64
2021-09-06 12:27:48 +00:00
Sameer Kolhar
afbc30fec5 server: set tracecontext and userInfo for DML actions on PG sources
https://github.com/hasura/graphql-engine-mono/pull/2174

GitOrigin-RevId: e8cfb4e330938e7dfb7232e58d2c1fc07bf97896
2021-09-01 17:57:39 +00:00
Rakesh Emmadi
7ca48decfb server/mssql: integrate insert mutation schema parser for MSSQL backend
>

### Description
>
This PR is an incremental work towards [enabling insert mutations on MSSQL](https://github.com/hasura/graphql-engine-mono/pull/1974). In this PR, we generate insert mutation schema parser for MSSQL backend.

### Changelog

- [ ] `CHANGELOG.md` is updated with user-facing content relevant to this PR. If no changelog is required, then add the `no-changelog-required` label.

### Affected components

- [x] Server

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

GitOrigin-RevId: 8595008dece35f7fded9c52e134de8b97b64f53f
2021-08-31 13:35:49 +00:00
Auke Booij
fe8eabff19 server: fix the nullability of object relationships (fix hasura/graphql-engine#7201)
When adding object relationships, we set the nullability of the generated GraphQL field based on whether the database backend enforces that the referenced data always exists. For manual relationships (corresponding to `manual_configuration`), the database backend is unaware of any relationship between data, and hence such fields are always set to be nullable.

For relationships generated from foreign key constraints (corresponding to `foreign_key_constraint_on`), we distinguish between two cases:

1. The "forward" object relationship from a referencing table (i.e. which has the foreign key constraint) to a referenced table. This should be set to be non-nullable when all referencing columns are non-nullable. But in fact, it used to set it to be non-nullable if *any* referencing column is non-nullable, which is only correct in Postgres when `MATCH FULL` is set (a flag we don't consider). This fixes that by changing a boolean conjunction to a disjunction.
2. The "reverse" object relationship from a referenced table to a referencing table which has the foreign key constraint. This should always be set to be nullable. But in fact, it used to always be set to non-nullable, as was reported in hasura/graphql-engine#7201. This fixes that.

Moreover, we have moved the computation of the nullability from `Hasura.RQL.DDL.Relationship` to `Hasura.GraphQL.Schema.Select`: this nullability used to be passed through the `riIsNullable` field of `RelInfo`, but for array relationships this information is not actually used, and moreover the remaining fields of `RelInfo` are already enough to deduce the nullability.

This also adds regression tests for both (1) and (2) above.

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

GitOrigin-RevId: 617f12765614f49746d18d3368f41dfae2f3e6ca
2021-08-26 15:27:34 +00:00
Lyndon Maydwell
605499e6da [pro, server] Allow response when cache limits are hit
https://github.com/hasura/graphql-engine-mono/pull/2094

GitOrigin-RevId: f8b186a7cf830f61226e7ea82631a4a9e5f269bc
2021-08-25 01:53:45 +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
Sameer Kolhar
edeb8c98fd server: support for graphql-ws protocol
https://github.com/hasura/graphql-engine-mono/pull/1655

Co-authored-by: Rakesh Emmadi <12475069+rakeshkky@users.noreply.github.com>
Co-authored-by: Vijay Prasanna <11921040+vijayprasanna13@users.noreply.github.com>
Co-authored-by: hasura-bot <30118761+hasura-bot@users.noreply.github.com>
Co-authored-by: Brandon Simmons <210815+jberryman@users.noreply.github.com>
Co-authored-by: Varun Choudhary <68095256+Varun-Choudhary@users.noreply.github.com>
Co-authored-by: Divi <32202683+imperfect-fourth@users.noreply.github.com>
GitOrigin-RevId: 9db3902388fef06b94f9513255e2b5333bd23c3e
2021-08-24 16:26:12 +00:00
Auke Booij
99963a78c2 server: reduce memory usage during type collection by using a more concrete effect stack
Replaces one instance of `mtl`-style effects with `transformers`-style, as this results in a measurable reduction in memory usage. The change is kept completely within one module.

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

GitOrigin-RevId: 587b8e61725bb4a505404bbe741185759b7bceeb
2021-08-24 09:16:15 +00:00
Auke Booij
67f2f49f33 server: remove stray comment
This re-removes a comment that was previously removed in
7bead93827 and re-added by
f49e13c890

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

GitOrigin-RevId: d16c19c8a0d5bed2a52b8033a1fe20cc6d6a2c92
2021-08-23 15:03:33 +00:00
Robert
c1bdc99334 Fix comment formatting to allow parsing in haddock-mode
This is just a one-off fix, based on running ormolu across
the code base, which uses GHC's parser in haddock mode.

### Description

Fixes several instances of illegal haddock comments.

### Related Issues

#1679

### Steps to test and verify

Run ormolu over the codebase. Prior to this change, it complains that it
can't parse certain files due to malformed Haddock comments, after it
doesn't (there are still some other errors).

### Limitations, known bugs & workarounds

This doesn't ensure that we don't introduce similar issues in the future;
that'll be dealt with once we implement #1679.

#### Breaking changes

- [x] No Breaking changes, only touches code comments

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

GitOrigin-RevId: 7fbab0325ce13a16a04ff98d351f1af768e25d7c
2021-08-16 22:20:25 +00:00
Rakesh Emmadi
c2f667a06d server: correctly generate remote relationship field type
>

### Description
>
From HGE version 2.0 onwards, all remote relationship fields are generated as plain types without non-nullable and lists. This PR fixes the same.

### Changelog

- [x] `CHANGELOG.md` is updated with user-facing content relevant to this PR. If no changelog is required, then add the `no-changelog-required` label.

### Affected components

- [x] Server
- [x] Tests

### Related Issues
->
fix https://github.com/hasura/graphql-engine/issues/7284

### Steps to test and verify
>
- Create a remote relationship to a field in remote schema with non-nullable or list type
- The HGE introspection should give the remote relationship field type correctly as like in the remote schema

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

GitOrigin-RevId: e113f5d17b62bfa0a25028c20260ae1782ae224b
2021-08-12 12:17:52 +00:00
Evie Ciobanu
11b3e1573d [server] generate the correct type for single-row returning functions
https://github.com/hasura/graphql-engine-mono/pull/2055

GitOrigin-RevId: 94c1cc32028054c7ec11d6ada2fc57f0820a4d5e
2021-08-11 12:42:30 +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
Aniket Deshpande
a9fb2710db server/bigquery: implement _in and _nin operators. (close #7343)
https://github.com/hasura/graphql-engine-mono/pull/2033

GitOrigin-RevId: 58d4de268b62c6d7cb6106bec38214e651926816
2021-08-06 19:58:33 +00:00
jkachmar
4a83bb1834 Remote schema execution logic
https://github.com/hasura/graphql-engine-mono/pull/1995

Co-authored-by: David Overton <7734777+dmoverton@users.noreply.github.com>
GitOrigin-RevId: 178669089ec5e63b1f3da1d3ba0a9f8debbc108d
2021-08-06 13:40:37 +00:00
awjchen
3aa0027c40 server: add support for tagged and dynamic metrics
https://github.com/hasura/graphql-engine-mono/pull/1680

GitOrigin-RevId: c92d4f977b5b7fe9a0b71d3841e960a95f722299
2021-08-05 21:08:17 +00:00
David Overton
1000df2e0a Fix/remote nested field customization
https://github.com/hasura/graphql-engine-mono/pull/2009

GitOrigin-RevId: bec59d2173afd6f392997f6bd953775f4a42dd48
2021-08-05 14:59:55 +00:00
jkachmar
c322af93f8 server: Uses GraphQL type in remote variable cache key
https://github.com/hasura/graphql-engine-mono/pull/1801

GitOrigin-RevId: 98843e422b2431849b675acdb318ffae2f492f18
2021-08-04 21:24:36 +00:00
David Overton
9be6d4cd97 Fix getCustomizer test case
https://github.com/hasura/graphql-engine-mono/pull/1986

GitOrigin-RevId: 2f94613a7f6afe89738aee0fc5fba0ab6b19c8da
2021-08-03 13:17:34 +00:00
Swann Moreau
63d5b7ad53 pro, server: improve parameterised query hash handling for batched requests (fix #1767)
https://github.com/hasura/graphql-engine-mono/pull/1768

GitOrigin-RevId: 11615408ee2fb097e68ee4a641e5dc46c1d28795
2021-08-02 16:05:17 +00:00
Evie Ciobanu
e48ccd7fab server: Check session variables for subscriptions
https://github.com/hasura/graphql-engine-mono/pull/1879

GitOrigin-RevId: 78d3384cb21a36e8b8c85c17ae7578ce0b4230f8
2021-07-30 21:42:52 +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
Rakesh Emmadi
a63fa18d9c server/postgres: Support computed fields in permission check/filter
https://github.com/hasura/graphql-engine-mono/pull/1697

GitOrigin-RevId: 6cdf8acc90d3fd97d20a3ee68c84306c3f589370
2021-07-28 08:10:25 +00:00
Rakesh Emmadi
5cfac6ea87 server/postgres: support computed fields in order by
https://github.com/hasura/graphql-engine-mono/pull/1793

GitOrigin-RevId: e0396c0d4d96fc8f9bdbd7567193933db5b295a6
2021-07-27 16:28:23 +00:00
Auke Booij
7bead93827 server: remove remnants of query plan caching (fix #1795)
Query plan caching was introduced by - I believe - hasura/graphql-engine#1934 in order to reduce the query response latency. During the development of PDV in hasura/graphql-engine#4111, it was found out that the new architecture (for which query plan caching wasn't implemented) performed comparably to the pre-PDV architecture with caching. Hence, it was decided to leave query plan caching until some day in the future when it was deemed necessary.

Well, we're in the future now, and there still isn't a convincing argument for query plan caching. So the time has come to remove some references to query plan caching from the codebase. For the most part, any code being removed would probably not be very well suited to the post-PDV architecture of query execution, so arguably not much is lost.

Apart from simplifying the code, this PR will contribute towards making the GraphQL schema generation more modular, testable, and easier to profile. I'd like to eventually work towards a situation in which it's easy to generate a GraphQL schema parser *in isolation*, without being connected to a database, and then parse a GraphQL query *in isolation*, without even listening any HTTP port. It is important that both of these operations can be examined in detail, and in isolation, since they are two major performance bottlenecks, as well as phases where many important upcoming features hook into.

Implementation

The following have been removed:
- The entirety of `server/src-lib/Hasura/GraphQL/Execute/Plan.hs`
- The core phases of query parsing and execution no longer have any references to query plan caching. Note that this is not to be confused with query *response* caching, which is not affected by this PR. This includes removal of the types:
- - `Opaque`, which is replaced by a tuple. Note that the old implementation was broken and did not adequately hide the constructors.
- - `QueryReusability` (and the `markNotReusable` method). Notably, the implementation of the `ParseT` monad now consists of two, rather than three, monad transformers.
- Cache-related tests (in `server/src-test/Hasura/CacheBoundedSpec.hs`) have been removed .
- References to query plan caching in the documentation.
- The `planCacheOptions` in the `TenantConfig` type class was removed. However, during parsing, unrecognized fields in the YAML config get ignored, so this does not cause a breaking change. (Confirmed manually, as well as in consultation with @sordina.)
- The metrics no longer send cache hit/miss messages.

There are a few places in which one can still find references to query plan caching:

- We still accept the `--query-plan-cache-size` command-line option for backwards compatibility. The `HASURA_QUERY_PLAN_CACHE_SIZE` environment variable is not read.

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

GitOrigin-RevId: 17d92b254ec093c62a7dfeec478658ede0813eb7
2021-07-27 11:52:43 +00:00
Evie Ciobanu
4b0f5f09c9 server: add IR support for DB-to-DB joins
GJ IR changes cherry-picked from the original GJ branch. There is a separate (can be merged independently) PR for metadata changes (#1727) and there will be a different PR upcoming PR for execution changes.

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

Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: c31956af29dc9c9b75d002aba7d93c230697c5f4
2021-07-26 13:05:53 +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
Sibi Prabakaran
385d27449e mysql: Metadata awareness
https://github.com/hasura/graphql-engine-mono/pull/1599

Co-authored-by: Chris Done <11019+chrisdone@users.noreply.github.com>
Co-authored-by: Aniket Deshpande <922486+aniketd@users.noreply.github.com>
Co-authored-by: Abby Sassel <3883855+sassela@users.noreply.github.com>
GitOrigin-RevId: 4df4a8ff00fa8ef311a85199d66abe4cc10adc8c
2021-07-15 12:45:51 +00:00
Anon Ray
d8fa32776b server: log query in http-log/ws-log only if query-log is enabled
https://github.com/hasura/graphql-engine-mono/pull/1771

GitOrigin-RevId: 1fb8246f6ebff7e114779f284ba36d510b504f29
2021-07-13 12:24:19 +00:00
Rakesh Emmadi
a375f8c105 server/postgres: Support scalar computed fields in remote joins
https://github.com/hasura/graphql-engine-mono/pull/1692

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
GitOrigin-RevId: fcef85910899859f7421cad554c022f8023965ea
2021-07-12 16:04:37 +00:00
Antoine Leblanc
0a9382f2dc [gardening] remove Alias from Backend
### Description

In our haste to generalize everything for MSSQL, we put every single "suspicious" type in Backend, including ones that weren't required. `Alias` is one of those: it's only used in a type alias, and is actually just an implementation detail of the translation layer. This PR removes it.

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

GitOrigin-RevId: fb348934ec65a51aae7f95d93c83c3bb704587b5
2021-07-09 15:54:56 +00:00
Antoine Leblanc
d91029ad51 [gardening] remove all traverse functions from RQL.IR
### Description

This PR removes all `fmapX` and `traverseX` functions from RQL.IR, favouring instead `Functor` and `Traversable` instances throughout the code. This was a relatively straightforward change, except for two small pain points: `AnnSelectG` and `AnnInsert`. Both were parametric over two types `a` and `v`, making it impossible to make them traversable functors... But it turns out that in every single use case, `a ~ f v`. By changing those types to take such an `f :: Type -> Type` as an argument instead of `a :: Type` makes it possible to make them functors.

The only small difference is for `AnnIns`, I had to introduce one `Identity` transformation for one of the `f` parameters. This is relatively straightforward.

### Notes

This PR fixes the most verbose BigQuery hint (`let` instead of `<- pure`).

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

GitOrigin-RevId: e632263a8c559aa04aeae10dcaec915b4a81ad1a
2021-07-08 15:42:53 +00:00
Rakesh Emmadi
e567a096e6 server/postgres: support computed fields in query filters ('where' expression)
https://github.com/hasura/graphql-engine-mono/pull/1677

GitOrigin-RevId: 30175a442237f6ac4b112c652f448a635ad90dc6
2021-07-07 11:59:32 +00:00
Robert
ae6d624441 server: improve handling of HTTP client errors for remote schema calls
https://github.com/hasura/graphql-engine-mono/pull/1719

GitOrigin-RevId: 5ff671bcff5f0559b9821f8359ebee4129f4b664
2021-07-07 10:15:05 +00:00
Swann Moreau
f6e49500d5 server: log request type (batched/single) in http-log
https://github.com/hasura/graphql-engine-mono/pull/1488

GitOrigin-RevId: 092335d6eb95224b8ed81d853a71fca01379dd7d
2021-07-05 09:46:29 +00:00
Robert
5cc91aebc3 server: Log action and event names (close #1603)
- add name fields to log output in several spots:
  - action logs get the action name in detail.action_name
  - events (triggered and scheduled) get the trigger name in detail.event_name
  - one-off scheduled events don't have a trigger name; instead, they get the
    comment if it exists
- remove unused event creation timestamp from ExtraLogContext

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

GitOrigin-RevId: 28907340d4e2d9adc0c48cc5d3010eef1fa902e1
2021-07-05 07:48:39 +00:00
Anon Ray
f263af31a0 server: add query field to http-log and websocket-log
https://github.com/hasura/graphql-engine-mono/pull/1683

GitOrigin-RevId: 6f46e31bb14f135d528b20ae9513e393c06c3c8a
2021-07-02 13:05:57 +00:00
Sameer Kolhar
c425b77e2d server: fix regression in action responses where aliased fields are dropped
https://github.com/hasura/graphql-engine-mono/pull/1612

GitOrigin-RevId: a031ec2e9fa15df6394382befd9a0db759ef5213
2021-06-21 12:12:07 +00:00
Antoine Leblanc
8a77386fcf server: IR for DB-DB joins
### Description

This PR adds the required IR for DB to DB joins, based on @paf31 and @0x777 's `feature/db-to-db` branch.

To do so, it also refactors the IR to introduce a new type parameter, `r`, which is used to recursively constructs the `v` parameter of remote QueryDBs. When collecting remote joins, we replace `r` with `Const Void`, indicating at the type level that there cannot be any leftover remote join.

Furthermore, this PR refactors IR.Select for readability, moves some code from IR.Root to IR.Select to avoid having to deal with circular dependencies, and makes it compile by adding `error` in all new cases in the execution pipeline.

The diff doesn't make it clear, but most of Select.hs is actually unchanged. Declarations have just been reordered by topic, in the following order:
- type declarations
- instance declarations
- type aliases
- constructor functions
- traverse functions

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

Co-authored-by: Phil Freeman <630306+paf31@users.noreply.github.com>
GitOrigin-RevId: bbdcb4119cec8bb3fc32f1294f91b8dea0728721
2021-06-17 23:13:05 +00:00
Phil Freeman
456caa59e1 server: fix caching for queries using remote schema permissions
https://github.com/hasura/graphql-engine-mono/pull/1579

Co-authored-by: Solomon Bothwell <24038+ssbothwell@users.noreply.github.com>
GitOrigin-RevId: 8fdf33863d812f2ee4edee7eec34150a7dc03231
2021-06-17 19:16:59 +00:00
Solomon Bothwell
99e7e3b7b4 Implement refresh parameter for Cached Directive
https://github.com/hasura/graphql-engine-mono/pull/1523

Co-authored-by: Phil Freeman <630306+paf31@users.noreply.github.com>
GitOrigin-RevId: f83b73d23db15efdd19a61eca35badc3ff235779
2021-06-17 06:28:45 +00:00
Karthikeyan Chinnakonda
62e7fe62db server: log additional info in the livequery poller logs
https://github.com/hasura/graphql-engine-mono/pull/1529

GitOrigin-RevId: 27060632d5ac0da3f695c6755350f4e32dc0efc1
2021-06-16 13:28:17 +00:00
Antoine Leblanc
9a8a211367 server: remove XDistinct, cleanup table arguments
https://github.com/hasura/graphql-engine-mono/pull/1028

GitOrigin-RevId: dae3d46097520f6838b7e95cdda1ab8d53dc9700
2021-06-15 15:54:12 +00:00
Antoine Leblanc
a805f4d185 server: misc cleanups
https://github.com/hasura/graphql-engine-mono/pull/1553

GitOrigin-RevId: b67dc40e54496ed6ad6c85755cf66745664416f7
2021-06-15 15:06:37 +00:00
Vamshi Surabhi
e8e4f30dd6 server: support remote relationships on SQL Server and BigQuery (#1497)
Remote relationships are now supported on SQL Server and BigQuery. The major change though is the re-architecture of remote join execution logic. Prior to this PR, each backend is responsible for processing the remote relationships that are part of their AST.

This is not ideal as there is nothing specific about a remote join's execution that ties it to a backend. The only backend specific part is whether or not the specification of the remote relationship is valid (i.e, we'll need to validate whether the scalars are compatible).

The approach now changes to this:

1. Before delegating the AST to the backend, we traverse the AST, collect all the remote joins while modifying the AST to add necessary join fields where needed.

1. Once the remote joins are collected from the AST, the database call is made to fetch the response. The necessary data for the remote join(s) is collected from the database's response and one or more remote schema calls are constructed as necessary.

1. The remote schema calls are then executed and the data from the database and from the remote schemas is joined to produce the final response.

### Known issues

1. Ideally the traversal of the IR to collect remote joins should return an AST which does not include remote join fields. This operation can be type safe but isn't taken up as part of the PR.

1. There is a lot of code duplication between `Transport/HTTP.hs` and `Transport/Websocket.hs` which needs to be fixed ASAP. This too hasn't been taken up by this PR.

1. The type which represents the execution plan is only modified to handle our current remote joins and as such it will have to be changed to accommodate general remote joins.

1. Use of lenses would have reduced the boilerplate code to collect remote joins from the base AST.

1. The current remote join logic assumes that the join columns of a remote relationship appear with their names in the database response. This however is incorrect as they could be aliased. This can be taken up by anyone, I've left a comment in the code.

### Notes to the reviewers

I think it is best reviewed commit by commit.

1. The first one is very straight forward.

1. The second one refactors the remote join execution logic but other than moving things around, it doesn't change the user facing functionality.  This moves Postgres specific parts to `Backends/Postgres` module from `Execute`. Some IR related code to `Hasura.RQL.IR` module.  Simplifies various type class function signatures as a backend doesn't have to handle remote joins anymore

1. The third one fixes partial case matches that for some weird reason weren't shown as warnings before this refactor

1. The fourth one generalizes the validation logic of remote relationships and implements `scalarTypeGraphQLName` function on SQL Server and BigQuery which is used by the validation logic. This enables remote relationships on BigQuery and SQL Server.

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

GitOrigin-RevId: 77dd8eed326602b16e9a8496f52f46d22b795598
2021-06-11 03:27:39 +00:00
Antoine Leblanc
2d8ac777b3 server: introduce new custom scalars and remove offsetParser
GitOrigin-RevId: 5db058a7ae8f57bdc7e9844fcdd94e31ce11d961
2021-06-10 16:14:21 +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
Antoine Leblanc
8c3808f2bc server: make runMonadSchema backend agnostic
GitOrigin-RevId: ce4e36aedade18d47d035b90a69b9c545ea7d6ed
2021-06-09 13:03:08 +00:00
Vamshi Surabhi
355c3ff736 server: split Internal/Parser to avoid hs-boot files
This is a minor refactor (part of `Internal/Parser.hs` is moved into `Internal/Input.hs`) to remove `Collect.hs-boot` and `Directives.hs-boot` files. Without these changes:
1. Most changes would trigger recompilation from the modules with hs-boot files.
1. haskell-language-server fails for some reason in the presence of hs-boot files.

GitOrigin-RevId: 77a2e443417b449c5d7d9d418fc75fcdf076a9ae
2021-06-03 15:15:12 +00:00
Philip Lykke Carlsen
125f37ea28 Server: Use a bespoke type for nullability instead of Bool
GitOrigin-RevId: a793c7a921174611d44b7e7cdc1dc43b132376fe
2021-05-28 10:40:15 +00:00
Antoine Leblanc
6e95f761f5 server: rewrite remote input parsers to deal with partial variable expansion (fix hasura/graphql-engine#6656)
GitOrigin-RevId: e0b197a0fd1e259d43e6152b726b350c4d527a4b
2021-05-24 20:13:47 +00:00
Abby Sassel
c9e7e10eaa server/bugfix: Include permission filter in the exists clause. Fixes #6931
GitOrigin-RevId: d3080dfa00c96afcf1254d83757a5e50a0726381
2021-05-24 09:09:50 +00:00
Antoine Leblanc
60a119ae22 server: also collect types from directives into the schema
GitOrigin-RevId: 0736570fd8781e66d558bde313d26ad62f7cf6ca
2021-05-21 04:55:32 +00:00
Abby Sassel
1afa4ac3cc server/citus: feature branch
Co-authored-by: Vladimir Ciobanu <1017953+vladciobanu@users.noreply.github.com>
Co-authored-by: Antoine Leblanc <1618949+nicuveo@users.noreply.github.com>
Co-authored-by: Ikechukwu Eze <22247592+iykekings@users.noreply.github.com>
Co-authored-by: Philip Lykke Carlsen <358550+plcplc@users.noreply.github.com>
Co-authored-by: Phil Freeman <630306+paf31@users.noreply.github.com>
GitOrigin-RevId: 1b964fe5f5f50380172cb702b6a328fed782b6b7
2021-05-21 02:47:51 +00:00
Antoine Leblanc
5238bb8011 server: support for custom directives
Co-authored-by: Aravind K P <8335904+scriptonist@users.noreply.github.com>
GitOrigin-RevId: f11b3b2e964af4860c3bb0fd9efec6be54c2e88b
2021-05-20 10:03:50 +00:00
Karthikeyan Chinnakonda
9a99923fef server: support adding a tracked function as a computed field and vice versa
GitOrigin-RevId: 2f4db0b716d493ce245d9fa7e37e11382f18cd67
2021-05-20 06:29:24 +00:00
Antoine Leblanc
dfbdfca144 server: fix order of fields in introspection output
GitOrigin-RevId: edd6af755d46c3d13c8b7b5504f8d89701a3250f
2021-05-19 16:38:54 +00:00
Swann Moreau
a83194239e server: forward request id when not user-provided
GitOrigin-RevId: 78745dda0112321c809220fdcdeaf2adc6f9c3e5
2021-05-19 14:08:00 +00:00
David Overton
ddad668f07 Fix/custom table name
GitOrigin-RevId: 5004717ac7d9e848ca186a1cdf52e375547034bf
2021-05-18 13:37:27 +00:00
Antoine Leblanc
ecb90c47a1 server: fix action output fields return type (fix hasura/graphql-engine#6631)
GitOrigin-RevId: 9be5ac87fe69c55aafb6b5af918eb4deb97e27d5
2021-05-18 09:32:43 +00:00
Antoine Leblanc
4fce62d125 server: fix action poller being a bit too eager
GitOrigin-RevId: a767123e49aeb3ee472e9313a86b55a30db468e4
2021-05-17 06:00:02 +00:00
Karthikeyan Chinnakonda
ecb4b9d098 server: graceful shutdown for event and cron triggers and async action (II)
GitOrigin-RevId: 2090c3cc34f633c691b4e4ff9ae918a60c37ce26
2021-05-14 09:39:33 +00:00
Antoine Leblanc
2152911e24 server: introduce Hasura.Base (take 2)
GitOrigin-RevId: 0dd10f1ccd338b1cf382ebff59b6ee7f209d39a1
2021-05-11 15:19:33 +00:00
Chris Done
56c094b299 Support query explain for MSSQL (fixes #1024)
Co-authored-by: Abby Sassel <3883855+sassela@users.noreply.github.com>
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 5a57d7570884a5469a947742e4ab9290a0cff55f
2021-05-11 10:05:39 +00:00
Antoine Leblanc
d22d26b39c server: fix BigQuery's hack for explain.
GitOrigin-RevId: 6668e16dee1a6bb0b666cfe0b4727f2c4f3181fb
2021-05-05 16:20:54 +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
Anon Ray
3adbbcd219 server: add EKG metrics for active subscriptions
GitOrigin-RevId: 348245eebf5c3ddaf975707a23125e1bb057fe34
2021-05-05 04:25:07 +00:00
Antoine Leblanc
34fc92ea8c server: fix validation of query variables (fixes hasura/graphql-engine#6867)
GitOrigin-RevId: 395bf986e0b823f9f18fb9f204e2056b2d2fd682
2021-05-04 17:58:43 +00:00
Anon Ray
7550761853 server: add active websocket connections to server metrics
GitOrigin-RevId: 5177d1c90ffd48c7e28f8ffb726753cb55c89b7f
2021-04-29 10:32:15 +00:00
Swann Moreau
c834629afb server: fix regression in query-log generation
Co-authored-by: Anon Ray <616387+ecthiender@users.noreply.github.com>
GitOrigin-RevId: 74cc6bad2274dc1587f4d3b38e444857d079a4ac
2021-04-28 17:39:02 +00:00
Karthikeyan Chinnakonda
aca8964fdc server: make postgres related ENV vars source specific
Co-authored-by: Tirumarai Selvan <8663570+tirumaraiselvan@users.noreply.github.com>
Co-authored-by: Vishnu Bharathi <4211715+scriptnull@users.noreply.github.com>
GitOrigin-RevId: 8ec3db00f00e9c28bf2dc0f47bd312a656c61a69
2021-04-28 16:50:14 +00:00
Antoine Leblanc
5283eebf75 server: fix on_conflict missing when no column update permissions
GitOrigin-RevId: 34dd9f648ca1e268274b6244c48c9e9710c4477d
2021-04-22 10:27:35 +00:00
Antoine Leblanc
ba70ca427a server: switch to a sub-backend approach
GitOrigin-RevId: 660126d5f65620fb58a3ffcbed564e9e35f59938
2021-04-21 21:45:32 +00:00
Antoine Leblanc
84ed74aba1 server: fix empty remote input objects (fixes #6029, #6703)
GitOrigin-RevId: 3c474ee85b5d1271abfc8848e29ae1d3be28ff63
2021-04-21 01:17:01 +00:00
Abby Sassel
703928de9f mssql: support query multiplexing in subscriptions
GitOrigin-RevId: 757ceba2c1cdb1107ce0b0e41d2e70ac795d0d73
2021-04-20 16:58:13 +00:00
Lyndon Maydwell
33f6ffecec Generating query-log for cached requests
GitOrigin-RevId: fe620d0860854b257ab4901ad301646bacd15e0d
2021-04-19 01:23:01 +00:00
Antoine Leblanc
dd1192ca2c server: cleanup of language extensions [gardening]
GitOrigin-RevId: d862c724715cb8a4c2f37d2e0e525d12c46b18eb
2021-04-16 06:55:56 +00:00
Abby Sassel
791f136d09 server/mssql: Plug in the Explain API
Co-authored-by: Antoine Leblanc <1618949+nicuveo@users.noreply.github.com>
GitOrigin-RevId: 069055449f6a005f433ee80a4f92b962f21aa714
2021-04-13 11:11:23 +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
Chris Done
f7a202a363 BigQuery Feature Branch
This will implement BigQuery support.

Co-authored-by: Antoine Leblanc <1618949+nicuveo@users.noreply.github.com>
Co-authored-by: Sibi Prabakaran <737477+psibi@users.noreply.github.com>
Co-authored-by: Aniket Deshpande <922486+aniketd@users.noreply.github.com>
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 1a6ffaf34233e13e8125a5c908eaa7e32d65007b
2021-04-12 10:19:20 +00:00
Antoine Leblanc
1a4aad4ba1 server: introduce option to revert to v1 boolean collapse behaviour
GitOrigin-RevId: af6c944270301d8b17618a706ab328a28c0e51dc
2021-04-08 08:26:18 +00:00
Karthikeyan Chinnakonda
ce4794cdcc pro-server: log parameterized query hash for GraphQL queries
GitOrigin-RevId: e804d0b3397a0ae8df05225be43de264babd3de3
2021-04-06 17:53:55 +00:00
Antoine Leblanc
71ae144aa6 server: implement transaction workaround
GitOrigin-RevId: 404f8bbdefb8a99b31fac75e4253daad81c8af90
2021-04-01 20:41:41 +00:00
Rakesh Emmadi
362230e8d0 server: async action query subscription
Multi source support had limited the availability of async action queries in subscriptions. This PR
adds support for async action query subscriptions with new implementation. Also addresses https://github.com/hasura/graphql-engine/issues/6460.

GitOrigin-RevId: 5ddc321073d224f287dc4b86ce2239ff55190b36
2021-03-31 10:40:15 +00:00
Karthikeyan Chinnakonda
3e880be55f server: efficient polling for cron triggers and async actions
GitOrigin-RevId: 210df9e6e660b90fb74e930a8909129edba4e7a3
2021-03-30 12:58:40 +00:00
Antoine Leblanc
d8c56a40f6 server: split boolean operators between core and backend-specific
GitOrigin-RevId: f1291946a1122220e82371676d88867fd7b2b7c4
2021-03-25 17:51:08 +00:00
Rakesh Emmadi
97549ccc8e server: fix action output type generation (#850)
* fix action output type generation

* update CHANGELOG.md

GitOrigin-RevId: 558ff640f5fe5dd5ebf15a3c063f1b989a5fb28a
2021-03-22 10:57:46 +00:00
Antoine Leblanc
f1183b8ae3 server: memoize recursive action input arguments
GitOrigin-RevId: 0dc11f95953f6ad8dfcd82a11f105442042291f8
2021-03-19 14:47:58 +00:00
Antoine Leblanc
b7e964952f server: move backendTag to its own class.
GitOrigin-RevId: 4d22215611079f01c5f31ab3adc996ec7e5e390e
2021-03-19 11:00:37 +00:00
Antoine Leblanc
1abe5d4902 server: combine instance imports
GitOrigin-RevId: 4deab805ceef1202e5a2d04f0568fa33df3ff791
2021-03-18 17:40:45 +00:00
Vladimir Ciobanu
91710bba58 server: use relative paths in TH splices
While debugging issues with HLS, Reed Mullanix noticed that we don't use relative paths. This leads to problems when using HLS + Emacs due to a bug in `lsp-mode` which prevents it from finding the correct project root.

However, it is still a good practice to use relative paths in TH for other reasons, including being able to import these modules in GHCI.

This PR should make it so HLS-1.0 & emacs provide type inference, imports, etc., in all modules in our codebase.

GitOrigin-RevId: 5f53b9a7ccf46df1ea7be94ff0a5c6ec861f4ead
2021-03-16 17:36:39 +00:00
Solomon Bothwell
e4b669e56b Traverses RFAction RootField cnstr to accumulate session variables
GitOrigin-RevId: 148bc50c59820254dc40b8951e43abadcac2c25b
2021-03-16 06:13:31 +00:00
Vladimir Ciobanu
da8f6981d4 server: reduce the number of backend dispatches
Fixes https://github.com/hasura/graphql-engine-mono/issues/712

Main point of interest: the `Hasura.SQL.Backend` module.

This PR creates an `Exists` type indexed by indexed type and packed constraint while hiding all of its complexity by not exporting the constructor.

Existential constructors/types which are no longer (directly) existential:
- [X] BackendSourceInfo :: BackendSourceInfo
- [x] BackendSourceMetadata :: BackendSourceMetadata
- [x] MOSourceObjId :: MetadatObjId
- [x] SOSourceObj :: SchemaObjId
- [x] RFDB :: RootField
- [x] LQP :: LiveQueryPlan
- [x] ExecutionStep :: ExecStepDB

This PR also removes ALL usages of `Typeable.cast` from our codebase. We still need to derive `Typeable` in a few places in order to be able to derive `Data` in one place. I have not dug deeper to see why this is needed.

GitOrigin-RevId: bb47e957192e4bb0af4c4116aee7bb92f7983445
2021-03-15 13:03:55 +00:00
Karthikeyan Chinnakonda
6093010a6e server: fix issue of parsing input objects in remote schema queries
GitOrigin-RevId: 98c62cab836aff2778dbfedd6535450989090a30
2021-03-15 06:32:07 +00:00
Antoine Leblanc
a544fe9822 server: generalized LogQueryLog (fix #708)
GitOrigin-RevId: 0e18e0f5caaa6889804debf7111ef9aa99e080b5
2021-03-13 14:41:44 +00:00
Rakesh Emmadi
2b0c990d50 server: remove Action.hs-boot file
GitOrigin-RevId: 65267a7b6343a12b690f7710785fdfa30873e479
2021-03-10 07:27:19 +00:00
Karthikeyan Chinnakonda
0a7d634326 server: fix issue when remote relationship col has a custom GQL name
GitOrigin-RevId: ca45383020d0e8f80afb445ab8bb240cc1505ea9
2021-03-09 09:25:29 +00:00
Karthikeyan Chinnakonda
92026b769f [Preview] Inherited roles for postgres read queries
fixes #3868

docker image - `hasura/graphql-engine:inherited-roles-preview-48b73a2de`

Note:

To be able to use the inherited roles feature, the graphql-engine should be started with the env variable `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` set to `inherited_roles`.

Introduction
------------

This PR implements the idea of multiple roles as presented in this [paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/FGALanguageICDE07.pdf). The multiple roles feature in this PR can be used via inherited roles. An inherited role is a role which can be created by combining multiple singular roles. For example, if there are two roles `author` and `editor` configured in the graphql-engine, then we can create a inherited role with the name of `combined_author_editor` role which will combine the select permissions of the `author` and `editor` roles and then make GraphQL queries using the `combined_author_editor`.

How are select permissions of different roles are combined?
------------------------------------------------------------

A select permission includes 5 things:

1. Columns accessible to the role
2. Row selection filter
3. Limit
4. Allow aggregation
5. Scalar computed fields accessible to the role

 Suppose there are two roles, `role1` gives access to the `address` column with row filter `P1` and `role2` gives access to both the `address` and the `phone` column with row filter `P2` and we create a new role `combined_roles` which combines `role1` and `role2`.

Let's say the following GraphQL query is queried with the `combined_roles` role.

```graphql
query {
   employees {
     address
     phone
   }
}
```

This will translate to the following SQL query:

```sql

 select
    (case when (P1 or P2) then address else null end) as address,
    (case when P2 then phone else null end) as phone
 from employee
 where (P1 or P2)
```

The other parameters of the select permission will be combined in the following manner:

1. Limit - Minimum of the limits will be the limit of the inherited role
2. Allow aggregations - If any of the role allows aggregation, then the inherited role will allow aggregation
3. Scalar computed fields - same as table column fields, as in the above example

APIs for inherited roles:
----------------------

1. `add_inherited_role`

`add_inherited_role` is the [metadata API](https://hasura.io/docs/1.0/graphql/core/api-reference/index.html#schema-metadata-api) to create a new inherited role. It accepts two arguments

`role_name`: the name of the inherited role to be added (String)
`role_set`: list of roles that need to be combined (Array of Strings)

Example:

```json
{
  "type": "add_inherited_role",
  "args": {
      "role_name":"combined_user",
      "role_set":[
          "user",
          "user1"
      ]
  }
}
```

After adding the inherited role, the inherited role can be used like single roles like earlier

Note:

An inherited role can only be created with non-inherited/singular roles.

2. `drop_inherited_role`

The `drop_inherited_role` API accepts the name of the inherited role and drops it from the metadata. It accepts a single argument:

`role_name`: name of the inherited role to be dropped

Example:

```json

{
  "type": "drop_inherited_role",
  "args": {
      "role_name":"combined_user"
  }
}
```

Metadata
---------

The derived roles metadata will be included under the `experimental_features` key while exporting the metadata.

```json
{
  "experimental_features": {
    "derived_roles": [
      {
        "role_name": "manager_is_employee_too",
        "role_set": [
          "employee",
          "manager"
        ]
      }
    ]
  }
}
```

Scope
------

Only postgres queries and subscriptions are supported in this PR.

Important points:
-----------------

1. All columns exposed to an inherited role will be marked as `nullable`, this is done so that cell value nullification can be done.

TODOs
-------

- [ ] Tests
   - [ ] Test a GraphQL query running with a inherited role without enabling inherited roles in experimental features
   - [] Tests for aggregate queries, limit, computed fields, functions, subscriptions (?)
   - [ ] Introspection test with a inherited role (nullability changes in a inherited role)
- [ ] Docs
- [ ] Changelog

Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: 3b8ee1e11f5ceca80fe294f8c074d42fbccfec63
2021-03-08 11:15:10 +00:00
hasura-bot
da3c9f2c53 minor typo fixes (#165)
Co-authored-by: Colby Thomas <coloradocolby@gmail.com>
GITHUB_PR_NUMBER: 6311
GITHUB_PR_URL: https://github.com/hasura/graphql-engine/pull/6311

Co-authored-by: Colby Thomas <coloradocolby@gmail.com>
Co-authored-by: Vamshi Surabhi <0x777@users.noreply.github.com>
GitOrigin-RevId: 946665878fb9199d067ad1bd981de9525e86a0ae
2021-03-04 06:36:15 +00:00
Vladimir Ciobanu
d5ff1acf2d better handling for one-to-one relationships
Co-authored-by: Rikin Kachhia <54616969+rikinsk@users.noreply.github.com>
GitOrigin-RevId: 1bb5bc0c4ac8109ee1d20563d23cf98e0906a483
2021-03-03 13:02:59 +00:00
Karthikeyan Chinnakonda
15ed0cf536 server: document the remote joins architecture
GitOrigin-RevId: f142908fa3dd3b0cb8887521c639be4a017e606a
2021-03-03 11:47:13 +00:00
Vladimir Ciobanu
ddbc497506 docs: add note on existentials and references to it
Added a note on existentials. I plan to create a subsequent PR with a note on how we use the singletons trick to recover the type inside an existential.

GitOrigin-RevId: 1f227d859dcc384b4ac7e103053f643f879827d1
2021-03-01 21:38:50 +00:00
Vladimir Ciobanu
281cb771ff server: add MSSQL support
Co-authored-by: Rakesh Emmadi <12475069+rakeshkky@users.noreply.github.com>
Co-authored-by: Antoine Leblanc <1618949+nicuveo@users.noreply.github.com>
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
Co-authored-by: Aravind K P <8335904+scriptonist@users.noreply.github.com>
GitOrigin-RevId: 699c453b9692e1b822f393f23ff5e6db4e010d57
2021-02-23 17:38:36 +00:00
Antoine Leblanc
377425ff2d server: generalize subscriptions
GitOrigin-RevId: 464e80abf151032dc50eaf6cf8dafc5e7cfa51cd
2021-02-20 13:46:43 +00:00
Karthikeyan Chinnakonda
7be72d7bee server: support for maintenance mode in v1.4
Co-authored-by: Anon Ray <616387+ecthiender@users.noreply.github.com>
GitOrigin-RevId: 85f636b1bc8063689845da90e85cc480e87dca7e
2021-02-18 16:47:22 +00:00
Rakesh Emmadi
9ef603360c server: generalize schema cache building (#496)
Co-authored-by: Vamshi Surabhi <vamshi@hasura.io>
Co-authored-by: Vladimir Ciobanu <admin@cvlad.info>
Co-authored-by: Antoine Leblanc <antoine@hasura.io>
Co-authored-by: Stylish Haskell Bot <stylish-haskell@users.noreply.github.com>
GitOrigin-RevId: 9d631878037637f3ed2994b5d0525efd978f7b8f
2021-02-14 06:08:46 +00:00
Phil Freeman
7fffc11077 Caching, Rate Limiting, Metrics & Session Variable Improvements (#376)
* server: use a leaky bucket algorithm for bytes-per-second cache rate limiting

* Use evalsha properly

* Adds redis cache limit parameters to PoliciesConfig

* Loads Leaky Bucket Script On Server Start

* Adds more redis logging and moves cache update into lua script

* reverts setex in lua and adds notes

* Refactors cacheStore and adds max TTL and cache size limits

* Filter session vars in cache key

* WIP

* parens

* cache-clear-hander POC implementation

* cache-clear-hander POC implementation

* Pro projectId used as cache key

* POC working!

* prefixing query-response keys in redis

* Add cacheClearer to RedisScripts

* Partial implementation of cacheClearer from scripts record

* updating tests

* [automated] stylish-haskell commit

* Adds query look with up with metrics script

* Adds missing module and lua script from last commit

* Changes redis script module structure to match cache clearing branch

* minor change to lua script

* cleaning up cache clearing

* generalising JsonLog

* [automated] stylish-haskell commit

* Draft Cache Metrics Endpoint

* Adds Cache Metrics Handler

* Adds hook handler module

* Missed HandlerHook module in last commit

* glob

* Fixes redis mget bug

* Removes cache totals and changes dashes to colons in metric cache keys

* Adds query param to clear clear endpoint for deleting specific keys

* Adds query param to clear clear endpoint for deleting specific keys

* Cache Metrics on query families rather then queries

* Replace Set with nub

* Base16 Redis Hashes

* Query Family Redis Keys With Roles

* response headers for cache keys

* fixing bug in family key by excluding operation name; using hash for response header instead of entire key

* Adds query family to redis cache keys and cache clear endpoint

* Fixes queryfamily hash bug

* Moves cache endpoints to /pro

* Moved cache clear to POST

* Refactors cache clear function

* Fixes query family format bug

* Adds query cache tests and optional --redis-url flag to python test suite

* Adds session variable cache test

* Update pro changelog

* adding documentation for additional caching features

* more docs

* clearing up units of leaky bucket params

* Adds comments to leaky bucket script

* removes old todo

* Fixes session variable filtering to work with new query rootfield

* more advanced defaulting behaviour for bucket rate and capacity.

* Updates Docs

* Moves Role into QueryFamily hash

* Use Aeson for Cache Clear endpoint response

* Moves trace to bracket the leaky bucket script

* Misc review tweaks

* Adds sum type for cache clear query params

* Hardcodes RegisReplyLog log level

* Update docs/graphql/cloud/response-caching.rst

Co-authored-by: Phil Freeman <phil@hasura.io>

* new prose for rate limiting docs

* [automated] stylish-haskell commit

* make rootToSessVarPreds total

* [automated] stylish-haskell commit

* Fixes out of scope error

* Renamed _acRedis to _acCacheStore

Co-authored-by: Solomon Bothwell <ssbothwell@gmail.com>
Co-authored-by: Lyndon Maydwell <lyndon@sordina.net>
Co-authored-by: David Overton <david@hasura.io>
Co-authored-by: Stylish Haskell Bot <stylish-haskell@users.noreply.github.com>
Co-authored-by: Lyndon Maydwell <lyndon@hasura.io>
GitOrigin-RevId: dda5c1a3f902967b3d78310f950541a55fabb1b0
2021-02-13 00:06:18 +00:00
Karthikeyan Chinnakonda
8a68cc6650 server: don't expose remote schema mutations in relay
GitOrigin-RevId: 21c126bfd46a22d3b0e64d57e92d78ea3c4df9ab
2021-02-12 13:29:19 +00:00
Antoine Leblanc
1ca4034697 server: generalize execution of queries and mutations
GitOrigin-RevId: aff477a0849d4667f2f6dc6804d6ca2982e53f95
2021-02-12 03:05:05 +00:00
Matthew Pickering
35b81f39e9 Memory performance improvements from Cherre (#518)
* Stop shutdown handler retaining the whole serveCtx

This might look like quite a strange way to write the function but it's
the only way I could get GHC to not capture `serveCtx` in the shutdown
handler.

Fixes the metadata issue in #344

* Force argumentNames

The arguments list is often empty so we end up with a lot of duplicate
thunks if this value is not forced.

* Increase sharing in nullableType and nonNullableType

The previous definitions would lead to increased allocation as it would
destory any previously created sharing. The new definition only allocate
a fresh constructor if the value is changed.

* Add memoization for field parsers

It was observed in #344 that many parsers were not being memoised which
led to an increase in memory usage. This patch generalisation memoisation so
that it works for FieldParsers as well as normal Parsers.

There can still be substantial improvement made by also memoising
InputFieldParsers but that is left for future work.

Co-authored-by: Antoine Leblanc <antoine@hasura.io>

* [automated] stylish-haskell commit

* changelog

Co-authored-by: Phil Freeman <paf31@cantab.net>
Co-authored-by: Antoine Leblanc <antoine@hasura.io>
Co-authored-by: Stylish Haskell Bot <stylish-haskell@users.noreply.github.com>
Co-authored-by: Phil Freeman <phil@hasura.io>
GitOrigin-RevId: 36255f77a47cf283ea61df9d6a4f9138d4e5834c
2021-02-12 01:34:56 +00:00
Anon Ray
06b599b747 server: multitenant metadata storage
The metadata storage implementation for graphql-engine-multitenant.

- It uses a centralized PG database to store metadata of all tenants (instead of per tenant database)
- Similarly, it uses a single schema-sync listener thread per MT worker (instead of listener thread per tenant) (PS: although, the processor thread is spawned per tenant)
- 2 new flags are introduced - `--metadataDatabaseUrl` and (optional) `--metadataDatabaseRetries`

Internally, a "metadata mode" is introduced to indicate an external/managed store vs a store managed by each pro-server.

To run :
- obtain the schema file (located at `pro/server/res/cloud/metadata_db_schema.sql`)
- apply the schema on a PG database
- set the `--metadataDatabaseUrl` flag to point to the above database
- run the MT executable

The schema (and its migrations) for the metadata db is managed outside the MT worker.

### New metadata

The following is the new portion of `Metadata` added :

```yaml
version: 3
metrics_config:
  analyze_query_variables: true
  analyze_response_body: false
api_limits:
  disabled: false
  depth_limit:
    global: 5
    per_role:
      user: 7
      editor: 9
  rate_limit:
    per_role:
      user:
        unique_params:
        - x-hasura-user-id
        - x-hasura-team-id
        max_reqs_per_min: 20
    global:
      unique_params: IP
      max_reqs_per_min: 10
```

- In Pro, the code around fetching/updating/syncing pro-config is removed
- That also means, `hdb_pro_catalog` for keeping the config cache is not required. Hence the `hdb_pro_catalog` is also removed
- The required config comes from metadata / schema cache

### New Metadata APIs

- `set_api_limits`
- `remove_api_limits`
- `set_metrics_config`
- `remove_metrics_config`

#### `set_api_limits`

```yaml
type: set_api_limits
args:
  disabled: false
  depth_limit:
    global: 5
    per_role:
      user: 7
      editor: 9
  rate_limit:
    per_role:
      anonymous:
         max_reqs_per_min: 10
         unique_params: "ip"
      editor:
        max_reqs_per_min: 30
        unique_params:
        - x-hasura-user-id
      user:
        unique_params:
        - x-hasura-user-id
        - x-hasura-team-id
        max_reqs_per_min: 20
    global:
      unique_params: IP
      max_reqs_per_min: 10
```

#### `remove_api_limits`

```yaml
type: remove_api_limits
args: {}
```

#### `set_metrics_config`

```yaml
type: set_metrics_config
args:
  analyze_query_variables: true
  analyze_response_body: false
```

#### `remove_metrics_config`

```yaml
type: remove_metrics_config
args: {}
```

#### TODO
- [x] on-prem pro implementation for `MonadMetadataStorage`
- [x] move the project config from Lux to pro metadata (PR: #379)
- [ ] console changes for pro config/api limits, subscription workers (cc @soorajshankar @beerose)
- [x] address other minor TODOs
  - [x] TxIso for `MonadSourceResolver`
  - [x] enable EKG connection pool metrics
  - [x] add logging of connection info when sources are added?
  - [x] confirm if the `buildReason` for schema cache is correct
- [ ] testing
- [x] 1.3 -> 1.4 cloud migration script (#465; PR: #508)
  - [x] one-time migration of existing metadata from users' db to centralized PG
  - [x] one-time migration of pro project config + api limits + regression tests from metrics API  to metadata
- [ ] integrate with infra team (WIP - cc @hgiasac)
  - [x] benchmark with 1000+ tenants + each tenant making read/update metadata query every second (PR: https://github.com/hasura/graphql-engine-mono/pull/411)
  - [ ] benchmark with few tenants having large metadata (100+ tables etc.)
  - [ ] when user moves regions (https://github.com/hasura/lux/issues/1717)
    - [ ] metadata has to be migrated from one regional PG to another
    - [ ] migrate metrics data as well ?
      - [ ] operation logs
      - [ ] regression test runs

- [ ] find a way to share the schema files with the infra team

Co-authored-by: Naveen Naidu <30195193+Naveenaidu@users.noreply.github.com>
GitOrigin-RevId: 39e8361f2c0e96e0f9e8f8fb45e6cc14857f31f1
2021-02-11 17:55:21 +00:00