On Monday 20 July 2015 12:42:47 Federico Capoano wrote: > > Just a final note: I think this solution is not the optimal one
I agree. The optimal solution would be for us to be able to define a test database with unlogged tables and all the data-integrity-sync options off, while the "production" database (production in quotes because it applies also to the main development database) keeps sane settings. Since PostgreSQL defines most of these at the cluster level, this would require setting up a separate cluster for testing (Debian makes this easy with its pg_createcluster command, but on other systems it would be more involved). But on the Django side, this requires the ability to specify accessing a different cluster (that is, usually, separate ports on the machine) for testing. We currently do not have this ability. The only danger I see in this is a "slippery slope" -- next thing, people will want a separate engine for testing, and before we know it, all testing will be run only against Sqlite. I don't think this fear is justified. Are there good reasons to avoid giving users more control over their test databases? Shai.
