Closed GavinRay97 closed 4 years ago
This is not part of the database URL but an option which needs to be passed to the migra.Migration
constructor. I added a schema
option which you can now use:
[database]
url = "postgresql://postgres:mypassword@localhost:5432/mydatabase"
schema = "public"
...or...
[database]
user = "postgres"
password = "mypassword"
host = "localhost"
port = "5432"
dbname = "mydatabase"
schema = "public"
I just release tusker 0.2.2 on PyPI which supports the database.schema
option.
I was planning to add a [migra]
config group in the future for more feature flags specific to the underlying migra tool. So maybe this option will need to be moved. For the time being it doesn't feel completely off in the [database]
group.
@bikeshedder Thank you! :pray:
I also get the error TypeError: you can't specify both 'database' and 'dbname' arguments
when running tusker diff database schema
tusker.toml
[schema]
filename = "schema.sql"
[migrations]
directory = "migrations"
[database]
url = "postgresql://marius:m@localhost:5432/db"
schema = "public"
I'd like to get schema.sql from current db, then run a diff from schema,sql to another db.
Thanks
That error message is highly misleading. It seams that this is a psycopg2
bug.
Using a dsn
together with dbname
causes this error.
I'm preparing a tusker 0.3.3
release right now which works around that issue so you can use database.url
and database.schema
together. With tusker 0.3.2
you need to split the URL into the separate config fields: database.host
, database.port
, etc.
I just released tusker 0.3.3
which fixes this problem: https://pypi.org/project/tusker/0.3.3/
Currently if you run
tusker diff database schema
, it will suggest dropping other schemas.For example, if you have some schemas which are autogenerated by tools, let's call it
internal
, the migration will containDROP
statements for all the tables in theinternal
schema if you only have a SQL schema file with tables forpublic
.Unfortunately this makes it unusable without manually picking through the results =/
Proposed solution:
Normally you could skirt this manually through passing search path in connection params, but I think the
psycopg2
config is set up in a way that conflicts with this: