graphql-engine/server/src-lib/Hasura/GraphQL/Schema/BoolExp.hs
Auke Booij 8ccf7724ce server: Metadata origin for definitions (type parameter version v2)
The code that builds the GraphQL schema, and `buildGQLContext` in particular, is partial: not every value of `(ServerConfigCtx, GraphQLQueryType, SourceCache, HashMap RemoteSchemaName (RemoteSchemaCtx, MetadataObject), ActionCache, AnnotatedCustomTypes)` results in a valid GraphQL schema. When it fails, we want to be able to return better error messages than we currently do.

The key thing that is missing is a way to trace back GraphQL type information to their origin from the Hasura metadata. Currently, we have a number of correctness checks of our GraphQL schema. But these correctness checks only have access to pure GraphQL type information, and hence can only report errors in terms of that. Possibly the worst is the "conflicting definitions" error, which, in practice, can only be debugged by Hasura engineers. This is terrible DX for customers.

This PR allows us to print better error messages, by adding a field to the `Definition` type that traces the GraphQL type to its origin in the metadata. So the idea is simple: just add `MetadataObjId`, or `Maybe` that, or some other sum type of that, to `Definition`.

However, we want to avoid having to import a `Hasura.RQL` module from `Hasura.GraphQL.Parser`. So we instead define this additional field of `Definition` through a new type parameter, which is threaded through in `Hasura.GraphQL.Parser`. We then define type synonyms in `Hasura.GraphQL.Schema.Parser` that fill in this type parameter, so that it is not visible for the majority of the codebase.

The idea of associating metadata information to `Definition`s really comes to fruition when combined with hasura/graphql-engine-mono#4517. Their combination would allow us to use the API of fatal errors (just like the current `MonadError QErr`) to report _inconsistencies_ in the metadata. Such inconsistencies are then _automatically_ ignored. So no ad-hoc decisions need to be made on how to cut out inconsistent metadata from the GraphQL schema. This will allow us to report much better errors, as well as improve the likelihood of a successful HGE startup.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4770
Co-authored-by: Samir Talwar <47582+SamirTalwar@users.noreply.github.com>
GitOrigin-RevId: 728402b0cae83ae8e83463a826ceeb609001acae
2022-06-28 15:53:44 +00:00

234 lines
9.5 KiB
Haskell
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

{-# LANGUAGE ApplicativeDo #-}
{-# LANGUAGE TemplateHaskell #-}
module Hasura.GraphQL.Schema.BoolExp
( boolExp,
mkBoolOperator,
equalityOperators,
comparisonOperators,
)
where
import Data.Text.Casing (GQLNameIdentifier)
import Data.Text.Casing qualified as C
import Data.Text.Extended
import Hasura.GraphQL.Parser.Class
import Hasura.GraphQL.Schema.Backend
import Hasura.GraphQL.Schema.Common (askTableInfo, partialSQLExpToUnpreparedValue)
import Hasura.GraphQL.Schema.Parser
( InputFieldsParser,
Kind (..),
Parser,
)
import Hasura.GraphQL.Schema.Parser qualified as P
import Hasura.GraphQL.Schema.Table
import Hasura.Name qualified as Name
import Hasura.Prelude
import Hasura.RQL.IR.BoolExp
import Hasura.RQL.IR.Value
import Hasura.RQL.Types.Backend
import Hasura.RQL.Types.Column
import Hasura.RQL.Types.ComputedField
import Hasura.RQL.Types.Function
import Hasura.RQL.Types.Relationships.Local
import Hasura.RQL.Types.SchemaCache hiding (askTableInfo)
import Hasura.RQL.Types.Source
import Hasura.RQL.Types.SourceCustomization (NamingCase, applyFieldNameCaseIdentifier)
import Hasura.RQL.Types.Table
import Language.GraphQL.Draft.Syntax qualified as G
-- |
-- > input type_bool_exp {
-- > _or: [type_bool_exp!]
-- > _and: [type_bool_exp!]
-- > _not: type_bool_exp
-- > column: type_comparison_exp
-- > ...
-- > }
boolExp ::
forall b r m n.
MonadBuildSchema b r m n =>
SourceInfo b ->
TableInfo b ->
m (Parser 'Input n (AnnBoolExp b (UnpreparedValue b)))
boolExp sourceInfo tableInfo = memoizeOn 'boolExp (_siName sourceInfo, tableName) $ do
tableGQLName <- getTableGQLName tableInfo
name <- P.mkTypename $ tableGQLName <> Name.__bool_exp
let description =
G.Description $
"Boolean expression to filter rows from the table " <> tableName
<<> ". All fields are combined with a logical 'AND'."
fieldInfos <- tableSelectFields sourceInfo tableInfo
tableFieldParsers <- catMaybes <$> traverse mkField fieldInfos
recur <- boolExp sourceInfo tableInfo
-- Bafflingly, ApplicativeDo doesnt work if we inline this definition (I
-- think the TH splices throw it off), so we have to define it separately.
let specialFieldParsers =
[ P.fieldOptional Name.__or Nothing (BoolOr <$> P.list recur),
P.fieldOptional Name.__and Nothing (BoolAnd <$> P.list recur),
P.fieldOptional Name.__not Nothing (BoolNot <$> recur)
]
pure $
BoolAnd <$> P.object name (Just description) do
tableFields <- map BoolFld . catMaybes <$> sequenceA tableFieldParsers
specialFields <- catMaybes <$> sequenceA specialFieldParsers
pure (tableFields ++ specialFields)
where
tableName = tableInfoName tableInfo
mkField ::
FieldInfo b ->
m (Maybe (InputFieldsParser n (Maybe (AnnBoolExpFld b (UnpreparedValue b)))))
mkField fieldInfo = runMaybeT do
fieldName <- hoistMaybe $ fieldInfoGraphQLName fieldInfo
P.fieldOptional fieldName Nothing <$> case fieldInfo of
-- field_name: field_type_comparison_exp
FIColumn columnInfo ->
lift $ fmap (AVColumn columnInfo) <$> comparisonExps @b (ciType columnInfo)
-- field_name: field_type_bool_exp
FIRelationship relationshipInfo -> do
remoteTableInfo <- askTableInfo sourceInfo $ riRTable relationshipInfo
remotePermissions <- lift $ tableSelectPermissions remoteTableInfo
let remoteTableFilter =
fmap partialSQLExpToUnpreparedValue
<$> maybe annBoolExpTrue spiFilter remotePermissions
remoteBoolExp <- lift $ boolExp sourceInfo remoteTableInfo
pure $ fmap (AVRelationship relationshipInfo . andAnnBoolExps remoteTableFilter) remoteBoolExp
FIComputedField ComputedFieldInfo {..} -> do
let ComputedFieldFunction {..} = _cfiFunction
-- For a computed field to qualify in boolean expression it shouldn't have any input arguments
case toList _cffInputArgs of
[] -> do
let functionArgs =
flip FunctionArgsExp mempty $
fromComputedFieldImplicitArguments @b UVSession _cffComputedFieldImplicitArgs
fmap (AVComputedField . AnnComputedFieldBoolExp _cfiXComputedFieldInfo _cfiName _cffName functionArgs)
<$> case computedFieldReturnType @b _cfiReturnType of
ReturnsScalar scalarType -> lift $ fmap CFBEScalar <$> comparisonExps @b (ColumnScalar scalarType)
ReturnsTable table -> do
info <- askTableInfo sourceInfo table
lift $ fmap (CFBETable table) <$> boolExp sourceInfo info
ReturnsOthers -> hoistMaybe Nothing
_ -> hoistMaybe Nothing
-- Using remote relationship fields in boolean expressions is not supported.
FIRemoteRelationship _ -> empty
{- Note [Nullability in comparison operators]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In comparisonExps, we hardcode most operators with `Nullability False` when
calling `column`, which might seem a bit sketchy. Shouldnt the nullability
depend on the nullability of the underlying Postgres column?
No. If we did that, then we would allow boolean expressions like this:
delete_users(where: {status: {eq: null}})
which in turn would generate a SQL query along the lines of:
DELETE FROM users WHERE users.status = NULL
but `= NULL` might not do what they expect. For instance, on Postgres, it always
evaluates to False!
Even operators for which `null` is a valid value must be careful in their
implementation. An explicit `null` must always be handled explicitly! If,
instead, an explicit null is ignored:
foo <- fmap join $ fieldOptional "_foo_level" $ nullable int
then
delete_users(where: {_foo_level: null})
=> delete_users(where: {})
=> delete_users()
Now weve gone and deleted every user in the database. Whoops! Hopefully the
user had backups!
In most cases, as mentioned above, we avoid this problem by making the column
value non-nullable (which is correct, since we never treat a null value as a SQL
NULL), then creating the field using 'fieldOptional'. This creates a parser that
rejects nulls, but wont be called at all if the field is not specified, which
is permitted by the GraphQL specification. See Note [The value of omitted
fields] in Hasura.GraphQL.Parser.Internal.Parser for more details.
Additionally, it is worth nothing that the `column` parser *does* handle
explicit nulls, by creating a Null column value.
But... the story doesn't end there. Some of our users WANT this peculiar
behaviour. For instance, they want to be able to express the following:
query($isVerified: Boolean) {
users(where: {_isVerified: {_eq: $isVerified}}) {
name
}
}
$isVerified is True -> return users who are verified
$isVerified is False -> return users who aren't
$isVerified is null -> return all users
In the future, we will likely introduce a separate group of operators that do
implement this particular behaviour explicitly; but for now we have an option that
reverts to the previous behaviour.
To do so, we have to treat explicit nulls as implicit one: this is what the
'nullable' combinator does: it treats an explicit null as if the field has never
been called at all.
-}
-- This is temporary, and should be removed as soon as possible.
mkBoolOperator ::
(MonadParse n, 'Input P.<: k) =>
-- | Naming convention for the field
NamingCase ->
-- | shall this be collapsed to True when null is given?
Bool ->
-- | name of this operator
GQLNameIdentifier ->
-- | optional description
Maybe G.Description ->
-- | parser for the underlying value
Parser k n a ->
InputFieldsParser n (Maybe a)
mkBoolOperator tCase True name desc = fmap join . P.fieldOptional (applyFieldNameCaseIdentifier tCase name) desc . P.nullable
mkBoolOperator tCase False name desc = P.fieldOptional (applyFieldNameCaseIdentifier tCase name) desc
equalityOperators ::
(MonadParse n, 'Input P.<: k) =>
NamingCase ->
-- | shall this be collapsed to True when null is given?
Bool ->
-- | parser for one column value
Parser k n (UnpreparedValue b) ->
-- | parser for a list of column values
Parser k n (UnpreparedValue b) ->
[InputFieldsParser n (Maybe (OpExpG b (UnpreparedValue b)))]
equalityOperators tCase collapseIfNull valueParser valueListParser =
[ mkBoolOperator tCase collapseIfNull (C.fromTuple $$(G.litGQLIdentifier ["_is", "null"])) Nothing $ bool ANISNOTNULL ANISNULL <$> P.boolean,
mkBoolOperator tCase collapseIfNull (C.fromName Name.__eq) Nothing $ AEQ True <$> valueParser,
mkBoolOperator tCase collapseIfNull (C.fromName Name.__neq) Nothing $ ANE True <$> valueParser,
mkBoolOperator tCase collapseIfNull (C.fromName Name.__in) Nothing $ AIN <$> valueListParser,
mkBoolOperator tCase collapseIfNull (C.fromName Name.__nin) Nothing $ ANIN <$> valueListParser
]
comparisonOperators ::
(MonadParse n, 'Input P.<: k) =>
NamingCase ->
-- | shall this be collapsed to True when null is given?
Bool ->
-- | parser for one column value
Parser k n (UnpreparedValue b) ->
[InputFieldsParser n (Maybe (OpExpG b (UnpreparedValue b)))]
comparisonOperators tCase collapseIfNull valueParser =
[ mkBoolOperator tCase collapseIfNull (C.fromName Name.__gt) Nothing $ AGT <$> valueParser,
mkBoolOperator tCase collapseIfNull (C.fromName Name.__lt) Nothing $ ALT <$> valueParser,
mkBoolOperator tCase collapseIfNull (C.fromName Name.__gte) Nothing $ AGTE <$> valueParser,
mkBoolOperator tCase collapseIfNull (C.fromName Name.__lte) Nothing $ ALTE <$> valueParser
]