Chris Withers wrote:
Jim Fulton wrote:
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
you'll be hosed.
Not sure what you mean by that... The reason I want to use savepoints is
for ease of tearDown...
Yes, but if anything dos an actual commit, your tear down
won't be able to roll it back.
I suggest using demo storages instead. Demo storages will
also be faster.
...I'm already using DemoStorage.
Cool. Then why are you trying to use a savepoint.
You do realize that you can stack demo storages.
Create a demo storage for the layer and test and
toss the database when you're done. Look at the way
zope.app.testing.functional works for an example.
Well, they are going to make any approach like this difficult. That's why
I avoid them.
Still leaves me wondering why they were implemented :-S
They seem ideal for this kind of thing...
I really don't know why relational databases were implemented. I'm not really
the one to ask. ;)
3. savepoints are really slow :-(
I'm guessing the savepoint speed is going to be dictated by the
I doubt it,
Which storage is your comment based on?
FileStorage, ClientStorage, DemoStorage.
Savepoints write their data to temporary files.
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