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.

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

Some details #1

Open
marcua opened this issue Jun 18, 2018 · 1 comment
Open

Some details #1

marcua opened this issue Jun 18, 2018 · 1 comment

Comments

@marcua
Copy link
Member

marcua commented Jun 18, 2018

Problems

  • Because we hard-code view names, we can't have multiple environments (e.g., dev/production)
  • Because there's no notion of view dependencies, when we change a view's schema, we have to manually drop views and recreate the dependency chain.
  • Our view materializer similarly runs into these issues.

Solution: Room with a View, an open source package for managing (Redshift) views

  • Any view/function/anything you can write in SQL can be preceded with a SQL comment of the form --export thing_name.
  • If you want to use an exported thing in another file, you can say --from path/to/some/file.sql import exported_name

Example of how the package can get used

  • room_with_a_view.py --environment staging --connection conection1 sync viewname -> creates the necessary views and functions that viewname depends on (including any other view that would have been dropped due to the cascading drop of the view to support schema changes)
  • Alternative sync examples: room_with_a_view.py --environment staging --connection conection1 sync_all or room_with_a_view.py --environment staging --connection conection1 sync_file filename.sql
  • room_with_a_view.py --environment staging --connection conection1 [drop viewname|drop_all|drop_file filename.sql]
  • room_with_a_view.py --environment staging --connection conection1 materialize viewname would create viewname
  • room_with_a_view.py --environment staging --connection conection1 list would list all known exported symbols and the comment around them

Other things

  • We might have to say export function or export view so we know how to drop it (DROP FUNCTION vs DROP VIEW)

Example settings.yaml file

connections:
  connection1:
    hostname: hostname
    port: 5432
environments:
  production:
    postfix: ""
  staging:
    postfix: _staging
@thisisdhaas
Copy link
Member

I took at stab at this in #2. It uses regexes to automatically parse CREATE VIEW and CREATE FUNCTION statements and automatically builds the dependency graph by looking for other view and function names in the body of the statements.

It doesn't support namespacing or materialization, both of which are nontrivial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants