Chris Withers wrote:
(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.
This is a risky approach. If you have any software that does actual commits,
you'll be hosed. I suggest using demo storages instead. Demo storages will
also be faster.
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 :-/
Well, they are going to make any approach like this difficult. That's why
I avoid them.
2. dropping savepoints is slow.
That hasn't been my experience.
> 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?
See Gary's response.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list