graphql-engine/server/src-lib/Hasura/SQL
Auke Booij 8888e06bbb Spell out the TH in Hasura.SQL.{Tag,AnyBackend}
The module `Hasura.SQL.AnyBackend` was introduced (in #751) to centralize the logic for case-switching behavior that depends on the particular flavor of relational DB backend (Postgres vs MSSQL vs BigQuery vs MySQL vs DataConnectors). This allows us to write a bunch of code in a backend-agnostic way, even if runtime behavior does depend on the chosen backend. At the same time, it allows us to write backend-specific code without having to care (too much) about the existence of other backends.

In #851 this module was rewritten to use Template Haskell.

I've heard that one of the reasons for the use of TH was that this would make it easier to keep backends out of the compilation product entirely. This would allow customers, especially on OSS, to benefit from simpler software licensing.

However:
1. This conditional compilation never materialized.
2. It's not clear whether writing this particular module based on TH would be sufficient for conditional compilation. And in any case, it can be done using CPP pragmas as well.
3. The TH code is extraordinarily complex. Since its introduction, it has been documented extraordinarily well, but it's still very difficult to maintain and/or refactor, due to its non-idiomatic nature.
4. Hasura's company objectives are now Cloud-oriented, so that software licensing issues work differently, and in particular, do not depend on what's part of the compilation product.

So this PR reverts on #851 by spelling out the code generated by TH. This is a net-negative diff size. IOW we used to generate less code than the size of the code doing the generating. This makes the code readable and maintainable.

The generated code has been modified in one way, which I'll now describe.

In the scenario that support for a new backend is introduced, a constructor is added to the `BackendType` type. This would then cause `liftTag` to be partial, thus raising a compiler warning. Resolving this requires adding corresponding constructors to the `BackendTag` and `AnyBackend` types. This would then require amending **almost** all other methods.

The exceptions are `composeAnyBackend` and `unpackAnyBackend`. These methods test whether two values are compatible, i.e. belong to the same backend. Both have a default case that in one way or another ignores the input values. Using TH here ensures that all values that belong together are caught. But after spelling out the TH, the presence of the default case means that no compiler warning is thrown for a missing match of matching values. So in the default case, we now do an explicit check for equality. If there _is_ an equality, that means that there is a missing `case`. So this is reported as an `error` (which is very crude, but it should be).

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5333
GitOrigin-RevId: 5aaf0a93394bd740aa7371526d3175c8142b3541
2022-08-11 09:11:07 +00:00
..
AnyBackend.hs Spell out the TH in Hasura.SQL.{Tag,AnyBackend} 2022-08-11 09:11:07 +00:00
Backend.hs Rename Data Wrapper to Data Connector [GDW-89] 2022-05-02 05:04:07 +00:00
BackendMap.hs server: migrate to aeson-2 in preparation for ghc 9.2 upgrade 2022-06-08 15:32:27 +00:00
GeoJSON.hs server: GHC 9.2 changes compatible with 8.10 (#3550) 2022-06-25 22:09:05 +00:00
Tag.hs Spell out the TH in Hasura.SQL.{Tag,AnyBackend} 2022-08-11 09:11:07 +00:00
Time.hs Rewrite OpenAPI 2022-06-30 12:57:09 +00:00
Types.hs server: accept extensions_schema while adding a source 2022-08-10 09:42:09 +00:00
Value.hs server: add explicit export lists in OSS server and enforce with warning 2021-11-04 16:09:38 +00:00
WKT.hs server, pro: actually reformat the code-base using ormolu 2021-09-23 22:57:37 +00:00