On Thu, May 23, 2013 at 2:25 PM, Gary Martin <[email protected]> wrote: > Apart from this kind of case, I was also thinking that it might be better to > get the reset_db method overridden so that it resets the database back to > the clean form that we want.
I like the idea, but how to we get the database to a clean state after it has been migrated to multiproduct in setUp? Do we hard code which fields and tables need to be removed and which keys do need to be modified? I still think that forcing the trac to use a separate database for separate environments is a cleaner solution. An alternative to monkey patching ConnectionPool is to modify EnvironmentStub to use DatabaseManager that creates one connection to database per product (if we are using in memory database).
