1
0
mirror of https://github.com/hasura/graphql-engine.git synced 2024-12-18 04:51:35 +03:00
Commit Graph

17 Commits

Author SHA1 Message Date
Gil Mizrahi
625e41cd77 rename naqi to logimo part 3 - data types
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8068
GitOrigin-RevId: 435527a98e645ed69c9be484ff0bd21af8181d69
2023-02-22 13:46:54 +00:00
Philip Lykke Carlsen
70c8bc8700 Integrating Native Query metadata and schema
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7657
Co-authored-by: Daniel Harvey <4729125+danieljharvey@users.noreply.github.com>
GitOrigin-RevId: d5047559e3560f5d7870eac6e07c89704146ccab
2023-01-30 16:06:34 +00:00
Daniel Harvey
06b284cf33 [server] metadata API for native access
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7476
Co-authored-by: Tom Harding <6302310+i-am-tom@users.noreply.github.com>
GitOrigin-RevId: 781c29666e92004dc82918c2292fdacc27fded4c
2023-01-16 17:21:22 +00:00
Daniel Chambers
57607f5295 Refactor Update IR to generalize Update vs Update Many across backends - compositional approach [GDC-687]
[GDC-687]: https://hasurahq.atlassian.net/browse/GDC-687?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
[GDC-687]: https://hasurahq.atlassian.net/browse/GDC-687?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7355
GitOrigin-RevId: fa02a83c0c594abe05c1071d0de5054478c32e56
2023-01-10 01:56:14 +00:00
Antoine Leblanc
42e5205eb5 server: reduce schema contexts to the bare minimum
### Description

This monster of a PR took way too long. As the title suggests, it reduces the schema context carried in the readers to the very strict minimum. In practice, that means that to build a source, we only require:
  - the global `SchemaContext`
  - the global `SchemaOptions` (soon to be renamed `SchemaSourceOptions`)
  - that source's `SourceInfo`

Furthermore, _we no longer carry "default" customization options throughout the schema_. All customization information is extracted from the `SourceInfo`, when required. This prevents an entire category of bugs we had previously encountered, such as parts of the code using uninitialized / unupdated customization info.

In turn, this meant that we could remove the explicit threading of the `SourceInfo` throughout the schema, since it is now always available through the reader context.

Finally, this meant making a few adjustments to relay and actions as well, such as the introduction of a new separate "context" for actions, and a change to how we create some of the action-specific postgres scalar parsers.

I'll highlight with review comments the areas of interest.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6709
GitOrigin-RevId: ea80fddcb24e2513779dd04b0b700a55f0028dd1
2022-11-17 10:35:54 +00:00
Philip Lykke Carlsen
d43a30e8fc feat(tests): Introduce AggregationPredicatesSpec
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5686
GitOrigin-RevId: 85b39ad569180929e5620c45bf9a98ef6ee99d42
2022-09-07 12:10:52 +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
Philip Lykke Carlsen
bb2c704c6d refactor(tests): Rename monad types
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5683
GitOrigin-RevId: 3d0a3f327eb069fdeb5339981dd5022d8f48699a
2022-09-05 16:29:20 +00:00
Philip Lykke Carlsen
360786389e refactor: Separate out TableInfo building
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5635
GitOrigin-RevId: 2846a64a8e3b0f55bb302a969bcaedaf2e1cf1a5
2022-08-25 17:55:55 +00:00
Evie Ciobanu
80cbf3ae33 server/nada: add unit test infrastructure for Postgres delete SQL generation
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5434
GitOrigin-RevId: 839a45a1469272def9d28c0f3e7454a5bf506f35
2022-08-11 10:46:49 +00:00
Evie Ciobanu
72cfb7fc9b server/nada: test mkUpdateCTE
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5341
GitOrigin-RevId: 39db14cc2d2329d8cadb7a6080b1e2361eba1fb5
2022-08-05 21:42:19 +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
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
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
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
Auke Booij
13fc1c62d1 Move Hasura.GraphQL.Parser.Column to .RQL.IR. and .GraphQL.Schema.
This is a first step towards clarifying the role of `UnpreparedValue` as part of the IR. It certainly does not belong in the parser framework.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4588
GitOrigin-RevId: d1582a0b266729b79e00d31057178a4099168e6d
2022-05-30 22:07:57 +00:00
Evie Ciobanu
a8c0137f21 server: add infrastructure to write runit tests for update parsers
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4533
GitOrigin-RevId: d094149d6cbdeebe152c58032715bad725480d9b
2022-05-26 14:06:24 +00:00