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

Support Redshift #7

Open
gmcguire opened this issue Jun 20, 2014 · 3 comments
Open

Support Redshift #7

gmcguire opened this issue Jun 20, 2014 · 3 comments

Comments

@gmcguire
Copy link

Loving this tool for our Postgres 9.x ecosystem. We are beginning to roll out a multi-schema Redshift data warehouse, and I'm investigating this for adaptation. Looks like for our use case there are two major issues/enhancements needed:

  1. Remove requirement for PL/pgSQL. (Redshift doesn't support it or any user defined functions.) Aside from the bootstrap s-e-o data model I don't see it in use.
  2. Support multiple schemas. We are using Postgres schemas for multi-tenancy and would need to apply changes across one or all schemas in a database.

I can work on these if it's something you are interested in, but wanted your input first. Thanks!

@mbryzek
Copy link
Owner

mbryzek commented Jun 20, 2014

Thanks! Would love to have this work for redshift.

1: Agreed - let me think of best way to do this, but probably will just remove the script entirely from sem (it's orthogonal to management of scripts and can easily be its own script). Only wrinkle is getting sem to bootstrap itself - and rewriting that from pl/pgsql to probably a set of ruby scripts. If you already have a patch or want to write one - that would be great!

  1. interesting - do you think this should be an intrinsic feature of sem or of a script outside of sem that just runs sem-apply multiple times?

@gmcguire
Copy link
Author

@mbryzek I don't have any patches yet, but would be happy to write some. I don't know any ruby, but can learn.

For the multi-schema support I think it would be best as a feature of sem, because the scripts data model will (probably?) need an additional schema column to reflect the schema that was patched. I was thinking it could be null by default to keep the existing schema-less behavior, but the unique constraint could be changed to include (schema, filename). If you specified a command-line list of one or more schemas you'd just loop over them, populating the schema column of the scripts table as you go. Otherwise you just use the default behavior of current schema and insert NULL for the schema.

@khy
Copy link

khy commented Dec 15, 2015

So, I ran into the same issues when attempting to use with Redshift. To workaround, I did the following manually, which has worked so far:

dw=# create schema schema_evolution_manager;
CREATE SCHEMA
dw=# create table schema_evolution_manager.scripts (
dw(#   id           bigint identity not null primary key,
dw(#   filename     varchar(100) not null unique,
dw(#   created_at   timestamp default getdate() not null
dw(# );
CREATE TABLE
dw=# create table schema_evolution_manager.bootstrap_scripts (
dw(#   id           bigint identity not null primary key,
dw(#   filename     varchar(100) not null unique,
dw(#   created_at   timestamp default getdate() not null
dw(# );
CREATE TABLE
dw=# insert into schema_evolution_manager.bootstrap_scripts (filename) values ('20130318-105434.sql');
INSERT 0 1
dw=# insert into schema_evolution_manager.bootstrap_scripts (filename) values ('20130318-105456.sql');
INSERT 0 1

Notes:

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

3 participants