2021-06-11 06:26:50 +03:00
|
|
|
module Hasura.GraphQL.Execute.RemoteJoin.Collect
|
2022-03-10 09:17:48 +03:00
|
|
|
( getRemoteJoinsQueryDB,
|
2021-06-11 06:26:50 +03:00
|
|
|
getRemoteJoinsMutationDB,
|
|
|
|
getRemoteJoinsActionQuery,
|
|
|
|
getRemoteJoinsActionMutation,
|
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
|
|
|
getRemoteJoinsGraphQLField,
|
2021-06-11 06:26:50 +03:00
|
|
|
)
|
|
|
|
where
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
import Control.Lens (Traversal', preview, traverseOf, _2)
|
2021-08-06 16:39:00 +03:00
|
|
|
import Control.Monad.Writer
|
2023-04-26 18:42:13 +03:00
|
|
|
import Data.HashMap.Strict qualified as HashMap
|
2023-04-27 10:41:55 +03:00
|
|
|
import Data.HashMap.Strict.InsOrd qualified as InsOrdHashMap
|
2022-03-01 19:03:23 +03:00
|
|
|
import Data.HashMap.Strict.NonEmpty (NEHashMap)
|
|
|
|
import Data.HashMap.Strict.NonEmpty qualified as NEMap
|
2021-09-22 13:43:05 +03:00
|
|
|
import Data.Text qualified as T
|
2023-04-03 13:18:54 +03:00
|
|
|
import Hasura.Function.Cache
|
2021-06-11 06:26:50 +03:00
|
|
|
import Hasura.GraphQL.Execute.RemoteJoin.Types
|
2022-06-23 12:14:24 +03:00
|
|
|
import Hasura.GraphQL.Parser.Name qualified as GName
|
|
|
|
import Hasura.Name qualified as Name
|
2021-06-11 06:26:50 +03:00
|
|
|
import Hasura.Prelude
|
|
|
|
import Hasura.RQL.IR
|
2023-05-09 19:16:57 +03:00
|
|
|
import Hasura.RQL.IR.Select.Lenses
|
2022-04-27 16:57:28 +03:00
|
|
|
import Hasura.RQL.Types.Backend
|
|
|
|
import Hasura.RQL.Types.Common
|
|
|
|
import Hasura.RQL.Types.ComputedField
|
|
|
|
import Hasura.RQL.Types.Relationships.Remote
|
2021-06-11 06:26:50 +03:00
|
|
|
import Hasura.SQL.AnyBackend qualified as AB
|
2022-03-03 06:43:27 +03:00
|
|
|
import Language.GraphQL.Draft.Syntax qualified as G
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2022-03-01 19:03:23 +03:00
|
|
|
{- Note [Remote Joins Architecture]
|
2021-06-11 06:26:50 +03:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
2022-03-01 19:03:23 +03:00
|
|
|
Unparsed Incoming GraphQL +------------------------------+
|
|
|
|
--------------------------> | Parsing of the GraphQL query |-----+
|
|
|
|
+------------------------------+ |
|
|
|
|
| DB Query and remote joins (if any)
|
|
|
|
|
|
|
|
|
V
|
|
|
|
+----------------------------------+ SQL query response +----------------------------+
|
|
|
|
| Traverse the DB response to | <------------------- | Execution of the DB query |
|
|
|
|
| get the values of the arguments | +----------------------------+
|
|
|
|
| of the remote field |
|
|
|
|
+----------------------------------+
|
|
|
|
|
|
|
|
|
| Remote field arguments
|
|
|
|
V
|
|
|
|
+--------------------------+ Remote schema response +----------------------------------------+
|
|
|
|
| Query the remote schema | ------------------------> | Replace the remote join fields in |
|
|
|
|
| with the remote field | | the SQL query response (JSON) with |
|
|
|
|
| arguments to the remote | | the response obtained from the remote |
|
|
|
|
| field configured in the | | schema at appropriate places. |
|
|
|
|
| remote join. | +----------------------------------------+
|
|
|
|
+--------------------------+
|
2021-06-11 06:26:50 +03:00
|
|
|
-}
|
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
-- AST entry points
|
|
|
|
|
|
|
|
-- | Collects remote joins from the a 'QueryDB' if any, and transforms the
|
|
|
|
-- selection to add new join fields where those occured.
|
|
|
|
--
|
|
|
|
-- Returns the transformed selection set, in which remote fields have been
|
|
|
|
-- inserted, and for which the @r@ type is now 'Void'.
|
|
|
|
getRemoteJoinsQueryDB ::
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend b) =>
|
2022-03-10 09:17:48 +03:00
|
|
|
QueryDB b (RemoteRelationshipField UnpreparedValue) (UnpreparedValue b) ->
|
|
|
|
(QueryDB b Void (UnpreparedValue b), Maybe RemoteJoins)
|
|
|
|
getRemoteJoinsQueryDB =
|
|
|
|
runCollector . \case
|
|
|
|
QDBMultipleRows s ->
|
|
|
|
QDBMultipleRows <$> transformSelect s
|
|
|
|
QDBSingleRow s ->
|
|
|
|
QDBSingleRow <$> transformSelect s
|
|
|
|
QDBAggregation s ->
|
|
|
|
QDBAggregation <$> transformAggregateSelect s
|
|
|
|
QDBConnection s ->
|
|
|
|
QDBConnection <$> transformConnectionSelect s
|
2022-04-07 17:41:43 +03:00
|
|
|
QDBStreamMultipleRows s ->
|
|
|
|
QDBStreamMultipleRows <$> transformStreamSelect s
|
2022-03-10 09:17:48 +03:00
|
|
|
|
|
|
|
-- | Collects remote joins from the a 'MutationDB' if any, and transforms the
|
|
|
|
-- selection to add new join fields where those occured.
|
|
|
|
--
|
|
|
|
-- Returns the transformed selection set, in which remote fields have been
|
|
|
|
-- inserted, and for which the @r@ type is now 'Void'.
|
|
|
|
getRemoteJoinsMutationDB ::
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend b) =>
|
2022-03-10 09:17:48 +03:00
|
|
|
MutationDB b (RemoteRelationshipField UnpreparedValue) (UnpreparedValue b) ->
|
|
|
|
(MutationDB b Void (UnpreparedValue b), Maybe RemoteJoins)
|
|
|
|
getRemoteJoinsMutationDB =
|
|
|
|
runCollector . \case
|
|
|
|
MDBInsert insert ->
|
|
|
|
MDBInsert <$> traverseOf aiOutput transformMutationOutput insert
|
|
|
|
MDBUpdate update ->
|
|
|
|
MDBUpdate <$> traverseOf auOutput transformMutationOutput update
|
|
|
|
MDBDelete delete ->
|
|
|
|
MDBDelete <$> traverseOf adOutput transformMutationOutput delete
|
|
|
|
MDBFunction aggSelect select ->
|
|
|
|
MDBFunction aggSelect <$> transformSelect select
|
|
|
|
|
|
|
|
getRemoteJoinsActionQuery ::
|
|
|
|
ActionQuery (RemoteRelationshipField UnpreparedValue) ->
|
|
|
|
(ActionQuery Void, Maybe RemoteJoins)
|
|
|
|
getRemoteJoinsActionQuery =
|
|
|
|
runCollector . \case
|
|
|
|
AQQuery sync ->
|
|
|
|
AQQuery <$> transformSyncAction sync
|
|
|
|
AQAsync async ->
|
|
|
|
AQAsync <$> traverseOf aaaqFields (traverseFields transformAsyncFields) async
|
|
|
|
|
|
|
|
getRemoteJoinsActionMutation ::
|
|
|
|
ActionMutation (RemoteRelationshipField UnpreparedValue) ->
|
|
|
|
(ActionMutation Void, Maybe RemoteJoins)
|
|
|
|
getRemoteJoinsActionMutation =
|
|
|
|
runCollector . \case
|
|
|
|
AMAsync async -> pure $ AMAsync async
|
|
|
|
AMSync sync -> AMSync <$> transformSyncAction sync
|
|
|
|
|
|
|
|
getRemoteJoinsSourceRelation ::
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend b) =>
|
2022-03-10 09:17:48 +03:00
|
|
|
SourceRelationshipSelection b (RemoteRelationshipField UnpreparedValue) UnpreparedValue ->
|
|
|
|
(SourceRelationshipSelection b Void UnpreparedValue, Maybe RemoteJoins)
|
|
|
|
getRemoteJoinsSourceRelation =
|
|
|
|
runCollector . \case
|
|
|
|
SourceRelationshipObject objectSelect ->
|
|
|
|
SourceRelationshipObject <$> transformObjectSelect objectSelect
|
|
|
|
SourceRelationshipArray simpleSelect ->
|
|
|
|
SourceRelationshipArray <$> transformSelect simpleSelect
|
|
|
|
SourceRelationshipArrayAggregate aggregateSelect ->
|
|
|
|
SourceRelationshipArrayAggregate <$> transformAggregateSelect aggregateSelect
|
|
|
|
|
|
|
|
getRemoteJoinsGraphQLField ::
|
|
|
|
GraphQLField (RemoteRelationshipField UnpreparedValue) var ->
|
|
|
|
(GraphQLField Void var, Maybe RemoteJoins)
|
|
|
|
getRemoteJoinsGraphQLField =
|
|
|
|
runCollector . transformGraphQLField
|
|
|
|
|
|
|
|
getRemoteJoinsGraphQLSelectionSet ::
|
|
|
|
SelectionSet (RemoteRelationshipField UnpreparedValue) var ->
|
|
|
|
(SelectionSet Void var, Maybe RemoteJoins)
|
|
|
|
getRemoteJoinsGraphQLSelectionSet =
|
|
|
|
runCollector . transformGraphQLSelectionSet
|
|
|
|
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
|
2021-08-06 16:39:00 +03:00
|
|
|
-- | A writer monad used to collect together all remote joins
|
|
|
|
-- appearing in some data structure.
|
|
|
|
--
|
|
|
|
-- In the functions below, the 'withField' function is used to track the
|
|
|
|
-- context of the path from the root of the current selection set.
|
|
|
|
--
|
|
|
|
-- It is important that we work bottom-up, and do not 'collect' duplicate
|
|
|
|
-- field names at any level, because the 'Semigroup' instance for 'RemoteJoins'
|
|
|
|
-- does not allow for these duplicates.
|
|
|
|
newtype Collector a = Collector {runCollector :: (a, Maybe RemoteJoins)}
|
|
|
|
deriving
|
|
|
|
(Functor, Applicative, Monad, MonadWriter (Maybe RemoteJoins))
|
|
|
|
via Writer (Maybe RemoteJoins)
|
|
|
|
|
|
|
|
-- | Collect some remote joins appearing at the given field names in the current
|
|
|
|
-- context.
|
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
|
|
|
collect :: NEHashMap QualifiedFieldName RemoteJoin -> Collector ()
|
2022-03-01 19:03:23 +03:00
|
|
|
collect = tell . Just . JoinTree . fmap Leaf
|
2021-08-06 16:39:00 +03:00
|
|
|
|
|
|
|
-- | Keep track of the given field name in the current path from the root of the
|
|
|
|
-- selection set.
|
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
|
|
|
withField :: Maybe Text -> Text -> Collector a -> Collector a
|
|
|
|
withField typeName fieldName = censor (fmap wrap)
|
2021-08-06 16:39:00 +03:00
|
|
|
where
|
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
|
|
|
wrap rjs = JoinTree $ NEMap.singleton (QualifiedFieldName typeName fieldName) (Tree rjs)
|
2021-08-06 16:39:00 +03:00
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
-- | Traverse a list of fields, while applying 'withField' to keep track of the
|
|
|
|
-- path within the AST. This function assumes that no type name is required for
|
|
|
|
-- the 'QualifiedFieldName' and uses 'Nothing'.
|
|
|
|
traverseFields ::
|
|
|
|
(a -> Collector b) ->
|
|
|
|
Fields a ->
|
|
|
|
Collector (Fields b)
|
|
|
|
traverseFields fun =
|
|
|
|
traverse \field@(fieldName, _) ->
|
|
|
|
withField Nothing (getFieldNameTxt fieldName) $ traverse fun field
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
-- Internal AST traversals
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
transformAsyncFields ::
|
|
|
|
AsyncActionQueryFieldG (RemoteRelationshipField UnpreparedValue) ->
|
|
|
|
Collector (AsyncActionQueryFieldG Void)
|
|
|
|
transformAsyncFields = traverseOf _AsyncOutput transformActionFields
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
transformMutationOutput ::
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend b) =>
|
2021-12-07 16:12:02 +03:00
|
|
|
MutationOutputG b (RemoteRelationshipField UnpreparedValue) (UnpreparedValue b) ->
|
2022-03-10 09:17:48 +03:00
|
|
|
Collector (MutationOutputG b Void (UnpreparedValue b))
|
|
|
|
transformMutationOutput = \case
|
|
|
|
MOutMultirowFields mutationFields ->
|
|
|
|
MOutMultirowFields <$> transformMutationFields mutationFields
|
|
|
|
MOutSinglerowObject annFields ->
|
|
|
|
MOutSinglerowObject <$> transformAnnFields annFields
|
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
|
|
|
where
|
2022-03-10 09:17:48 +03:00
|
|
|
transformMutationFields = traverseFields $ traverseOf _MRet transformAnnFields
|
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
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
transformSyncAction ::
|
2022-03-03 06:43:27 +03:00
|
|
|
AnnActionExecution (RemoteRelationshipField UnpreparedValue) ->
|
2022-03-10 09:17:48 +03:00
|
|
|
Collector (AnnActionExecution Void)
|
|
|
|
transformSyncAction = traverseOf aaeFields transformActionFields
|
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
|
|
|
|
2021-06-11 06:26:50 +03:00
|
|
|
transformSelect ::
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend b) =>
|
2021-12-07 16:12:02 +03:00
|
|
|
AnnSimpleSelectG b (RemoteRelationshipField UnpreparedValue) (UnpreparedValue b) ->
|
|
|
|
Collector (AnnSimpleSelectG b Void (UnpreparedValue b))
|
2022-03-10 09:17:48 +03:00
|
|
|
transformSelect = traverseOf asnFields transformAnnFields
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2022-04-07 17:41:43 +03:00
|
|
|
transformStreamSelect ::
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend b) =>
|
2022-04-07 17:41:43 +03:00
|
|
|
AnnSimpleStreamSelectG b (RemoteRelationshipField UnpreparedValue) (UnpreparedValue b) ->
|
|
|
|
Collector (AnnSimpleStreamSelectG b Void (UnpreparedValue b))
|
|
|
|
transformStreamSelect select@AnnSelectStreamG {_assnFields = fields} = do
|
|
|
|
-- Transform selects in array, object and computed fields
|
|
|
|
transformedFields <- transformAnnFields fields
|
|
|
|
pure select {_assnFields = transformedFields}
|
|
|
|
|
2021-06-11 06:26:50 +03:00
|
|
|
transformAggregateSelect ::
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend b) =>
|
2021-12-07 16:12:02 +03:00
|
|
|
AnnAggregateSelectG b (RemoteRelationshipField UnpreparedValue) (UnpreparedValue b) ->
|
|
|
|
Collector (AnnAggregateSelectG b Void (UnpreparedValue b))
|
2022-03-10 09:17:48 +03:00
|
|
|
transformAggregateSelect =
|
2023-05-24 16:51:56 +03:00
|
|
|
traverseOf asnFields
|
|
|
|
$ traverseFields
|
|
|
|
$ traverseOf (_TAFNodes . _2) transformAnnFields
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
-- Relay doesn't support remote relationships: we can drill down directly to the
|
|
|
|
-- inner non-relay selection sets.
|
2021-06-11 06:26:50 +03:00
|
|
|
transformConnectionSelect ::
|
2021-08-06 16:39:00 +03:00
|
|
|
forall b.
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend b) =>
|
2021-12-07 16:12:02 +03:00
|
|
|
ConnectionSelect b (RemoteRelationshipField UnpreparedValue) (UnpreparedValue b) ->
|
|
|
|
Collector (ConnectionSelect b Void (UnpreparedValue b))
|
2022-03-10 09:17:48 +03:00
|
|
|
transformConnectionSelect =
|
2023-05-24 16:51:56 +03:00
|
|
|
traverseOf (csSelect . asnFields)
|
|
|
|
$ traverseFields
|
|
|
|
$ traverseOf _ConnectionEdges
|
|
|
|
$ traverseFields
|
|
|
|
$ traverseOf _EdgeNode transformAnnFields
|
2021-06-11 06:26:50 +03:00
|
|
|
|
|
|
|
transformObjectSelect ::
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend b) =>
|
2021-12-07 16:12:02 +03:00
|
|
|
AnnObjectSelectG b (RemoteRelationshipField UnpreparedValue) (UnpreparedValue b) ->
|
|
|
|
Collector (AnnObjectSelectG b Void (UnpreparedValue b))
|
2022-03-10 09:17:48 +03:00
|
|
|
transformObjectSelect = traverseOf aosFields transformAnnFields
|
2021-06-11 06:26:50 +03:00
|
|
|
|
2023-04-11 04:29:05 +03:00
|
|
|
transformNestedObjectSelect ::
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend b) =>
|
2023-04-11 04:29:05 +03:00
|
|
|
AnnNestedObjectSelectG b (RemoteRelationshipField UnpreparedValue) (UnpreparedValue b) ->
|
|
|
|
Collector (AnnNestedObjectSelectG b Void (UnpreparedValue b))
|
|
|
|
transformNestedObjectSelect = traverseOf anosFields transformAnnFields
|
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
transformGraphQLField ::
|
|
|
|
GraphQLField (RemoteRelationshipField UnpreparedValue) var ->
|
|
|
|
Collector (GraphQLField Void var)
|
|
|
|
transformGraphQLField = traverseOf fSelectionSet transformGraphQLSelectionSet
|
2021-12-07 16:12:02 +03:00
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
transformGraphQLSelectionSet ::
|
|
|
|
SelectionSet (RemoteRelationshipField UnpreparedValue) var ->
|
|
|
|
Collector (SelectionSet Void var)
|
|
|
|
transformGraphQLSelectionSet = \case
|
|
|
|
SelectionSetNone -> pure SelectionSetNone
|
|
|
|
SelectionSetObject s -> SelectionSetObject <$> transformObjectSelectionSet Nothing s
|
|
|
|
SelectionSetUnion s -> SelectionSetUnion <$> transformDeduplicatedTypeSelectionSet s
|
|
|
|
SelectionSetInterface s -> SelectionSetInterface <$> transformDeduplicatedTypeSelectionSet s
|
|
|
|
where
|
|
|
|
transformDeduplicatedTypeSelectionSet =
|
2023-04-26 18:42:13 +03:00
|
|
|
traverseOf dssMemberSelectionSets $ HashMap.traverseWithKey \typeName objectSelectionSet ->
|
2022-03-10 09:17:48 +03:00
|
|
|
transformObjectSelectionSet (Just typeName) objectSelectionSet
|
|
|
|
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
-- Actual transformations
|
|
|
|
|
|
|
|
-- | Transforms a source selection set.
|
|
|
|
--
|
|
|
|
-- This function takes an 'AnnFieldsG', which corresponds to a selection of
|
|
|
|
-- fields on a source, and extracts remote joins: for every field we encounter
|
|
|
|
-- that maps to a remote destination (either another source or a remote schema),
|
|
|
|
-- we replace it with a phantom field and 'collect' the corresponding
|
|
|
|
-- 'RemoteJoin'.
|
2021-06-11 06:26:50 +03:00
|
|
|
transformAnnFields ::
|
2021-09-22 13:43:05 +03:00
|
|
|
forall src.
|
2023-05-24 16:51:56 +03:00
|
|
|
(Backend src) =>
|
2021-12-07 16:12:02 +03:00
|
|
|
AnnFieldsG src (RemoteRelationshipField UnpreparedValue) (UnpreparedValue src) ->
|
|
|
|
Collector (AnnFieldsG src Void (UnpreparedValue src))
|
2021-08-06 16:39:00 +03:00
|
|
|
transformAnnFields fields = do
|
Nested array support for Data Connectors Backend and MongoDB
## Description
This change adds support for querying into nested arrays in Data Connector agents that support such a concept (currently MongoDB).
### DC API changes
- New API type `ColumnType` which allows representing the type of a "column" as either a scalar type, an object reference or an array of `ColumnType`s. This recursive definition allows arbitrary nesting of arrays of types.
- The `type` fields in the API types `ColumnInfo` and `ColumnInsertSchema` now take a `ColumnType` instead of a `ScalarType`.
- To ensure backwards compatibility, a `ColumnType` representing a scalar serialises and deserialises to the same representation as `ScalarType`.
- In queries, the `Field` type now has a new constructor `NestedArrayField`. This contains a nested `Field` along with optional `limit`, `offset`, `where` and `order_by` arguments. (These optional arguments are not yet used by either HGE or the MongoDB agent.)
### MongoDB Haskell agent changes
- The `/schema` endpoint will now recognise arrays within the JSON validation schema and generate corresponding arrays in the DC schema.
- The `/query` endpoint will now handle `NestedArrayField`s within queries (although it does not yet handle `limit`, `offset`, `where` and `order_by`).
### HGE server changes
- The `Backend` type class adds a new type family `XNestedArrays b` to enable nested arrays on a per-backend basis (currently enabled only for the `DataConnector` backend.
- Within `RawColumnInfo` the column type is now represented by a new type `RawColumnType b` which mirrors the shape of the DC API `ColumnType`, but uses `XNestedObjects b` and `XNestedArrays b` type families to allow turning nested object and array supports on or off for a particular backend. In the `DataConnector` backend `API.CustomType` is converted into `RawColumnInfo 'DataConnector` while building the schema.
- In the next stage of schema building, the `RawColumnInfo` is converted into a `StructuredColumnInfo` which allows us to represent the three different types of columns: scalar, object and array. TODO: the `StructuredColumnInfo` looks very similar to the Logical Model types. The main difference is that it uses the `XNestedObjects` and `XNestedArrays` type families. We should be able to combine these two representations.
- The `StructuredColumnInfo` is then placed into a `FIColumn` `FieldInfo`. This involved some refactoring of `FieldInfo` as I had previously split out `FINestedObject` into a separate constructor. However it works out better to represent all "column" fields (i.e. scalar, object and array) using `FIColumn` as this make it easier to implement permission checking correctly. This is the reason the `StructuredColumnInfo` was needed.
- Next, the `FieldInfo` are used to generate `FieldParser`s. We add a new constructor to `AnnFieldG` for `AFNestedArray`. An `AFNestedArray` field parser can contain either a simple array selection or an array aggregate. Simple array `FieldParsers` are currently limited to subfield selection. We will add support for limit, offset, where and order_by in a future PR. We also don't yet generate array aggregate `FieldParsers.
- The new `AFNestedArray` field is handled by the `QueryPlan` module in the `DataConnector` backend. There we generate an `API.NestedArrayField` from the AFNestedArray. We also handle nested arrays when reshaping the response from the DC agent.
## Limitations
- Support for limit, offset, filter (where) and order_by is not yet fully implemented, although it should not be hard to add this
- Support for aggregations on nested arrays is not yet fully implemented
- Permissions involving nested arrays (and objects) not yet implemented
- This should be integrated with Logical Model types, but that will happen in a separate PR
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9149
GitOrigin-RevId: 0e7b71a994fc1d2ca1ef73bfe7b96e95b5328531
2023-05-24 11:00:59 +03:00
|
|
|
let transformAnnField :: AnnFieldG src (RemoteRelationshipField UnpreparedValue) (UnpreparedValue src) -> Collector (AnnFieldG src Void (UnpreparedValue src), Maybe RemoteJoin)
|
|
|
|
transformAnnField = \case
|
|
|
|
-- AnnFields which do not need to be transformed.
|
|
|
|
AFNodeId x sn qt pkeys ->
|
|
|
|
pure (AFNodeId x sn qt pkeys, Nothing)
|
|
|
|
AFColumn c ->
|
|
|
|
pure (AFColumn c, Nothing)
|
|
|
|
AFExpression t ->
|
|
|
|
pure (AFExpression t, Nothing)
|
|
|
|
-- AnnFields with no associated remote joins and whose transformations are
|
|
|
|
-- relatively straightforward.
|
|
|
|
AFObjectRelation annRel -> do
|
|
|
|
transformed <- traverseOf aarAnnSelect transformObjectSelect annRel
|
|
|
|
pure (AFObjectRelation transformed, Nothing)
|
|
|
|
AFArrayRelation (ASSimple annRel) -> do
|
|
|
|
transformed <- traverseOf aarAnnSelect transformSelect annRel
|
|
|
|
pure (AFArrayRelation . ASSimple $ transformed, Nothing)
|
|
|
|
AFArrayRelation (ASAggregate aggRel) -> do
|
|
|
|
transformed <- traverseOf aarAnnSelect transformAggregateSelect aggRel
|
|
|
|
pure (AFArrayRelation . ASAggregate $ transformed, Nothing)
|
|
|
|
AFArrayRelation (ASConnection annRel) -> do
|
|
|
|
transformed <- traverseOf aarAnnSelect transformConnectionSelect annRel
|
|
|
|
pure (AFArrayRelation . ASConnection $ transformed, Nothing)
|
|
|
|
AFComputedField computedField computedFieldName computedFieldSelect -> do
|
|
|
|
transformed <- case computedFieldSelect of
|
|
|
|
CFSScalar cfss cbe -> pure $ CFSScalar cfss cbe
|
|
|
|
CFSTable jsonAggSel annSel -> do
|
|
|
|
transformed <- transformSelect annSel
|
|
|
|
pure $ CFSTable jsonAggSel transformed
|
|
|
|
pure (AFComputedField computedField computedFieldName transformed, Nothing)
|
|
|
|
-- Remote AnnFields, whose elements require annotation so that they can be
|
|
|
|
-- used to construct a remote join.
|
|
|
|
AFRemote RemoteRelationshipSelect {..} ->
|
|
|
|
pure
|
|
|
|
( -- We generate this so that the response has a key with the relationship,
|
|
|
|
-- without which preserving the order of fields in the final response
|
|
|
|
-- would require a lot of bookkeeping.
|
|
|
|
remoteAnnPlaceholder,
|
|
|
|
Just $ createRemoteJoin (HashMap.intersection joinColumnAliases _rrsLHSJoinFields) _rrsRelationship
|
|
|
|
)
|
|
|
|
AFNestedObject nestedObj ->
|
|
|
|
(,Nothing) . AFNestedObject <$> transformNestedObjectSelect nestedObj
|
|
|
|
AFNestedArray supportsNestedArray (ANASSimple nestedArrayField) -> do
|
|
|
|
(,Nothing) . AFNestedArray supportsNestedArray . ANASSimple . fst <$> transformAnnField nestedArrayField
|
|
|
|
AFNestedArray supportsNestedArray (ANASAggregate agg) -> do
|
|
|
|
transformed <- transformAggregateSelect agg
|
|
|
|
pure (AFNestedArray supportsNestedArray (ANASAggregate transformed), Nothing)
|
|
|
|
|
2021-08-06 16:39:00 +03:00
|
|
|
-- Produces a list of transformed fields that may or may not have an
|
|
|
|
-- associated remote join.
|
2022-03-10 09:17:48 +03:00
|
|
|
annotatedFields <-
|
Nested array support for Data Connectors Backend and MongoDB
## Description
This change adds support for querying into nested arrays in Data Connector agents that support such a concept (currently MongoDB).
### DC API changes
- New API type `ColumnType` which allows representing the type of a "column" as either a scalar type, an object reference or an array of `ColumnType`s. This recursive definition allows arbitrary nesting of arrays of types.
- The `type` fields in the API types `ColumnInfo` and `ColumnInsertSchema` now take a `ColumnType` instead of a `ScalarType`.
- To ensure backwards compatibility, a `ColumnType` representing a scalar serialises and deserialises to the same representation as `ScalarType`.
- In queries, the `Field` type now has a new constructor `NestedArrayField`. This contains a nested `Field` along with optional `limit`, `offset`, `where` and `order_by` arguments. (These optional arguments are not yet used by either HGE or the MongoDB agent.)
### MongoDB Haskell agent changes
- The `/schema` endpoint will now recognise arrays within the JSON validation schema and generate corresponding arrays in the DC schema.
- The `/query` endpoint will now handle `NestedArrayField`s within queries (although it does not yet handle `limit`, `offset`, `where` and `order_by`).
### HGE server changes
- The `Backend` type class adds a new type family `XNestedArrays b` to enable nested arrays on a per-backend basis (currently enabled only for the `DataConnector` backend.
- Within `RawColumnInfo` the column type is now represented by a new type `RawColumnType b` which mirrors the shape of the DC API `ColumnType`, but uses `XNestedObjects b` and `XNestedArrays b` type families to allow turning nested object and array supports on or off for a particular backend. In the `DataConnector` backend `API.CustomType` is converted into `RawColumnInfo 'DataConnector` while building the schema.
- In the next stage of schema building, the `RawColumnInfo` is converted into a `StructuredColumnInfo` which allows us to represent the three different types of columns: scalar, object and array. TODO: the `StructuredColumnInfo` looks very similar to the Logical Model types. The main difference is that it uses the `XNestedObjects` and `XNestedArrays` type families. We should be able to combine these two representations.
- The `StructuredColumnInfo` is then placed into a `FIColumn` `FieldInfo`. This involved some refactoring of `FieldInfo` as I had previously split out `FINestedObject` into a separate constructor. However it works out better to represent all "column" fields (i.e. scalar, object and array) using `FIColumn` as this make it easier to implement permission checking correctly. This is the reason the `StructuredColumnInfo` was needed.
- Next, the `FieldInfo` are used to generate `FieldParser`s. We add a new constructor to `AnnFieldG` for `AFNestedArray`. An `AFNestedArray` field parser can contain either a simple array selection or an array aggregate. Simple array `FieldParsers` are currently limited to subfield selection. We will add support for limit, offset, where and order_by in a future PR. We also don't yet generate array aggregate `FieldParsers.
- The new `AFNestedArray` field is handled by the `QueryPlan` module in the `DataConnector` backend. There we generate an `API.NestedArrayField` from the AFNestedArray. We also handle nested arrays when reshaping the response from the DC agent.
## Limitations
- Support for limit, offset, filter (where) and order_by is not yet fully implemented, although it should not be hard to add this
- Support for aggregations on nested arrays is not yet fully implemented
- Permissions involving nested arrays (and objects) not yet implemented
- This should be integrated with Logical Model types, but that will happen in a separate PR
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9149
GitOrigin-RevId: 0e7b71a994fc1d2ca1ef73bfe7b96e95b5328531
2023-05-24 11:00:59 +03:00
|
|
|
fields & traverseFields transformAnnField
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-08-06 16:39:00 +03:00
|
|
|
let transformedFields = (fmap . fmap) fst annotatedFields
|
|
|
|
remoteJoins =
|
|
|
|
annotatedFields & mapMaybe \(fieldName, (_, mRemoteJoin)) ->
|
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
|
|
|
(QualifiedFieldName Nothing (getFieldNameTxt fieldName),) <$> mRemoteJoin
|
2021-12-07 16:12:02 +03:00
|
|
|
|
2022-03-01 19:03:23 +03:00
|
|
|
case NEMap.fromList remoteJoins of
|
2021-06-11 06:26:50 +03:00
|
|
|
Nothing -> pure transformedFields
|
2021-08-06 16:39:00 +03:00
|
|
|
Just neRemoteJoins -> do
|
2021-12-07 16:12:02 +03:00
|
|
|
collect neRemoteJoins
|
2021-08-06 16:39:00 +03:00
|
|
|
pure $ transformedFields <> phantomFields
|
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
|
|
|
where
|
2021-08-06 16:39:00 +03:00
|
|
|
-- Placeholder text to annotate a remote relationship field.
|
2021-12-07 16:12:02 +03:00
|
|
|
remoteAnnPlaceholder :: AnnFieldG src Void (UnpreparedValue src)
|
2021-08-06 16:39:00 +03:00
|
|
|
remoteAnnPlaceholder = AFExpression "remote relationship placeholder"
|
|
|
|
|
|
|
|
-- This is a map of column name to its alias of all columns in the
|
|
|
|
-- selection set.
|
2021-09-22 13:43:05 +03:00
|
|
|
columnFields :: HashMap (Column src) FieldName
|
2021-08-06 16:39:00 +03:00
|
|
|
columnFields =
|
2023-05-24 16:51:56 +03:00
|
|
|
HashMap.fromList
|
|
|
|
$ [ (_acfColumn annColumn, alias)
|
|
|
|
| (alias, annColumn) <- getFields _AFColumn fields
|
|
|
|
]
|
2021-08-06 16:39:00 +03:00
|
|
|
|
|
|
|
-- This is a map of computed field name to its alias of all computed fields
|
|
|
|
-- in the selection set.
|
2023-04-26 18:42:13 +03:00
|
|
|
computedFields :: HashMap.HashMap ComputedFieldName FieldName
|
2021-08-06 16:39:00 +03:00
|
|
|
computedFields =
|
2023-05-24 16:51:56 +03:00
|
|
|
HashMap.fromList
|
|
|
|
$ [ (fieldName, alias)
|
|
|
|
| -- Note that we do not currently care about input arguments to a computed
|
|
|
|
-- field because only computed fields which do not accept input arguments
|
|
|
|
-- are currently allowed.
|
|
|
|
(alias, fieldName) <- getFields (_AFComputedField . _2) fields
|
|
|
|
]
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-12-07 16:12:02 +03:00
|
|
|
-- Annotate a 'DBJoinField' with its field name and an alias so that it may
|
|
|
|
-- be used to construct a remote join.
|
|
|
|
annotateDBJoinField ::
|
|
|
|
FieldName -> DBJoinField src -> (DBJoinField src, JoinColumnAlias)
|
|
|
|
annotateDBJoinField fieldName = \case
|
|
|
|
jc@(JoinColumn column _) ->
|
|
|
|
let alias = getJoinColumnAlias fieldName column columnFields allAliases
|
|
|
|
in (jc, alias)
|
|
|
|
jcf@(JoinComputedField ScalarComputedField {..}) ->
|
|
|
|
let alias = getJoinColumnAlias fieldName _scfName computedFields allAliases
|
|
|
|
in (jcf, alias)
|
|
|
|
where
|
|
|
|
allAliases = map fst fields
|
|
|
|
|
|
|
|
-- goes through all the remote relationships in the selection set and emits
|
|
|
|
-- 1. a map of join field names to their aliases in the lhs response
|
|
|
|
-- 2. a list of extra fields that need to be included in the lhs query
|
|
|
|
-- that are required for the join
|
|
|
|
(joinColumnAliases, phantomFields) =
|
|
|
|
let lhsJoinFields =
|
2023-04-26 18:42:13 +03:00
|
|
|
HashMap.unions $ map (_rrsLHSJoinFields . snd) $ getFields _AFRemote fields
|
|
|
|
annotatedJoinColumns = HashMap.mapWithKey annotateDBJoinField $ lhsJoinFields
|
2021-12-07 16:12:02 +03:00
|
|
|
phantomFields_ =
|
|
|
|
toList annotatedJoinColumns & mapMaybe \(joinField, alias) ->
|
|
|
|
case alias of
|
|
|
|
JCSelected _ -> Nothing
|
|
|
|
JCPhantom a -> case joinField of
|
|
|
|
JoinColumn column columnType ->
|
|
|
|
let annotatedColumn =
|
|
|
|
AFColumn $ AnnColumnField column columnType False Nothing Nothing
|
|
|
|
in Just (a, annotatedColumn)
|
|
|
|
JoinComputedField computedFieldInfo ->
|
|
|
|
Just (a, mkScalarComputedFieldSelect computedFieldInfo)
|
|
|
|
in (fmap snd annotatedJoinColumns, phantomFields_)
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-08-06 16:39:00 +03:00
|
|
|
mkScalarComputedFieldSelect ::
|
2022-05-25 13:24:41 +03:00
|
|
|
forall b.
|
|
|
|
(Backend b) =>
|
2021-08-06 16:39:00 +03:00
|
|
|
ScalarComputedField b ->
|
2021-12-07 16:12:02 +03:00
|
|
|
AnnFieldG b Void (UnpreparedValue b)
|
2021-07-12 19:03:36 +03:00
|
|
|
mkScalarComputedFieldSelect ScalarComputedField {..} =
|
|
|
|
let functionArgs =
|
2022-05-25 13:24:41 +03:00
|
|
|
flip FunctionArgsExp mempty $ fromComputedFieldImplicitArguments @b UVSession _scfComputedFieldImplicitArgs
|
2021-07-12 19:03:36 +03:00
|
|
|
fieldSelect =
|
2023-05-24 16:51:56 +03:00
|
|
|
flip CFSScalar Nothing
|
|
|
|
$ ComputedFieldScalarSelect _scfFunction functionArgs _scfType Nothing
|
2021-07-12 19:03:36 +03:00
|
|
|
in AFComputedField _scfXField _scfName fieldSelect
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
-- | Transforms an action's selection set.
|
|
|
|
--
|
|
|
|
-- This function takes an 'ActionFieldsG', which corresponds to a selection of
|
|
|
|
-- fields on the result of an action, and extracts remote joins: for every field
|
|
|
|
-- we encounter that maps to a remote destination (either a source or a remote
|
|
|
|
-- schema), we replace it with a phantom field and 'collect' the corresponding
|
|
|
|
-- 'RemoteJoin'.
|
2021-12-16 02:51:52 +03:00
|
|
|
transformActionFields ::
|
2022-03-03 06:43:27 +03:00
|
|
|
ActionFieldsG (RemoteRelationshipField UnpreparedValue) ->
|
2022-03-12 04:37:11 +03:00
|
|
|
Collector ActionFields
|
2021-12-16 02:51:52 +03:00
|
|
|
transformActionFields fields = do
|
|
|
|
-- Produces a list of transformed fields that may or may not have an
|
|
|
|
-- associated remote join.
|
2022-03-10 09:17:48 +03:00
|
|
|
annotatedFields <-
|
|
|
|
fields & traverseFields \case
|
2022-03-03 06:43:27 +03:00
|
|
|
-- ActionFields which do not need to be transformed.
|
|
|
|
ACFScalar c -> pure (ACFScalar c, Nothing)
|
|
|
|
ACFExpression t -> pure (ACFExpression t, Nothing)
|
|
|
|
-- Remote ActionFields, whose elements require annotation so that they can be
|
|
|
|
-- used to construct a remote join.
|
|
|
|
ACFRemote ActionRemoteRelationshipSelect {..} ->
|
|
|
|
pure
|
|
|
|
( -- We generate this so that the response has a key with the relationship,
|
|
|
|
-- without which preserving the order of fields in the final response
|
|
|
|
-- would require a lot of bookkeeping.
|
|
|
|
remoteActionPlaceholder,
|
2023-04-26 18:42:13 +03:00
|
|
|
Just $ createRemoteJoin (HashMap.intersection joinColumnAliases _arrsLHSJoinFields) _arrsRelationship
|
2022-03-03 06:43:27 +03:00
|
|
|
)
|
|
|
|
ACFNestedObject fn fs ->
|
|
|
|
(,Nothing) . ACFNestedObject fn <$> transformActionFields fs
|
|
|
|
|
|
|
|
let transformedFields = (fmap . fmap) fst annotatedFields
|
|
|
|
remoteJoins =
|
|
|
|
annotatedFields & mapMaybe \(fieldName, (_, mRemoteJoin)) ->
|
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
|
|
|
(QualifiedFieldName Nothing (getFieldNameTxt fieldName),) <$> mRemoteJoin
|
2022-03-03 06:43:27 +03:00
|
|
|
|
|
|
|
case NEMap.fromList remoteJoins of
|
|
|
|
Nothing -> pure transformedFields
|
|
|
|
Just neRemoteJoins -> do
|
|
|
|
collect neRemoteJoins
|
|
|
|
pure $ transformedFields <> phantomFields
|
|
|
|
where
|
|
|
|
-- Placeholder text to annotate a remote relationship field.
|
|
|
|
remoteActionPlaceholder :: ActionFieldG Void
|
|
|
|
remoteActionPlaceholder = ACFExpression "remote relationship placeholder"
|
|
|
|
|
|
|
|
-- This is a map of column name to its alias of all columns in the
|
|
|
|
-- selection set.
|
|
|
|
scalarFields :: HashMap G.Name FieldName
|
|
|
|
scalarFields =
|
2023-05-24 16:51:56 +03:00
|
|
|
HashMap.fromList
|
|
|
|
$ [ (name, alias)
|
|
|
|
| (alias, name) <- getFields _ACFScalar fields
|
|
|
|
]
|
2022-03-03 06:43:27 +03:00
|
|
|
|
|
|
|
-- Annotate a join field with its field name and an alias so that it may
|
|
|
|
-- be used to construct a remote join.
|
|
|
|
annotateJoinField ::
|
|
|
|
FieldName -> G.Name -> (G.Name, JoinColumnAlias)
|
|
|
|
annotateJoinField fieldName field =
|
|
|
|
let alias = getJoinColumnAlias fieldName field scalarFields allAliases
|
|
|
|
in (field, alias)
|
|
|
|
where
|
|
|
|
allAliases = map fst fields
|
|
|
|
|
|
|
|
-- goes through all the remote relationships in the selection set and emits
|
|
|
|
-- 1. a map of join field names to their aliases in the lhs response
|
|
|
|
-- 2. a list of extra fields that need to be included in the lhs query
|
|
|
|
-- that are required for the join
|
|
|
|
(joinColumnAliases, phantomFields :: ([(FieldName, ActionFieldG Void)])) =
|
|
|
|
let lhsJoinFields =
|
2023-04-26 18:42:13 +03:00
|
|
|
HashMap.unions $ map (_arrsLHSJoinFields . snd) $ getFields _ACFRemote fields
|
|
|
|
annotatedJoinColumns = HashMap.mapWithKey annotateJoinField $ lhsJoinFields
|
2022-03-03 06:43:27 +03:00
|
|
|
phantomFields_ :: ([(FieldName, ActionFieldG Void)]) =
|
|
|
|
toList annotatedJoinColumns & mapMaybe \(joinField, alias) ->
|
|
|
|
case alias of
|
|
|
|
JCSelected _ -> Nothing
|
|
|
|
JCPhantom a ->
|
|
|
|
let annotatedColumn =
|
|
|
|
ACFScalar joinField
|
|
|
|
in Just (a, annotatedColumn)
|
|
|
|
in (fmap snd annotatedJoinColumns, phantomFields_)
|
2021-12-16 02:51:52 +03:00
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
-- | Transforms a GraphQL selection set.
|
2022-03-10 05:12:53 +03:00
|
|
|
--
|
2022-03-10 09:17:48 +03:00
|
|
|
-- This function takes an 'SelectionSet', which corresponds to a selection of
|
|
|
|
-- fields on a remote GraphQL schema, and extracts remote joins: for every field
|
|
|
|
-- we encounter that maps to a remote destination (either a source or another
|
|
|
|
-- remote schema), we replace it with a phantom field and 'collect' the
|
|
|
|
-- corresponding 'RemoteJoin'.
|
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
|
|
|
transformObjectSelectionSet ::
|
|
|
|
-- | The type name on which this selection set is defined; this is only
|
|
|
|
-- expected to be provided for unions and interfaces, not for regular objects,
|
|
|
|
-- as this is used to determine whether a selection set is potentially
|
|
|
|
-- "ambiguous" or not, and regular objects cannot. This will be used as the
|
|
|
|
-- type name in the 'QualifiedFieldName' key of the join tree if this
|
|
|
|
-- selection set or its subselections contain remote joins.
|
|
|
|
Maybe G.Name ->
|
|
|
|
ObjectSelectionSet (RemoteRelationshipField UnpreparedValue) var ->
|
|
|
|
Collector (ObjectSelectionSet Void var)
|
|
|
|
transformObjectSelectionSet typename selectionSet = do
|
|
|
|
-- we need to keep track of whether any subfield contained a remote join
|
|
|
|
(annotatedFields, subfieldsContainRemoteJoins) <-
|
2023-05-24 16:51:56 +03:00
|
|
|
listens isJust
|
|
|
|
$ flip InsOrdHashMap.traverseWithKey selectionSet \alias field ->
|
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
|
|
|
withField (G.unName <$> typename) (G.unName alias) do
|
|
|
|
case field of
|
|
|
|
FieldGraphQL f -> (,Nothing) <$> transformGraphQLField f
|
|
|
|
FieldRemote SchemaRemoteRelationshipSelect {..} -> do
|
|
|
|
pure
|
|
|
|
( mkPlaceholderField alias,
|
2023-04-26 18:42:13 +03:00
|
|
|
Just $ createRemoteJoin (HashMap.intersection joinColumnAliases _srrsLHSJoinFields) _srrsRelationship
|
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
|
|
|
)
|
2022-06-23 12:14:24 +03:00
|
|
|
let internalTypeAlias = Name.___hasura_internal_typename
|
2023-04-27 10:41:55 +03:00
|
|
|
remoteJoins = InsOrdHashMap.mapMaybe snd annotatedFields
|
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
|
|
|
additionalFields =
|
|
|
|
if
|
2023-05-24 16:51:56 +03:00
|
|
|
| isJust typename && (not (null remoteJoins) || subfieldsContainRemoteJoins) ->
|
|
|
|
-- We are in a situation in which the type name matters, and we know
|
|
|
|
-- that there is at least one remote join in this part of tree, meaning
|
|
|
|
-- we might need to branch on the typename when traversing the join
|
|
|
|
-- tree: we insert a custom field that will return the type name.
|
|
|
|
InsOrdHashMap.singleton internalTypeAlias
|
|
|
|
$ mkGraphQLField
|
|
|
|
(Just internalTypeAlias)
|
|
|
|
GName.___typename
|
|
|
|
mempty
|
|
|
|
mempty
|
|
|
|
SelectionSetNone
|
|
|
|
| otherwise ->
|
|
|
|
-- Either the typename doesn't matter, or this tree doesn't have remote
|
|
|
|
-- joins; this selection set isn't "ambiguous".
|
|
|
|
mempty
|
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
|
|
|
transformedFields = fmap fst annotatedFields <> additionalFields
|
2023-04-27 10:41:55 +03:00
|
|
|
case NEMap.fromList $ InsOrdHashMap.toList remoteJoins of
|
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
|
|
|
Nothing -> pure $ fmap FieldGraphQL transformedFields
|
|
|
|
Just neRemoteJoins -> do
|
|
|
|
collect $ NEMap.mapKeys (\fieldGName -> QualifiedFieldName (G.unName <$> typename) (G.unName fieldGName)) neRemoteJoins
|
2023-05-24 16:51:56 +03:00
|
|
|
pure
|
|
|
|
$ fmap
|
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
|
|
|
FieldGraphQL
|
2023-04-27 10:41:55 +03:00
|
|
|
(transformedFields <> InsOrdHashMap.fromList [(_fAlias fld, fld) | fld <- toList phantomFields])
|
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
|
|
|
where
|
|
|
|
nameToField = FieldName . G.unName
|
2023-04-27 10:41:55 +03:00
|
|
|
allAliases = map (nameToField . fst) $ InsOrdHashMap.toList selectionSet
|
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
|
|
|
|
|
|
|
mkPlaceholderField alias =
|
2022-06-23 12:14:24 +03:00
|
|
|
mkGraphQLField (Just alias) GName.___typename mempty mempty SelectionSetNone
|
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
|
|
|
|
|
|
|
-- A map of graphql scalar fields (without any arguments) to their aliases
|
|
|
|
-- in the selection set. We do not yet support lhs join fields which take
|
|
|
|
-- arguments. To be consistent with that, we ignore fields with arguments
|
|
|
|
noArgsGraphQLFields =
|
2023-05-24 16:51:56 +03:00
|
|
|
HashMap.fromList
|
|
|
|
$ flip mapMaybe (InsOrdHashMap.toList selectionSet) \(alias, field) -> case field of
|
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
|
|
|
FieldGraphQL f ->
|
|
|
|
if null (_fArguments f)
|
|
|
|
then Just (_fName f, FieldName $ G.unName alias)
|
|
|
|
else Nothing
|
|
|
|
FieldRemote _ -> Nothing
|
|
|
|
|
|
|
|
annotateLHSJoinField fieldName lhsJoinField =
|
|
|
|
let columnAlias =
|
|
|
|
getJoinColumnAlias fieldName lhsJoinField noArgsGraphQLFields allAliases
|
2022-03-10 05:12:53 +03:00
|
|
|
-- This alias is generated in 'getJoinColumnAlias', and is guaranteed
|
|
|
|
-- to be a valid GraphQLName.
|
|
|
|
columnGraphQLName =
|
2022-07-01 13:49:31 +03:00
|
|
|
G.mkName $ getFieldNameTxt $ getAliasFieldName columnAlias
|
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
|
|
|
in ( mkGraphQLField
|
2022-07-01 13:49:31 +03:00
|
|
|
columnGraphQLName
|
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
|
|
|
lhsJoinField
|
|
|
|
mempty
|
|
|
|
mempty
|
|
|
|
SelectionSetNone,
|
|
|
|
columnAlias
|
|
|
|
)
|
|
|
|
|
|
|
|
(joinColumnAliases, phantomFields) =
|
|
|
|
let lhsJoinFields =
|
2023-04-26 18:42:13 +03:00
|
|
|
HashMap.unions $ map _srrsLHSJoinFields $ mapMaybe (preview _FieldRemote) $ toList selectionSet
|
|
|
|
annotatedJoinColumns = HashMap.mapWithKey annotateLHSJoinField lhsJoinFields
|
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
|
|
|
in (fmap snd annotatedJoinColumns, fmap fst annotatedJoinColumns)
|
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
-- Internal helpers
|
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
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
-- | Converts a remote relationship field into a 'RemoteJoin' that
|
|
|
|
-- the execution engine understands.
|
|
|
|
createRemoteJoin ::
|
|
|
|
-- We need information about 'how' the lhs join fields appear in the lhs
|
|
|
|
-- response to construct a 'RemoteJoin' node
|
2023-04-26 18:42:13 +03:00
|
|
|
HashMap.HashMap FieldName JoinColumnAlias ->
|
2022-03-10 09:17:48 +03:00
|
|
|
-- The remote relationship field as captured in the IR
|
|
|
|
RemoteRelationshipField UnpreparedValue ->
|
|
|
|
RemoteJoin
|
|
|
|
createRemoteJoin joinColumnAliases = \case
|
|
|
|
RemoteSchemaField RemoteSchemaSelect {..} ->
|
2023-04-26 18:42:13 +03:00
|
|
|
let inputArgsToMap = HashMap.fromList . map (_rfaArgument &&& _rfaValue)
|
2022-03-10 09:17:48 +03:00
|
|
|
(transformedSchemaRelationship, schemaRelationshipJoins) =
|
|
|
|
getRemoteJoinsGraphQLSelectionSet _rselSelection
|
|
|
|
remoteJoin =
|
|
|
|
RemoteSchemaJoin
|
|
|
|
(inputArgsToMap _rselArgs)
|
|
|
|
_rselResultCustomizer
|
|
|
|
transformedSchemaRelationship
|
|
|
|
joinColumnAliases
|
|
|
|
_rselFieldCall
|
|
|
|
_rselRemoteSchema
|
|
|
|
in RemoteJoinRemoteSchema remoteJoin schemaRelationshipJoins
|
|
|
|
RemoteSourceField anySourceSelect ->
|
|
|
|
AB.dispatchAnyBackend @Backend anySourceSelect \RemoteSourceSelect {..} ->
|
|
|
|
let (transformedSourceRelationship, sourceRelationshipJoins) =
|
|
|
|
getRemoteJoinsSourceRelation _rssSelection
|
|
|
|
|
|
|
|
-- the invariant here is that the the keys in joinColumnAliases and
|
|
|
|
-- _rssJoinMapping are the same. We could've opted for a more type
|
|
|
|
-- safe representation Map k (a, b) instead of (Map k a, Map k b)
|
|
|
|
-- but that would make the type of lhs join columns creep into
|
|
|
|
-- RemoteRelationshipField which would make the type a little
|
|
|
|
-- unweildy
|
|
|
|
joinColumns =
|
2023-04-26 18:42:13 +03:00
|
|
|
_rssJoinMapping & HashMap.mapMaybeWithKey
|
2022-03-10 18:25:25 +03:00
|
|
|
\joinFieldName (rhsColumnType, rhsColumn) ->
|
|
|
|
(,(rhsColumn, rhsColumnType))
|
2023-04-26 18:42:13 +03:00
|
|
|
<$> HashMap.lookup joinFieldName joinColumnAliases
|
2022-03-10 09:17:48 +03:00
|
|
|
anySourceJoin =
|
2023-05-24 16:51:56 +03:00
|
|
|
AB.mkAnyBackend
|
|
|
|
$ RemoteSourceJoin
|
2022-03-10 09:17:48 +03:00
|
|
|
_rssName
|
|
|
|
_rssConfig
|
|
|
|
transformedSourceRelationship
|
|
|
|
joinColumns
|
2022-12-19 17:03:13 +03:00
|
|
|
_rssStringifyNums
|
2022-03-10 09:17:48 +03:00
|
|
|
in RemoteJoinSource anySourceJoin sourceRelationshipJoins
|
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
|
|
|
|
2022-03-10 09:17:48 +03:00
|
|
|
-- | Constructs a 'JoinColumnAlias' for a given field in a selection set.
|
|
|
|
--
|
|
|
|
-- If the field was already requested, we leave it unchanged, to avoid
|
|
|
|
-- double-fetching the same information. However, if this field is a "phantom"
|
|
|
|
-- field, that we only add for the purpose of fetching a join key, we rename it
|
|
|
|
-- in a way that is guaranteed to avoid conflicts.
|
|
|
|
--
|
|
|
|
-- NOTE: if the @fieldName@ argument is a valid GraphQL name, then the
|
|
|
|
-- constructed alias MUST also be a valid GraphQL name.
|
|
|
|
getJoinColumnAlias ::
|
2023-05-24 16:51:56 +03:00
|
|
|
(Hashable field) =>
|
2022-03-10 09:17:48 +03:00
|
|
|
FieldName ->
|
|
|
|
field ->
|
|
|
|
HashMap field FieldName ->
|
|
|
|
[FieldName] ->
|
|
|
|
JoinColumnAlias
|
|
|
|
getJoinColumnAlias fieldName field selectedFields allAliases =
|
2023-04-26 18:42:13 +03:00
|
|
|
case HashMap.lookup field selectedFields of
|
2022-03-10 09:17:48 +03:00
|
|
|
Nothing -> JCPhantom uniqueAlias
|
|
|
|
Just fieldAlias -> JCSelected fieldAlias
|
|
|
|
where
|
|
|
|
-- This generates an alias for a phantom field that does not conflict with
|
|
|
|
-- any of the existing aliases in the selection set
|
|
|
|
--
|
|
|
|
-- If we generate a unique name for each field name which is longer than
|
|
|
|
-- the longest alias in the selection set, the generated name would be
|
|
|
|
-- unique.
|
|
|
|
uniqueAlias :: FieldName
|
|
|
|
uniqueAlias =
|
|
|
|
let suffix =
|
|
|
|
"_join_column"
|
|
|
|
<>
|
|
|
|
-- 12 is the length of "_join_column"
|
|
|
|
T.replicate ((longestAliasLength - (T.length (coerce fieldName) + 12)) + 1) "_"
|
|
|
|
in fieldName <> FieldName suffix
|
|
|
|
where
|
|
|
|
longestAliasLength = maximum $ map (T.length . coerce) allAliases
|
|
|
|
|
|
|
|
-- | Get the fields targeted by some 'Traversal' for an arbitrary list of
|
|
|
|
-- tuples, discarding any elements whose fields cannot be focused upon.
|
|
|
|
getFields :: Traversal' super sub -> [(any, super)] -> [(any, sub)]
|
|
|
|
getFields focus = mapMaybe (traverse $ preview focus)
|