Chris Withers wrote:
Hi all,

(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 introducing layers.

Using savepoints in place of transaction.commit()'s meant it took over 400s! :-(


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  
Zope Corporation
Zope3-dev mailing list

Reply via email to