Philipp Auersperg wrote:

I have two questons concerning ZODB:

1. Since ZODB does not overwrite objects on change one can get the older versions when undoing the changes. My question now: how can I access older versions of objects without undoing? transactions? (I had a short glance at the ZODB classes, but found nothing)

In Zope 2.2, objects that expose a "history" tab (e.g. DTML Methods) can be reverted to one of their historical revisions. You may want to look at how these objects implement this feature if you'd like to create your own historying objects.

2.Is it possible ( or will be ) to define ZODB objects for which updates are done by overwriting and not appending to the object database

Not with FileStorage... it would be possible to do so with a relational storage or with another kind of storage like BerkeleyStorage.

- That is an important issue for objects that are subject to frequent and simple changes. For example Webcounters or Advertising banners that count the clicks. Solutions to write these changes into external files (like FSCounter) are not more than emergency solutions for me.

For right now, the only way to get the behavior you want is to use a nonundoing storage. In the future, the default Zope storage will probably not be FileStorage. Instead, it will probably be something more flexible that doesn't require an all-appends strategy to maintain transactional integrity (or at least one that abstracts this behavior out). With a (as-yet-mythical) next-generation storage, there will be a more granular way to indicate that you'd like an object to overwrite a previous historical revision.

Hello Philipp!

1. Since ZODB does not overwrite objects on change one can get the older versions when undoing the changes. My question now: how can I access older versions of objects without undoing transactions? (I had a short glance at the ZODB classes, but found nothing)

The code for the History functionality is in History.py, which is located in the .../lib/python/OFS directory of a Zope 2.2.x installation. It is currently used by DTMLDocument .py and DTMLMethod.py (both also in OFS) and implements the history tab functionality for the management interface. As the actual implementation is plain simple (import History, add "History.Historical" to the class definitions and "+History.Historical.manage_options" to the manage_options), I patched my Image.py, which defines the classes for images and files, accordingly. The only thing that won't work right "out of the box" is the "Compare" option - you'd have to implement document-specific comparison code. I don't know if it is that easy to do the same patch with ZClasses, but it might be worth a try (I guess patching the necessary base classes should work). As you can script everything in the management interface, this patch makes all your file/image objects' old versions accessible, including date of change and id of the person who changed. I think it would also be possible to look at what History.py is doing and implement the functionality you need without the "overhead" of patching the object classes. I didn't check in detail, but all you need seems to be there (or should be found in some ZODB documentation). Regards Joachim. ---------------------------------------- Content-Type: text/html; name="unnamed" Content-Transfer-Encoding: 7bit Content-Description: ---------------------------------------- -- Iuveno - Smart Communication Joachim Werner _________________________________________ Marie-Curie-Straße 6 85055 Ingolstadt Tel.: +49 841/90 14-325 (Fax -322) Mobil: +49 179/39 60 327 E-Mail: joachim.werner@iuveno.de/joachim.werner@iuveno-net.de WWW: www.iuveno.de/www.iuveno-net.de