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

Drop Db doesn't (can't) work if connected to the db you want to drop #3

Open
vertiman opened this issue Jan 4, 2016 · 6 comments
Open

Comments

@vertiman
Copy link

vertiman commented Jan 4, 2016

The Drop DB command doesn't work if you're trying to drop the database which you're connected to. You can get around this by creating another environment that connects to the template1 or postgres database, and then drop the one you want.

I can't think of an intelligent way to bake this behaviour into the driver so we don't need to use a workaround, any ideas? If you have an implementation idea I'm happy to take a stab at implementing it.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@wzrdtales
Copy link
Member

Hum, ic. This is problematic indeed, quick thought, if it is not possible to delete the db you're connected to. I assume it is also not possible to delete a db as long as at least one 1 connection is open to it?

@vertiman
Copy link
Author

vertiman commented Jan 4, 2016

Yeah, although I think you can issue commands to drop others connections. Are you thinking establish a separate connection inside the dropDatabase on a different database? Are all the connection parameters (login, password, host) available in that scope?

@wzrdtales
Copy link
Member

Ok, I take a few minutes of my time now for a quick write up:

Since postgres is always only connected to one db per connection and it is not possible to switch (I already stumbled this when I implemented the scopes a while ago) dbs and now it opens that it is also not possible to delete dbs.

What I can think of is:
Open up a "maintenance" connection on the driver and connect to the default db to execute this kinds of queries. This connection gets either opened on demand and closed instantly after the action has taken place or is opened on the driver creation.
From the point that it is currently not implemented as a feature to switch the database when using scopes see https://github.com/db-migrate/pg/blob/master/index.js#L105-L121 and http://db-migrate.readthedocs.org/en/latest/Getting%20Started/the%20commands/#scope-configuration, it might be from interest to look at the possibility of creating new connections and disposing old ones, or replacing them, on the pg driver level.

@wzrdtales
Copy link
Member

yes they are, they get passed as config object here https://github.com/db-migrate/pg/blob/master/index.js#L486

@vertiman
Copy link
Author

vertiman commented Jan 4, 2016

Ok I'll fiddle with this over the next few days. Need to work on something else first. Thanks for the idea, it will probably work. From a usage perspective, can you do a db:drop at the same time as any other command? I don't think so, right? So we don't have to worry about someone polluting the "main" connection, if I manage to programatically kill it?

@wzrdtales
Copy link
Member

It would be possible, but I do not see a reason why one would execute a drop action in another instance of db-migrate while migrating something.

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

No branches or pull requests

2 participants