The word "reset" is little ambiguous (reset to scratch or reset to last known consistent state). metadata reset clears the all the metadata to mimic a freshly installed hasura instance. This actually invokes the clear_metadata API in the backend and hence should also be called metadata clear for perfect clarity.
All references to metadata reset should be changed to metadata clear.
<!-- Thank you for submitting this PR! :) -->
<!-- Provide a general summary of your changes in the Title above ^, end with (close #<issue-no>) or (fix #<issue-no>) -->
### Description
<!-- The title might not be enough to convey how this change affects the user. -->
<!-- Describe the changes from a user's perspective -->
This PR adds a bash script and a serverless function to clean up the output of `pg_dump` so that it can be used as a migration file for Hasura. This can be later integrated with the CLI so that the cleanup is handled by CLI.
### Affected components
<!-- Remove non-affected components from the list -->
- Scripts
### Related Issues
<!-- Please make sure you have an issue associated with this Pull Request -->
<!-- And then add `(close #<issue-no>)` to the pull request title -->
<!-- Add the issue number below (e.g. #234) -->
#1861
### Solution and Design
<!-- How is this issue solved/fixed? What is the design? -->
<!-- It's better if we elaborate -->
- A serverless function written in Go gets the SQL content though HTTP POST.
- A set of pre-defined lines are removed from this SQL string.
- SQL comments are removed using regex matching.
- Postgres triggers created by Hasura for use with event triggers are removed with regex matching.
- Empty newlines are removed by regex matching.
- Resulting string is returned in the HTTP response.
### Steps to test and verify
<!-- If this is a feature, what are the steps to try them out? -->
<!-- If this is a bug-fix, how do we verify the fix? -->
```bash
curl --data-binary @filename.sql https://hasura-edit-pg-dump.now.sh > newfile.sql
```
### Limitations, known bugs & workarounds
<!-- Limitations of the PR, known bugs and suggested workarounds -->
NA
<!-- Feel free to delete these comment lines -->
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.
