2022-09-23 00:07:54 +03:00
|
|
|
{-# LANGUAGE ViewPatterns #-}
|
2022-03-16 03:39:21 +03:00
|
|
|
|
2021-01-07 12:04:22 +03:00
|
|
|
-- | The RQL query ('/v2/query')
|
2021-11-04 19:08:33 +03:00
|
|
|
module Hasura.Server.API.V2Query
|
|
|
|
( RQLQuery,
|
|
|
|
queryModifiesSchema,
|
|
|
|
runQuery,
|
|
|
|
)
|
|
|
|
where
|
2021-01-07 12:04:22 +03:00
|
|
|
|
2022-12-05 16:48:58 +03:00
|
|
|
import Control.Concurrent.Async.Lifted (mapConcurrently)
|
2022-11-03 16:56:35 +03:00
|
|
|
import Control.Lens (preview, _Right)
|
2021-09-24 01:56:37 +03:00
|
|
|
import Control.Monad.Trans.Control (MonadBaseControl)
|
|
|
|
import Data.Aeson
|
2022-09-23 00:07:54 +03:00
|
|
|
import Data.Aeson.Types (Parser)
|
2021-09-24 01:56:37 +03:00
|
|
|
import Data.Environment qualified as Env
|
2022-08-19 00:56:47 +03:00
|
|
|
import Data.Text qualified as T
|
|
|
|
import GHC.Generics.Extended (constrName)
|
Clean `AppEnv` and `AppContext` passing, remove `RunT`, reduce `ServerConfigCtx` uses
## Description
This PR does several different things that happen to overlap; the most important being:
- it removes `RunT`: it was redundant in places where we already had `Handler`, and only used in one other place, `SchemaUpdate`, for which a local `SchemaUpdateT` is more than enough;
- it reduces the number of places where we create a `ServerConfigCtx`, since now `HasServerConfigCtx` can be implemented directly by `SchemaUpdateT` and `Handler` based on the full `AppContext`;
- it drastically reduces the number of arguments we pass around in the app init code, by introducing `HasAppEnv`;
- it simplifies `HandlerCtx` to reduce duplication
In doing so, this changes paves the way towards removing `ServerConfigCtx`, since there are only very few places where we construct it: we can now introduce smaller classes than `HasServerConfigCtx`, that expose only a relevant subset of fields, and implement them where we now implement `HasServerConfigCtx`.
This PR is loosely based on ideas in #8337, that are no longer applicable due to the changes introduced in #8159. A challenge of this PR was the postgres tests, which were running in `PGMetadataStorageAppT CacheBuild` :scream_cat:
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8392
GitOrigin-RevId: b90c1359066d20dbea329c87762ccdd1217b4d69
2023-03-21 13:44:21 +03:00
|
|
|
import Hasura.App.State
|
2021-09-24 01:56:37 +03:00
|
|
|
import Hasura.Backends.BigQuery.DDL.RunSQL qualified as BigQuery
|
2022-09-23 00:07:54 +03:00
|
|
|
import Hasura.Backends.DataConnector.Adapter.RunSQL qualified as DataConnector
|
2022-11-03 16:56:35 +03:00
|
|
|
import Hasura.Backends.DataConnector.Adapter.Types (DataConnectorName, mkDataConnectorName)
|
2021-09-24 01:56:37 +03:00
|
|
|
import Hasura.Backends.MSSQL.DDL.RunSQL qualified as MSSQL
|
|
|
|
import Hasura.Backends.MySQL.SQL qualified as MySQL
|
|
|
|
import Hasura.Backends.Postgres.DDL.RunSQL qualified as Postgres
|
|
|
|
import Hasura.Base.Error
|
|
|
|
import Hasura.EncJSON
|
|
|
|
import Hasura.Metadata.Class
|
|
|
|
import Hasura.Prelude
|
2023-03-31 00:18:11 +03:00
|
|
|
import Hasura.QueryTags
|
2021-09-24 01:56:37 +03:00
|
|
|
import Hasura.RQL.DDL.Schema
|
|
|
|
import Hasura.RQL.DML.Count
|
|
|
|
import Hasura.RQL.DML.Delete
|
|
|
|
import Hasura.RQL.DML.Insert
|
|
|
|
import Hasura.RQL.DML.Select
|
|
|
|
import Hasura.RQL.DML.Types
|
2022-09-23 00:07:54 +03:00
|
|
|
( CountQuery,
|
|
|
|
DeleteQuery,
|
|
|
|
InsertQuery,
|
|
|
|
SelectQuery,
|
|
|
|
UpdateQuery,
|
|
|
|
)
|
2021-09-24 01:56:37 +03:00
|
|
|
import Hasura.RQL.DML.Update
|
2022-04-27 16:57:28 +03:00
|
|
|
import Hasura.RQL.Types.Metadata
|
2023-03-28 16:26:08 +03:00
|
|
|
import Hasura.RQL.Types.SchemaCache (MetadataWithResourceVersion (MetadataWithResourceVersion))
|
2022-04-27 16:57:28 +03:00
|
|
|
import Hasura.RQL.Types.SchemaCache.Build
|
|
|
|
import Hasura.RQL.Types.Source
|
|
|
|
import Hasura.SQL.Backend
|
2021-09-24 01:56:37 +03:00
|
|
|
import Hasura.Server.Types
|
harmonize network manager handling
## Description
### I want to speak to the `Manager`
Oh boy. This PR is both fairly straightforward and overreaching, so let's break it down.
For most network access, we need a [`HTTP.Manager`](https://hackage.haskell.org/package/http-client-0.1.0.0/docs/Network-HTTP-Client-Manager.html). It is created only once, at the top level, when starting the engine, and is then threaded through the application to wherever we need to make a network call. As of main, the way we do this is not standardized: most of the GraphQL execution code passes it "manually" as a function argument throughout the code. We also have a custom monad constraint, `HasHttpManagerM`, that describes a monad's ability to provide a manager. And, finally, several parts of the code store the manager in some kind of argument structure, such as `RunT`'s `RunCtx`.
This PR's first goal is to harmonize all of this: we always create the manager at the root, and we already have it when we do our very first `runReaderT`. Wouldn't it make sense for the rest of the code to not manually pass it anywhere, to not store it anywhere, but to always rely on the current monad providing it? This is, in short, what this PR does: it implements a constraint on the base monads, so that they provide the manager, and removes most explicit passing from the code.
### First come, first served
One way this PR goes a tiny bit further than "just" doing the aforementioned harmonization is that it starts the process of implementing the "Services oriented architecture" roughly outlined in this [draft document](https://docs.google.com/document/d/1FAigqrST0juU1WcT4HIxJxe1iEBwTuBZodTaeUvsKqQ/edit?usp=sharing). Instead of using the existing `HasHTTPManagerM`, this PR revamps it into the `ProvidesNetwork` service.
The idea is, again, that we should make all "external" dependencies of the engine, all things that the core of the engine doesn't care about, a "service". This allows us to define clear APIs for features, to choose different implementations based on which version of the engine we're running, harmonizes our many scattered monadic constraints... Which is why this service is called "Network": we can refine it, moving forward, to be the constraint that defines how all network communication is to operate, instead of relying on disparate classes constraint or hardcoded decisions. A comment in the code clarifies this intent.
### Side-effects? In my Haskell?
This PR also unavoidably touches some other aspects of the codebase. One such example: it introduces `Hasura.App.AppContext`, named after `HasuraPro.Context.AppContext`: a name for the reader structure at the base level. It also transforms `Handler` from a type alias to a newtype, as `Handler` is where we actually enforce HTTP limits; but without `Handler` being a distinct type, any code path could simply do a `runExceptT $ runReader` and forget to enforce them.
(As a rule of thumb, i am starting to consider any straggling `runReaderT` or `runExceptT` as a code smell: we should not stack / unstack monads haphazardly, and every layer should be an opaque `newtype` with a corresponding run function.)
## Further work
In several places, i have left TODOs when i have encountered things that suggest that we should do further unrelated cleanups. I'll write down the follow-up steps, either in the aforementioned document or on slack. But, in short, at a glance, in approximate order, we could:
- delete `ExecutionCtx` as it is only a subset of `ServerCtx`, and remove one more `runReaderT` call
- delete `ServerConfigCtx` as it is only a subset of `ServerCtx`, and remove it from `RunCtx`
- remove `ServerCtx` from `HandlerCtx`, and make it part of `AppContext`, or even make it the `AppContext` altogether (since, at least for the OSS version, `AppContext` is there again only a subset)
- remove `CacheBuildParams` and `CacheBuild` altogether, as they're just a distinct stack that is a `ReaderT` on top of `IO` that contains, you guessed it, the same thing as `ServerCtx`
- move `RunT` out of `RQL.Types` and rename it, since after the previous cleanups **it only contains `UserInfo`**; it could be bundled with the authentication service, made a small implementation detail in `Hasura.Server.Auth`
- rename `PGMetadaStorageT` to something a bit more accurate, such as `App`, and enforce its IO base
This would significantly simply our complex stack. From there, or in parallel, we can start moving existing dependencies as Services. For the purpose of supporting read replicas entitlement, we could move `MonadResolveSource` to a `SourceResolver` service, as attempted in #7653, and transform `UserAuthenticationM` into a `Authentication` service.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7736
GitOrigin-RevId: 68cce710eb9e7d752bda1ba0c49541d24df8209f
2023-02-22 18:53:52 +03:00
|
|
|
import Hasura.Services
|
2021-09-24 01:56:37 +03:00
|
|
|
import Hasura.Session
|
|
|
|
import Hasura.Tracing qualified as Tracing
|
2022-10-18 07:17:57 +03:00
|
|
|
import Language.GraphQL.Draft.Syntax qualified as GQL
|
2021-01-07 12:04:22 +03:00
|
|
|
|
|
|
|
data RQLQuery
|
|
|
|
= RQInsert !InsertQuery
|
|
|
|
| RQSelect !SelectQuery
|
|
|
|
| RQUpdate !UpdateQuery
|
|
|
|
| RQDelete !DeleteQuery
|
2021-09-24 01:56:37 +03:00
|
|
|
| RQCount !CountQuery
|
2021-05-27 18:06:13 +03:00
|
|
|
| RQRunSql !Postgres.RunSQL
|
2021-03-11 21:17:41 +03:00
|
|
|
| RQMssqlRunSql !MSSQL.MSSQLRunSQL
|
2021-05-27 18:06:13 +03:00
|
|
|
| RQCitusRunSql !Postgres.RunSQL
|
2022-08-25 16:30:34 +03:00
|
|
|
| RQCockroachRunSql !Postgres.RunSQL
|
2021-07-21 13:22:03 +03:00
|
|
|
| RQMysqlRunSql !MySQL.RunSQL
|
2021-04-12 13:18:29 +03:00
|
|
|
| RQBigqueryRunSql !BigQuery.BigQueryRunSQL
|
2022-09-23 00:07:54 +03:00
|
|
|
| RQDataConnectorRunSql !DataConnectorName !DataConnector.DataConnectorRunSQL
|
2021-04-12 13:18:29 +03:00
|
|
|
| RQBigqueryDatabaseInspection !BigQuery.BigQueryRunSQL
|
2021-01-07 12:04:22 +03:00
|
|
|
| RQBulk ![RQLQuery]
|
2022-12-05 16:48:58 +03:00
|
|
|
| -- | A variant of 'RQBulk' that runs a bulk of read-only queries concurrently.
|
|
|
|
-- Asserts that queries on this lists are not modifying the schema.
|
|
|
|
--
|
|
|
|
-- This is mainly used by the graphql-engine console.
|
|
|
|
RQConcurrentBulk [RQLQuery]
|
2022-08-19 00:56:47 +03:00
|
|
|
deriving (Generic)
|
2021-01-07 12:04:22 +03:00
|
|
|
|
2022-09-23 00:07:54 +03:00
|
|
|
-- | This instance has been written by hand so that "wildcard" prefixes of _run_sql can be delegated to data connectors.
|
|
|
|
instance FromJSON RQLQuery where
|
|
|
|
parseJSON = withObject "RQLQuery" \o -> do
|
|
|
|
t <- o .: "type"
|
|
|
|
let args :: forall a. FromJSON a => Parser a
|
|
|
|
args = o .: "args"
|
2022-11-03 16:56:35 +03:00
|
|
|
dcNameFromRunSql = T.stripSuffix "_run_sql" >=> GQL.mkName >=> preview _Right . mkDataConnectorName
|
2022-09-23 00:07:54 +03:00
|
|
|
case t of
|
|
|
|
"insert" -> RQInsert <$> args
|
|
|
|
"select" -> RQSelect <$> args
|
|
|
|
"update" -> RQUpdate <$> args
|
|
|
|
"delete" -> RQDelete <$> args
|
|
|
|
"count" -> RQCount <$> args
|
2023-02-02 17:03:26 +03:00
|
|
|
-- Optionally, we can specify a `pg_` prefix. This primarily makes some
|
|
|
|
-- string interpolation easier in the cross-backend tests.
|
2022-09-23 00:07:54 +03:00
|
|
|
"run_sql" -> RQRunSql <$> args
|
2023-02-02 17:03:26 +03:00
|
|
|
"pg_run_sql" -> RQRunSql <$> args
|
2022-09-23 00:07:54 +03:00
|
|
|
"mssql_run_sql" -> RQMssqlRunSql <$> args
|
|
|
|
"citus_run_sql" -> RQCitusRunSql <$> args
|
|
|
|
"cockroach_run_sql" -> RQCockroachRunSql <$> args
|
|
|
|
"mysql_run_sql" -> RQMysqlRunSql <$> args
|
|
|
|
"bigquery_run_sql" -> RQBigqueryRunSql <$> args
|
|
|
|
(dcNameFromRunSql -> Just t') -> RQDataConnectorRunSql t' <$> args
|
|
|
|
"bigquery_database_inspection" -> RQBigqueryDatabaseInspection <$> args
|
|
|
|
"bulk" -> RQBulk <$> args
|
2022-12-05 16:48:58 +03:00
|
|
|
"concurrent_bulk" -> RQConcurrentBulk <$> args
|
2022-09-23 00:07:54 +03:00
|
|
|
_ -> fail $ "Unrecognised RQLQuery type: " <> T.unpack t
|
2021-07-07 04:43:42 +03:00
|
|
|
|
2021-09-24 01:56:37 +03:00
|
|
|
runQuery ::
|
2021-10-13 19:38:56 +03:00
|
|
|
( MonadIO m,
|
2021-09-24 01:56:37 +03:00
|
|
|
MonadBaseControl IO m,
|
2023-02-03 04:03:23 +03:00
|
|
|
MonadError QErr m,
|
Clean `AppEnv` and `AppContext` passing, remove `RunT`, reduce `ServerConfigCtx` uses
## Description
This PR does several different things that happen to overlap; the most important being:
- it removes `RunT`: it was redundant in places where we already had `Handler`, and only used in one other place, `SchemaUpdate`, for which a local `SchemaUpdateT` is more than enough;
- it reduces the number of places where we create a `ServerConfigCtx`, since now `HasServerConfigCtx` can be implemented directly by `SchemaUpdateT` and `Handler` based on the full `AppContext`;
- it drastically reduces the number of arguments we pass around in the app init code, by introducing `HasAppEnv`;
- it simplifies `HandlerCtx` to reduce duplication
In doing so, this changes paves the way towards removing `ServerConfigCtx`, since there are only very few places where we construct it: we can now introduce smaller classes than `HasServerConfigCtx`, that expose only a relevant subset of fields, and implement them where we now implement `HasServerConfigCtx`.
This PR is loosely based on ideas in #8337, that are no longer applicable due to the changes introduced in #8159. A challenge of this PR was the postgres tests, which were running in `PGMetadataStorageAppT CacheBuild` :scream_cat:
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8392
GitOrigin-RevId: b90c1359066d20dbea329c87762ccdd1217b4d69
2023-03-21 13:44:21 +03:00
|
|
|
HasAppEnv m,
|
2021-09-24 01:56:37 +03:00
|
|
|
Tracing.MonadTrace m,
|
|
|
|
MonadMetadataStorage m,
|
|
|
|
MonadResolveSource m,
|
harmonize network manager handling
## Description
### I want to speak to the `Manager`
Oh boy. This PR is both fairly straightforward and overreaching, so let's break it down.
For most network access, we need a [`HTTP.Manager`](https://hackage.haskell.org/package/http-client-0.1.0.0/docs/Network-HTTP-Client-Manager.html). It is created only once, at the top level, when starting the engine, and is then threaded through the application to wherever we need to make a network call. As of main, the way we do this is not standardized: most of the GraphQL execution code passes it "manually" as a function argument throughout the code. We also have a custom monad constraint, `HasHttpManagerM`, that describes a monad's ability to provide a manager. And, finally, several parts of the code store the manager in some kind of argument structure, such as `RunT`'s `RunCtx`.
This PR's first goal is to harmonize all of this: we always create the manager at the root, and we already have it when we do our very first `runReaderT`. Wouldn't it make sense for the rest of the code to not manually pass it anywhere, to not store it anywhere, but to always rely on the current monad providing it? This is, in short, what this PR does: it implements a constraint on the base monads, so that they provide the manager, and removes most explicit passing from the code.
### First come, first served
One way this PR goes a tiny bit further than "just" doing the aforementioned harmonization is that it starts the process of implementing the "Services oriented architecture" roughly outlined in this [draft document](https://docs.google.com/document/d/1FAigqrST0juU1WcT4HIxJxe1iEBwTuBZodTaeUvsKqQ/edit?usp=sharing). Instead of using the existing `HasHTTPManagerM`, this PR revamps it into the `ProvidesNetwork` service.
The idea is, again, that we should make all "external" dependencies of the engine, all things that the core of the engine doesn't care about, a "service". This allows us to define clear APIs for features, to choose different implementations based on which version of the engine we're running, harmonizes our many scattered monadic constraints... Which is why this service is called "Network": we can refine it, moving forward, to be the constraint that defines how all network communication is to operate, instead of relying on disparate classes constraint or hardcoded decisions. A comment in the code clarifies this intent.
### Side-effects? In my Haskell?
This PR also unavoidably touches some other aspects of the codebase. One such example: it introduces `Hasura.App.AppContext`, named after `HasuraPro.Context.AppContext`: a name for the reader structure at the base level. It also transforms `Handler` from a type alias to a newtype, as `Handler` is where we actually enforce HTTP limits; but without `Handler` being a distinct type, any code path could simply do a `runExceptT $ runReader` and forget to enforce them.
(As a rule of thumb, i am starting to consider any straggling `runReaderT` or `runExceptT` as a code smell: we should not stack / unstack monads haphazardly, and every layer should be an opaque `newtype` with a corresponding run function.)
## Further work
In several places, i have left TODOs when i have encountered things that suggest that we should do further unrelated cleanups. I'll write down the follow-up steps, either in the aforementioned document or on slack. But, in short, at a glance, in approximate order, we could:
- delete `ExecutionCtx` as it is only a subset of `ServerCtx`, and remove one more `runReaderT` call
- delete `ServerConfigCtx` as it is only a subset of `ServerCtx`, and remove it from `RunCtx`
- remove `ServerCtx` from `HandlerCtx`, and make it part of `AppContext`, or even make it the `AppContext` altogether (since, at least for the OSS version, `AppContext` is there again only a subset)
- remove `CacheBuildParams` and `CacheBuild` altogether, as they're just a distinct stack that is a `ReaderT` on top of `IO` that contains, you guessed it, the same thing as `ServerCtx`
- move `RunT` out of `RQL.Types` and rename it, since after the previous cleanups **it only contains `UserInfo`**; it could be bundled with the authentication service, made a small implementation detail in `Hasura.Server.Auth`
- rename `PGMetadaStorageT` to something a bit more accurate, such as `App`, and enforce its IO base
This would significantly simply our complex stack. From there, or in parallel, we can start moving existing dependencies as Services. For the purpose of supporting read replicas entitlement, we could move `MonadResolveSource` to a `SourceResolver` service, as attempted in #7653, and transform `UserAuthenticationM` into a `Authentication` service.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7736
GitOrigin-RevId: 68cce710eb9e7d752bda1ba0c49541d24df8209f
2023-02-22 18:53:52 +03:00
|
|
|
MonadQueryTags m,
|
Clean `AppEnv` and `AppContext` passing, remove `RunT`, reduce `ServerConfigCtx` uses
## Description
This PR does several different things that happen to overlap; the most important being:
- it removes `RunT`: it was redundant in places where we already had `Handler`, and only used in one other place, `SchemaUpdate`, for which a local `SchemaUpdateT` is more than enough;
- it reduces the number of places where we create a `ServerConfigCtx`, since now `HasServerConfigCtx` can be implemented directly by `SchemaUpdateT` and `Handler` based on the full `AppContext`;
- it drastically reduces the number of arguments we pass around in the app init code, by introducing `HasAppEnv`;
- it simplifies `HandlerCtx` to reduce duplication
In doing so, this changes paves the way towards removing `ServerConfigCtx`, since there are only very few places where we construct it: we can now introduce smaller classes than `HasServerConfigCtx`, that expose only a relevant subset of fields, and implement them where we now implement `HasServerConfigCtx`.
This PR is loosely based on ideas in #8337, that are no longer applicable due to the changes introduced in #8159. A challenge of this PR was the postgres tests, which were running in `PGMetadataStorageAppT CacheBuild` :scream_cat:
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8392
GitOrigin-RevId: b90c1359066d20dbea329c87762ccdd1217b4d69
2023-03-21 13:44:21 +03:00
|
|
|
ProvidesHasuraServices m,
|
Remove `HasServerConfigCtx` from the schema cache build.
## Description
This PR is a incremental step towards achieving the goal of #8344. It is a less ambitious version of #8484.
This PR removes all references to `HasServerConfigCtx` from the cache build and removes `ServerConfigCtx` from `CacheBuildParams`, making `ServerConfigCtx` an argument being passed around manually instead. This has several benefits: by making it an arrow argument, we now properly integrate the fields that change over time in the dependency framework, as they should be, and we can clean up some of the top-level app code.
## Implementation
In practice, this PR introduces a `HasServerConfigCtx` instance for `CacheRWT`, the monad we use to build the cache, so we can retrieve the `ServerConfigCtx` in the implementation of `CacheRWM`. This contributes to reducing the amount of `HasServerConfigCtx` in the code: we can remove `SchemaUpdateT` altogether, and we can remove the `HasServerConfigCtx` instance of `Handler`. This makes `HasServerConfigCtx` almost **an implementation detail of the Metadata API**.
This first step is enough to achieve the goal of #8344: we can now build the schema cache in the app monad, since we no longer rely on `HasServerConfigCtx` to build it.
## Drawbacks
This PR does not attempt to remove the use of `ServerConfigCtx` itself in the schema cache build: doing so would make this PR much much bigger. Ideally, to avoid having all the static fields given as arrow-ish arguments to the cache, we could depend on `HasAppEnv` in the cache build, and use `AppContext` as an arrow argument. But making the cache build depend on the full `AppEnv` and `AppContext` creates a lot of circular imports; and since removing `ServerConfigCtx` itself isn't required to achieve #8344, this PR keeps it wholesale and defers cleaning it to a future PR.
A negative consequence of this is that we need an `Eq` instance on `ServerConfigCtx`, and that instance is inelegant.
## Future work
There are several further steps we can take in parallel after this is merged. First, again, we can make a new version of #8344, removing `CacheBuild`, FINALLY. As for `ServerConfigCtx`, we can split it / rename it to make ad-hoc structures. If it turns out that `ServerConfigCtx` is only ever used for the schema cache build, we could split it between `CacheBuildEnv` and `CacheBuildContext`, which will be subsets of `AppEnv` and `AppContext`, avoiding import loops.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8509
GitOrigin-RevId: 01b37cc3fd3490d6b117701e22fc4ac88b62b6b5
2023-03-27 20:42:37 +03:00
|
|
|
UserInfoM m
|
2021-09-24 01:56:37 +03:00
|
|
|
) =>
|
Clean `AppEnv` and `AppContext` passing, remove `RunT`, reduce `ServerConfigCtx` uses
## Description
This PR does several different things that happen to overlap; the most important being:
- it removes `RunT`: it was redundant in places where we already had `Handler`, and only used in one other place, `SchemaUpdate`, for which a local `SchemaUpdateT` is more than enough;
- it reduces the number of places where we create a `ServerConfigCtx`, since now `HasServerConfigCtx` can be implemented directly by `SchemaUpdateT` and `Handler` based on the full `AppContext`;
- it drastically reduces the number of arguments we pass around in the app init code, by introducing `HasAppEnv`;
- it simplifies `HandlerCtx` to reduce duplication
In doing so, this changes paves the way towards removing `ServerConfigCtx`, since there are only very few places where we construct it: we can now introduce smaller classes than `HasServerConfigCtx`, that expose only a relevant subset of fields, and implement them where we now implement `HasServerConfigCtx`.
This PR is loosely based on ideas in #8337, that are no longer applicable due to the changes introduced in #8159. A challenge of this PR was the postgres tests, which were running in `PGMetadataStorageAppT CacheBuild` :scream_cat:
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8392
GitOrigin-RevId: b90c1359066d20dbea329c87762ccdd1217b4d69
2023-03-21 13:44:21 +03:00
|
|
|
AppContext ->
|
2021-09-24 01:56:37 +03:00
|
|
|
RebuildableSchemaCache ->
|
|
|
|
RQLQuery ->
|
|
|
|
m (EncJSON, RebuildableSchemaCache)
|
Clean `AppEnv` and `AppContext` passing, remove `RunT`, reduce `ServerConfigCtx` uses
## Description
This PR does several different things that happen to overlap; the most important being:
- it removes `RunT`: it was redundant in places where we already had `Handler`, and only used in one other place, `SchemaUpdate`, for which a local `SchemaUpdateT` is more than enough;
- it reduces the number of places where we create a `ServerConfigCtx`, since now `HasServerConfigCtx` can be implemented directly by `SchemaUpdateT` and `Handler` based on the full `AppContext`;
- it drastically reduces the number of arguments we pass around in the app init code, by introducing `HasAppEnv`;
- it simplifies `HandlerCtx` to reduce duplication
In doing so, this changes paves the way towards removing `ServerConfigCtx`, since there are only very few places where we construct it: we can now introduce smaller classes than `HasServerConfigCtx`, that expose only a relevant subset of fields, and implement them where we now implement `HasServerConfigCtx`.
This PR is loosely based on ideas in #8337, that are no longer applicable due to the changes introduced in #8159. A challenge of this PR was the postgres tests, which were running in `PGMetadataStorageAppT CacheBuild` :scream_cat:
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8392
GitOrigin-RevId: b90c1359066d20dbea329c87762ccdd1217b4d69
2023-03-21 13:44:21 +03:00
|
|
|
runQuery appContext schemaCache rqlQuery = do
|
Remove `HasServerConfigCtx` from the schema cache build.
## Description
This PR is a incremental step towards achieving the goal of #8344. It is a less ambitious version of #8484.
This PR removes all references to `HasServerConfigCtx` from the cache build and removes `ServerConfigCtx` from `CacheBuildParams`, making `ServerConfigCtx` an argument being passed around manually instead. This has several benefits: by making it an arrow argument, we now properly integrate the fields that change over time in the dependency framework, as they should be, and we can clean up some of the top-level app code.
## Implementation
In practice, this PR introduces a `HasServerConfigCtx` instance for `CacheRWT`, the monad we use to build the cache, so we can retrieve the `ServerConfigCtx` in the implementation of `CacheRWM`. This contributes to reducing the amount of `HasServerConfigCtx` in the code: we can remove `SchemaUpdateT` altogether, and we can remove the `HasServerConfigCtx` instance of `Handler`. This makes `HasServerConfigCtx` almost **an implementation detail of the Metadata API**.
This first step is enough to achieve the goal of #8344: we can now build the schema cache in the app monad, since we no longer rely on `HasServerConfigCtx` to build it.
## Drawbacks
This PR does not attempt to remove the use of `ServerConfigCtx` itself in the schema cache build: doing so would make this PR much much bigger. Ideally, to avoid having all the static fields given as arrow-ish arguments to the cache, we could depend on `HasAppEnv` in the cache build, and use `AppContext` as an arrow argument. But making the cache build depend on the full `AppEnv` and `AppContext` creates a lot of circular imports; and since removing `ServerConfigCtx` itself isn't required to achieve #8344, this PR keeps it wholesale and defers cleaning it to a future PR.
A negative consequence of this is that we need an `Eq` instance on `ServerConfigCtx`, and that instance is inelegant.
## Future work
There are several further steps we can take in parallel after this is merged. First, again, we can make a new version of #8344, removing `CacheBuild`, FINALLY. As for `ServerConfigCtx`, we can split it / rename it to make ad-hoc structures. If it turns out that `ServerConfigCtx` is only ever used for the schema cache build, we could split it between `CacheBuildEnv` and `CacheBuildContext`, which will be subsets of `AppEnv` and `AppContext`, avoiding import loops.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8509
GitOrigin-RevId: 01b37cc3fd3490d6b117701e22fc4ac88b62b6b5
2023-03-27 20:42:37 +03:00
|
|
|
appEnv@AppEnv {..} <- askAppEnv
|
Clean `AppEnv` and `AppContext` passing, remove `RunT`, reduce `ServerConfigCtx` uses
## Description
This PR does several different things that happen to overlap; the most important being:
- it removes `RunT`: it was redundant in places where we already had `Handler`, and only used in one other place, `SchemaUpdate`, for which a local `SchemaUpdateT` is more than enough;
- it reduces the number of places where we create a `ServerConfigCtx`, since now `HasServerConfigCtx` can be implemented directly by `SchemaUpdateT` and `Handler` based on the full `AppContext`;
- it drastically reduces the number of arguments we pass around in the app init code, by introducing `HasAppEnv`;
- it simplifies `HandlerCtx` to reduce duplication
In doing so, this changes paves the way towards removing `ServerConfigCtx`, since there are only very few places where we construct it: we can now introduce smaller classes than `HasServerConfigCtx`, that expose only a relevant subset of fields, and implement them where we now implement `HasServerConfigCtx`.
This PR is loosely based on ideas in #8337, that are no longer applicable due to the changes introduced in #8159. A challenge of this PR was the postgres tests, which were running in `PGMetadataStorageAppT CacheBuild` :scream_cat:
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8392
GitOrigin-RevId: b90c1359066d20dbea329c87762ccdd1217b4d69
2023-03-21 13:44:21 +03:00
|
|
|
when ((appEnvEnableReadOnlyMode == ReadOnlyModeEnabled) && queryModifiesUserDB rqlQuery) $
|
2021-12-08 09:26:46 +03:00
|
|
|
throw400 NotSupported "Cannot run write queries when read-only mode is enabled"
|
|
|
|
|
Remove `HasServerConfigCtx` from the schema cache build.
## Description
This PR is a incremental step towards achieving the goal of #8344. It is a less ambitious version of #8484.
This PR removes all references to `HasServerConfigCtx` from the cache build and removes `ServerConfigCtx` from `CacheBuildParams`, making `ServerConfigCtx` an argument being passed around manually instead. This has several benefits: by making it an arrow argument, we now properly integrate the fields that change over time in the dependency framework, as they should be, and we can clean up some of the top-level app code.
## Implementation
In practice, this PR introduces a `HasServerConfigCtx` instance for `CacheRWT`, the monad we use to build the cache, so we can retrieve the `ServerConfigCtx` in the implementation of `CacheRWM`. This contributes to reducing the amount of `HasServerConfigCtx` in the code: we can remove `SchemaUpdateT` altogether, and we can remove the `HasServerConfigCtx` instance of `Handler`. This makes `HasServerConfigCtx` almost **an implementation detail of the Metadata API**.
This first step is enough to achieve the goal of #8344: we can now build the schema cache in the app monad, since we no longer rely on `HasServerConfigCtx` to build it.
## Drawbacks
This PR does not attempt to remove the use of `ServerConfigCtx` itself in the schema cache build: doing so would make this PR much much bigger. Ideally, to avoid having all the static fields given as arrow-ish arguments to the cache, we could depend on `HasAppEnv` in the cache build, and use `AppContext` as an arrow argument. But making the cache build depend on the full `AppEnv` and `AppContext` creates a lot of circular imports; and since removing `ServerConfigCtx` itself isn't required to achieve #8344, this PR keeps it wholesale and defers cleaning it to a future PR.
A negative consequence of this is that we need an `Eq` instance on `ServerConfigCtx`, and that instance is inelegant.
## Future work
There are several further steps we can take in parallel after this is merged. First, again, we can make a new version of #8344, removing `CacheBuild`, FINALLY. As for `ServerConfigCtx`, we can split it / rename it to make ad-hoc structures. If it turns out that `ServerConfigCtx` is only ever used for the schema cache build, we could split it between `CacheBuildEnv` and `CacheBuildContext`, which will be subsets of `AppEnv` and `AppContext`, avoiding import loops.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8509
GitOrigin-RevId: 01b37cc3fd3490d6b117701e22fc4ac88b62b6b5
2023-03-27 20:42:37 +03:00
|
|
|
let serverConfigCtx = buildServerConfigCtx appEnv appContext
|
2023-03-28 16:26:08 +03:00
|
|
|
MetadataWithResourceVersion metadata currentResourceVersion <- Tracing.newSpan "fetchMetadata" $ liftEitherM fetchMetadata
|
Clean `AppEnv` and `AppContext` passing, remove `RunT`, reduce `ServerConfigCtx` uses
## Description
This PR does several different things that happen to overlap; the most important being:
- it removes `RunT`: it was redundant in places where we already had `Handler`, and only used in one other place, `SchemaUpdate`, for which a local `SchemaUpdateT` is more than enough;
- it reduces the number of places where we create a `ServerConfigCtx`, since now `HasServerConfigCtx` can be implemented directly by `SchemaUpdateT` and `Handler` based on the full `AppContext`;
- it drastically reduces the number of arguments we pass around in the app init code, by introducing `HasAppEnv`;
- it simplifies `HandlerCtx` to reduce duplication
In doing so, this changes paves the way towards removing `ServerConfigCtx`, since there are only very few places where we construct it: we can now introduce smaller classes than `HasServerConfigCtx`, that expose only a relevant subset of fields, and implement them where we now implement `HasServerConfigCtx`.
This PR is loosely based on ideas in #8337, that are no longer applicable due to the changes introduced in #8159. A challenge of this PR was the postgres tests, which were running in `PGMetadataStorageAppT CacheBuild` :scream_cat:
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8392
GitOrigin-RevId: b90c1359066d20dbea329c87762ccdd1217b4d69
2023-03-21 13:44:21 +03:00
|
|
|
((result, updatedMetadata), updatedCache, invalidations) <-
|
|
|
|
runQueryM (acEnvironment appContext) rqlQuery
|
|
|
|
-- We can use defaults here unconditionally, since there is no MD export function in V2Query
|
|
|
|
& runMetadataT metadata (acMetadataDefaults appContext)
|
Remove `HasServerConfigCtx` from the schema cache build.
## Description
This PR is a incremental step towards achieving the goal of #8344. It is a less ambitious version of #8484.
This PR removes all references to `HasServerConfigCtx` from the cache build and removes `ServerConfigCtx` from `CacheBuildParams`, making `ServerConfigCtx` an argument being passed around manually instead. This has several benefits: by making it an arrow argument, we now properly integrate the fields that change over time in the dependency framework, as they should be, and we can clean up some of the top-level app code.
## Implementation
In practice, this PR introduces a `HasServerConfigCtx` instance for `CacheRWT`, the monad we use to build the cache, so we can retrieve the `ServerConfigCtx` in the implementation of `CacheRWM`. This contributes to reducing the amount of `HasServerConfigCtx` in the code: we can remove `SchemaUpdateT` altogether, and we can remove the `HasServerConfigCtx` instance of `Handler`. This makes `HasServerConfigCtx` almost **an implementation detail of the Metadata API**.
This first step is enough to achieve the goal of #8344: we can now build the schema cache in the app monad, since we no longer rely on `HasServerConfigCtx` to build it.
## Drawbacks
This PR does not attempt to remove the use of `ServerConfigCtx` itself in the schema cache build: doing so would make this PR much much bigger. Ideally, to avoid having all the static fields given as arrow-ish arguments to the cache, we could depend on `HasAppEnv` in the cache build, and use `AppContext` as an arrow argument. But making the cache build depend on the full `AppEnv` and `AppContext` creates a lot of circular imports; and since removing `ServerConfigCtx` itself isn't required to achieve #8344, this PR keeps it wholesale and defers cleaning it to a future PR.
A negative consequence of this is that we need an `Eq` instance on `ServerConfigCtx`, and that instance is inelegant.
## Future work
There are several further steps we can take in parallel after this is merged. First, again, we can make a new version of #8344, removing `CacheBuild`, FINALLY. As for `ServerConfigCtx`, we can split it / rename it to make ad-hoc structures. If it turns out that `ServerConfigCtx` is only ever used for the schema cache build, we could split it between `CacheBuildEnv` and `CacheBuildContext`, which will be subsets of `AppEnv` and `AppContext`, avoiding import loops.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8509
GitOrigin-RevId: 01b37cc3fd3490d6b117701e22fc4ac88b62b6b5
2023-03-27 20:42:37 +03:00
|
|
|
& runCacheRWT serverConfigCtx schemaCache
|
Clean `AppEnv` and `AppContext` passing, remove `RunT`, reduce `ServerConfigCtx` uses
## Description
This PR does several different things that happen to overlap; the most important being:
- it removes `RunT`: it was redundant in places where we already had `Handler`, and only used in one other place, `SchemaUpdate`, for which a local `SchemaUpdateT` is more than enough;
- it reduces the number of places where we create a `ServerConfigCtx`, since now `HasServerConfigCtx` can be implemented directly by `SchemaUpdateT` and `Handler` based on the full `AppContext`;
- it drastically reduces the number of arguments we pass around in the app init code, by introducing `HasAppEnv`;
- it simplifies `HandlerCtx` to reduce duplication
In doing so, this changes paves the way towards removing `ServerConfigCtx`, since there are only very few places where we construct it: we can now introduce smaller classes than `HasServerConfigCtx`, that expose only a relevant subset of fields, and implement them where we now implement `HasServerConfigCtx`.
This PR is loosely based on ideas in #8337, that are no longer applicable due to the changes introduced in #8159. A challenge of this PR was the postgres tests, which were running in `PGMetadataStorageAppT CacheBuild` :scream_cat:
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8392
GitOrigin-RevId: b90c1359066d20dbea329c87762ccdd1217b4d69
2023-03-21 13:44:21 +03:00
|
|
|
when (queryModifiesSchema rqlQuery) $ do
|
|
|
|
case appEnvEnableMaintenanceMode of
|
|
|
|
MaintenanceModeDisabled -> do
|
|
|
|
-- set modified metadata in storage
|
|
|
|
newResourceVersion <-
|
|
|
|
Tracing.newSpan "setMetadata" $
|
|
|
|
liftEitherM $
|
|
|
|
setMetadata currentResourceVersion updatedMetadata
|
|
|
|
-- notify schema cache sync
|
|
|
|
Tracing.newSpan "notifySchemaCacheSync" $
|
|
|
|
liftEitherM $
|
|
|
|
notifySchemaCacheSync newResourceVersion appEnvInstanceId invalidations
|
|
|
|
MaintenanceModeEnabled () ->
|
|
|
|
throw500 "metadata cannot be modified in maintenance mode"
|
|
|
|
pure (result, updatedCache)
|
2021-01-07 12:04:22 +03:00
|
|
|
|
|
|
|
queryModifiesSchema :: RQLQuery -> Bool
|
|
|
|
queryModifiesSchema = \case
|
2021-09-24 01:56:37 +03:00
|
|
|
RQInsert _ -> False
|
|
|
|
RQSelect _ -> False
|
|
|
|
RQUpdate _ -> False
|
|
|
|
RQDelete _ -> False
|
|
|
|
RQCount _ -> False
|
|
|
|
RQRunSql q -> Postgres.isSchemaCacheBuildRequiredRunSQL q
|
|
|
|
RQCitusRunSql q -> Postgres.isSchemaCacheBuildRequiredRunSQL q
|
2022-08-25 16:30:34 +03:00
|
|
|
RQCockroachRunSql q -> Postgres.isSchemaCacheBuildRequiredRunSQL q
|
2021-10-22 17:49:15 +03:00
|
|
|
RQMssqlRunSql q -> MSSQL.isSchemaCacheBuildRequiredRunSQL q
|
2021-09-24 01:56:37 +03:00
|
|
|
RQMysqlRunSql _ -> False
|
|
|
|
RQBigqueryRunSql _ -> False
|
2022-09-23 00:07:54 +03:00
|
|
|
RQDataConnectorRunSql _ _ -> False
|
2021-06-11 14:38:03 +03:00
|
|
|
RQBigqueryDatabaseInspection _ -> False
|
2021-09-24 01:56:37 +03:00
|
|
|
RQBulk l -> any queryModifiesSchema l
|
2022-12-05 16:48:58 +03:00
|
|
|
RQConcurrentBulk l -> any queryModifiesSchema l
|
2021-01-07 12:04:22 +03:00
|
|
|
|
2021-09-24 01:56:37 +03:00
|
|
|
runQueryM ::
|
2021-10-13 19:38:56 +03:00
|
|
|
( MonadError QErr m,
|
2021-09-24 01:56:37 +03:00
|
|
|
MonadIO m,
|
|
|
|
MonadBaseControl IO m,
|
|
|
|
UserInfoM m,
|
|
|
|
CacheRWM m,
|
|
|
|
HasServerConfigCtx m,
|
|
|
|
Tracing.MonadTrace m,
|
|
|
|
MetadataM m,
|
|
|
|
MonadQueryTags m
|
|
|
|
) =>
|
|
|
|
Env.Environment ->
|
|
|
|
RQLQuery ->
|
|
|
|
m EncJSON
|
Rewrite `Tracing` to allow for only one `TraceT` in the entire stack.
This PR is on top of #7789.
### Description
This PR entirely rewrites the API of the Tracing library, to make `interpTraceT` a thing of the past. Before this change, we ran traces by sticking a `TraceT` on top of whatever we were doing. This had several major drawbacks:
- we were carrying a bunch of `TraceT` across the codebase, and the entire codebase had to know about it
- we needed to carry a second class constraint around (`HasReporterM`) to be able to run all of those traces
- we kept having to do stack rewriting with `interpTraceT`, which went from inconvenient to horrible
- we had to declare several behavioral instances on `TraceT m`
This PR rewrite all of `Tracing` using a more conventional model: there is ONE `TraceT` at the bottom of the stack, and there is an associated class constraint `MonadTrace`: any part of the code that happens to satisfy `MonadTrace` is able to create new traces. We NEVER have to do stack rewriting, `interpTraceT` is gone, and `TraceT` and `Reporter` become implementation details that 99% of the code is blissfully unaware of: code that needs to do tracing only needs to declare that the monad in which it operates implements `MonadTrace`.
In doing so, this PR revealed **several bugs in the codebase**: places where we were expecting to trace something, but due to the default instance of `HasReporterM IO` we would actually not do anything. This PR also splits the code of `Tracing` in more byte-sized modules, with the goal of potentially moving to `server/lib` down the line.
### Remaining work
This PR is a draft; what's left to do is:
- [x] make Pro compile; i haven't updated `HasuraPro/Main` yet
- [x] document Tracing by writing a note that explains how to use the library, and the meaning of "reporter", "trace" and "span", as well as the pitfalls
- [x] discuss some of the trade-offs in the implementation, which is why i'm opening this PR already despite it not fully building yet
- [x] it depends on #7789 being merged first
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7791
GitOrigin-RevId: cadd32d039134c93ddbf364599a2f4dd988adea8
2023-03-13 20:37:16 +03:00
|
|
|
runQueryM env rq = Tracing.newSpan (T.pack $ constrName rq) $ case rq of
|
2021-09-24 01:56:37 +03:00
|
|
|
RQInsert q -> runInsert q
|
|
|
|
RQSelect q -> runSelect q
|
|
|
|
RQUpdate q -> runUpdate q
|
|
|
|
RQDelete q -> runDelete q
|
|
|
|
RQCount q -> runCount q
|
|
|
|
RQRunSql q -> Postgres.runRunSQL @'Vanilla q
|
|
|
|
RQMssqlRunSql q -> MSSQL.runSQL q
|
|
|
|
RQMysqlRunSql q -> MySQL.runSQL q
|
|
|
|
RQCitusRunSql q -> Postgres.runRunSQL @'Citus q
|
2022-08-25 16:30:34 +03:00
|
|
|
RQCockroachRunSql q -> Postgres.runRunSQL @'Cockroach q
|
2021-09-24 01:56:37 +03:00
|
|
|
RQBigqueryRunSql q -> BigQuery.runSQL q
|
2022-09-23 00:07:54 +03:00
|
|
|
RQDataConnectorRunSql t q -> DataConnector.runSQL t q
|
2021-04-12 13:18:29 +03:00
|
|
|
RQBigqueryDatabaseInspection q -> BigQuery.runDatabaseInspection q
|
2021-09-24 01:56:37 +03:00
|
|
|
RQBulk l -> encJFromList <$> indexedMapM (runQueryM env) l
|
2022-12-05 16:48:58 +03:00
|
|
|
RQConcurrentBulk l -> do
|
|
|
|
when (queryModifiesSchema rq) $
|
|
|
|
throw500 "Only read-only queries are allowed in a concurrent_bulk"
|
|
|
|
encJFromList <$> mapConcurrently (runQueryM env) l
|
2021-12-08 09:26:46 +03:00
|
|
|
|
|
|
|
queryModifiesUserDB :: RQLQuery -> Bool
|
|
|
|
queryModifiesUserDB = \case
|
|
|
|
RQInsert _ -> True
|
|
|
|
RQSelect _ -> False
|
|
|
|
RQUpdate _ -> True
|
|
|
|
RQDelete _ -> True
|
|
|
|
RQCount _ -> False
|
2023-03-23 16:03:21 +03:00
|
|
|
RQRunSql runsql -> not (Postgres.isReadOnly runsql)
|
|
|
|
RQCitusRunSql runsql -> not (Postgres.isReadOnly runsql)
|
|
|
|
RQCockroachRunSql runsql -> not (Postgres.isReadOnly runsql)
|
2021-12-08 09:26:46 +03:00
|
|
|
RQMssqlRunSql _ -> True
|
|
|
|
RQMysqlRunSql _ -> True
|
|
|
|
RQBigqueryRunSql _ -> True
|
2022-09-23 00:07:54 +03:00
|
|
|
RQDataConnectorRunSql _ _ -> True
|
2021-12-08 09:26:46 +03:00
|
|
|
RQBigqueryDatabaseInspection _ -> False
|
|
|
|
RQBulk q -> any queryModifiesUserDB q
|
2022-12-05 16:48:58 +03:00
|
|
|
RQConcurrentBulk _ -> False
|