Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

deploy: add support for managing SQL views #33

Draft
wants to merge 1 commit into
base: baseline/master
Choose a base branch
from
Draft

deploy: add support for managing SQL views #33

wants to merge 1 commit into from

Commits on Jul 10, 2020

  1. deploy: add support for managing SQL views 

    This commit takes a stab at implementing support for managing SQL views
with rex.deploy.

The example usage:

```
- view: persons
  definition: |
    select name, email
    from user

- view: persons
  definition: |
    select name, email
    from user
    union
    select name, email
    from patient

- view: persons
  present: false
```

I've been trying to follow the code for tables but of course making this
specific to the views.

Some notes/design questions appeared:

- How things are introspected has changed, previously both tables and
  views were loaded as TableImage objects. Now we load views as
  ViewImage objects and we DON'T load view columns. I suspect this will
  make a different when querying views with HTSQL?

- When building a model out of facts we need to check for name clashes
  between tables and views as they share the same namespace in the
  database.

- Should we raise an error in case the same named view appears with
  different definitions? Or should we instead override the former with
  the latter (dangerous)?

- Right now we load view definition with `pg_get_viewdef` function but
  I'm not sure if it is suitable for comparison with view definition in
  facts as db can probably mangle the original SQL. We should probably
  store view definition in a COMMENT in a database.

- Do we need to support view defined with HTSQL? That would be cool.

- Would be nice to be able to specify a pk for a view (required for
  HTSQL to query such view).

- We need to track dependencies:

  As we use SQL for view definitions we might need to use SQL parser for
  that. I'm thinking of using https://pglast.readthedocs.io/en/latest/
  which wraps PostgreSQL's parser.

  If we want to add HTSQL based view then we can use HTSQL to infer the
  dependencies.

  - view -> table, why?

    - So we can require to drop view before we drop the table. It is
      implemented for linked tables? Would be nice as it will allow to
      validate migrations w/o accessing a database.

  - view -> view, why?

    - so we can require to drop dependent views before we drop the
      view

    - so we can change definition of a view with dependents (in this
      case we need to drop and re-create a view and its dependents)
    @andreypopp
    andreypopp committed Jul 10, 2020
    Configuration menu
    Copy the full SHA
    07eb371 View commit details
    Browse the repository at this point in the history