2022-03-16 03:39:21 +03:00
|
|
|
{-# LANGUAGE TemplateHaskell #-}
|
|
|
|
|
2020-04-24 10:55:51 +03:00
|
|
|
-- | The RQL query ('/v1/query')
|
2021-11-04 19:08:33 +03:00
|
|
|
module Hasura.Server.API.Query
|
|
|
|
( RQLQuery,
|
|
|
|
queryModifiesSchemaCache,
|
|
|
|
requiresAdmin,
|
|
|
|
runQuery,
|
|
|
|
)
|
|
|
|
where
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2021-09-24 01:56:37 +03:00
|
|
|
import Control.Monad.Trans.Control (MonadBaseControl)
|
|
|
|
import Data.Aeson
|
|
|
|
import Data.Aeson.Casing
|
|
|
|
import Data.Aeson.TH
|
|
|
|
import Data.Environment qualified as Env
|
|
|
|
import Data.Has (Has)
|
|
|
|
import Hasura.Backends.Postgres.DDL.RunSQL
|
|
|
|
import Hasura.Base.Error
|
|
|
|
import Hasura.EncJSON
|
|
|
|
import Hasura.GraphQL.Execute.Backend
|
|
|
|
import Hasura.Logging qualified as L
|
|
|
|
import Hasura.Metadata.Class
|
|
|
|
import Hasura.Prelude
|
|
|
|
import Hasura.RQL.DDL.Action
|
|
|
|
import Hasura.RQL.DDL.ComputedField
|
|
|
|
import Hasura.RQL.DDL.CustomTypes
|
|
|
|
import Hasura.RQL.DDL.Endpoint
|
|
|
|
import Hasura.RQL.DDL.EventTrigger
|
|
|
|
import Hasura.RQL.DDL.Metadata
|
|
|
|
import Hasura.RQL.DDL.Permission
|
|
|
|
import Hasura.RQL.DDL.QueryCollection
|
|
|
|
import Hasura.RQL.DDL.Relationship
|
|
|
|
import Hasura.RQL.DDL.Relationship.Rename
|
|
|
|
import Hasura.RQL.DDL.RemoteRelationship
|
|
|
|
import Hasura.RQL.DDL.ScheduledTrigger
|
|
|
|
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
|
|
|
|
import Hasura.RQL.DML.Update
|
2022-04-27 16:57:28 +03:00
|
|
|
import Hasura.RQL.Types.Allowlist
|
|
|
|
import Hasura.RQL.Types.Common
|
|
|
|
import Hasura.RQL.Types.CustomTypes
|
2022-03-13 10:40:06 +03:00
|
|
|
import Hasura.RQL.Types.Endpoint
|
2022-04-27 16:57:28 +03:00
|
|
|
import Hasura.RQL.Types.Metadata
|
|
|
|
import Hasura.RQL.Types.Permission
|
|
|
|
import Hasura.RQL.Types.QueryCollection
|
2021-09-24 01:56:37 +03:00
|
|
|
import Hasura.RQL.Types.Run
|
2022-04-27 16:57:28 +03:00
|
|
|
import Hasura.RQL.Types.ScheduledTrigger
|
|
|
|
import Hasura.RQL.Types.SchemaCache.Build
|
|
|
|
import Hasura.RQL.Types.Source
|
scaffolding for remote-schemas module
The main aim of the PR is:
1. To set up a module structure for 'remote-schemas' package.
2. Move parts by the remote schema codebase into the new module structure to validate it.
## Notes to the reviewer
Why a PR with large-ish diff?
1. We've been making progress on the MM project but we don't yet know long it is going to take us to get to the first milestone. To understand this better, we need to figure out the unknowns as soon as possible. Hence I've taken a stab at the first two items in the [end-state](https://gist.github.com/0x777/ca2bdc4284d21c3eec153b51dea255c9) document to figure out the unknowns. Unsurprisingly, there are a bunch of issues that we haven't discussed earlier. These are documented in the 'open questions' section.
1. The diff is large but that is only code moved around and I've added a section that documents how things are moved. In addition, there are fair number of PR comments to help with the review process.
## Changes in the PR
### Module structure
Sets up the module structure as follows:
```
Hasura/
RemoteSchema/
Metadata/
Types.hs
SchemaCache/
Types.hs
Permission.hs
RemoteRelationship.hs
Build.hs
MetadataAPI/
Types.hs
Execute.hs
```
### 1. Types representing metadata are moved
Types that capture metadata information (currently scattered across several RQL modules) are moved into `Hasura.RemoteSchema.Metadata.Types`.
- This new module only depends on very 'core' modules such as
`Hasura.Session` for the notion of roles and `Hasura.Incremental` for `Cacheable` typeclass.
- The requirement on database modules is avoided by generalizing the remote schemas metadata to accept an arbitrary 'r' for a remote relationship
definition.
### 2. SchemaCache related types and build logic have been moved
Types that represent remote schemas information in SchemaCache are moved into `Hasura.RemoteSchema.SchemaCache.Types`.
Similar to `H.RS.Metadata.Types`, this module depends on 'core' modules except for `Hasura.GraphQL.Parser.Variable`. It has something to do with remote relationships but I haven't spent time looking into it. The validation of 'remote relationships to remote schema' is also something that needs to be looked at.
Rips out the logic that builds remote schema's SchemaCache information from the monolithic `buildSchemaCacheRule` and moves it into `Hasura.RemoteSchema.SchemaCache.Build`. Further, the `.SchemaCache.Permission` and `.SchemaCache.RemoteRelationship` have been created from existing modules that capture schema cache building logic for those two components.
This was a fair amount of work. On main, currently remote schema's SchemaCache information is built in two phases - in the first phase, 'permissions' and 'remote relationships' are ignored and in the second phase they are filled in.
While remote relationships can only be resolved after partially resolving sources and other remote schemas, the same isn't true for permissions. Further, most of the work that is done to resolve remote relationships can be moved to the first phase so that the second phase can be a very simple traversal.
This is the approach that was taken - resolve permissions and as much as remote relationships information in the first phase.
### 3. Metadata APIs related types and build logic have been moved
The types that represent remote schema related metadata APIs and the execution logic have been moved to `Hasura.RemoteSchema.MetadataAPI.Types` and `.Execute` modules respectively.
## Open questions:
1. `Hasura.RemoteSchema.Metadata.Types` is so called because I was hoping that all of the metadata related APIs of remote schema can be brought in at `Hasura.RemoteSchema.Metadata.API`. However, as metadata APIs depended on functions from `SchemaCache` module (see [1](https://github.com/hasura/graphql-engine-mono/blob/ceba6d62264603ee5d279814677b29bcc43ecaea/server/src-lib/Hasura/RQL/DDL/RemoteSchema.hs#L55) and [2](https://github.com/hasura/graphql-engine-mono/blob/ceba6d62264603ee5d279814677b29bcc43ecaea/server/src-lib/Hasura/RQL/DDL/RemoteSchema.hs#L91), it made more sense to create a separate top-level module for `MetadataAPI`s.
Maybe we can just have `Hasura.RemoteSchema.Metadata` and get rid of the extra nesting or have `Hasura.RemoteSchema.Metadata.{Core,Permission,RemoteRelationship}` if we want to break them down further.
1. `buildRemoteSchemas` in `H.RS.SchemaCache.Build` has the following type:
```haskell
buildRemoteSchemas ::
( ArrowChoice arr,
Inc.ArrowDistribute arr,
ArrowWriter (Seq CollectedInfo) arr,
Inc.ArrowCache m arr,
MonadIO m,
HasHttpManagerM m,
Inc.Cacheable remoteRelationshipDefinition,
ToJSON remoteRelationshipDefinition,
MonadError QErr m
) =>
Env.Environment ->
( (Inc.Dependency (HashMap RemoteSchemaName Inc.InvalidationKey), OrderedRoles),
[RemoteSchemaMetadataG remoteRelationshipDefinition]
)
`arr` HashMap RemoteSchemaName (PartiallyResolvedRemoteSchemaCtxG remoteRelationshipDefinition, MetadataObject)
```
Note the dependence on `CollectedInfo` which is defined as
```haskell
data CollectedInfo
= CIInconsistency InconsistentMetadata
| CIDependency
MetadataObject
-- ^ for error reporting on missing dependencies
SchemaObjId
SchemaDependency
deriving (Eq)
```
this pretty much means that remote schemas is dependent on types from databases, actions, ....
How do we fix this? Maybe introduce a typeclass such as `ArrowCollectRemoteSchemaDependencies` which is defined in `Hasura.RemoteSchema` and then implemented in graphql-engine?
1. The dependency on `buildSchemaCacheFor` in `.MetadataAPI.Execute` which has the following signature:
```haskell
buildSchemaCacheFor ::
(QErrM m, CacheRWM m, MetadataM m) =>
MetadataObjId ->
MetadataModifier ->
```
This can be easily resolved if we restrict what the metadata APIs are allowed to do. Currently, they operate in an unfettered access to modify SchemaCache (the `CacheRWM` constraint):
```haskell
runAddRemoteSchema ::
( QErrM m,
CacheRWM m,
MonadIO m,
HasHttpManagerM m,
MetadataM m,
Tracing.MonadTrace m
) =>
Env.Environment ->
AddRemoteSchemaQuery ->
m EncJSON
```
This should instead be changed to restrict remote schema APIs to only modify remote schema metadata (but has access to the remote schemas part of the schema cache), this dependency is completely removed.
```haskell
runAddRemoteSchema ::
( QErrM m,
MonadIO m,
HasHttpManagerM m,
MonadReader RemoteSchemasSchemaCache m,
MonadState RemoteSchemaMetadata m,
Tracing.MonadTrace m
) =>
Env.Environment ->
AddRemoteSchemaQuery ->
m RemoteSchemeMetadataObjId
```
The idea is that the core graphql-engine would call these functions and then call
`buildSchemaCacheFor`.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6291
GitOrigin-RevId: 51357148c6404afe70219afa71bd1d59bdf4ffc6
2022-10-21 06:13:07 +03:00
|
|
|
import Hasura.RemoteSchema.MetadataAPI
|
2022-04-27 16:57:28 +03:00
|
|
|
import Hasura.SQL.Backend
|
2021-09-24 01:56:37 +03:00
|
|
|
import Hasura.Server.Types
|
|
|
|
import Hasura.Server.Utils
|
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
|
2021-05-11 18:18:31 +03:00
|
|
|
|
2019-09-19 07:47:36 +03:00
|
|
|
data RQLQueryV1
|
2021-04-22 00:44:37 +03:00
|
|
|
= RQAddExistingTableOrView !(TrackTable ('Postgres 'Vanilla))
|
|
|
|
| RQTrackTable !(TrackTable ('Postgres 'Vanilla))
|
|
|
|
| RQUntrackTable !(UntrackTable ('Postgres 'Vanilla))
|
2022-10-11 12:08:04 +03:00
|
|
|
| RQSetTableIsEnum !(SetTableIsEnum ('Postgres 'Vanilla))
|
2021-06-17 16:21:55 +03:00
|
|
|
| RQSetTableCustomization !(SetTableCustomization ('Postgres 'Vanilla))
|
2021-04-22 00:44:37 +03:00
|
|
|
| RQTrackFunction !(TrackFunction ('Postgres 'Vanilla))
|
|
|
|
| RQUntrackFunction !(UnTrackFunction ('Postgres 'Vanilla))
|
|
|
|
| RQCreateObjectRelationship !(CreateObjRel ('Postgres 'Vanilla))
|
|
|
|
| RQCreateArrayRelationship !(CreateArrRel ('Postgres 'Vanilla))
|
|
|
|
| RQDropRelationship !(DropRel ('Postgres 'Vanilla))
|
|
|
|
| RQSetRelationshipComment !(SetRelComment ('Postgres 'Vanilla))
|
|
|
|
| RQRenameRelationship !(RenameRel ('Postgres 'Vanilla))
|
2021-09-24 01:56:37 +03:00
|
|
|
| -- computed fields related
|
|
|
|
RQAddComputedField !(AddComputedField ('Postgres 'Vanilla))
|
2021-04-22 00:44:37 +03:00
|
|
|
| RQDropComputedField !(DropComputedField ('Postgres 'Vanilla))
|
Fix several issues with remote relationships.
## Remaining Work
- [x] changelog entry
- [x] more tests: `<backend>_delete_remote_relationship` is definitely untested
- [x] negative tests: we probably want to assert that there are some APIs we DON'T support
- [x] update the console to use the new API, if necessary
- [x] ~~adding the corresponding documentation for the API for other backends (only `pg_` was added here)~~
- deferred to https://github.com/hasura/graphql-engine-mono/issues/3170
- [x] ~~deciding which backends should support this API~~
- deferred to https://github.com/hasura/graphql-engine-mono/issues/3170
- [x] ~~deciding what to do about potentially overlapping schematic representations~~
- ~~cf. https://github.com/hasura/graphql-engine-mono/pull/3157#issuecomment-995307624~~
- deferred to https://github.com/hasura/graphql-engine-mono/issues/3171
- [x] ~~add more descriptive versioning information to some of the types that are changing in this PR~~
- cf. https://github.com/hasura/graphql-engine-mono/pull/3157#discussion_r769830920
- deferred to https://github.com/hasura/graphql-engine-mono/issues/3172
## Description
This PR fixes several important issues wrt. the remote relationship API.
- it fixes a regression introduced by [#3124](https://github.com/hasura/graphql-engine-mono/pull/3124), which prevented `<backend>_create_remote_relationship` from accepting the old argument format (break of backwards compatibility, broke the console)
- it removes the command `create_remote_relationship` added to the v1/metadata API as a work-around as part of [#3124](https://github.com/hasura/graphql-engine-mono/pull/3124)
- it reverts the subsequent fix in the console: [#3149](https://github.com/hasura/graphql-engine-mono/pull/3149)
Furthermore, this PR also addresses two other issues:
- THE DOCUMENTATION OF THE METADATA API WAS WRONG, and documented `create_remote_relationship` instead of `<backend>_create_remote_relationship`: this PR fixes this by adding `pg_` everywhere, but does not attempt to add the corresponding documentation for other backends, partly because:
- `<backend>_delete_remote_relationship` WAS BROKEN ON NON-POSTGRES BACKENDS; it always expected an argument parameterized by Postgres.
As of main, the `<backend>_(create|update|delete)_remote_relationship` commands are supported on Postgres, Citus, BigQuery, but **NOT MSSQL**. I do not know if this is intentional or not, if it even should be publicized or not, and as a result this PR doesn't change this.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3157
Co-authored-by: jkachmar <8461423+jkachmar@users.noreply.github.com>
GitOrigin-RevId: 37e2f41522a9229a11c595574c3f4984317d652a
2021-12-16 23:28:08 +03:00
|
|
|
| RQCreateRemoteRelationship !(CreateFromSourceRelationship ('Postgres 'Vanilla))
|
|
|
|
| RQUpdateRemoteRelationship !(CreateFromSourceRelationship ('Postgres 'Vanilla))
|
2021-12-01 07:53:34 +03:00
|
|
|
| RQDeleteRemoteRelationship !(DeleteFromSourceRelationship ('Postgres 'Vanilla))
|
2021-06-09 22:42:37 +03:00
|
|
|
| RQCreateInsertPermission !(CreatePerm InsPerm ('Postgres 'Vanilla))
|
|
|
|
| RQCreateSelectPermission !(CreatePerm SelPerm ('Postgres 'Vanilla))
|
|
|
|
| RQCreateUpdatePermission !(CreatePerm UpdPerm ('Postgres 'Vanilla))
|
|
|
|
| RQCreateDeletePermission !(CreatePerm DelPerm ('Postgres 'Vanilla))
|
2022-04-06 15:47:35 +03:00
|
|
|
| RQDropInsertPermission !(DropPerm ('Postgres 'Vanilla))
|
|
|
|
| RQDropSelectPermission !(DropPerm ('Postgres 'Vanilla))
|
|
|
|
| RQDropUpdatePermission !(DropPerm ('Postgres 'Vanilla))
|
|
|
|
| RQDropDeletePermission !(DropPerm ('Postgres 'Vanilla))
|
2021-04-22 00:44:37 +03:00
|
|
|
| RQSetPermissionComment !(SetPermComment ('Postgres 'Vanilla))
|
2019-04-17 19:29:39 +03:00
|
|
|
| RQGetInconsistentMetadata !GetInconsistentMetadata
|
|
|
|
| RQDropInconsistentMetadata !DropInconsistentMetadata
|
2018-06-27 16:11:32 +03:00
|
|
|
| RQInsert !InsertQuery
|
|
|
|
| RQSelect !SelectQuery
|
|
|
|
| RQUpdate !UpdateQuery
|
|
|
|
| RQDelete !DeleteQuery
|
|
|
|
| RQCount !CountQuery
|
|
|
|
| RQBulk ![RQLQuery]
|
2021-09-24 01:56:37 +03:00
|
|
|
| -- schema-stitching, custom resolver related
|
|
|
|
RQAddRemoteSchema !AddRemoteSchemaQuery
|
2021-06-21 20:41:43 +03:00
|
|
|
| RQUpdateRemoteSchema !AddRemoteSchemaQuery
|
2019-07-08 08:51:41 +03:00
|
|
|
| RQRemoveRemoteSchema !RemoteSchemaNameQuery
|
|
|
|
| RQReloadRemoteSchema !RemoteSchemaNameQuery
|
2020-05-27 18:02:58 +03:00
|
|
|
| RQIntrospectRemoteSchema !RemoteSchemaNameQuery
|
2021-04-22 00:44:37 +03:00
|
|
|
| RQCreateEventTrigger !(CreateEventTriggerQuery ('Postgres 'Vanilla))
|
|
|
|
| RQDeleteEventTrigger !(DeleteEventTriggerQuery ('Postgres 'Vanilla))
|
2021-09-24 01:56:37 +03:00
|
|
|
| RQRedeliverEvent !(RedeliverEventQuery ('Postgres 'Vanilla))
|
2021-04-22 00:44:37 +03:00
|
|
|
| RQInvokeEventTrigger !(InvokeEventTriggerQuery ('Postgres 'Vanilla))
|
2021-09-24 01:56:37 +03:00
|
|
|
| -- scheduled triggers
|
|
|
|
RQCreateCronTrigger !CreateCronTrigger
|
2020-05-13 15:33:16 +03:00
|
|
|
| RQDeleteCronTrigger !ScheduledTriggerName
|
|
|
|
| RQCreateScheduledEvent !CreateScheduledEvent
|
2021-09-24 01:56:37 +03:00
|
|
|
| -- query collections, allow list related
|
|
|
|
RQCreateQueryCollection !CreateCollection
|
2022-08-19 16:36:02 +03:00
|
|
|
| RQRenameQueryCollection !RenameCollection
|
2019-05-16 09:13:25 +03:00
|
|
|
| RQDropQueryCollection !DropCollection
|
|
|
|
| RQAddQueryToCollection !AddQueryToCollection
|
|
|
|
| RQDropQueryFromCollection !DropQueryFromCollection
|
2022-02-08 19:53:30 +03:00
|
|
|
| RQAddCollectionToAllowlist !AllowlistEntry
|
|
|
|
| RQDropCollectionFromAllowlist !DropCollectionFromAllowlist
|
2018-06-27 16:11:32 +03:00
|
|
|
| RQRunSql !RunSQL
|
2020-12-28 15:56:00 +03:00
|
|
|
| RQReplaceMetadata !ReplaceMetadata
|
2018-06-27 16:11:32 +03:00
|
|
|
| RQExportMetadata !ExportMetadata
|
|
|
|
| RQClearMetadata !ClearMetadata
|
2018-09-05 18:25:30 +03:00
|
|
|
| RQReloadMetadata !ReloadMetadata
|
2020-02-13 20:38:23 +03:00
|
|
|
| RQCreateAction !CreateAction
|
|
|
|
| RQDropAction !DropAction
|
|
|
|
| RQUpdateAction !UpdateAction
|
|
|
|
| RQCreateActionPermission !CreateActionPermission
|
|
|
|
| RQDropActionPermission !DropActionPermission
|
2021-01-29 04:02:34 +03:00
|
|
|
| RQCreateRestEndpoint !CreateEndpoint
|
|
|
|
| RQDropRestEndpoint !DropEndpoint
|
2018-06-27 16:11:32 +03:00
|
|
|
| RQDumpInternalState !DumpInternalState
|
2020-02-13 20:38:23 +03:00
|
|
|
| RQSetCustomTypes !CustomTypes
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2019-09-19 07:47:36 +03:00
|
|
|
data RQLQueryV2
|
2021-04-22 00:44:37 +03:00
|
|
|
= RQV2TrackTable !(TrackTableV2 ('Postgres 'Vanilla))
|
2020-10-29 15:48:45 +03:00
|
|
|
| RQV2SetTableCustomFields !SetTableCustomFields -- deprecated
|
2021-04-22 00:44:37 +03:00
|
|
|
| RQV2TrackFunction !(TrackFunctionV2 ('Postgres 'Vanilla))
|
2021-02-16 11:08:19 +03:00
|
|
|
| RQV2ReplaceMetadata !ReplaceMetadataV2
|
2019-09-19 07:47:36 +03:00
|
|
|
|
|
|
|
data RQLQuery
|
|
|
|
= RQV1 !RQLQueryV1
|
|
|
|
| RQV2 !RQLQueryV2
|
|
|
|
|
2022-06-26 01:08:01 +03:00
|
|
|
-- Since at least one of the following mutually recursive instances is defined
|
|
|
|
-- via TH, after 9.0 they must all be defined within the same TH splice.
|
|
|
|
$( concat
|
|
|
|
<$> sequence
|
|
|
|
[ [d|
|
|
|
|
instance FromJSON RQLQuery where
|
|
|
|
parseJSON = withObject "Object" $ \o -> do
|
|
|
|
mVersion <- o .:? "version"
|
|
|
|
let version = fromMaybe VIVersion1 mVersion
|
|
|
|
val = Object o
|
|
|
|
case version of
|
|
|
|
VIVersion1 -> RQV1 <$> parseJSON val
|
|
|
|
VIVersion2 -> RQV2 <$> parseJSON val
|
|
|
|
|],
|
|
|
|
deriveFromJSON
|
|
|
|
defaultOptions
|
|
|
|
{ constructorTagModifier = snakeCase . drop 2,
|
|
|
|
sumEncoding = TaggedObject "type" "args"
|
|
|
|
}
|
|
|
|
''RQLQueryV1,
|
|
|
|
deriveFromJSON
|
|
|
|
defaultOptions
|
|
|
|
{ constructorTagModifier = snakeCase . drop 4,
|
|
|
|
sumEncoding = TaggedObject "type" "args",
|
|
|
|
tagSingleConstructors = True
|
|
|
|
}
|
|
|
|
''RQLQueryV2
|
|
|
|
]
|
2019-09-19 07:47:36 +03:00
|
|
|
)
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2021-09-24 01:56:37 +03:00
|
|
|
runQuery ::
|
2021-10-13 19:38:56 +03:00
|
|
|
( MonadIO m,
|
2023-02-03 04:03:23 +03:00
|
|
|
MonadError QErr m,
|
2021-09-24 01:56:37 +03:00
|
|
|
Tracing.MonadTrace m,
|
|
|
|
MonadBaseControl IO m,
|
2023-02-03 04:03:23 +03:00
|
|
|
MonadMetadataStorageQueryAPI m,
|
2021-09-24 01:56:37 +03:00
|
|
|
MonadResolveSource m,
|
2022-09-15 14:45:14 +03:00
|
|
|
MonadQueryTags 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
|
|
|
MonadEventLogCleanup m,
|
|
|
|
ProvidesHasuraServices m
|
2021-09-24 01:56:37 +03:00
|
|
|
) =>
|
|
|
|
Env.Environment ->
|
|
|
|
L.Logger L.Hasura ->
|
|
|
|
InstanceId ->
|
|
|
|
UserInfo ->
|
|
|
|
RebuildableSchemaCache ->
|
|
|
|
ServerConfigCtx ->
|
|
|
|
RQLQuery ->
|
|
|
|
m (EncJSON, RebuildableSchemaCache)
|
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
|
|
|
runQuery env logger instanceId userInfo sc serverConfigCtx query = do
|
2021-12-08 09:26:46 +03:00
|
|
|
when ((_sccReadOnlyMode serverConfigCtx == ReadOnlyModeEnabled) && queryModifiesUserDB query) $
|
|
|
|
throw400 NotSupported "Cannot run write queries when read-only mode is enabled"
|
|
|
|
|
2022-10-20 15:45:31 +03:00
|
|
|
let exportsMetadata = \case
|
|
|
|
RQV1 (RQExportMetadata _) -> True
|
|
|
|
_ -> False
|
|
|
|
metadataDefaults =
|
|
|
|
if (exportsMetadata query)
|
|
|
|
then emptyMetadataDefaults
|
|
|
|
else _sccMetadataDefaults serverConfigCtx
|
|
|
|
|
2023-02-03 04:03:23 +03:00
|
|
|
(metadata, currentResourceVersion) <- liftEitherM fetchMetadata
|
2021-09-24 01:56:37 +03:00
|
|
|
result <-
|
2021-09-25 06:59:35 +03:00
|
|
|
runReaderT (runQueryM env query) logger & \x -> do
|
|
|
|
((js, meta), rsc, ci) <-
|
2022-10-20 15:45:31 +03:00
|
|
|
x
|
|
|
|
& runMetadataT metadata metadataDefaults
|
2021-09-24 01:56:37 +03:00
|
|
|
& runCacheRWT sc
|
|
|
|
& peelRun runCtx
|
2021-09-25 06:59:35 +03:00
|
|
|
pure (js, rsc, ci, meta)
|
2021-02-19 05:39:30 +03:00
|
|
|
withReload currentResourceVersion result
|
2019-03-12 08:46:27 +03:00
|
|
|
where
|
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
|
|
|
runCtx = RunCtx userInfo serverConfigCtx
|
2020-12-08 17:22:31 +03:00
|
|
|
|
2021-02-19 05:39:30 +03:00
|
|
|
withReload currentResourceVersion (result, updatedCache, invalidations, updatedMetadata) = do
|
2020-01-09 02:19:02 +03:00
|
|
|
when (queryModifiesSchemaCache query) $ do
|
2021-02-18 19:46:14 +03:00
|
|
|
case (_sccMaintenanceMode serverConfigCtx) of
|
2021-04-06 06:25:02 +03:00
|
|
|
MaintenanceModeDisabled -> do
|
2021-02-18 19:46:14 +03:00
|
|
|
-- set modified metadata in storage
|
2023-02-03 04:03:23 +03:00
|
|
|
newResourceVersion <- liftEitherM $ setMetadata currentResourceVersion updatedMetadata
|
2021-04-06 06:25:02 +03:00
|
|
|
-- notify schema cache sync
|
2023-02-03 04:03:23 +03:00
|
|
|
liftEitherM $ notifySchemaCacheSync newResourceVersion instanceId invalidations
|
2022-04-28 23:55:13 +03:00
|
|
|
MaintenanceModeEnabled () ->
|
2021-02-18 19:46:14 +03:00
|
|
|
throw500 "metadata cannot be modified in maintenance mode"
|
2020-12-14 07:30:19 +03:00
|
|
|
pure (result, updatedCache)
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2020-01-09 02:19:02 +03:00
|
|
|
-- | A predicate that determines whether the given query might modify/rebuild the schema cache. If
|
|
|
|
-- so, it needs to acquire the global lock on the schema cache so that other queries do not modify
|
|
|
|
-- it concurrently.
|
|
|
|
--
|
|
|
|
-- Ideally, we would enforce this using the type system — queries for which this function returns
|
|
|
|
-- 'False' should not be allowed to modify the schema cache. But for now we just ensure consistency
|
|
|
|
-- by hand.
|
|
|
|
queryModifiesSchemaCache :: RQLQuery -> Bool
|
|
|
|
queryModifiesSchemaCache (RQV1 qi) = case qi of
|
2021-09-24 01:56:37 +03:00
|
|
|
RQAddExistingTableOrView _ -> True
|
|
|
|
RQTrackTable _ -> True
|
|
|
|
RQUntrackTable _ -> True
|
|
|
|
RQTrackFunction _ -> True
|
|
|
|
RQUntrackFunction _ -> True
|
|
|
|
RQSetTableIsEnum _ -> True
|
|
|
|
RQCreateObjectRelationship _ -> True
|
|
|
|
RQCreateArrayRelationship _ -> True
|
|
|
|
RQDropRelationship _ -> True
|
|
|
|
RQSetRelationshipComment _ -> False
|
|
|
|
RQRenameRelationship _ -> True
|
|
|
|
RQAddComputedField _ -> True
|
|
|
|
RQDropComputedField _ -> True
|
|
|
|
RQCreateRemoteRelationship _ -> True
|
|
|
|
RQUpdateRemoteRelationship _ -> True
|
|
|
|
RQDeleteRemoteRelationship _ -> True
|
|
|
|
RQCreateInsertPermission _ -> True
|
|
|
|
RQCreateSelectPermission _ -> True
|
|
|
|
RQCreateUpdatePermission _ -> True
|
|
|
|
RQCreateDeletePermission _ -> True
|
|
|
|
RQDropInsertPermission _ -> True
|
|
|
|
RQDropSelectPermission _ -> True
|
|
|
|
RQDropUpdatePermission _ -> True
|
|
|
|
RQDropDeletePermission _ -> True
|
|
|
|
RQSetPermissionComment _ -> False
|
|
|
|
RQGetInconsistentMetadata _ -> False
|
|
|
|
RQDropInconsistentMetadata _ -> True
|
|
|
|
RQInsert _ -> False
|
|
|
|
RQSelect _ -> False
|
|
|
|
RQUpdate _ -> False
|
|
|
|
RQDelete _ -> False
|
|
|
|
RQCount _ -> False
|
|
|
|
RQAddRemoteSchema _ -> True
|
|
|
|
RQUpdateRemoteSchema _ -> True
|
|
|
|
RQRemoveRemoteSchema _ -> True
|
|
|
|
RQReloadRemoteSchema _ -> True
|
|
|
|
RQIntrospectRemoteSchema _ -> False
|
|
|
|
RQCreateEventTrigger _ -> True
|
|
|
|
RQDeleteEventTrigger _ -> True
|
|
|
|
RQRedeliverEvent _ -> False
|
|
|
|
RQInvokeEventTrigger _ -> False
|
|
|
|
RQCreateCronTrigger _ -> True
|
|
|
|
RQDeleteCronTrigger _ -> True
|
|
|
|
RQCreateScheduledEvent _ -> False
|
|
|
|
RQCreateQueryCollection _ -> True
|
2022-08-19 16:36:02 +03:00
|
|
|
RQRenameQueryCollection _ -> True
|
2021-09-24 01:56:37 +03:00
|
|
|
RQDropQueryCollection _ -> True
|
|
|
|
RQAddQueryToCollection _ -> True
|
|
|
|
RQDropQueryFromCollection _ -> True
|
|
|
|
RQAddCollectionToAllowlist _ -> True
|
2020-07-14 22:00:58 +03:00
|
|
|
RQDropCollectionFromAllowlist _ -> True
|
2021-09-24 01:56:37 +03:00
|
|
|
RQRunSql q -> isSchemaCacheBuildRequiredRunSQL q
|
|
|
|
RQReplaceMetadata _ -> True
|
|
|
|
RQExportMetadata _ -> False
|
|
|
|
RQClearMetadata _ -> True
|
|
|
|
RQReloadMetadata _ -> True
|
|
|
|
RQCreateRestEndpoint _ -> True
|
|
|
|
RQDropRestEndpoint _ -> True
|
|
|
|
RQCreateAction _ -> True
|
|
|
|
RQDropAction _ -> True
|
|
|
|
RQUpdateAction _ -> True
|
|
|
|
RQCreateActionPermission _ -> True
|
|
|
|
RQDropActionPermission _ -> True
|
|
|
|
RQDumpInternalState _ -> False
|
|
|
|
RQSetCustomTypes _ -> True
|
|
|
|
RQSetTableCustomization _ -> True
|
|
|
|
RQBulk qs -> any queryModifiesSchemaCache qs
|
2020-01-09 02:19:02 +03:00
|
|
|
queryModifiesSchemaCache (RQV2 qi) = case qi of
|
2021-09-24 01:56:37 +03:00
|
|
|
RQV2TrackTable _ -> True
|
2019-09-19 07:47:36 +03:00
|
|
|
RQV2SetTableCustomFields _ -> True
|
2021-09-24 01:56:37 +03:00
|
|
|
RQV2TrackFunction _ -> True
|
|
|
|
RQV2ReplaceMetadata _ -> True
|
2018-06-27 16:11:32 +03:00
|
|
|
|
2021-12-08 09:26:46 +03:00
|
|
|
-- | A predicate that determines whether the given query might modify user's Database. If
|
|
|
|
-- so, when the server is run in safe mode, we should not proceed with those operations.
|
|
|
|
queryModifiesUserDB :: RQLQuery -> Bool
|
|
|
|
queryModifiesUserDB (RQV1 qi) = case qi of
|
|
|
|
RQAddExistingTableOrView _ -> False
|
|
|
|
RQTrackTable _ -> False
|
|
|
|
RQUntrackTable _ -> False
|
|
|
|
RQTrackFunction _ -> False
|
|
|
|
RQUntrackFunction _ -> False
|
|
|
|
RQSetTableIsEnum _ -> False
|
|
|
|
RQCreateObjectRelationship _ -> False
|
|
|
|
RQCreateArrayRelationship _ -> False
|
|
|
|
RQDropRelationship _ -> False
|
|
|
|
RQSetRelationshipComment _ -> False
|
|
|
|
RQRenameRelationship _ -> False
|
|
|
|
RQAddComputedField _ -> False
|
|
|
|
RQDropComputedField _ -> False
|
|
|
|
RQCreateRemoteRelationship _ -> False
|
|
|
|
RQUpdateRemoteRelationship _ -> False
|
|
|
|
RQDeleteRemoteRelationship _ -> False
|
|
|
|
RQCreateInsertPermission _ -> False
|
|
|
|
RQCreateSelectPermission _ -> False
|
|
|
|
RQCreateUpdatePermission _ -> False
|
|
|
|
RQCreateDeletePermission _ -> False
|
|
|
|
RQDropInsertPermission _ -> False
|
|
|
|
RQDropSelectPermission _ -> False
|
|
|
|
RQDropUpdatePermission _ -> False
|
|
|
|
RQDropDeletePermission _ -> False
|
|
|
|
RQSetPermissionComment _ -> False
|
|
|
|
RQGetInconsistentMetadata _ -> False
|
|
|
|
RQDropInconsistentMetadata _ -> False
|
|
|
|
RQInsert _ -> True
|
|
|
|
RQSelect _ -> False
|
|
|
|
RQUpdate _ -> True
|
|
|
|
RQDelete _ -> True
|
|
|
|
RQCount _ -> False
|
|
|
|
RQAddRemoteSchema _ -> False
|
|
|
|
RQUpdateRemoteSchema _ -> False
|
|
|
|
RQRemoveRemoteSchema _ -> False
|
|
|
|
RQReloadRemoteSchema _ -> False
|
|
|
|
RQIntrospectRemoteSchema _ -> False
|
|
|
|
RQCreateEventTrigger _ -> True
|
|
|
|
RQDeleteEventTrigger _ -> True
|
|
|
|
RQRedeliverEvent _ -> False
|
|
|
|
RQInvokeEventTrigger _ -> False
|
|
|
|
RQCreateCronTrigger _ -> False
|
|
|
|
RQDeleteCronTrigger _ -> False
|
|
|
|
RQCreateScheduledEvent _ -> False
|
|
|
|
RQCreateQueryCollection _ -> False
|
2022-08-19 16:36:02 +03:00
|
|
|
RQRenameQueryCollection _ -> False
|
2021-12-08 09:26:46 +03:00
|
|
|
RQDropQueryCollection _ -> False
|
|
|
|
RQAddQueryToCollection _ -> False
|
|
|
|
RQDropQueryFromCollection _ -> False
|
|
|
|
RQAddCollectionToAllowlist _ -> False
|
|
|
|
RQDropCollectionFromAllowlist _ -> False
|
|
|
|
RQRunSql _ -> True
|
|
|
|
RQReplaceMetadata _ -> True
|
|
|
|
RQExportMetadata _ -> False
|
|
|
|
RQClearMetadata _ -> False
|
|
|
|
RQReloadMetadata _ -> False
|
|
|
|
RQCreateRestEndpoint _ -> False
|
|
|
|
RQDropRestEndpoint _ -> False
|
|
|
|
RQCreateAction _ -> False
|
|
|
|
RQDropAction _ -> False
|
|
|
|
RQUpdateAction _ -> False
|
|
|
|
RQCreateActionPermission _ -> False
|
|
|
|
RQDropActionPermission _ -> False
|
|
|
|
RQDumpInternalState _ -> False
|
|
|
|
RQSetCustomTypes _ -> False
|
|
|
|
RQSetTableCustomization _ -> False
|
|
|
|
RQBulk qs -> any queryModifiesUserDB qs
|
|
|
|
queryModifiesUserDB (RQV2 qi) = case qi of
|
|
|
|
RQV2TrackTable _ -> False
|
|
|
|
RQV2SetTableCustomFields _ -> False
|
|
|
|
RQV2TrackFunction _ -> False
|
|
|
|
RQV2ReplaceMetadata _ -> True
|
|
|
|
|
2021-09-24 01:56:37 +03:00
|
|
|
runQueryM ::
|
2021-10-13 19:38:56 +03:00
|
|
|
( CacheRWM m,
|
2021-09-24 01:56:37 +03:00
|
|
|
UserInfoM m,
|
|
|
|
MonadBaseControl IO m,
|
|
|
|
MonadIO m,
|
|
|
|
HasServerConfigCtx m,
|
|
|
|
Tracing.MonadTrace m,
|
|
|
|
MetadataM m,
|
|
|
|
MonadMetadataStorageQueryAPI m,
|
|
|
|
MonadQueryTags m,
|
|
|
|
MonadReader r m,
|
2023-02-03 04:03:23 +03:00
|
|
|
MonadError QErr m,
|
2022-09-15 14:45:14 +03:00
|
|
|
Has (L.Logger L.Hasura) r,
|
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
|
|
|
MonadEventLogCleanup m,
|
|
|
|
ProvidesHasuraServices m
|
2021-09-24 01:56:37 +03:00
|
|
|
) =>
|
|
|
|
Env.Environment ->
|
|
|
|
RQLQuery ->
|
|
|
|
m EncJSON
|
2021-01-07 12:04:22 +03:00
|
|
|
runQueryM env rq = withPathK "args" $ case rq of
|
2020-01-09 02:19:02 +03:00
|
|
|
RQV1 q -> runQueryV1M q
|
|
|
|
RQV2 q -> runQueryV2M q
|
2019-07-08 08:51:41 +03:00
|
|
|
where
|
2019-09-19 07:47:36 +03:00
|
|
|
runQueryV1M = \case
|
2021-09-24 01:56:37 +03:00
|
|
|
RQAddExistingTableOrView q -> runTrackTableQ q
|
|
|
|
RQTrackTable q -> runTrackTableQ q
|
|
|
|
RQUntrackTable q -> runUntrackTableQ q
|
|
|
|
RQSetTableIsEnum q -> runSetExistingTableIsEnumQ q
|
|
|
|
RQSetTableCustomization q -> runSetTableCustomization q
|
|
|
|
RQTrackFunction q -> runTrackFunc q
|
|
|
|
RQUntrackFunction q -> runUntrackFunc q
|
|
|
|
RQCreateObjectRelationship q -> runCreateRelationship ObjRel $ unCreateObjRel q
|
|
|
|
RQCreateArrayRelationship q -> runCreateRelationship ArrRel $ unCreateArrRel q
|
|
|
|
RQDropRelationship q -> runDropRel q
|
|
|
|
RQSetRelationshipComment q -> runSetRelComment q
|
|
|
|
RQRenameRelationship q -> runRenameRel q
|
|
|
|
RQAddComputedField q -> runAddComputedField q
|
|
|
|
RQDropComputedField q -> runDropComputedField q
|
|
|
|
RQCreateInsertPermission q -> runCreatePerm q
|
|
|
|
RQCreateSelectPermission q -> runCreatePerm q
|
|
|
|
RQCreateUpdatePermission q -> runCreatePerm q
|
|
|
|
RQCreateDeletePermission q -> runCreatePerm q
|
2022-04-06 15:47:35 +03:00
|
|
|
RQDropInsertPermission q -> runDropPerm PTInsert q
|
|
|
|
RQDropSelectPermission q -> runDropPerm PTSelect q
|
|
|
|
RQDropUpdatePermission q -> runDropPerm PTUpdate q
|
|
|
|
RQDropDeletePermission q -> runDropPerm PTDelete q
|
2021-09-24 01:56:37 +03:00
|
|
|
RQSetPermissionComment q -> runSetPermComment q
|
|
|
|
RQGetInconsistentMetadata q -> runGetInconsistentMetadata q
|
|
|
|
RQDropInconsistentMetadata q -> runDropInconsistentMetadata q
|
|
|
|
RQInsert q -> runInsert q
|
|
|
|
RQSelect q -> runSelect q
|
|
|
|
RQUpdate q -> runUpdate q
|
|
|
|
RQDelete q -> runDelete q
|
|
|
|
RQCount q -> runCount q
|
|
|
|
RQAddRemoteSchema q -> runAddRemoteSchema env q
|
|
|
|
RQUpdateRemoteSchema q -> runUpdateRemoteSchema env q
|
|
|
|
RQRemoveRemoteSchema q -> runRemoveRemoteSchema q
|
|
|
|
RQReloadRemoteSchema q -> runReloadRemoteSchema q
|
|
|
|
RQIntrospectRemoteSchema q -> runIntrospectRemoteSchema q
|
Fix several issues with remote relationships.
## Remaining Work
- [x] changelog entry
- [x] more tests: `<backend>_delete_remote_relationship` is definitely untested
- [x] negative tests: we probably want to assert that there are some APIs we DON'T support
- [x] update the console to use the new API, if necessary
- [x] ~~adding the corresponding documentation for the API for other backends (only `pg_` was added here)~~
- deferred to https://github.com/hasura/graphql-engine-mono/issues/3170
- [x] ~~deciding which backends should support this API~~
- deferred to https://github.com/hasura/graphql-engine-mono/issues/3170
- [x] ~~deciding what to do about potentially overlapping schematic representations~~
- ~~cf. https://github.com/hasura/graphql-engine-mono/pull/3157#issuecomment-995307624~~
- deferred to https://github.com/hasura/graphql-engine-mono/issues/3171
- [x] ~~add more descriptive versioning information to some of the types that are changing in this PR~~
- cf. https://github.com/hasura/graphql-engine-mono/pull/3157#discussion_r769830920
- deferred to https://github.com/hasura/graphql-engine-mono/issues/3172
## Description
This PR fixes several important issues wrt. the remote relationship API.
- it fixes a regression introduced by [#3124](https://github.com/hasura/graphql-engine-mono/pull/3124), which prevented `<backend>_create_remote_relationship` from accepting the old argument format (break of backwards compatibility, broke the console)
- it removes the command `create_remote_relationship` added to the v1/metadata API as a work-around as part of [#3124](https://github.com/hasura/graphql-engine-mono/pull/3124)
- it reverts the subsequent fix in the console: [#3149](https://github.com/hasura/graphql-engine-mono/pull/3149)
Furthermore, this PR also addresses two other issues:
- THE DOCUMENTATION OF THE METADATA API WAS WRONG, and documented `create_remote_relationship` instead of `<backend>_create_remote_relationship`: this PR fixes this by adding `pg_` everywhere, but does not attempt to add the corresponding documentation for other backends, partly because:
- `<backend>_delete_remote_relationship` WAS BROKEN ON NON-POSTGRES BACKENDS; it always expected an argument parameterized by Postgres.
As of main, the `<backend>_(create|update|delete)_remote_relationship` commands are supported on Postgres, Citus, BigQuery, but **NOT MSSQL**. I do not know if this is intentional or not, if it even should be publicized or not, and as a result this PR doesn't change this.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3157
Co-authored-by: jkachmar <8461423+jkachmar@users.noreply.github.com>
GitOrigin-RevId: 37e2f41522a9229a11c595574c3f4984317d652a
2021-12-16 23:28:08 +03:00
|
|
|
RQCreateRemoteRelationship q -> runCreateRemoteRelationship q
|
|
|
|
RQUpdateRemoteRelationship q -> runUpdateRemoteRelationship q
|
2021-09-24 01:56:37 +03:00
|
|
|
RQDeleteRemoteRelationship q -> runDeleteRemoteRelationship q
|
|
|
|
RQCreateEventTrigger q -> runCreateEventTriggerQuery q
|
|
|
|
RQDeleteEventTrigger q -> runDeleteEventTriggerQuery q
|
|
|
|
RQRedeliverEvent q -> runRedeliverEvent q
|
|
|
|
RQInvokeEventTrigger q -> runInvokeEventTrigger q
|
|
|
|
RQCreateCronTrigger q -> runCreateCronTrigger q
|
|
|
|
RQDeleteCronTrigger q -> runDeleteCronTrigger q
|
|
|
|
RQCreateScheduledEvent q -> runCreateScheduledEvent q
|
|
|
|
RQCreateQueryCollection q -> runCreateCollection q
|
2022-08-19 16:36:02 +03:00
|
|
|
RQRenameQueryCollection q -> runRenameCollection q
|
2021-09-24 01:56:37 +03:00
|
|
|
RQDropQueryCollection q -> runDropCollection q
|
|
|
|
RQAddQueryToCollection q -> runAddQueryToCollection q
|
|
|
|
RQDropQueryFromCollection q -> runDropQueryFromCollection q
|
|
|
|
RQAddCollectionToAllowlist q -> runAddCollectionToAllowlist q
|
2020-11-02 14:50:40 +03:00
|
|
|
RQDropCollectionFromAllowlist q -> runDropCollectionFromAllowlist q
|
2021-09-24 01:56:37 +03:00
|
|
|
RQReplaceMetadata q -> runReplaceMetadata q
|
|
|
|
RQClearMetadata q -> runClearMetadata q
|
|
|
|
RQExportMetadata q -> runExportMetadata q
|
|
|
|
RQReloadMetadata q -> runReloadMetadata q
|
|
|
|
RQCreateAction q -> runCreateAction q
|
|
|
|
RQDropAction q -> runDropAction q
|
|
|
|
RQUpdateAction q -> runUpdateAction q
|
|
|
|
RQCreateActionPermission q -> runCreateActionPermission q
|
|
|
|
RQDropActionPermission q -> runDropActionPermission q
|
|
|
|
RQCreateRestEndpoint q -> runCreateEndpoint q
|
|
|
|
RQDropRestEndpoint q -> runDropEndpoint q
|
|
|
|
RQDumpInternalState q -> runDumpInternalState q
|
|
|
|
RQRunSql q -> runRunSQL @'Vanilla q
|
|
|
|
RQSetCustomTypes q -> runSetCustomTypes q
|
|
|
|
RQBulk qs -> encJFromList <$> indexedMapM (runQueryM env) qs
|
2019-09-19 07:47:36 +03:00
|
|
|
|
|
|
|
runQueryV2M = \case
|
2021-09-24 01:56:37 +03:00
|
|
|
RQV2TrackTable q -> runTrackTableV2Q q
|
2021-01-29 04:02:34 +03:00
|
|
|
RQV2SetTableCustomFields q -> runSetTableCustomFieldsQV2 q
|
2021-09-24 01:56:37 +03:00
|
|
|
RQV2TrackFunction q -> runTrackFunctionV2 q
|
2022-12-16 13:19:42 +03:00
|
|
|
RQV2ReplaceMetadata q -> runReplaceMetadataV2 q
|
2019-11-26 15:14:21 +03:00
|
|
|
|
|
|
|
requiresAdmin :: RQLQuery -> Bool
|
|
|
|
requiresAdmin = \case
|
|
|
|
RQV1 q -> case q of
|
2021-09-24 01:56:37 +03:00
|
|
|
RQAddExistingTableOrView _ -> True
|
|
|
|
RQTrackTable _ -> True
|
|
|
|
RQUntrackTable _ -> True
|
|
|
|
RQSetTableIsEnum _ -> True
|
|
|
|
RQSetTableCustomization _ -> True
|
|
|
|
RQTrackFunction _ -> True
|
|
|
|
RQUntrackFunction _ -> True
|
|
|
|
RQCreateObjectRelationship _ -> True
|
|
|
|
RQCreateArrayRelationship _ -> True
|
|
|
|
RQDropRelationship _ -> True
|
|
|
|
RQSetRelationshipComment _ -> True
|
|
|
|
RQRenameRelationship _ -> True
|
|
|
|
RQAddComputedField _ -> True
|
|
|
|
RQDropComputedField _ -> True
|
|
|
|
RQCreateRemoteRelationship _ -> True
|
|
|
|
RQUpdateRemoteRelationship _ -> True
|
|
|
|
RQDeleteRemoteRelationship _ -> True
|
|
|
|
RQCreateInsertPermission _ -> True
|
|
|
|
RQCreateSelectPermission _ -> True
|
|
|
|
RQCreateUpdatePermission _ -> True
|
|
|
|
RQCreateDeletePermission _ -> True
|
|
|
|
RQDropInsertPermission _ -> True
|
|
|
|
RQDropSelectPermission _ -> True
|
|
|
|
RQDropUpdatePermission _ -> True
|
|
|
|
RQDropDeletePermission _ -> True
|
|
|
|
RQSetPermissionComment _ -> True
|
|
|
|
RQGetInconsistentMetadata _ -> True
|
|
|
|
RQDropInconsistentMetadata _ -> True
|
|
|
|
RQInsert _ -> False
|
|
|
|
RQSelect _ -> False
|
|
|
|
RQUpdate _ -> False
|
|
|
|
RQDelete _ -> False
|
|
|
|
RQCount _ -> False
|
|
|
|
RQAddRemoteSchema _ -> True
|
|
|
|
RQUpdateRemoteSchema _ -> True
|
|
|
|
RQRemoveRemoteSchema _ -> True
|
|
|
|
RQReloadRemoteSchema _ -> True
|
|
|
|
RQIntrospectRemoteSchema _ -> True
|
|
|
|
RQCreateEventTrigger _ -> True
|
|
|
|
RQDeleteEventTrigger _ -> True
|
|
|
|
RQRedeliverEvent _ -> True
|
|
|
|
RQInvokeEventTrigger _ -> True
|
|
|
|
RQCreateCronTrigger _ -> True
|
|
|
|
RQDeleteCronTrigger _ -> True
|
|
|
|
RQCreateScheduledEvent _ -> True
|
|
|
|
RQCreateQueryCollection _ -> True
|
2022-08-19 16:36:02 +03:00
|
|
|
RQRenameQueryCollection _ -> True
|
2021-09-24 01:56:37 +03:00
|
|
|
RQDropQueryCollection _ -> True
|
|
|
|
RQAddQueryToCollection _ -> True
|
|
|
|
RQDropQueryFromCollection _ -> True
|
|
|
|
RQAddCollectionToAllowlist _ -> True
|
2020-07-14 22:00:58 +03:00
|
|
|
RQDropCollectionFromAllowlist _ -> True
|
2021-09-24 01:56:37 +03:00
|
|
|
RQReplaceMetadata _ -> True
|
|
|
|
RQClearMetadata _ -> True
|
|
|
|
RQExportMetadata _ -> True
|
|
|
|
RQReloadMetadata _ -> True
|
|
|
|
RQCreateRestEndpoint _ -> True
|
|
|
|
RQDropRestEndpoint _ -> True
|
|
|
|
RQCreateAction _ -> True
|
|
|
|
RQDropAction _ -> True
|
|
|
|
RQUpdateAction _ -> True
|
|
|
|
RQCreateActionPermission _ -> True
|
|
|
|
RQDropActionPermission _ -> True
|
|
|
|
RQDumpInternalState _ -> True
|
|
|
|
RQSetCustomTypes _ -> True
|
|
|
|
RQRunSql _ -> True
|
|
|
|
RQBulk qs -> any requiresAdmin qs
|
2019-11-26 15:14:21 +03:00
|
|
|
RQV2 q -> case q of
|
2021-09-24 01:56:37 +03:00
|
|
|
RQV2TrackTable _ -> True
|
2019-11-26 15:14:21 +03:00
|
|
|
RQV2SetTableCustomFields _ -> True
|
2021-09-24 01:56:37 +03:00
|
|
|
RQV2TrackFunction _ -> True
|
|
|
|
RQV2ReplaceMetadata _ -> True
|