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 commits,
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 :-(

ditto.

I'm guessing the savepoint speed is going to be dictated by the underlying storage?

I doubt it,

Which storage is your comment based on?

FileStorage, ClientStorage, DemoStorage.

Savepoints write their data to temporary files.

Jim

--
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
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to