mirror of
https://github.com/hasura/graphql-engine.git
synced 2024-12-15 17:31:56 +03:00
Merge branch 'master' into 512
This commit is contained in:
Phil Freeman
GitHub
commit
4124497257
@ -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
|
||||
|
||||
@ -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
|
||||
:ref:`deployment_docker`.
|
||||
|
||||
quickly. For more detailed instructions on deploying using Docker with an
|
||||
external database, check out :ref:`deployment_docker`.
|
||||
|
||||
@ -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``
|
||||
|
||||
@ -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
|
||||
---------------
|
||||
|
||||
@ -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>`
|
||||
|
||||
@ -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.
|
||||
@ -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>
|
||||
|
||||
@ -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>`.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user