Commit Graph

68 Commits

Author SHA1 Message Date
Auke Booij
3efabe99b3 Memoize column parsers (within roles)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6036
GitOrigin-RevId: 225698f6db02b16599d9f157c9fe4c03b16fb71b
2022-10-03 20:11:44 +00:00
Auke Booij
b03ed983f1 Remove spaces before colons in error messages and descriptions
This PR is the result of running the following commands:
```bash
$ git grep -l '".* : "' -- '*.hs' | xargs sed -i -E 's/(".*) : "/\1: "/'
$ scripts/dev.sh test --integration --accept
```

Also manually fixed a few tests and docs

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6148
GitOrigin-RevId: cf8b87605d41d9ce86613a41ac5fd18691f5a641
2022-10-01 14:48:58 +00:00
Lyndon Maydwell
4d2e37b3e6 Raw Query Support for Data Connectors - GDW-394
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5890
Co-authored-by: Vijay Prasanna <11921040+vijayprasanna13@users.noreply.github.com>
GitOrigin-RevId: f6bd2ed5fe170bcce262564cf4f45c95c9bdff94
2022-09-22 21:09:06 +00:00
Daniel Chambers
dc9a86680c Gardening: Clean up Data Connector API types
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5977
GitOrigin-RevId: 1a6898d6416fff265a8add74d414c979f7fa3bc5
2022-09-21 05:13:03 +00:00
Daniel Chambers
5c06eb7a3e Remove duplicated Data Connector API types
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5930
GitOrigin-RevId: 8c11387fa8556c3cdf8c92a0924ae53d31b953a5
2022-09-20 06:20:25 +00:00
David Overton
cbddcce26b Data connector cache invalidations
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5820
GitOrigin-RevId: ded80e378901cc0c0ca12eb67d9264756a8d6ff4
2022-09-14 13:00:47 +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
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
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. #5339 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. #5517 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 #5517 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
Lyndon Maydwell
88c5b14c3d Adding EXPLAIN endpoint capability and implementation for SQLite data connector agent GDW-181
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5603
GitOrigin-RevId: b9255d265ceb88d96643c95f409387fb93df6676
2022-08-29 03:40:16 +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
Solomon
37601d7303 Adds support for GDC relationships in metadata API and adds support for foreign key constraints to GDC
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5561
GitOrigin-RevId: 221a5dae514c3ac60cc60ba1ec9451a04984d491
2022-08-23 21:47:26 +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 Chambers
ef0ca7dea2 server: Data Connectors support for ordering by related table column and aggregates [GDW-126]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5478
GitOrigin-RevId: 269d33d48f7d41efc7ab4ac6efd9442c6741d08c
2022-08-19 07:01:52 +00:00
Solomon
7a2352dd6e Introduce GDC Add/Remove Agent and List Source Kinds Metadata API Actions
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5415
GitOrigin-RevId: b46f928eae85a747378bbc18968d93dcb81c895a
2022-08-17 22:14:40 +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
Karthikeyan Chinnakonda
f3dd172821 server: accept extensions_schema while adding a source
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5401
Co-authored-by: Naveen Naidu <30195193+Naveenaidu@users.noreply.github.com>
GitOrigin-RevId: 75b68c439fc68662a8e312f84132126d761dda48
2022-08-10 09:42:09 +00:00
Auke Booij
1007ea27ae server: refactor MonadSchema into MonadMemoize
Followup to hasura/graphql-engine-mono#4713.

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`.

hasura/graphql-engine-mono#518 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 hasura/graphql-engine-mono#4713, by removing that constraint.

hasura/graphql-engine-mono#2980 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 hasura/graphql-engine-mono#4726, 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
Daniel Chambers
c209b60239 server: Support the namespacing of table names in Data Connectors
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5329
GitOrigin-RevId: 5cf492bc2b09fef6250f4dd50f74f750f55ebe6a
2022-08-04 08:35:52 +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
Daniel Chambers
731dff7558 server: Support min/max aggregates on string-type columns [GDW-206]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5264
GitOrigin-RevId: 6937e4936a2bb5c6cb8814da9ed4529fdfb6072a
2022-08-02 00:23:13 +00:00
Daniel Chambers
94ddf10df6 server: Remove multiple column count aggregate support from Data Connectors [GDW-207]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5224
GitOrigin-RevId: be62ad21ed60cf5c9fb05cda8454b99a0c024866
2022-07-28 07:25:23 +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
Daniel Chambers
2df835624d server: Nodes field support in Data Connector aggregate queries [GDW-187]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5108
GitOrigin-RevId: 2d707abab0ae429e30be620225c4c419b960aa3f
2022-07-22 09:47:32 +00:00
Lyndon Maydwell
6821b90910 Moving kriti function references into a single module for coordination of availability
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5095
GitOrigin-RevId: 8394c33f0182baad53306c6efc3ab720957b7339
2022-07-21 07:07:29 +00:00
Daniel Chambers
c1380e1daf server: Data Connectors aggregation agent API contract [GDW-95]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5069
GitOrigin-RevId: acd80975c162935d5594e55db47228cf689e5fd7
2022-07-20 05:21:54 +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
Evie Ciobanu
187bf385fc remove homebrew NESeq, use vendored
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5094
GitOrigin-RevId: 3342e571d3574a4d94fe3bfedb60f332b8c10853
2022-07-19 08:42:28 +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
Evie Ciobanu
d76aab99e1 server: postgres multiple updates
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4837
GitOrigin-RevId: 505f669298298fd004dfc4e84eaa0d21df055216
2022-07-18 15:16:47 +00:00
David Overton
b2b195c0a3 Add support for custom comparison operators
Add support for custom comparison operators in the DC agent API and IR.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4974
GitOrigin-RevId: 9580160e6171df77fe4979b7c2e87c473aaccbfc
2022-07-15 03:29:06 +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
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
Daniel Chambers
b9fb7d8720 Support composite primary keys for Data Connector [GDW-127]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4926
GitOrigin-RevId: 2b6e5052f56a765e0b9a19345fcc4688d7e4700f
2022-07-01 12:21:17 +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
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
Daniel Chambers
7ec5e79bd1 AVRelationship Support for Data Connectors [GDW-123]
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4735
GitOrigin-RevId: f23965a6c7ea8a0e6b25dbf9d3faeccec0ef6ec3
2022-06-24 06:59:52 +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
David Overton
5c7489cc23 Flesh out capabilities types
>

## Description ✍️
->

Fleshes out the Capabilities types used by Data Connector agents.

### Related Issues ✍
->

https://hasurahq.atlassian.net/browse/GDW-85

### Solution and Design ✍
>

Capabilities are divided into sections for queries, mutation, subscriptions, filtering and relationships:
```haskell
data Capabilities = Capabilities
  { cQueries :: Maybe QueryCapabilities,
    cMutations :: Maybe MutationCapabilities,
    cSubscriptions :: Maybe SubscriptionCapabilities,
    cFiltering :: Maybe FilteringCapabilities,
    cRelationships :: Maybe RelationshipCapabilities
  }
```

Each section is optional. If the section is absent it means the the related capabilities are not supported by the agent.
The types for each section can contain additional details about exactly what is supported. E.g.
```haskell
data QueryCapabilities = QueryCapabilities
  { qcSupportsPrimaryKeys :: Bool
  }
```

These are currently mostly empty, but will be filled in later.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4671
GitOrigin-RevId: 3d48570266bfce5e177a543a0ed6f63a7b450f0b
2022-06-16 08:31:07 +00:00
Solomon
97ae14a43a [GDW-93] Fix "conflicting definitions" when using both DC backend and PG backend
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4686
GitOrigin-RevId: 254e2ad5d951f73a799e55b1dbcfaa0097054122
2022-06-10 04:00:07 +00:00
Brandon Simmons
6e8da71ece server: migrate to aeson-2 in preparation for ghc 9.2 upgrade
(Work here originally done by awjchen, rebased and fixed up for merge by
jberryman)

This is part of a merge train towards GHC 9.2 compatibility. The main
issue is the use of the new abstract `KeyMap` in 2.0. See:
https://hackage.haskell.org/package/aeson-2.0.3.0/changelog

Alex's original work is here:
#4305

BEHAVIOR CHANGE NOTE: This change causes a different arbitrary ordering
of serialized Json, for example during metadata export. CLI users care
about this in particular, and so we need to call it out as a _behavior
change_ as we did in v2.5.0. The good news though is that after this
change ordering should be more stable (alphabetical key order).

See: https://hasurahq.slack.com/archives/C01M20G1YRW/p1654012632634389

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4611
Co-authored-by: awjchen <13142944+awjchen@users.noreply.github.com>
GitOrigin-RevId: 700265162c782739b2bb88300ee3cda3819b2e87
2022-06-08 15:32:27 +00:00
Antoine Leblanc
e3c2bf53a5 Move, document, and prune action types and custom types types.
### Description

This PR is a first step in a series of cleanups of action relationships. This first step does not contain any behavioral change, and it simply reorganizes / prunes / rearranges / documents the code. Mainly:
- it divides some files in RQL.Types between metadata types, schema cache types, execution types;
- it renames some types for consistency;
- it minimizes exports and prunes unnecessary types;
- it moves some types in places where they make more sense;
- it replaces uses of `DMap BackendTag` with `BackendMap`.

Most of the "movement" within files re-organizes declarations in a "top-down" fashion, by moving all TH splices to the end of the file, which avoids order or declarations mattering.

### Optional list types

One main type change this PR makes is a replacement of variant list types in `CustomTypes.hs`; we had `Maybe [a]`, or sometimes `Maybe (NonEmpty a)`. This PR harmonizes all of them to `[a]`, as most of the code would use them as such, by doing `fromMaybe []` or `maybe [] toList`.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4613
GitOrigin-RevId: bc624e10df587eba862ff27a5e8021b32d0d78a2
2022-06-07 15:45:00 +00:00
Antoine Leblanc
eaba2e08d3 Clean Relay's code, break schema cycles, introduce Node ID V2
## Motivation

This PR rewrites most of Relay to achieve the following:
- ~~fix a bug in which the same node id could refer to two different tables in the schema~~
- remove one of the few remaining uses of the source cache in the schema building code

In doing so, it also:
- simplifies the `BackendSchema` class by removing `node` from it,
- makes it much easier for other backends to support Relay,
- documents, re-organizes, and clarifies the code.

## Description

This PR introduces a new `NodeId` version ~~, and adapts the Postgres code to always generate this V2 version~~. This new id contains the source name, in addition to the table name, in order to disambiguate similar table names across different sources (which is now possible with source customization). In doing so, it now explicitly handles that case for V1 node ids, and returns an explicit error message instead of running the risk of _silently returning the wrong information_.

Furthermore, it adapts `nodeField` to support multiple backends; most of the code was trivial to generalize, and as a result it lowers the cost of entry for other backends, that now only need to support `AFNodeId` in their translation layer.

Finally, it removes one more cycle in the schema building code, by using the same trick we used for remote relationships instead of using the memoization trick of #4576.

## Remaining work

- ~~[ ]write a Changelog entry~~
- ~~[x] adapt all tests that were asserting on an old node id~~

## Future work

This PR was adapted from its original form to avoid a breaking change: while it introduces a Node ID V2, we keep generating V1 IDs and the parser rejects V2 IDs. It will be easy to make the switch at a later data in a subsequent PR.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4593
GitOrigin-RevId: 88e5cb91e8b0646900547fa8c7c0e1463de267a1
2022-06-07 13:36:29 +00:00