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.
If returning field contains nested selections then mutation is performed in two steps
1. Mutation is performed with returning columns of any primary key and unique constraints
2. returning fields are queried on rows returned by selecting from table by filtering with column values returned in Step 1.
Since mutation takes two courses based on selecting relations in returning field, it is hard to maintain sequence of prepared arguments (PrepArg) generated while resolving returning field. So, we're using txtConverter instead of prepare to resolve mutation fields.
CircleCI jobs are run for any PR that is submitted to the repo. This PR adds a check to decide whether the job should be run or not.
Figured out that CircleCI has a way to gracefully terminate a job:
```
circleci-agent step halt
```
A `.ciignore` file is ran against all the changes in the PR to decide whether the PR should be built or not. If the answer comes out as `no`, a file is written at `/buid/skip_job.txt`. This is done in the `check_build_worthiness` step.
All further jobs, in the beginning, looks for this file and gracefully terminates the job if this file is present. The directory is passed down to the jobs as the workspace.
```yaml
skip_job_on_ciignore: &skip_job_on_ciignore
run: |
if [ -f /build/skip_job.txt ]; then
echo "halting job due to /build/skip_job.txt"
circleci-agent step halt
fi
```
ref: https://support.circleci.com/hc/en-us/articles/360015562253-Conditionally-end-a-running-job-gracefully
There are some known issues on jobs that are run when PR is merged to master, need to address them after this PR is merged.
