Massive unit test vs MySQL

[Richard Wesley]

In article <hawkfish-7B21B7.09501410092003 at spectator.sj.sys.us.xo.net>,
 Richard Wesley <hawkfish at trustedmedianetworks.com> wrote:

> In article <bjkdoa$3ea$1 at nntp0.reith.bbc.co.uk>,
>  Neil Padgen <neil.padgen at mon.bbc.co.uk> wrote:
> 
> > On Monday 08 September 2003 22:28, Richard Wesley wrote:
> > 
> > > In article <bji5h7$bqo$1 at nntp0.reith.bbc.co.uk>,
> > >  Neil Padgen <neil.padgen at mon.bbc.co.uk> wrote:
> > > 
> > 
> > > I doubt it - it is generated by mysqldump.  And there is no problem
> > > from the command line.
> > > 
> > 
> > I use exactly the same approach to set up my unit tests, but I have a
> > different way to get the mysqldump data into the database:
> > 
> > os.system('mysql database_name < dumpfile')
> 
> Sadly, this did not work, nor did garbage collection (gc.collect()).
> 
> For some reason, mysql is holding onto a whole lot of connections from 
> my script until the script terminates.

OK, I'm an idiot.  It had nothing to do with the reload script.  The 
connections were from the TestCase subclass I have that instantiates a 
connection management object.  It appears that the unittest module does 
not dispose of the objects it instantiates until the end of the run, so 
you need to REALLY clean up in the tearDown method.  I discovered this 
by making a persistent connection for the reload operation and noticing 
that the number of connections still increased.

Thanks to all who responded.

-- 
Best regards,

Richard Wesley
Co-President, Electric Fish, Inc.
<http://www.electricfish.com/>
(v) +1-206-493-1690x210
(f) +1-206-493-1697
(h) +1-206-632-4536
(m) +1-206-409-4536