Merge branch 'master' into 512

docs/graphql/cloud/projects/secure.rst

@@ -41,10 +41,10 @@ On the ``Env vars`` tab, click the button to add a new env var.
 Step 3: Add an admin secret
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-In the ``Key`` dropdown, choose ``ADMIN_SECRET`` and add the secret in the ``Value`` field. Then click the ``Add`` button.
+In the ``Key`` dropdown, choose ``ADMIN_SECRET`` and add a secret of your choice in the ``Value`` field. Then click the ``Add`` button.
 
 .. thumbnail:: /img/graphql/cloud/projects/secure-add-envvar.png
-   :alt: Navigate to env vars
+   :alt: Set admin secret
    :width: 865px
 
 Accessing Hasura

docs/graphql/core/getting-started/docker-simple.rst

@@ -76,6 +76,5 @@ Advanced
 --------
 
 This was a quickstart guide to get the Hasura GraphQL engine up and running
-quickly. For more detailed instructions on deploying using Docker, check out
+quickly. For more detailed instructions on deploying using Docker with an
-:ref:`deployment_docker`.
+external database, check out :ref:`deployment_docker`.
-

docs/graphql/core/guides/docker-networking.rst

@@ -15,7 +15,7 @@ Docker networking
 Introduction
 ------------
 
-Sometimes you might want to connect Hasura with APIs (e.g. auth webhooks, event triggers, remote schemas) that are either running outside of Docker or in a different Docker container.
+Sometimes you might want to connect Hasura running in Docker with APIs (e.g. auth webhooks, event triggers, remote schemas) that are either running outside of Docker or in a different Docker container.
 Depending on the setting, the network config is different. This section shows how to connect in each of these use cases.
 
 Network config
@@ -34,7 +34,7 @@ Network config
          - Config
          - Comment
        * - **Hasura to API (outside Docker)**
-         - 1. With ``--net=host``, e.g. ``localhost:3000 --net=host``
+         - 1. With ``--net=host``, ``localhost:3000``
            2. Otherwise, ``<docker-bridge-ip>:3000``, e.g. ``172.17.0.1:3000``
          - 1. Assuming the API is running on port ``3000``
            2. The Docker bridge IP can be found via ``ifconfig``

docs/graphql/core/guides/mysql-preview.rst

@@ -19,7 +19,7 @@ We are in the process of launching support for MySQL, and we have a preview avai
 
 .. admonition:: Supported MySQL versions
 
-  Hasura GraphQL engine currently supports **MySQL 8.0**. Support for earlier
+  Hasura GraphQL engine currently supports **MySQL 8.0.14 and above**. Support for earlier
   versions will be added soon.
 
 Try it out
@@ -70,6 +70,9 @@ MySQL database *(replace the values surrounded by <>)*
     - <mysql-password>
     ...
 
+Our :ref:`docker networking guide <docker_networking>` might be useful to set
+the appropriate value for ``mysql-host``. *(See Hasura to API)*
+
 Step 3: Run Hasura GraphQL engine
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -93,13 +96,15 @@ Check if the containers are running:
 Step 4: Try out the GraphQL API
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The GraphiQL on the console available at ``http://localhost:8080/console`` can be
+The GraphiQL on the Hasura console available at ``http://localhost:8080/console`` can be
 used to try out the generated GraphQL API.
 
 **The Hasura console currently does not support managing the MySQL database schema**.
 i.e. The ``Data`` section of the console will not display the MySQL tables, etc. Hence the database
 schema needs to be managed externally as of now. *(support for this is coming very soon)*
 
+See the `source PR <https://github.com/hasura/graphql-engine/pull/5655>`__ for more information
+on current limitations and upcoming features.
 
 Keep up to date
 ---------------

docs/graphql/core/index.rst

@@ -67,7 +67,7 @@ The Hasura GraphQL engine makes your data instantly accessible over a real-time
 
     .. container:: toc-list-content
 
-      - :ref:`Basics <migrations_basics>`
+      - :ref:`Migrations basics <migrations>`
       - :ref:`Setting Up Migrations <migrations_setup>`
       - :ref:`Managing Metadata <manage_hasura_metadata>`
       - :ref:`Deploy Using Hasura Cloud <cloud_docs>`

docs/graphql/core/migrations/basics.rst

@@ -1,152 +0,0 @@
-.. meta::
-  :description: Hasura migrations basics
-  :keywords: hasura, docs, migration, metadata
-
-.. _migrations_basics:
-
-Hasura migrations basics
-========================
-
-.. contents:: Table of contents
-  :backlinks: none
-  :depth: 1
-  :local:
-
-.. note::
-
-  For ``config v1``, see :ref:`manage_migrations_v1`.
-
-Initializing migrations
------------------------
-
-:ref:`Install <install_hasura_cli>` the Hasura CLI or :ref:`update <hasura_update-cli>`
-to the latest version if current version is ``< v1.2.0``.
-
-Now run:
-
-.. code-block:: bash
-
-  # create a Hasura project
-  hasura init
-
-  # cd into project dir
-
-  # Export current Hasura state
-  hasura migrate create <init-migration-name> --from-server --endpoint <endpoint>
-  hasura metadata export --endpoint <endpoint>
-
-  # mark the init migration as applied on this server
-  hasura migrate apply --version "<init-migration-version>" --skip-execution
-
-Generating migrations
----------------------
-
-.. rst-class:: api_tabs
-.. tabs::
-
-  .. tab:: Via console
-
-    - Open the Hasura console via the CLI
-
-      .. code-block:: bash
-
-        hasura console
-
-    - As you make changes, migration files will be created and latest
-      metadata will be exported automatically
-
-  .. tab:: Manually
-
-    - Create a new migration
-
-      .. code-block:: bash
-
-        hasura migrate create <name-of-migration>
-
-    - Add SQL manually to the ``up.sql`` and ``down.sql`` files in the newly
-      created migration's directory in ``/migrations``
-    - Edit the corresponding metadata manually in ``/metadata``
-
-Managing migrations
--------------------
-
-For maintaining a clean set of migrations with the possibility to move between
-different checkpoints in your project's state it is recommended to clean
-up intermediate DB migration files and to version control the Hasura project.
-
-Squash migrations
-^^^^^^^^^^^^^^^^^
-
-Typically while adding a feature a lot of incremental migration files get
-created for each of the small tasks that you did to achieve the feature.
-
-Once you are confident about the final state of a feature, you can use the
-``migrate squash`` command to make a single DB migration file containing all
-the intermediate steps required to reach the final state.
-
-.. code-block:: bash
-
-  hasura migrate squash --name "<feature-name>" --from <migration-version>
-
-  # mark the squashed migration as applied on this server
-  hasura migrate apply --version "<squash-migration-version>" --skip-execution
-
-Add checkpoints
-^^^^^^^^^^^^^^^
-
-As your metadata is exported on every change you make to the schema, once a final
-state for a feature is reached you should mark it as a checkpoint via version
-control so that you can get back the metadata at that point.
-
-.. code-block:: bash
-
-  git commit -m "<feature-name>"
-
-Applying migrations
--------------------
-
-- Get the Hasura project with the ``migrations`` and ``metadata`` directories.
-
-- Apply DB migration files and metadata snapshot
-
-  .. code-block:: bash
-
-    hasura migrate apply --endpoint <server-endpoint>
-    hasura metadata apply --endpoint <server-endpoint>
-
-Your Hasura server should be up and running!
-
-Checking migrations status
---------------------------
-
-The following command will print out each migration version present in the ``migrations``
-directory along with its name, source status and database status.
-
-.. code-block:: bash
-
-   # in project dir
-   hasura migrate status
-
-For example,
-
-.. code-block:: bash
-
-   $ hasura migrate status
-   VERSION        NAME                           SOURCE STATUS  DATABASE STATUS
-   1590493510167  init                           Present        Present
-   1590497881360  create_table_public_address    Present        Present
-
-Such a migration status indicates that there are 2 migration versions in the
-local directory and both of them are applied on the database.
-
-If ``SOURCE STATUS`` indicates ``Not Present``, it means that the migration
-version is present on the server, but not on the current user's local directory.
-This typically happens if multiple people are collaborating on a project and one
-of the collaborators forgot to pull the latest changes which included the latest
-migration files, or another collaborator forgot to push the latest migration
-files that were applied on the database. Syncing of the files would fix the
-issue.
-
-If ``DATABASE STATUS`` indicates ``Not Present``, it denotes that there are new
-migration versions in the local directory which are not applied on the database
-yet. Executing ``hasura migrate apply`` will resolve this.

docs/graphql/core/migrations/index.rst

@@ -46,6 +46,11 @@ DB schema.
 DB migration files can be generated incrementally and can by applied in parts to
 reach particular checkpoints. They can be used to roll-back the DB schema as well.
 
+.. note::
+
+  You can manage database migrations using external tools like knex, TypeORM, Django/Rails migrations, etc.
+  as well.
+
 Hasura metadata files
 ^^^^^^^^^^^^^^^^^^^^^
 
@@ -55,10 +60,13 @@ in the snapshot.
 
 Hasura metadata can be exported and imported as a whole.
 
+.. note::
+
+
 Setting up migrations
 ---------------------
 
-See :ref:`migrations_basics`.
+See :ref:`migrations_setup`.
 
 
 Advanced use cases
@@ -80,7 +88,6 @@ Reference documentation
   :maxdepth: 1
   :hidden:
 
-  Basics <basics>
   Setting up migrations <migrations-setup>
   Managing metadata <manage-metadata>
   Advanced use cases <advanced/index>

docs/graphql/core/migrations/reference/how-it-works.rst

@@ -12,6 +12,9 @@ How Hasura migrations work
   :depth: 1
   :local:
 
+Introduction
+------------
+
 This is an explanation on how the Hasura migration system works. To understand how
 to use the system, refer to :ref:`Migrations & Metadata <migrations>`.