1
0
mirror of https://github.com/hasura/graphql-engine.git synced 2024-12-19 05:21:47 +03:00
Commit Graph

235 Commits

Author SHA1 Message Date
paritosh-08
f7115891f7 server: event trigger log cleanup | change metedata API field name
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5965
GitOrigin-RevId: aa50006946e79fe4d9c971568221dc436040b738
2022-09-20 16:33:11 +00:00
Abby Sassel
3056678e04 server/postgres: Implement execution of aggregation predicates
PR for the translation / execution step of [aggregation predicate filters](https://github.com/hasura/graphql-engine-mono/issues/5174).

[`translateAVAggregationPredicates`](translateAVAggregationPredicates) is the main change of note, everything else is a supporting or helper function. Please note this doesn't yet include [tests relating to permissions](https://hasurahq.slack.com/archives/C01RZPEPF0W/p1662560092197769); I decided to raise a PR without them for slightly faster feedback. I may include them in this PR or a separately if it's not trivial.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5724
GitOrigin-RevId: fcac258b64066e2bd45108372165a16fd957f5ab
2022-09-16 15:01:03 +00:00
paritosh-08
ab71adc3a0 server, pro: event trigger auto cleanup (increment 3)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5823
Co-authored-by: pranshi06 <85474619+pranshi06@users.noreply.github.com>
Co-authored-by: Puru Gupta <32328846+purugupta99@users.noreply.github.com>
Co-authored-by: Karthikeyan Chinnakonda <15602904+codingkarthik@users.noreply.github.com>
GitOrigin-RevId: 3d4af905d5df4c05107ad46ef29f4c0a567ff754
2022-09-15 11:46:22 +00:00
Samir Talwar
ee995aacc1 Extract out functions from columnParser in Backend.
The intent is to generalize `columnParser` to the point where it is the same across all backends, and then remove the interface in favor of a single implementation.

This extracts out `enumParser` and `possiblyNullable` as the two main areas that differ across backends. We may split `possiblyNullable` further so that we can extract some of that logic out into a common function too.

With these changes, the various `columnParser` implementations become semantically equivalent. They still do different things, and so reconciling them will require further changes.

Co-Authored-By: Antoine Leblanc <antoine@hasura.io>

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5841
GitOrigin-RevId: eec1770931eed5d72da70c97d7d0f00e33fa15d2
2022-09-13 21:22:25 +00:00
paritosh-08
db710d38b7 server, pro: event trigger auto cleanup (increment 2)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5746
Co-authored-by: pranshi06 <85474619+pranshi06@users.noreply.github.com>
Co-authored-by: Puru Gupta <32328846+purugupta99@users.noreply.github.com>
Co-authored-by: Karthikeyan Chinnakonda <15602904+codingkarthik@users.noreply.github.com>
GitOrigin-RevId: f4e5e06389ca57bdb5f7771f459c07418787111d
2022-09-13 08:34:52 +00:00
Jesse Hallett
977c624c9e server: prune health check from codecs for backends that don't support it
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5822
GitOrigin-RevId: 637a8c668299409385f340d62fc6a84df5c4aa0f
2022-09-09 13:07:33 +00:00
paritosh-08
d6970173c1 server, pro: event trigger auto cleanup (increment 1)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5612
Co-authored-by: pranshi06 <85474619+pranshi06@users.noreply.github.com>
Co-authored-by: Puru Gupta <32328846+purugupta99@users.noreply.github.com>
Co-authored-by: Karthikeyan Chinnakonda <15602904+codingkarthik@users.noreply.github.com>
GitOrigin-RevId: 6ce69ebb555e49439ae2b01fe42e39415ac53966
2022-09-09 08:28:31 +00:00
Antoine Leblanc
512a4dbb92 Use a different reader context for sources and remote schemas with new SchemaT monad.
### Description

This PR changes all the schema code to operate in a specific `SchemaT` monad, rather than in an arbitrary `m` monad. `SchemaT` is intended to be used opaquely with `runSourceSchema` and `runRemoteSchema`. The main goal of this is to allow a different reader context per part of the schema: this PR also minimizes the contexts. This means that we no longer require `SchemaOptions` when building remote schemas' schema, and this PR therefore removes a lot of dummy / placeholder values accordingly.

### Performance and stacking

This PR has been through several iterations.  was the original version, that accomplished the same thing by stacking readers on top of the stack at every remote relationship boundary. This raised performance concerns, and @0x777 confirmed with an ad-hoc test that in some extreme cases we could see up to a 10% performance impact. This version, while more verbose, allows us to unstack / re-stack the readers, and avoid that problem.  adds a new benchmark set to be able to automatically measure this on every PR.

### Remaining work

- [x] a comment (or perhaps even a Note?) should be added to `SchemaT`
- [x] we probably want for  to be merged first so that we can confirm the lack of performance penalty

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5458
GitOrigin-RevId: e06b83d90da475f745b838f1fd8f8b4d9d3f4b10
2022-09-06 16:49:23 +00:00
David Overton
f4419236ed Gdc capabilities scalar types - GDW-87
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5597
GitOrigin-RevId: 4f561bf476266955d7b1d3dbca4d406a97bf8b34
2022-09-06 04:26:03 +00:00
David Overton
0b7353657c Push capabilities resolution code into BackendMetadata type class
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5738
GitOrigin-RevId: 5c8e8232b8db67584d3f0a03987b97f0cce53a97
2022-09-05 02:44:10 +00:00
awjchen
78cf1d544e server/pro: enable health check on data sources and report via logging and API
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4868
Co-authored-by: Rakesh Emmadi <12475069+rakeshkky@users.noreply.github.com>
Co-authored-by: Sean Park-Ross <94021366+seanparkross@users.noreply.github.com>
GitOrigin-RevId: b8d43e3f7d977c4bb37b8506ac87ce7bf289d542
2022-09-02 06:34:29 +00:00
David Overton
00aeb57adf Add data connector agent capabilities schema cache
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5689
GitOrigin-RevId: 86e18e92106e5e5b6543f17fc21e2ab65bdd69ed
2022-09-01 05:29:04 +00:00
Jesse Hallett
84fd5910b0 server: polymorphic codec for metadata sources
This PR expands the OpenAPI specification generated for metadata to include separate definitions for `SourceMetadata` for each native database type, and for DataConnector.

For the most part the changes add `HasCodec` implementations, and don't modify existing code otherwise.

The generated OpenAPI spec can be used to generate TypeScript definitions that distinguish different source metadata types based on the value of the `kind` properly. There is a problem: because the specified `kind` value for a data connector source is any string, when TypeScript gets a source with a `kind` value of, say, `"postgres"`, it cannot unambiguously determine whether the source is postgres, or a data connector. For example,

```ts
function consumeSourceMetadata(source: SourceMetadata) {
    if (source.kind === "postgres" || source.kind === "pg") {
        // At this point TypeScript infers that `source` is either an instance
        // of `PostgresSourceMetadata`, or `DataconnectorSourceMetadata`. It
        // can't narrow further.
        source
    }
    if (source.kind === "something else") {
        // TypeScript infers that this `source` must be an instance of
        // `DataconnectorSourceMetadata` because `source.kind` does not match
        // any of the other options.
        source
    }
}
```

The simplest way I can think of to fix this would be to add a boolean property to the `SourceMetadata` type along the lines of `isNative` or `isDataConnector`. This could be a field that only exists in serialized data, like the metadata version field. The combination of one of the native database names for `kind`, and a true value for `isNative` would be enough for TypeScript to unambiguously distinguish the source kinds.

But note that in the current state TypeScript is able to reference the short `"pg"` name correctly!

~~Tests are not passing yet due to some discrepancies in DTO serialization vs existing Metadata serialization. I'm working on that.~~

The placeholders that I used for table and function metadata are not compatible with the ordered JSON serialization in use. I think the best solution is to write compatible codecs for those types in another PR. For now I have disabled some DTO tests for this PR.

Here are the generated [OpenAPI spec](https://github.com/hasura/graphql-engine-mono/files/9397333/openapi.tar.gz) based on these changes, and the generated [TypeScript client code](https://github.com/hasura/graphql-engine-mono/files/9397339/client-typescript.tar.gz) based on that spec.

Ticket: [MM-66](https://hasurahq.atlassian.net/browse/MM-66)

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5582
GitOrigin-RevId: e1446191c6c832879db04f129daa397a3be03f62
2022-08-25 18:36:02 +00:00
Naveen Naidu
dae6cfa9a6 server: enforce event triggers name in a source to be unique
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5394
GitOrigin-RevId: 78015262365985329c18ed25897ca6d6f4422ecb
2022-08-23 08:51:11 +00:00
Philip Lykke Carlsen
4431fb5ea9 Add schema implementation for Aggregation Predicates
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5259
GitOrigin-RevId: f53e310951fa4eb7570006d8c616398a98078632
2022-08-22 15:59:21 +00:00
Daniel Harvey
5a126a693e server: MSSQL varchars compared to nvarchars
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5536
GitOrigin-RevId: ff2e5c9a71dbb02e729b7715d5df752675fc4656
2022-08-22 08:34:41 +00:00
Philip Lykke Carlsen
0e921ca9a5 Define IR types for AggregationPredicates.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5258
GitOrigin-RevId: 172b9de69f44635c5700b3f75ce17304ec56c18a
2022-08-19 15:41:47 +00:00
Daniel Harvey
8600d78456 server: Remove duplicated Expression and Constants from Query module
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5530
GitOrigin-RevId: 2e1ad22472e4abdbff0a3701d73c632dbbcf649f
2022-08-19 12:27:12 +00:00
paritosh-08
9d23a10f33 server: fix behaviour of custom table name for graphql-default naming convention
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5290
GitOrigin-RevId: bc398989d82a0e78bfcf87d5aa81bcd6a709c67f
2022-08-17 12:47:49 +00:00
Auke Booij
4d5ee4c17e Inline a whole bunch of nothing for BackendSchema
This makes it easier to refactor `BackendSchema`, because if the type of a type class method is changed, it's easier to update the corresponding dummy implementations.

Partially addresses , in the sense that this aids refactors.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5443
GitOrigin-RevId: 65e169d01415a04e7c419a628cf32e743448543d
2022-08-11 11:58:40 +00:00
Auke Booij
1007ea27ae server: refactor MonadSchema into MonadMemoize
Followup to .

The `memoizeOn` method, part of `MonadSchema`, originally had the following type:
```haskell
  memoizeOn
    :: (HasCallStack, Ord a, Typeable a, Typeable b, Typeable k)
    => TH.Name
    -> a
    -> m (Parser k n b)
    -> m (Parser k n b)
```
The reason for operating on `Parser`s specifically was that the `MonadSchema` effect would additionally initialize certain `Unique` values, which appear (nested in) the type of `Parser`.

 changed the type of `memoizeOn`, to additionally allow memoizing `FieldParser`s. These also contained a `Unique` value, which was similarly initialized by the `MonadSchema` effect. The new type of `memoizeOn` was as follows:
```haskell
  memoizeOn
    :: forall p d a b
     . (HasCallStack, HasDefinition (p n b) d, Ord a, Typeable p, Typeable a, Typeable b)
    => TH.Name
    -> a
    -> m (p n b)
    -> m (p n b)
```

Note the type `p n b` of the value being memoized: by choosing `p` to be either `Parser k` or `FieldParser`, both can be memoized. Also note the new `HasDefinition (p n b) d` constraint, which provided a `Lens` for accessing the `Unique` value to be initialized.

A quick simplification is that the `HasCallStack` constraint has never been used by any code. This was realized in , by removing that constraint.

 removed the `Unique` value from our GraphQL-related types entirely, as their original purpose was never truly realized. One part of removing `Unique` consisted of dropping the `HasDefinition (p n b) d` constraint from `memoizeOn`.

What I didn't realize at the time was that this meant that the type of `memoizeOn` could be generalized and simplified much further. This PR finally implements that generalization. The new type is as follows:
```haskell
  memoizeOn ::
    forall a p.
    (Ord a, Typeable a, Typeable p) =>
    TH.Name ->
    a ->
    m p ->
    m p
```

This change has a couple of consequences.

1. While constructing the schema, we often output `Maybe (Parser ...)`, to model that the existence of certain pieces of GraphQL schema sometimes depends on the permissions that a certain role has. The previous versions of `memoizeOn` were not able to handle this, as the only thing they could memoize was fully-defined (if not yet fully-evaluated) `(Field)Parser`s. This much more general API _would_ allow memoizing `Maybe (Parser ...)`s. However, we probably have to be continue being cautious with this: if we blindly memoize all `Maybe (Parser ...)`s, the resulting code may never be able to decide whether the value is `Just` or `Nothing` - i.e. it never commits to the existence-or-not of a GraphQL schema fragment. This would manifest as a non-well-founded knot tying, and this would get reported as an error by the implementation of `memoizeOn`.

   tl;dr: This generalization _technically_ allows for memoizing `Maybe` values, but we probably still want to avoid doing so.

   For this reason, the PR adds a specialized version of `memoizeOn` to `Hasura.GraphQL.Schema.Parser`.
2. There is no longer any need to connect the `MonadSchema` knot-tying effect with the `MonadParse` effect. In fact, after this PR, the `memoizeOn` method is completely GraphQL-agnostic, and so we implement , separating `memoizeOn` from `MonadParse` entirely - `memoizeOn` can be defined and implemented as a general Haskell typeclass method.

   Since `MonadSchema` has been made into a single-type-parameter type class, it has been renamed to something more general, namely `MonadMemoize`. Its only task is to memoize arbitrary `Typeable p` objects under a combined key consisting of a `TH.Name` and a `Typeable a`.

   Also for this reason, the new `MonadMemoize` has been moved to the more general `Control.Monad.Memoize`.
3. After this change, it's somewhat clearer what `memoizeOn` does: it memoizes an arbitrary value of a `Typeable` type. The only thing that needs to be understood in its implementation is how the manual blackholing works. There is no more semantic interaction with _any_ GraphQL code.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4725
Co-authored-by: Daniel Harvey <4729125+danieljharvey@users.noreply.github.com>
GitOrigin-RevId: 089fa2e82c2ce29da76850e994eabb1e261f9c92
2022-08-04 13:45:53 +00:00
Antoine Leblanc
666f4cacb7 Only require MkRootFieldName in top-level functions (that make root fields)
### Description

By definition, root fields are at the root of the schema: only functions that craft root fields need to know about how to customize the name of root fields. However, the presence of `Has MkRootFieldName` in `MonadBuildSchemaBase` meant that the entirety of the schema building code was implicitly aware of / capable of altering root field names.

This PR removes this constraint, and moves it to the functions that do craft root fields. This has several upsides:
- it makes it more explicit where root fields are being crafted
- it prevents functions that should not use this from mistakenly applying it to non-root fields
- it simplifies the shared schema context

### Future work

- can we maybe pass this as an argument, instead of making it a required part of the context?
- ~~AFAICT, we only ever use `mempty` for it: is this actually dead code that we should actually just remove altogether?~~

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5235
GitOrigin-RevId: 4268751f3ab87ae8e03b6fe9e1efa1b096200027
2022-08-03 19:09:50 +00:00
Antoine Leblanc
0a69db81c9 Move RoleName into SchemaContext.
### Description

I am not 100% sure about this PR; while I think the code is better this way, I'm willing to be convinced otherwise.

In short, this PR moves the `RoleName` field into the `SchemaContext`, instead of being a nebulous `Has RoleName` constraint on the reader monad. The major upside of this is that it makes it an explicit named field, rather than something that must be given as part of a tuple of arguments when calling `runReader`.

However, the downside is that it breaks the helper permissions functions of `Schema.Table`, which relied on `Has RoleName r`. This PR makes the choice of passing the role name explicitly to all of those functions, which in turn means first explicitly fetching the role name in a lot of places. It makes it more explicit when a schema building block relies on the role name, but is a bit verbose...

### Alternatives

Some alternatives worth considering:
- attempting something like `Has context r, Has RoleName context`, which would allow them to be independent from the context but still fetch the role name from the reader, but might require type annotations to not be ambiguous
- keeping the permission functions the same, with `Has RoleName r`, and introducing a bunch of newtypes instead of using tuples to explicitly implement all the required `Has` instances
- changing the permission functions to `Has SchemaContext r`, since they are functions used only to build the schema, and therefore may be allowed to be tied to the context.

What do y'all think?

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5073
GitOrigin-RevId: 8fd09fafb54905a4d115ef30842d35da0c3db5d2
2022-07-29 15:38:44 +00:00
Gil Mizrahi
d64940f615 Remove strictness annotations from data types in the Hasura.Backends hierarchy
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5252
GitOrigin-RevId: e2c4098a06c674fa62118d0c1bdbc82c7d5b954e
2022-07-29 14:06:23 +00:00
Samir Talwar
f01c7f4ee6 server: Remove QErr and Code dependencies from the schema parsers.
In the process of decoupling the schema parsers from the GraphQL Engine, we need to remove dependencies on `Hasura.Base.Error`.

First of all, we have avoided using `QErr` in schema parsers code, instead returning a more appropriate data type which can be converted to a `Hasura.Base.Error.QErr` later.

Secondly, we create a new `ParseErrorCode` type to represent parse failure types, which are then converted to a `Hasura.Base.Error.Code` later.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5181
GitOrigin-RevId: 8655e26adb1e7d5e3d552c77a8a403f987b53467
2022-07-27 12:26:44 +00:00
Lyndon Maydwell
607497f82f Increase timeout for DC Agents
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5172
GitOrigin-RevId: 1d286447901e34a77518e062315b80f4f775eebf
2022-07-27 07:19:44 +00:00
paritosh-08
95adde4ce2 server: support for Apollo federation
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4584
Co-authored-by: Auke Booij <164426+abooij@users.noreply.github.com>
GitOrigin-RevId: 0f60c263efb5fbaa25620dd8159e8cfda25a61b2
2022-07-25 15:54:41 +00:00
Naveen Naidu
38a10bebb7 server: delete hasura SQL triggers when MSSQL source is dropped
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5060
GitOrigin-RevId: 377df03697d973cdaa643999b213697d7a368dee
2022-07-19 11:40:50 +00:00
paritosh-08
d66abcefab server: transform enum with upper for graphql-default
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5032
GitOrigin-RevId: 206a673f4bd59700436f6160feeb7df415f637ad
2022-07-19 06:56:45 +00:00
Lyndon Maydwell
2107c70e17 Kriti Transform of the DataConnectors Configuration [GDW-144]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4996
GitOrigin-RevId: 26d367ab83df4b161f58133afab2788c6f0c9746
2022-07-19 01:52:50 +00:00
Samir Talwar
eab4f75212 An ErrorMessage type, to encapsulate.
This introduces an `ErrorMessage` newtype which wraps `Text` in a manner which is designed to be easy to construct, and difficult to deconstruct.

It provides functionality similar to `Data.Text.Extended`, but designed _only_ for error messages. Error messages are constructed through `fromString`, concatenation, or the `toErrorValue` function, which is designed to be overridden for all meaningful domain types that might show up in an error message. Notably, there are not and should never be instances of `ToErrorValue` for `String`, `Text`, `Int`, etc. This is so that we correctly represent the value in a way that is specific to its type. For example, all `Name` values (from the _graphql-parser-hs_ library) are single-quoted now; no exceptions.

I have mostly had to add `instance ToErrorValue` for various backend types (and also add newtypes where necessary). Some of these are not strictly necessary for this changeset, as I had bigger aspirations when I started. These aspirations have been tempered by trying and failing twice.

As such, in this changeset, I have started by introducing this type to the `parseError` and `parseErrorWith` functions. In the future, I would like to extend this to the `QErr` record and the various `throwError` functions, but this is a much larger task and should probably be done in stages.

For now, `toErrorMessage` and `fromErrorMessage` are provided for conversion to and from `Text`, but the intent is to stop exporting these once all error messages are converted to the new type.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5018
GitOrigin-RevId: 84b37e238992e4312255a87ca44f41af65e2d89a
2022-07-18 20:27:06 +00:00
Samir Talwar
3d5f39702b Inline scalar type names in RQL.Common.
So that we don't need to import `RQL` from `GraphQL.Parser`.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5057
GitOrigin-RevId: 17b35871b853c52a6b03afe5bff9553f56f8e3b4
2022-07-15 10:11:13 +00:00
Tom Harding
2e7e6fd98a Move SchemaOptions to its own module, remove magic bools
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5048
GitOrigin-RevId: f666a10c6af5feda9d761d3ffee5c77695361fdf
2022-07-14 17:59:01 +00:00
Tom Harding
9b22eed82a Remove scalarTypeGraphQLName
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5051
GitOrigin-RevId: 7312156b29ceac50787e43f06bc01f2ba48de28f
2022-07-14 14:04:56 +00:00
Samir Talwar
c980af1b8f Move MkTypename and NamingCase into their own modules.
This moves `MkTypename` and `NamingCase` into their own modules, with the intent of reducing the scope of the schema parsers code, and trying to reduce imports of large modules when small ones will do.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4978
GitOrigin-RevId: 19541257fe010035390f6183a4eaa37bae0d3ca1
2022-07-12 14:01:28 +00:00
Gil Mizrahi
555e0d0afe server: adding a few code comments
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5014
GitOrigin-RevId: 7f0cb241d3eb2d91bd6feb2b2eb6bf830f1757f9
2022-07-12 09:26:32 +00:00
Daniel Chambers
728fcd011e Add Data Connector agent request logging, improve error messages, and add tracing support [GDW-83]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4987
GitOrigin-RevId: 71570d1656e0cd5be49c179740be81804a3ad05a
2022-07-11 08:05:40 +00:00
Karthikeyan Chinnakonda
edef724879 server: Create SQL trigger if not found while reloading metadata
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4716
GitOrigin-RevId: 5303477aa19257535e682e6cbd3e79d49aba1fa2
2022-07-04 10:10:54 +00:00
Samir Talwar
2be2200b1a server: Split CatalogVersion into Source… and Metadata…
This reflects the two different usages, which should not be conflated.

We also propagate the type a little more, to avoid `Text`.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4931
GitOrigin-RevId: 16278f14aa4c2cb5667ea54bbb6b25e6d362835c
2022-07-04 09:32:12 +00:00
Samir Talwar
40617719ef server: Remove the Show instance from QErr and anything that touches it.
We only use these `Show` instances in error messages (where we call
`show` explicitly anyway) and test cases (in which Hspec requires `Show
a` for any `a` in an assertion).

This removes the instance in favor of a custom `showQErr` function
(which serializes the error to JSON). It is then used in certain error
message production which previously called `show` on a `QErr`.

There are two places where we serialize a QErr and then construct a new
QErr from the resulting string. Instead, we modify the existing QErr to
add extra information.

An orphan `Show QErr` instance is retained for tests so that we can have
nice test failure messages.

This is preparation for future changes in which the error message within
`QErr` will not be exposed directly, and therefore will not have a
`Show` instance. That said, it feels like a sensible kind of cleanup
anyway.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4897
GitOrigin-RevId: 8f79f7a356f0aea571156f39aefac242bf751f3a
2022-07-01 11:48:26 +00:00
Tom Harding
99f6172d0d Implement HLint suggestions and turn warnings into errors
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4903
GitOrigin-RevId: acab9bbd8373bdf427a80ab1dd73d49ab61996a2
2022-07-01 10:50:33 +00:00
Naveen Naidu
2ab9646a4e server: fix mssql getMaintenanceModeTx
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4928
GitOrigin-RevId: e965ec74746bd56c0644b77b9e7085692ba91977
2022-07-01 07:57:27 +00:00
Naveen Naidu
d33025ff5b server: fix indexes for MSSQL event triggers
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4766
GitOrigin-RevId: 1c1bf173e53fd0b6692131632023817dc843b302
2022-07-01 06:51:41 +00:00
Philip Lykke Carlsen
824697a1e8 Break up class BackendSchema in two
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4901
GitOrigin-RevId: fdef33b69626d1694dc1938bb76e001284dd1b50
2022-06-30 15:23:35 +00:00
Naveen Naidu
f7178e75f9 server: fix unlockEventsInSource bug
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4821
GitOrigin-RevId: be417c1f05600e3b57fa1e448f69ebd8536c8ff7
2022-06-30 11:27:16 +00:00
Naveen Naidu
25bd8b6e0f server: fix mssql_redeliver_event API
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4885
GitOrigin-RevId: c422f10a06301cf33467e404438bee4b52b4d86d
2022-06-30 06:45:35 +00:00
Samir Talwar
5f38743f29 server: Encapsulate catalog versions in their own type.
This came about as I tried to add an instance over catalog versions and
found they were just simple integers most of the time (and in one case,
a float).

I think this change also clarifies how catalog versions work.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4864
GitOrigin-RevId: a6b7db86de564b71a8c2b602bee6a456b8e20d63
2022-06-29 08:19:33 +00:00
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 . 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
Brandon Simmons
b704192268 server: GHC 9.2 changes compatible with 8.10 ()
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4841
Co-authored-by: awjchen <13142944+awjchen@users.noreply.github.com>
GitOrigin-RevId: ce47b1290fefb07f3f800c6c62120437c02086e5
2022-06-25 22:09:05 +00:00
Samir Talwar
8db9b77c77 server: Reorganize quasi-quoted names.
Pretty much all quasi-quoted names in the server code base have ended up in `Hasura.GraphQL.Parser.Constants`. I'm now finding this unpleasant for two reasons:

1. I would like to factor out the parser code into its own Cabal package, and I don't want to have to expose all these names.
2. Most of them really have nothing to do with the parsers.

In order to remedy this, I have:

1. moved the names used by parser code to `Hasura.GraphQL.Parser.DirectiveName`, as they're all related to directives;
2. moved `Hasura.GraphQL.Parser.Constants` to `Hasura.Name`, changing the qualified import name from `G` to `Name`;
3. moved names only used in tests to the appropriate test case;
4. removed unused items from `Hasura.Name`; and
5. grouped related names.

Most of the changes are simply changing `G` to `Name`, which I find much more meaningful.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4777
GitOrigin-RevId: a77aa0aee137b2b5e6faec94495d3a9fbfa1348b
2022-06-23 09:15:31 +00:00