> John Rouillard added the comment:
> 
>>On the one hand, it
>>is better to be able to permanently disable database creation. On the
>>other hand, the ability to temporarily disable this feature may also be
>>important, and in my case I could just as easily use a flag.
> 
> I don't like to build too much magic into the code. What do you think
> of Roundup trying to nuke() the db. If it finds that the db exists but
> fails to delete it because of missing permissions it skips the
> delete/create and continues with the rest of the schema setup, data
> load etc.

As I mentioned earlier, creating a database is not usually a feature of
a web application. Of course, Roundup is more than just a web
application, but the first thing people expect from an issue tracking
system is that it can be interacted with using a web interface.

So even if a web application doesn't create the database by default, I
think it's okay. If an application skips database creation if it doesn't
have permissions, that's okay too.

At least this applies to server based databases. I assume that Roundup
inherits the same logic for them as for anydbm and sqlite. But these are
slightly different situations that need to be handled differently.

> The delete error raises psycopg2.errors.InsufficientPrivilege. I don't
> need to parse the exception args/message. One problem is what happens
> if the db isn't empty. I think it will fail trying to create
> tables. So the data will be ok but the error message will point to a
> table creation issue and not an inability to drop/create the db.

I think we can look at what web applications typically do when they
successfully connect to a database. Yes, they are trying to create
tables where they will write data. Some tables may be created by plugins
(if the application uses plugins), so the main application may not know
about them and need not do anything with them.

> It is possible to have other tables in the Roundup db and work with
> them from Roundup using psycodb2 (via the db connection parameter)
> directly. Roundup shouldn't touch those tables. I suppose using the
> schema table we could figure out what tables should exist, but indexes
> and other things would be left around. So actively trying to drop
> tables to clean the db doesn't seem like a good idea.

I completely agree with you.