Closed AndrewSisley closed 2 months ago
Some discussion in discord thread dev-db
.Decouple defra from gql
https://discord.com/channels/427944769851752448/1027210035115331626
Discussions that arose in #1054 that might be worth to explore as a part of this task:
Rename to request
package discussion:
More:
Related #1845
This has pretty much been completed, we may encounter some small leftovers when we get round to adding other query langs
Would like to reorganize the relationship between defra and gql. At the moment defra is a GQL database, however it would be fairly easy to decouple the two - I think this would make for a cleaner separation of concerns (preventing conceptual leaks), and gives us the opportunity to support more query languages in the future. It also removes the string/gql dependency from the collection ABI, and IMO makes it easier for source-dev/author specialization as the query language separated from the core db engine. It also provides cleaner guarantees that gql-elements are not persisted in defra (boosting interop) (e.g. saved in the schema).
The gql aspect (including generator) becomes a layer on top of defra (including constants). It is removed from the collection abi). The collection abi takes a well defined
mapper.Select
like type as a parameter, optimized for users, this gets converted to themapper.Select
(optimized for internal usage) within the planner package, the gql package parses the gql into theclient/collection.Select
.