On 23/05/13 14:18, Anze Staric wrote:
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?
Well you might just be able to run the original reset_db and then do the
upgrade. I prefer the idea of rolling back to the state from before the
test rather than an explicit reset though. I mean, I know we want it in
the initial state but we have already done the work of figuring out what
that state is in the first upgrade. This relies on all relevant
tearDowns taking part but there may be other advantages.
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).
I'm not sure that I agree yet but I think we are closer to understanding
what is going on at least! I'm not proposing that we revert your change
when there is other more important stuff to do but we might want to
consider this again later.
Cheers,
Gary
