2022-05-26 17:05:13 +03:00
|
|
|
{-# LANGUAGE UndecidableInstances #-}
|
|
|
|
|
2021-06-11 06:26:50 +03:00
|
|
|
module Hasura.RQL.IR.Root
|
2021-09-24 01:56:37 +03:00
|
|
|
( SourceConfigWith (..),
|
|
|
|
RootField (..),
|
|
|
|
MutationDB (..),
|
|
|
|
ActionQuery (..),
|
|
|
|
ActionMutation (..),
|
|
|
|
QueryRootField,
|
|
|
|
MutationRootField,
|
2022-06-07 08:32:08 +03:00
|
|
|
SubscriptionRootField,
|
2021-09-24 01:56:37 +03:00
|
|
|
QueryDBRoot (..),
|
|
|
|
MutationDBRoot (..),
|
2021-12-07 16:12:02 +03:00
|
|
|
RemoteRelationshipField (..),
|
2021-09-24 01:56:37 +03:00
|
|
|
)
|
|
|
|
where
|
|
|
|
|
|
|
|
import Data.Aeson.Ordered qualified as JO
|
|
|
|
import Data.Kind (Type)
|
|
|
|
import Hasura.Prelude
|
2022-05-14 14:09:29 +03:00
|
|
|
import Hasura.RQL.IR.Action
|
2021-09-24 01:56:37 +03:00
|
|
|
import Hasura.RQL.IR.Delete
|
|
|
|
import Hasura.RQL.IR.Insert
|
2021-12-07 16:12:02 +03:00
|
|
|
import Hasura.RQL.IR.RemoteSchema
|
2021-09-24 01:56:37 +03:00
|
|
|
import Hasura.RQL.IR.Select
|
|
|
|
import Hasura.RQL.IR.Update
|
|
|
|
import Hasura.RQL.Types.Backend qualified as RQL
|
|
|
|
import Hasura.RQL.Types.Common qualified as RQL
|
|
|
|
import Hasura.RQL.Types.QueryTags qualified as RQL
|
|
|
|
import Hasura.RQL.Types.RemoteSchema qualified as RQL
|
|
|
|
import Hasura.SQL.AnyBackend qualified as AB
|
|
|
|
import Hasura.SQL.Backend
|
|
|
|
|
|
|
|
data SourceConfigWith (db :: BackendType -> Type) (b :: BackendType)
|
|
|
|
= SourceConfigWith (RQL.SourceConfig b) (Maybe RQL.QueryTagsConfig) (db b)
|
2021-06-11 06:26:50 +03:00
|
|
|
|
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-18 02:12:11 +03:00
|
|
|
data RootField (db :: BackendType -> Type) remote action raw where
|
2021-09-24 01:56:37 +03:00
|
|
|
RFDB ::
|
|
|
|
RQL.SourceName ->
|
|
|
|
AB.AnyBackend (SourceConfigWith db) ->
|
|
|
|
RootField db remote action raw
|
2021-06-11 06:26:50 +03:00
|
|
|
RFRemote :: remote -> RootField db remote action raw
|
|
|
|
RFAction :: action -> RootField db remote action raw
|
2021-09-24 01:56:37 +03:00
|
|
|
RFRaw :: raw -> RootField db remote action raw
|
2022-07-25 18:53:25 +03:00
|
|
|
RFMulti :: [RootField db remote action raw] -> RootField db remote action raw
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2021-12-07 16:12:02 +03:00
|
|
|
data MutationDB (b :: BackendType) (r :: Type) v
|
2022-04-01 09:43:05 +03:00
|
|
|
= MDBInsert (AnnotatedInsert b r v)
|
2021-11-25 00:39:42 +03:00
|
|
|
| MDBUpdate (AnnotatedUpdateG b r v)
|
2021-09-24 01:56:37 +03:00
|
|
|
| MDBDelete (AnnDelG b r v)
|
|
|
|
| -- | This represents a VOLATILE function, and is AnnSimpleSelG for easy
|
|
|
|
-- re-use of non-VOLATILE function tracking code.
|
|
|
|
MDBFunction RQL.JsonAggSelect (AnnSimpleSelectG b r v)
|
2021-07-08 18:41:59 +03:00
|
|
|
deriving stock (Generic, Functor, Foldable, Traversable)
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2022-03-03 06:43:27 +03:00
|
|
|
data ActionQuery (r :: Type)
|
2022-08-01 12:32:04 +03:00
|
|
|
= AQQuery (AnnActionExecution r)
|
|
|
|
| AQAsync (AnnActionAsyncQuery ('Postgres 'Vanilla) r)
|
2022-03-08 11:22:20 +03:00
|
|
|
deriving stock (Functor, Foldable, Traversable)
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2022-03-03 06:43:27 +03:00
|
|
|
data ActionMutation (r :: Type)
|
2022-08-01 12:32:04 +03:00
|
|
|
= AMSync (AnnActionExecution r)
|
|
|
|
| AMAsync AnnActionMutationAsync
|
2021-07-08 18:41:59 +03:00
|
|
|
|
2021-06-11 06:26:50 +03:00
|
|
|
-- The `db` type argument of @RootField@ expects only one type argument, the backend `b`, as not all
|
|
|
|
-- types stored in a RootField will have a second parameter like @QueryDB@ does: they all only have
|
|
|
|
-- in common the fact that they're parametric over the backend. To define @QueryRootField@ in terms
|
|
|
|
-- of @QueryDB@ (and likewise for mutations), we need a type-level function `b -> QueryDB b (v
|
|
|
|
-- b)`. Sadly, neither type synonyms nor type families may be partially applied. Hence the need for
|
|
|
|
-- @QueryDBRoot@ and @MutationDBRoot@.
|
2021-09-24 01:56:37 +03:00
|
|
|
newtype QueryDBRoot r v b = QDBR (QueryDB b r (v b))
|
|
|
|
|
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-18 02:12:11 +03:00
|
|
|
newtype MutationDBRoot r v b = MDBR (MutationDB b r (v b))
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2021-12-07 16:12:02 +03:00
|
|
|
-- | IR of a remote relationship. A remote relationship currently can be to
|
|
|
|
-- either a remote schema or a database's table. See RemoteSourceSelect for
|
|
|
|
-- explanation on 'vf'.
|
|
|
|
data RemoteRelationshipField vf
|
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 06:17:28 +03:00
|
|
|
= RemoteSchemaField (RemoteSchemaSelect (RemoteRelationshipField vf))
|
2021-12-07 16:12:02 +03:00
|
|
|
| -- | AnyBackend is used here to capture a relationship to an arbitrary target
|
|
|
|
RemoteSourceField (AB.AnyBackend (RemoteSourceSelect (RemoteRelationshipField vf) vf))
|
|
|
|
|
2021-07-26 16:03:51 +03:00
|
|
|
-- | Represents a query root field to an action
|
2021-09-24 01:56:37 +03:00
|
|
|
type QueryActionRoot v =
|
2022-03-03 06:43:27 +03:00
|
|
|
ActionQuery (RemoteRelationshipField v)
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2021-07-26 16:03:51 +03:00
|
|
|
-- | Represents a mutation root field to an action
|
2021-09-24 01:56:37 +03:00
|
|
|
type MutationActionRoot v =
|
2022-03-03 06:43:27 +03:00
|
|
|
ActionMutation (RemoteRelationshipField v)
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-12-07 16:12:02 +03:00
|
|
|
type QueryRootField v =
|
|
|
|
RootField
|
|
|
|
(QueryDBRoot (RemoteRelationshipField v) v)
|
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 06:17:28 +03:00
|
|
|
(RemoteSchemaRootField (RemoteRelationshipField v) RQL.RemoteSchemaVariable)
|
2021-12-07 16:12:02 +03:00
|
|
|
(QueryActionRoot v)
|
|
|
|
JO.Value
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-12-07 16:12:02 +03:00
|
|
|
type MutationRootField v =
|
|
|
|
RootField
|
|
|
|
(MutationDBRoot (RemoteRelationshipField v) v)
|
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 06:17:28 +03:00
|
|
|
(RemoteSchemaRootField (RemoteRelationshipField v) RQL.RemoteSchemaVariable)
|
2021-12-07 16:12:02 +03:00
|
|
|
(MutationActionRoot v)
|
|
|
|
JO.Value
|
2022-06-07 08:32:08 +03:00
|
|
|
|
|
|
|
type SubscriptionRootField v =
|
|
|
|
RootField
|
|
|
|
(QueryDBRoot (RemoteRelationshipField v) v)
|
|
|
|
(RemoteSchemaRootField (RemoteRelationshipField v) RQL.RemoteSchemaVariable)
|
|
|
|
(QueryActionRoot v)
|
|
|
|
JO.Value
|