Massive unit test vs MySQL
hawkfish at trustedmedianetworks.com
Thu Sep 11 17:44:24 CEST 2003
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.
Co-President, Electric Fish, Inc.
More information about the Python-list