durusmail: durus-users: Does durus support rollbacks?
Does durus support rollbacks?
2007-04-27
2007-04-27
2007-04-27
2007-04-28
2007-04-28
2007-04-28
Does durus support rollbacks?
Terry Hancock
2007-04-28
David Binger wrote:
> On Apr 27, 2007, at 3:24 PM, Terry Hancock wrote:
>> David Binger wrote:
>>> I think you are talking about the ZODB feature called versioning,
>>> which I understand to be deprecated and faulty (but nevertheless
>>> cool to see working in a Zope application).
>>
>> I don't think so. I just want a simple 'undo'/'redo'.
>
> Are you saying that there is an undo feature in ZODB that is not
> called "versioning" in ZODB, or that I am mistaken about the
> deprecation of versioning.   I can't tell what you mean here.

Could just be ignorance on my part. :-)

I was under the impression that "versioning" included all kinds of
extras like branching, not just the ability to "turn back the clock",
which is all I need for PUB. I've only ever used ZODB via Zope (2.7),
which provides a simple "undo" reversion mechanism.

I do know that Zope had some kind of versioning system that allowed for
multiple co-existing versions of a Zope site, and that that system was
deprecated (apparently it was buggy? I never used it anyway). I just
assumed this was the same thing you were talking about (or a direct
consequence of it).

> Maybe you could just save the length of the file at that time.
> A rollback would just require truncating the file to that point
> and starting with a new connection.  (No packing allowed, though).
> The old "Storage" would be unusable because the offset index
> would no longer work correctly.

Sounds very simple to me, I like it!

So this means that (aside from packing) that Durus always appends rather
than writing into the middle of the storage file? That's a nice property.

(It's probably obvious that I haven't paid much attention to the
internals of Durus -- that's kind of the point of using it, though ;-) ).

> If you can afford to make a new Connection with a truncated file,  that
> would
> be easiest.

Yep, that's not hard. I've already decided to have a "Session" object
that manages the database, so that I have some separation from the
underlying mechanics, and also because I probably need some
non-persistent global state as well. So the Session is the only thing
that actually knows about the connection anyway.

I suppose if I go multi-user, I'll have to put all that into a server,
but I'm not even thinking about crossing that bridge just yet. Even
Durus is almost too much sophistication for PUB, really -- but shelve is
a little too simple, so I think Durus will be the right choice.

Thanks a lot for all your help, I think I'm good to go!

Cheers,
Terry

--
Terry Hancock (hancock@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

reply