1
0
mirror of https://github.com/hasura/graphql-engine.git synced 2024-12-21 06:21:39 +03:00
Commit Graph

68 Commits

Author SHA1 Message Date
Abby Sassel
9d93baa96f server/postgres: parameterise array variables in queries/subscriptions
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4776
Co-authored-by: Tom Harding <6302310+i-am-tom@users.noreply.github.com>
Co-authored-by: Brandon Martin <40686+codedmart@users.noreply.github.com>
GitOrigin-RevId: ca962e3bfaa28ef00c5d04273d6604348d7da1c8
2022-06-29 13:37:11 +00:00
Auke Booij
8ccf7724ce server: Metadata origin for definitions (type parameter version v2)
The code that builds the GraphQL schema, and `buildGQLContext` in particular, is partial: not every value of `(ServerConfigCtx, GraphQLQueryType, SourceCache, HashMap RemoteSchemaName (RemoteSchemaCtx, MetadataObject), ActionCache, AnnotatedCustomTypes)` results in a valid GraphQL schema. When it fails, we want to be able to return better error messages than we currently do.

The key thing that is missing is a way to trace back GraphQL type information to their origin from the Hasura metadata. Currently, we have a number of correctness checks of our GraphQL schema. But these correctness checks only have access to pure GraphQL type information, and hence can only report errors in terms of that. Possibly the worst is the "conflicting definitions" error, which, in practice, can only be debugged by Hasura engineers. This is terrible DX for customers.

This PR allows us to print better error messages, by adding a field to the `Definition` type that traces the GraphQL type to its origin in the metadata. So the idea is simple: just add `MetadataObjId`, or `Maybe` that, or some other sum type of that, to `Definition`.

However, we want to avoid having to import a `Hasura.RQL` module from `Hasura.GraphQL.Parser`. So we instead define this additional field of `Definition` through a new type parameter, which is threaded through in `Hasura.GraphQL.Parser`. We then define type synonyms in `Hasura.GraphQL.Schema.Parser` that fill in this type parameter, so that it is not visible for the majority of the codebase.

The idea of associating metadata information to `Definition`s really comes to fruition when combined with . Their combination would allow us to use the API of fatal errors (just like the current `MonadError QErr`) to report _inconsistencies_ in the metadata. Such inconsistencies are then _automatically_ ignored. So no ad-hoc decisions need to be made on how to cut out inconsistent metadata from the GraphQL schema. This will allow us to report much better errors, as well as improve the likelihood of a successful HGE startup.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4770
Co-authored-by: Samir Talwar <47582+SamirTalwar@users.noreply.github.com>
GitOrigin-RevId: 728402b0cae83ae8e83463a826ceeb609001acae
2022-06-28 15:53:44 +00:00
Tom Harding
16213a9b77 Remove resolveUnpreparedValue
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4743
GitOrigin-RevId: 1d532ac2475e292e587581ac840d056e3b96a951
2022-06-15 18:17:23 +00:00
Auke Booij
13fc1c62d1 Move Hasura.GraphQL.Parser.Column to .RQL.IR. and .GraphQL.Schema.
This is a first step towards clarifying the role of `UnpreparedValue` as part of the IR. It certainly does not belong in the parser framework.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4588
GitOrigin-RevId: d1582a0b266729b79e00d31057178a4099168e6d
2022-05-30 22:07:57 +00:00
Antoine Leblanc
f684fecc6c Cut ties with RQL.DML.Internal
## Description

As the name suggests, `DML.Internal` contains internal implementation details of RQL's DML. However, a lot of unrelated parts of the codebase still use some of the code it contains. This PR fixes this, and removes all imports of `RQL.DML.Internal` from outside of `RQL.DML`. Most of the time, this involves moving a function out of `DML.Internal` to an underlying module (see `getRolePermInfo`) or moving a function _back_ into it (see `checkRetCols`).

This PR also clarifies a bit the situation with `withTyAnn` and `withTypeAnn` by renaming the former into `withScalarTypeAnn` and moving them together. Worth noting: there might be a bug lurking in that function, as it doesn't seem to use the proper type annotations for some extension types!

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4380
GitOrigin-RevId: c8ae5b4e8378fefc0bcccf778d97813df727d3cb
2022-04-27 15:37:23 +00:00
Antoine Leblanc
3cbcbd9291 Remove RQL/Types.hs
## Description

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

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4363
GitOrigin-RevId: 894f29a19bff70b3dad8abc5d9858434d5065417
2022-04-27 13:58:47 +00:00
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
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
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
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
Puru Gupta
6ad050a29c multitenant: fix concurrent metadata init (closes )
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3983
GitOrigin-RevId: 6fa30a68b1f3d450e9da7b722b9e4938c71e7091
2022-03-24 11:51:59 +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
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
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
Evie Ciobanu
b74ed10cb5 server: trivial refactor in postgres insert
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3746
GitOrigin-RevId: 3d3004862bb64bef55d2716f4c2a86f95343cab5
2022-02-21 18:22:56 +00:00
Robert
ef64590985 server: remove an unused type and export
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3671
GitOrigin-RevId: 2d31c0131519be77366a7f1b761b8a07cfd36003
2022-02-15 19:56:13 +00:00
Evie Ciobanu
9337edf096 Evie/postgres/module docs
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3563
GitOrigin-RevId: e35aafbd210d526ed53db7088e1a47f89f0b9c44
2022-02-08 09:25:35 +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
Evie Ciobanu
974113c80e server: Improve code readability around OnConflict clauses
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3181
GitOrigin-RevId: 0ded0f2776fcbaaf51420f796673cf132b8cc248
2021-12-20 11:16:46 +00:00
Chris Parks
038a6113c3 Remove Identifier associated type family from Backend class (close )
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
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
Abby Sassel
3166010ac1 server: belatedly address feedback
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2945
GitOrigin-RevId: 8ccb6479391c2b38af6a4c9ac209e29d4e26f65c
2021-11-24 21:40:44 +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
Robert
9d185ffa03 server: make /healthz action clearer
This is effectively a no-op, the `Left err` case can't actually happen.

- removes some unused logic
- refactors the /healthz endpoint to be clearer
- that includes logging the full QErr if checkMetadataHealth fails,
  but it actually can't because the existing Postgres implementation
  just lifts

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/2849
GitOrigin-RevId: ac8abf51b6d869ad4048419e36012137c86e5abd
2021-11-17 17:59:39 +00:00
Robert
71af68e9e5 server: drop HasVersion implicit parameter (closes )
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
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
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
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
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
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
Naveen Naidu
f49e13c890 server: SQL query tags for GQL operations (closes )
https://github.com/hasura/graphql-engine-mono/pull/1393

GitOrigin-RevId: f867c16d8281865dac38c91f7dfcbf5815de898c
2021-07-29 08:30:10 +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
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
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 ()
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
Swann Moreau
8e3e7501c7 server: do not collect metrics for sources that have been dropped
GitOrigin-RevId: ed439426527237c2907df77f45582dbe566aeb51
2021-05-26 07:41:28 +00:00
Antoine Leblanc
6e95f761f5 server: rewrite remote input parsers to deal with partial variable expansion (fix )
GitOrigin-RevId: e0b197a0fd1e259d43e6152b726b350c4d527a4b
2021-05-24 20:13:47 +00:00
Anon Ray
63594e1828 server: fix referenced session vars for live queries when UDF has specified session argument
GitOrigin-RevId: 23efdf4d3b3902b5ce7ec14061faa53b18258e86
2021-05-24 07:34:33 +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
08d605baca gardening: move RQL.Instances to Base and clean it
GitOrigin-RevId: 01fa4133a4002f891d213c1f913511ccfd3c1741
2021-05-13 13:18:33 +00:00
Antoine Leblanc
2152911e24 server: introduce Hasura.Base (take 2)
GitOrigin-RevId: 0dd10f1ccd338b1cf382ebff59b6ee7f209d39a1
2021-05-11 15:19:33 +00:00
Antoine Leblanc
ba70ca427a server: switch to a sub-backend approach
GitOrigin-RevId: 660126d5f65620fb58a3ffcbed564e9e35f59938
2021-04-21 21:45:32 +00:00
Abby Sassel
703928de9f mssql: support query multiplexing in subscriptions
GitOrigin-RevId: 757ceba2c1cdb1107ce0b0e41d2e70ac795d0d73
2021-04-20 16:58:13 +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
Antoine Leblanc
d8c56a40f6 server: split boolean operators between core and backend-specific
GitOrigin-RevId: f1291946a1122220e82371676d88867fd7b2b7c4
2021-03-25 17:51:08 +00:00
Karthikeyan Chinnakonda
92026b769f [Preview] Inherited roles for postgres read queries
fixes 

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
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