Commit Graph

12 Commits

Author SHA1 Message Date
Daniel Harvey
7227e96278 feature(server): custom return types as discreet metadata entity
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8556
Co-authored-by: Tom Harding <6302310+i-am-tom@users.noreply.github.com>
GitOrigin-RevId: b7dcbcf378279c3bf4c8d223174b90c2cb4b9e53
2023-03-30 15:15:11 +00:00
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
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
Samir Talwar
342391f39d Upgrade Ormolu to v0.5.
This upgrades the version of Ormolu required by the HGE repository to v0.5.0.1, and reformats all code accordingly.

Ormolu v0.5 reformats code that uses infix operators. This is mostly useful, adding newlines and indentation to make it clear which operators are applied first, but in some cases, it's unpleasant. To make this easier on the eyes, I had to do the following:

* Add a few fixity declarations (search for `infix`)
* Add parentheses to make precedence clear, allowing Ormolu to keep everything on one line
* Rename `relevantEq` to `(==~)` in #6651 and set it to `infix 4`
* Add a few _.ormolu_ files (thanks to @hallettj for helping me get started), mostly for Autodocodec operators that don't have explicit fixity declarations

In general, I think these changes are quite reasonable. They mostly affect indentation.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6675
GitOrigin-RevId: cd47d87f1d089fb0bc9dcbbe7798dbceedcd7d83
2022-11-02 20:55:13 +00:00
Philip Lykke Carlsen
8cb14a592d server: Add an ExperimentalFeatureFlag for Aggregation Predicates
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6523
GitOrigin-RevId: 76861a1bf0d9895901564935b0778e7bda75c6a9
2022-10-25 13:21:40 +00:00
Gil Mizrahi
9c3bd2f0d0 server/postgres: fix the schema types conflict between aggregation predicates and table selection aggregates
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6452
GitOrigin-RevId: ed43442c7ade298659bdc42ff76e8e229825f0f1
2022-10-21 13:28:43 +00:00
Abby Sassel
b59008c880 server/postgres: implement execution of aggregation predicates (permissions)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5959
GitOrigin-RevId: eebfe36d217c333b393a308a1db19271809b6a87
2022-09-22 11:15:04 +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
Antoine Leblanc
40db3d7eab Resolve source customization at schema cache building time.
### Description

This PR attempts to fix several issues with source customization as it relates to remote relationships. There were several issues regarding casing: at the relationship border, we didn't properly set the target source's case, we didn't have access to the list of supported features to decide whether the feature was allowed or not, and we didn't have access to the global default.

However, all of that information is available when we build the schema cache, as we do resolve the case of some elements such as function names: we can therefore resolve source information at the same time, and simplify both the root of the schema and the remote relationship border.

To do this, this PR introduces a new type, `ResolvedSourceCustomization`, to be used in the Schema Cache, as opposed to the metadata's `SourceCustomization`, following a pattern established by a lot of other types.

### Remaining work and open questions

One major point of confusion: it seems to me that we didn't set the case at all across remote relationships, which would suggest we would use the case of the LHS source across the subset of the RHS one that is accessible through the remote relationship, which would in turn "corrupt" the parser cache and might result in the wrong case being used for that source later on. Is that assesment correct, and was I right to fix it?

Another one is that we seem not to be using the local case of the RHS to name the field in an object relationship; unless I'm mistaken we only use it for array relationships? Is that intentional?

This PR is also missing tests that would show-case the difference, and a changelog entry. To my knowledge, all the tests of this feature are in the python test suite; this could be the opportunity to move them to the hspec suite, but this might be a considerable amount of work?

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5619
GitOrigin-RevId: 51a81b713a74575e82d9f96b51633f158ce3a47b
2022-09-12 16:07:26 +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