2020-01-14 15:57:45 +03:00
|
|
|
|
.. meta::
|
|
|
|
|
:description: Customise the Hasura GraphQL schema with views
|
|
|
|
|
:keywords: hasura, docs, schema, view
|
|
|
|
|
|
2019-12-26 15:05:37 +03:00
|
|
|
|
.. _custom_views:
|
|
|
|
|
|
2018-09-11 14:11:24 +03:00
|
|
|
|
Customise schema with views
|
|
|
|
|
===========================
|
|
|
|
|
|
2018-12-03 15:12:24 +03:00
|
|
|
|
.. contents:: Table of contents
|
|
|
|
|
:backlinks: none
|
2019-12-26 15:05:37 +03:00
|
|
|
|
:depth: 2
|
2018-12-03 15:12:24 +03:00
|
|
|
|
:local:
|
|
|
|
|
|
|
|
|
|
|
2019-12-26 15:05:37 +03:00
|
|
|
|
What are views?
|
|
|
|
|
---------------
|
2018-09-11 14:11:24 +03:00
|
|
|
|
|
2019-12-26 15:05:37 +03:00
|
|
|
|
`Views <https://www.postgresql.org/docs/current/sql-createview.html>`_ can be used to expose the results of a custom
|
|
|
|
|
query as a virtual table. Views are not persisted physically i.e. the query defining a view is executed whenever
|
|
|
|
|
data is requested from the view.
|
2018-09-11 14:11:24 +03:00
|
|
|
|
|
2019-12-26 15:05:37 +03:00
|
|
|
|
Hasura GraphQL engine lets you expose views over the GraphQL API to allow querying them using both ``queries`` and
|
|
|
|
|
``subscriptions`` just like regular tables.
|
2018-09-11 14:11:24 +03:00
|
|
|
|
|
2019-12-26 15:05:37 +03:00
|
|
|
|
.. _create_views:
|
2018-09-11 14:11:24 +03:00
|
|
|
|
|
2019-12-26 15:05:37 +03:00
|
|
|
|
Creating & exposing views
|
|
|
|
|
-------------------------
|
2018-12-03 15:12:24 +03:00
|
|
|
|
|
|
|
|
|
Views can be created using SQL which can be run in the Hasura console:
|
|
|
|
|
|
|
|
|
|
- Head to the ``Data -> SQL`` section of the Hasura console
|
2019-03-13 13:04:40 +03:00
|
|
|
|
- Enter your `create view SQL statement <https://www.postgresql.org/docs/current/static/sql-createview.html>`__
|
2019-01-25 06:31:54 +03:00
|
|
|
|
- Select the ``Track this`` checkbox to expose the new view over the GraphQL API
|
2018-12-03 15:12:24 +03:00
|
|
|
|
- Hit the ``Run`` button
|
|
|
|
|
|
2019-12-26 15:05:37 +03:00
|
|
|
|
Use cases
|
|
|
|
|
---------
|
|
|
|
|
|
|
|
|
|
Views are ideal solutions for retrieving some derived data based on some custom business logic. If your custom logic
|
|
|
|
|
requires any user input, you should use :ref:`custom SQL functions <custom_sql_functions>` instead.
|
|
|
|
|
|
|
|
|
|
Let's see a few example use cases for views:
|
|
|
|
|
|
|
|
|
|
Example: Group by and then aggregate
|
|
|
|
|
************************************
|
|
|
|
|
|
|
|
|
|
Let’s see how to fetch the average article rating for each author in our author/article schema.
|
|
|
|
|
|
|
|
|
|
A view that averages the rating of articles for each author can be created using the following SQL query:
|
|
|
|
|
|
|
|
|
|
.. code-block:: SQL
|
|
|
|
|
|
|
|
|
|
CREATE VIEW author_average_rating AS
|
|
|
|
|
SELECT author_id, avg(rating)
|
|
|
|
|
FROM article
|
|
|
|
|
GROUP BY author_id
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example: Hide certain fields of a table
|
|
|
|
|
***************************************
|
|
|
|
|
|
|
|
|
|
Say, we have some sensitive information in a table which we wouldn't want to expose. We can create a view that only
|
|
|
|
|
exposes the non-sensitive fields.
|
|
|
|
|
|
|
|
|
|
Let's say our ``author`` table has the fields ``id, name, city, email, phone, address`` and we want to hide the ``email``,
|
|
|
|
|
``phone`` and ``address`` fields. We can create the following view to achieve this:
|
2018-12-03 15:12:24 +03:00
|
|
|
|
|
2019-12-26 15:05:37 +03:00
|
|
|
|
.. code-block:: SQL
|
2018-09-11 14:11:24 +03:00
|
|
|
|
|
2019-12-26 15:05:37 +03:00
|
|
|
|
CREATE VIEW author_public AS
|
|
|
|
|
SELECT id, name, city
|
|
|
|
|
FROM author
|