2021-02-23 20:37:27 +03:00
|
|
|
{-# OPTIONS_GHC -fno-warn-orphans #-}
|
|
|
|
|
2022-01-11 01:54:51 +03:00
|
|
|
-- | MSSQL Instances Transport
|
|
|
|
--
|
|
|
|
-- Defines the MSSQL instance of 'BackendTransport' and how to
|
|
|
|
-- interact with the database for running queries, mutations, subscriptions,
|
|
|
|
-- and so on.
|
2021-02-23 20:37:27 +03:00
|
|
|
module Hasura.Backends.MSSQL.Instances.Transport () where
|
|
|
|
|
2022-04-07 17:41:43 +03:00
|
|
|
import Control.Exception.Safe (throwIO)
|
Allow backend execution to happen on the base app monad.
### Description
Each Backend executes queries against the database in a slightly different stack: Postgres uses its own `TXeT`, MSSQL uses a variant of it, BigQuery is simply in `ExceptT QErr IO`... To accommodate those variations, we had originally introduced an `ExecutionMonad b` type family in `BackendExecute`, allowing each backend to describe its own stack. It was then up to that backend's `BackendTransport` instance to implement running said stack, and converting the result back into our main app monad.
However, this was not without complications: `TraceT` is one of them: as it usually needs to be on the top of the stack, converting from one stack to the other implies the use `interpTraceT`, which is quite monstrous. Furthermore, as part of the Entitlement Services work, we're trying to move to a "Services" architecture in which the entire engine runs in one base monad, that delegates features and dependencies to monad constraints; and as a result we'd like to minimize the number of different monad stacks we have to maintain and translate from and to in the codebase.
To improve things, this PR changes `ExecutionMonad b` from an _absolute_ stack to a _relative_ one: i.e.: what needs to be stacked on top of our base monad for the execution. In `Transport`, we then only need to pop the top of the stack, and voila. This greatly simplifies the implementation of the backends, as there's no longer any need to do any stack transformation: MySQL's implementation becomes a `runIdentityT`! This also removes most mentions of `TraceT` from the execution code since it's no longer required: we can rely on the base monad's existing `MonadTrace` constraint.
To continue encapsulating monadic actions in `DBStepInfo` and avoid threading a bunch of `forall` all over the place, this PR introduces a small local helper: `OnBaseMonad`. One only downside of all this is that this requires adding `MonadBaseControl IO m` constraint all over the place: previously, we would run directly on `IO` and lift, and would therefore not need to bring that constraint all the way.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7789
GitOrigin-RevId: e9b2e431c5c47fa9851abf87545c0415ff6d1a12
2023-02-09 17:38:33 +03:00
|
|
|
import Control.Monad.Trans.Control
|
2021-03-13 17:40:50 +03:00
|
|
|
import Data.Aeson qualified as J
|
2021-02-23 20:37:27 +03:00
|
|
|
import Data.ByteString qualified as B
|
2021-04-20 19:57:14 +03:00
|
|
|
import Data.String (fromString)
|
2021-02-23 20:37:27 +03:00
|
|
|
import Data.Text.Encoding (encodeUtf8)
|
|
|
|
import Data.Text.Extended
|
2022-03-21 15:14:52 +03:00
|
|
|
import Database.MSSQL.Transaction (forJsonQueryE)
|
2021-04-20 19:57:14 +03:00
|
|
|
import Database.ODBC.SQLServer qualified as ODBC
|
2021-02-25 21:15:55 +03:00
|
|
|
import Hasura.Backends.MSSQL.Connection
|
2022-04-28 22:33:33 +03:00
|
|
|
import Hasura.Backends.MSSQL.Execute.QueryTags (withQueryTags)
|
2021-02-23 20:37:27 +03:00
|
|
|
import Hasura.Backends.MSSQL.Instances.Execute
|
2022-02-07 17:11:49 +03:00
|
|
|
import Hasura.Backends.MSSQL.SQL.Error
|
2021-04-20 19:57:14 +03:00
|
|
|
import Hasura.Backends.MSSQL.ToQuery
|
2021-05-11 18:18:31 +03:00
|
|
|
import Hasura.Base.Error
|
2021-02-23 20:37:27 +03:00
|
|
|
import Hasura.EncJSON
|
|
|
|
import Hasura.GraphQL.Execute.Backend
|
2022-03-21 13:39:49 +03:00
|
|
|
import Hasura.GraphQL.Execute.Subscription.Plan
|
2021-03-13 17:40:50 +03:00
|
|
|
import Hasura.GraphQL.Logging
|
2021-10-29 17:42:07 +03:00
|
|
|
import Hasura.GraphQL.Namespace (RootFieldAlias)
|
2021-02-23 20:37:27 +03:00
|
|
|
import Hasura.GraphQL.Transport.Backend
|
|
|
|
import Hasura.GraphQL.Transport.HTTP.Protocol
|
|
|
|
import Hasura.Logging qualified as L
|
|
|
|
import Hasura.Prelude
|
2022-04-27 16:57:28 +03:00
|
|
|
import Hasura.RQL.Types.Backend
|
|
|
|
import Hasura.SQL.Backend
|
2021-02-23 20:37:27 +03:00
|
|
|
import Hasura.Server.Types (RequestId)
|
|
|
|
import Hasura.Session
|
|
|
|
import Hasura.Tracing
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-02-23 20:37:27 +03:00
|
|
|
instance BackendTransport 'MSSQL where
|
|
|
|
runDBQuery = runQuery
|
2021-04-13 14:10:08 +03:00
|
|
|
runDBQueryExplain = runQueryExplain
|
2021-02-23 20:37:27 +03:00
|
|
|
runDBMutation = runMutation
|
|
|
|
runDBSubscription = runSubscription
|
2023-01-25 10:12:53 +03:00
|
|
|
runDBStreamingSubscription _ _ _ _ =
|
2022-04-07 17:41:43 +03:00
|
|
|
liftIO . throwIO $ userError "runDBSubscription: not implemented for MS-SQL sources."
|
2021-02-23 20:37:27 +03:00
|
|
|
|
2021-04-20 19:57:14 +03:00
|
|
|
newtype CohortResult = CohortResult (CohortId, Text)
|
|
|
|
|
|
|
|
instance J.FromJSON CohortResult where
|
|
|
|
parseJSON = J.withObject "CohortResult" \o -> do
|
|
|
|
cohortId <- o J..: "result_id"
|
|
|
|
cohortData <- o J..: "result"
|
|
|
|
pure $ CohortResult (cohortId, cohortData)
|
|
|
|
|
2021-02-23 20:37:27 +03:00
|
|
|
runQuery ::
|
|
|
|
( MonadIO m,
|
Allow backend execution to happen on the base app monad.
### Description
Each Backend executes queries against the database in a slightly different stack: Postgres uses its own `TXeT`, MSSQL uses a variant of it, BigQuery is simply in `ExceptT QErr IO`... To accommodate those variations, we had originally introduced an `ExecutionMonad b` type family in `BackendExecute`, allowing each backend to describe its own stack. It was then up to that backend's `BackendTransport` instance to implement running said stack, and converting the result back into our main app monad.
However, this was not without complications: `TraceT` is one of them: as it usually needs to be on the top of the stack, converting from one stack to the other implies the use `interpTraceT`, which is quite monstrous. Furthermore, as part of the Entitlement Services work, we're trying to move to a "Services" architecture in which the entire engine runs in one base monad, that delegates features and dependencies to monad constraints; and as a result we'd like to minimize the number of different monad stacks we have to maintain and translate from and to in the codebase.
To improve things, this PR changes `ExecutionMonad b` from an _absolute_ stack to a _relative_ one: i.e.: what needs to be stacked on top of our base monad for the execution. In `Transport`, we then only need to pop the top of the stack, and voila. This greatly simplifies the implementation of the backends, as there's no longer any need to do any stack transformation: MySQL's implementation becomes a `runIdentityT`! This also removes most mentions of `TraceT` from the execution code since it's no longer required: we can rely on the base monad's existing `MonadTrace` constraint.
To continue encapsulating monadic actions in `DBStepInfo` and avoid threading a bunch of `forall` all over the place, this PR introduces a small local helper: `OnBaseMonad`. One only downside of all this is that this requires adding `MonadBaseControl IO m` constraint all over the place: previously, we would run directly on `IO` and lift, and would therefore not need to bring that constraint all the way.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7789
GitOrigin-RevId: e9b2e431c5c47fa9851abf87545c0415ff6d1a12
2023-02-09 17:38:33 +03:00
|
|
|
MonadBaseControl IO m,
|
2021-02-23 20:37:27 +03:00
|
|
|
MonadQueryLog m,
|
|
|
|
MonadTrace m,
|
|
|
|
MonadError QErr m
|
|
|
|
) =>
|
|
|
|
RequestId ->
|
|
|
|
GQLReqUnparsed ->
|
2021-10-29 17:42:07 +03:00
|
|
|
RootFieldAlias ->
|
2021-02-23 20:37:27 +03:00
|
|
|
UserInfo ->
|
|
|
|
L.Logger L.Hasura ->
|
|
|
|
SourceConfig 'MSSQL ->
|
Allow backend execution to happen on the base app monad.
### Description
Each Backend executes queries against the database in a slightly different stack: Postgres uses its own `TXeT`, MSSQL uses a variant of it, BigQuery is simply in `ExceptT QErr IO`... To accommodate those variations, we had originally introduced an `ExecutionMonad b` type family in `BackendExecute`, allowing each backend to describe its own stack. It was then up to that backend's `BackendTransport` instance to implement running said stack, and converting the result back into our main app monad.
However, this was not without complications: `TraceT` is one of them: as it usually needs to be on the top of the stack, converting from one stack to the other implies the use `interpTraceT`, which is quite monstrous. Furthermore, as part of the Entitlement Services work, we're trying to move to a "Services" architecture in which the entire engine runs in one base monad, that delegates features and dependencies to monad constraints; and as a result we'd like to minimize the number of different monad stacks we have to maintain and translate from and to in the codebase.
To improve things, this PR changes `ExecutionMonad b` from an _absolute_ stack to a _relative_ one: i.e.: what needs to be stacked on top of our base monad for the execution. In `Transport`, we then only need to pop the top of the stack, and voila. This greatly simplifies the implementation of the backends, as there's no longer any need to do any stack transformation: MySQL's implementation becomes a `runIdentityT`! This also removes most mentions of `TraceT` from the execution code since it's no longer required: we can rely on the base monad's existing `MonadTrace` constraint.
To continue encapsulating monadic actions in `DBStepInfo` and avoid threading a bunch of `forall` all over the place, this PR introduces a small local helper: `OnBaseMonad`. One only downside of all this is that this requires adding `MonadBaseControl IO m` constraint all over the place: previously, we would run directly on `IO` and lift, and would therefore not need to bring that constraint all the way.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7789
GitOrigin-RevId: e9b2e431c5c47fa9851abf87545c0415ff6d1a12
2023-02-09 17:38:33 +03:00
|
|
|
OnBaseMonad (ExceptT QErr) EncJSON ->
|
2021-05-21 14:37:34 +03:00
|
|
|
Maybe (PreparedQuery 'MSSQL) ->
|
2023-01-25 10:12:53 +03:00
|
|
|
ResolvedConnectionTemplate 'MSSQL ->
|
2021-02-23 20:37:27 +03:00
|
|
|
-- | Also return the time spent in the PG query; for telemetry.
|
|
|
|
m (DiffTime, EncJSON)
|
2023-01-25 10:12:53 +03:00
|
|
|
runQuery reqId query fieldName _userInfo logger _sourceConfig tx genSql _ = do
|
2021-03-13 17:40:50 +03:00
|
|
|
logQueryLog logger $ mkQueryLog query fieldName genSql reqId
|
2021-02-23 20:37:27 +03:00
|
|
|
withElapsedTime $
|
|
|
|
trace ("MSSQL Query for root field " <>> fieldName) $
|
|
|
|
run tx
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-04-13 14:10:08 +03:00
|
|
|
runQueryExplain ::
|
|
|
|
( MonadIO m,
|
Allow backend execution to happen on the base app monad.
### Description
Each Backend executes queries against the database in a slightly different stack: Postgres uses its own `TXeT`, MSSQL uses a variant of it, BigQuery is simply in `ExceptT QErr IO`... To accommodate those variations, we had originally introduced an `ExecutionMonad b` type family in `BackendExecute`, allowing each backend to describe its own stack. It was then up to that backend's `BackendTransport` instance to implement running said stack, and converting the result back into our main app monad.
However, this was not without complications: `TraceT` is one of them: as it usually needs to be on the top of the stack, converting from one stack to the other implies the use `interpTraceT`, which is quite monstrous. Furthermore, as part of the Entitlement Services work, we're trying to move to a "Services" architecture in which the entire engine runs in one base monad, that delegates features and dependencies to monad constraints; and as a result we'd like to minimize the number of different monad stacks we have to maintain and translate from and to in the codebase.
To improve things, this PR changes `ExecutionMonad b` from an _absolute_ stack to a _relative_ one: i.e.: what needs to be stacked on top of our base monad for the execution. In `Transport`, we then only need to pop the top of the stack, and voila. This greatly simplifies the implementation of the backends, as there's no longer any need to do any stack transformation: MySQL's implementation becomes a `runIdentityT`! This also removes most mentions of `TraceT` from the execution code since it's no longer required: we can rely on the base monad's existing `MonadTrace` constraint.
To continue encapsulating monadic actions in `DBStepInfo` and avoid threading a bunch of `forall` all over the place, this PR introduces a small local helper: `OnBaseMonad`. One only downside of all this is that this requires adding `MonadBaseControl IO m` constraint all over the place: previously, we would run directly on `IO` and lift, and would therefore not need to bring that constraint all the way.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7789
GitOrigin-RevId: e9b2e431c5c47fa9851abf87545c0415ff6d1a12
2023-02-09 17:38:33 +03:00
|
|
|
MonadBaseControl IO m,
|
|
|
|
MonadError QErr m,
|
|
|
|
MonadTrace m
|
2021-04-13 14:10:08 +03:00
|
|
|
) =>
|
|
|
|
DBStepInfo 'MSSQL ->
|
|
|
|
m EncJSON
|
2023-01-25 10:12:53 +03:00
|
|
|
runQueryExplain (DBStepInfo _ _ _ action _) = run action
|
2021-04-13 14:10:08 +03:00
|
|
|
|
2021-02-23 20:37:27 +03:00
|
|
|
runMutation ::
|
|
|
|
( MonadIO m,
|
Allow backend execution to happen on the base app monad.
### Description
Each Backend executes queries against the database in a slightly different stack: Postgres uses its own `TXeT`, MSSQL uses a variant of it, BigQuery is simply in `ExceptT QErr IO`... To accommodate those variations, we had originally introduced an `ExecutionMonad b` type family in `BackendExecute`, allowing each backend to describe its own stack. It was then up to that backend's `BackendTransport` instance to implement running said stack, and converting the result back into our main app monad.
However, this was not without complications: `TraceT` is one of them: as it usually needs to be on the top of the stack, converting from one stack to the other implies the use `interpTraceT`, which is quite monstrous. Furthermore, as part of the Entitlement Services work, we're trying to move to a "Services" architecture in which the entire engine runs in one base monad, that delegates features and dependencies to monad constraints; and as a result we'd like to minimize the number of different monad stacks we have to maintain and translate from and to in the codebase.
To improve things, this PR changes `ExecutionMonad b` from an _absolute_ stack to a _relative_ one: i.e.: what needs to be stacked on top of our base monad for the execution. In `Transport`, we then only need to pop the top of the stack, and voila. This greatly simplifies the implementation of the backends, as there's no longer any need to do any stack transformation: MySQL's implementation becomes a `runIdentityT`! This also removes most mentions of `TraceT` from the execution code since it's no longer required: we can rely on the base monad's existing `MonadTrace` constraint.
To continue encapsulating monadic actions in `DBStepInfo` and avoid threading a bunch of `forall` all over the place, this PR introduces a small local helper: `OnBaseMonad`. One only downside of all this is that this requires adding `MonadBaseControl IO m` constraint all over the place: previously, we would run directly on `IO` and lift, and would therefore not need to bring that constraint all the way.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7789
GitOrigin-RevId: e9b2e431c5c47fa9851abf87545c0415ff6d1a12
2023-02-09 17:38:33 +03:00
|
|
|
MonadBaseControl IO m,
|
2021-02-23 20:37:27 +03:00
|
|
|
MonadQueryLog m,
|
|
|
|
MonadTrace m,
|
|
|
|
MonadError QErr m
|
|
|
|
) =>
|
|
|
|
RequestId ->
|
|
|
|
GQLReqUnparsed ->
|
2021-10-29 17:42:07 +03:00
|
|
|
RootFieldAlias ->
|
2021-02-23 20:37:27 +03:00
|
|
|
UserInfo ->
|
|
|
|
L.Logger L.Hasura ->
|
|
|
|
SourceConfig 'MSSQL ->
|
Allow backend execution to happen on the base app monad.
### Description
Each Backend executes queries against the database in a slightly different stack: Postgres uses its own `TXeT`, MSSQL uses a variant of it, BigQuery is simply in `ExceptT QErr IO`... To accommodate those variations, we had originally introduced an `ExecutionMonad b` type family in `BackendExecute`, allowing each backend to describe its own stack. It was then up to that backend's `BackendTransport` instance to implement running said stack, and converting the result back into our main app monad.
However, this was not without complications: `TraceT` is one of them: as it usually needs to be on the top of the stack, converting from one stack to the other implies the use `interpTraceT`, which is quite monstrous. Furthermore, as part of the Entitlement Services work, we're trying to move to a "Services" architecture in which the entire engine runs in one base monad, that delegates features and dependencies to monad constraints; and as a result we'd like to minimize the number of different monad stacks we have to maintain and translate from and to in the codebase.
To improve things, this PR changes `ExecutionMonad b` from an _absolute_ stack to a _relative_ one: i.e.: what needs to be stacked on top of our base monad for the execution. In `Transport`, we then only need to pop the top of the stack, and voila. This greatly simplifies the implementation of the backends, as there's no longer any need to do any stack transformation: MySQL's implementation becomes a `runIdentityT`! This also removes most mentions of `TraceT` from the execution code since it's no longer required: we can rely on the base monad's existing `MonadTrace` constraint.
To continue encapsulating monadic actions in `DBStepInfo` and avoid threading a bunch of `forall` all over the place, this PR introduces a small local helper: `OnBaseMonad`. One only downside of all this is that this requires adding `MonadBaseControl IO m` constraint all over the place: previously, we would run directly on `IO` and lift, and would therefore not need to bring that constraint all the way.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7789
GitOrigin-RevId: e9b2e431c5c47fa9851abf87545c0415ff6d1a12
2023-02-09 17:38:33 +03:00
|
|
|
OnBaseMonad (ExceptT QErr) EncJSON ->
|
2021-05-21 14:37:34 +03:00
|
|
|
Maybe (PreparedQuery 'MSSQL) ->
|
2023-01-25 10:12:53 +03:00
|
|
|
ResolvedConnectionTemplate 'MSSQL ->
|
2021-02-23 20:37:27 +03:00
|
|
|
-- | Also return 'Mutation' when the operation was a mutation, and the time
|
|
|
|
-- spent in the PG query; for telemetry.
|
|
|
|
m (DiffTime, EncJSON)
|
2023-01-25 10:12:53 +03:00
|
|
|
runMutation reqId query fieldName _userInfo logger _sourceConfig tx _genSql _ = do
|
2021-03-13 17:40:50 +03:00
|
|
|
logQueryLog logger $ mkQueryLog query fieldName Nothing reqId
|
2021-02-23 20:37:27 +03:00
|
|
|
withElapsedTime $
|
|
|
|
trace ("MSSQL Mutation for root field " <>> fieldName) $
|
|
|
|
run tx
|
2021-09-24 01:56:37 +03:00
|
|
|
|
2021-02-23 20:37:27 +03:00
|
|
|
runSubscription ::
|
Allow backend execution to happen on the base app monad.
### Description
Each Backend executes queries against the database in a slightly different stack: Postgres uses its own `TXeT`, MSSQL uses a variant of it, BigQuery is simply in `ExceptT QErr IO`... To accommodate those variations, we had originally introduced an `ExecutionMonad b` type family in `BackendExecute`, allowing each backend to describe its own stack. It was then up to that backend's `BackendTransport` instance to implement running said stack, and converting the result back into our main app monad.
However, this was not without complications: `TraceT` is one of them: as it usually needs to be on the top of the stack, converting from one stack to the other implies the use `interpTraceT`, which is quite monstrous. Furthermore, as part of the Entitlement Services work, we're trying to move to a "Services" architecture in which the entire engine runs in one base monad, that delegates features and dependencies to monad constraints; and as a result we'd like to minimize the number of different monad stacks we have to maintain and translate from and to in the codebase.
To improve things, this PR changes `ExecutionMonad b` from an _absolute_ stack to a _relative_ one: i.e.: what needs to be stacked on top of our base monad for the execution. In `Transport`, we then only need to pop the top of the stack, and voila. This greatly simplifies the implementation of the backends, as there's no longer any need to do any stack transformation: MySQL's implementation becomes a `runIdentityT`! This also removes most mentions of `TraceT` from the execution code since it's no longer required: we can rely on the base monad's existing `MonadTrace` constraint.
To continue encapsulating monadic actions in `DBStepInfo` and avoid threading a bunch of `forall` all over the place, this PR introduces a small local helper: `OnBaseMonad`. One only downside of all this is that this requires adding `MonadBaseControl IO m` constraint all over the place: previously, we would run directly on `IO` and lift, and would therefore not need to bring that constraint all the way.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7789
GitOrigin-RevId: e9b2e431c5c47fa9851abf87545c0415ff6d1a12
2023-02-09 17:38:33 +03:00
|
|
|
(MonadIO m, MonadBaseControl IO m) =>
|
2021-02-23 20:37:27 +03:00
|
|
|
SourceConfig 'MSSQL ->
|
|
|
|
MultiplexedQuery 'MSSQL ->
|
|
|
|
[(CohortId, CohortVariables)] ->
|
2023-01-25 10:12:53 +03:00
|
|
|
ResolvedConnectionTemplate 'MSSQL ->
|
2021-02-23 20:37:27 +03:00
|
|
|
m (DiffTime, Either QErr [(CohortId, B.ByteString)])
|
2023-01-25 10:12:53 +03:00
|
|
|
runSubscription sourceConfig (MultiplexedQuery' reselect queryTags) variables _ = do
|
2022-01-04 14:53:50 +03:00
|
|
|
let mssqlExecCtx = _mscExecCtx sourceConfig
|
2021-04-20 19:57:14 +03:00
|
|
|
multiplexed = multiplexRootReselect variables reselect
|
2022-04-28 22:33:33 +03:00
|
|
|
query = toQueryFlat (fromSelect multiplexed)
|
|
|
|
-- Append query tags comment to the query. We cannot use 'toSQL' to convert
|
|
|
|
-- QueryTagsComment to Query, because it escapes the query tags comment which
|
|
|
|
-- will create a badly formatted query. Hence we use the 'rawUnescapedText' to
|
|
|
|
-- append the comment without any escaping.
|
|
|
|
queryWithQueryTags = query `withQueryTags` queryTags
|
|
|
|
withElapsedTime $ runExceptT $ executeMultiplexedQuery mssqlExecCtx queryWithQueryTags
|
2021-04-20 19:57:14 +03:00
|
|
|
|
|
|
|
executeMultiplexedQuery ::
|
Allow backend execution to happen on the base app monad.
### Description
Each Backend executes queries against the database in a slightly different stack: Postgres uses its own `TXeT`, MSSQL uses a variant of it, BigQuery is simply in `ExceptT QErr IO`... To accommodate those variations, we had originally introduced an `ExecutionMonad b` type family in `BackendExecute`, allowing each backend to describe its own stack. It was then up to that backend's `BackendTransport` instance to implement running said stack, and converting the result back into our main app monad.
However, this was not without complications: `TraceT` is one of them: as it usually needs to be on the top of the stack, converting from one stack to the other implies the use `interpTraceT`, which is quite monstrous. Furthermore, as part of the Entitlement Services work, we're trying to move to a "Services" architecture in which the entire engine runs in one base monad, that delegates features and dependencies to monad constraints; and as a result we'd like to minimize the number of different monad stacks we have to maintain and translate from and to in the codebase.
To improve things, this PR changes `ExecutionMonad b` from an _absolute_ stack to a _relative_ one: i.e.: what needs to be stacked on top of our base monad for the execution. In `Transport`, we then only need to pop the top of the stack, and voila. This greatly simplifies the implementation of the backends, as there's no longer any need to do any stack transformation: MySQL's implementation becomes a `runIdentityT`! This also removes most mentions of `TraceT` from the execution code since it's no longer required: we can rely on the base monad's existing `MonadTrace` constraint.
To continue encapsulating monadic actions in `DBStepInfo` and avoid threading a bunch of `forall` all over the place, this PR introduces a small local helper: `OnBaseMonad`. One only downside of all this is that this requires adding `MonadBaseControl IO m` constraint all over the place: previously, we would run directly on `IO` and lift, and would therefore not need to bring that constraint all the way.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7789
GitOrigin-RevId: e9b2e431c5c47fa9851abf87545c0415ff6d1a12
2023-02-09 17:38:33 +03:00
|
|
|
(MonadIO m, MonadBaseControl IO m) =>
|
2022-01-04 14:53:50 +03:00
|
|
|
MSSQLExecCtx ->
|
2021-04-20 19:57:14 +03:00
|
|
|
ODBC.Query ->
|
|
|
|
ExceptT QErr m [(CohortId, B.ByteString)]
|
2022-01-04 14:53:50 +03:00
|
|
|
executeMultiplexedQuery mssqlExecCtx query = do
|
2021-04-20 19:57:14 +03:00
|
|
|
let parseResult r = J.eitherDecodeStrict (encodeUtf8 r) `onLeft` \s -> throw400 ParseFailed (fromString s)
|
|
|
|
convertFromJSON :: [CohortResult] -> [(CohortId, B.ByteString)]
|
|
|
|
convertFromJSON = map \(CohortResult (cid, cresult)) -> (cid, encodeUtf8 cresult)
|
2022-03-21 15:14:52 +03:00
|
|
|
-- Because the 'query' will have a @FOR JSON@ clause at the toplevel it will
|
|
|
|
-- be split across multiple rows, hence use of 'forJsonQueryE' which takes
|
|
|
|
-- care of concatenating the results.
|
Allow backend execution to happen on the base app monad.
### Description
Each Backend executes queries against the database in a slightly different stack: Postgres uses its own `TXeT`, MSSQL uses a variant of it, BigQuery is simply in `ExceptT QErr IO`... To accommodate those variations, we had originally introduced an `ExecutionMonad b` type family in `BackendExecute`, allowing each backend to describe its own stack. It was then up to that backend's `BackendTransport` instance to implement running said stack, and converting the result back into our main app monad.
However, this was not without complications: `TraceT` is one of them: as it usually needs to be on the top of the stack, converting from one stack to the other implies the use `interpTraceT`, which is quite monstrous. Furthermore, as part of the Entitlement Services work, we're trying to move to a "Services" architecture in which the entire engine runs in one base monad, that delegates features and dependencies to monad constraints; and as a result we'd like to minimize the number of different monad stacks we have to maintain and translate from and to in the codebase.
To improve things, this PR changes `ExecutionMonad b` from an _absolute_ stack to a _relative_ one: i.e.: what needs to be stacked on top of our base monad for the execution. In `Transport`, we then only need to pop the top of the stack, and voila. This greatly simplifies the implementation of the backends, as there's no longer any need to do any stack transformation: MySQL's implementation becomes a `runIdentityT`! This also removes most mentions of `TraceT` from the execution code since it's no longer required: we can rely on the base monad's existing `MonadTrace` constraint.
To continue encapsulating monadic actions in `DBStepInfo` and avoid threading a bunch of `forall` all over the place, this PR introduces a small local helper: `OnBaseMonad`. One only downside of all this is that this requires adding `MonadBaseControl IO m` constraint all over the place: previously, we would run directly on `IO` and lift, and would therefore not need to bring that constraint all the way.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7789
GitOrigin-RevId: e9b2e431c5c47fa9851abf87545c0415ff6d1a12
2023-02-09 17:38:33 +03:00
|
|
|
textResult <- liftEitherM $ runExceptT $ mssqlRunReadOnly mssqlExecCtx $ forJsonQueryE defaultMSSQLTxErrorHandler query
|
2021-04-20 19:57:14 +03:00
|
|
|
parsedResult <- parseResult textResult
|
|
|
|
pure $ convertFromJSON parsedResult
|
2021-03-13 17:40:50 +03:00
|
|
|
|
Allow backend execution to happen on the base app monad.
### Description
Each Backend executes queries against the database in a slightly different stack: Postgres uses its own `TXeT`, MSSQL uses a variant of it, BigQuery is simply in `ExceptT QErr IO`... To accommodate those variations, we had originally introduced an `ExecutionMonad b` type family in `BackendExecute`, allowing each backend to describe its own stack. It was then up to that backend's `BackendTransport` instance to implement running said stack, and converting the result back into our main app monad.
However, this was not without complications: `TraceT` is one of them: as it usually needs to be on the top of the stack, converting from one stack to the other implies the use `interpTraceT`, which is quite monstrous. Furthermore, as part of the Entitlement Services work, we're trying to move to a "Services" architecture in which the entire engine runs in one base monad, that delegates features and dependencies to monad constraints; and as a result we'd like to minimize the number of different monad stacks we have to maintain and translate from and to in the codebase.
To improve things, this PR changes `ExecutionMonad b` from an _absolute_ stack to a _relative_ one: i.e.: what needs to be stacked on top of our base monad for the execution. In `Transport`, we then only need to pop the top of the stack, and voila. This greatly simplifies the implementation of the backends, as there's no longer any need to do any stack transformation: MySQL's implementation becomes a `runIdentityT`! This also removes most mentions of `TraceT` from the execution code since it's no longer required: we can rely on the base monad's existing `MonadTrace` constraint.
To continue encapsulating monadic actions in `DBStepInfo` and avoid threading a bunch of `forall` all over the place, this PR introduces a small local helper: `OnBaseMonad`. One only downside of all this is that this requires adding `MonadBaseControl IO m` constraint all over the place: previously, we would run directly on `IO` and lift, and would therefore not need to bring that constraint all the way.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7789
GitOrigin-RevId: e9b2e431c5c47fa9851abf87545c0415ff6d1a12
2023-02-09 17:38:33 +03:00
|
|
|
run :: (MonadIO m, MonadBaseControl IO m, MonadError QErr m, MonadTrace m) => OnBaseMonad (ExceptT QErr) a -> m a
|
|
|
|
run = liftEitherM . runExceptT . runOnBaseMonad
|
2021-03-13 17:40:50 +03:00
|
|
|
|
|
|
|
mkQueryLog ::
|
|
|
|
GQLReqUnparsed ->
|
2021-10-29 17:42:07 +03:00
|
|
|
RootFieldAlias ->
|
2021-05-21 14:37:34 +03:00
|
|
|
Maybe (PreparedQuery 'MSSQL) ->
|
2021-03-13 17:40:50 +03:00
|
|
|
RequestId ->
|
|
|
|
QueryLog
|
|
|
|
mkQueryLog gqlQuery fieldName preparedSql requestId =
|
2023-01-25 10:12:53 +03:00
|
|
|
-- @QueryLogKindDatabase Nothing@ means that the backend doesn't support connection templates
|
|
|
|
QueryLog gqlQuery ((fieldName,) <$> generatedQuery) requestId (QueryLogKindDatabase Nothing)
|
2021-03-13 17:40:50 +03:00
|
|
|
where
|
2021-05-21 14:37:34 +03:00
|
|
|
generatedQuery =
|
2021-06-01 13:04:29 +03:00
|
|
|
preparedSql <&> \queryString ->
|
|
|
|
GeneratedQuery queryString J.Null
|