From `alpha-40` we've been using a `WHERE` clause to fetch required rows and generate mutation response. This has a few limitations like the requirement of a primary key/unique constraint. This also returns inconsistent data on `delete` mutation as mentioned in #1794.
Now, we're using `VALUES (..)` (refer [here](https://www.postgresql.org/docs/current/sql-values.html)) expression to form virtual table rows in `SQL` to generate mutation response.
Internal changes:-
- Not to use primary key/unique constraint columns:-
- Revert back to `ConstraintName` from `TableConstraint` in `TableInfo` type
- Remove `tcCols` field in `TableConstraint` type
- Modify `table_info.sql` and `fetchTableMeta` function `SQL`
- A test case to perform `delete` mutation and returning relational objects.
This is a forked version of Urigo's [WhatsApp Clone](https://github.com/Urigo/WhatsApp-Clone-server), integrated with Hasura.
Hasura GraphQL APIs are used in place of custom resolvers. A simple JWT server replaces the original auth server. Image uploads use the same Cloudinary APIs.
[Original React Client](https://github.com/Urigo/WhatsApp-Clone-Client-React) has been updated to match Hasura APIs and typescript definitions have been generated using GraphQL Code Generator.
There was a postgres permission issue in the docs. The hasura user
needed to be owner of the system schemas (hdb_catalog), otherwise it
won't be able to table schema changes during version upgrades.
* Track this will be disabled if SQL contains a create function statement
* Track this will be disabled if SQL contains a create table/view statement for a table/view which is already tracked
1. Haskel library `pg-client-hs` has been updated to expose a function that helps listen to `postgres` notifications over a `channel` in this [PR](https://github.com/hasura/pg-client-hs/pull/5)
2. The server records an event in a table `hdb_catalog.hdb_cache_update_event` whenever any `/v1/query` (that changes metadata) is requested. A trigger notifies a `cache update` event via `hasura_cache_update` channel
3. The server runs two concurrent threads namely `listener` and `processor`. The `listener` thread listens to events on `hasura_cache_update` channel and pushed into a `Queue`. The `processor` thread fetches events from that `Queue` and processes it. Thus server rebuilds schema cache from database and updates.
