(sorry if some of this is Zope 2 - ish, the thread kinda started here
and the underlying bits of this are certainly relevant to Zope 3)
As you may have guessed by the flurry of mails today, I've been
refactoring a 2000 test suite to use layers.
I was hoping to use savepoints to speed things up...
Each layer drops a savepoint in setUp and then rolls it back it in
tearDown. Likewise, the TestCase's setUp would drop a savepoint and the
tearDown would roll back to it.
Sounds great, no?
Well, no, actually:
1. Usual problems of some datamanagers not supporting savepoints.
MaildropHost and some of the project's own products datamanagers do.
mxODBC does not :-/
2. dropping savepoints is slow. Figuring this might be due to saving
data from the layer each time transaction.savepoint() is called, I
thought of getting round this by dropping a savepoint at the end of the
layer's setUp method. This did make thing a litte better, but:
3. savepoints are really slow :-(
What's the usecase for savepoints? I would have thought this kind of
thing would be ideal, but they seem really slow...
For example, the above test suite takes about 300s to run prior to
Using savepoints in place of transaction.commit()'s meant it took over
So I'm left what the actual use for savepoints is and if they could be
made any faster?
Simplistix - Content Management, Zope & Python Consulting
Zope3-dev mailing list