Oo. That's bad. There is no way to selectively make something persistent but non-historying using FileStorage. I would suggest possibly using dbmStorage (or its brother BerkeleyStorage) to store this big data structure, as it does not perform undo. You might be successful using these storages in conjunction with the "mountable storage" option, whereby you can "mount" additional storages into your folder structure. Perhaps use FileStorage for "normal" operations but place the product's instances into the "mounted" section of your site (backed by dbmStorage or BerkeleyStorage, where it won't be historied). I've never used mounted storages, so I can't explain how it's done, but I'm sure other folks here can. Mounted storages fall down with versions (do not use versions in conjunction with mounted storages, it will do bad things to you).
-----Original Message----- From: Roman Milner [mailto:roman@speeder.org] Sent: Tuesday, August 29, 2000 11:29 PM To: zope@zope.org Subject: [Zope] how to keep stuff out of undo
Hi. We have a product (an mp3 jukebox) that uses the ZODB to store a large data structure of all the albums and track names. Many people are allowed to add/remove albums from the database. The problem is, when they do this the entire data structure is backed up for undo. So, by the end of each day, our ZODB has grown so large we are out of disk space.
Is is possible make something presistent but keep it from being backed up when it is changed?
Thanks, ^Roman
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Chris McDonough wrote:
Mounted storages fall down with versions (do not use versions in conjunction with mounted storages, it will do bad things to you).
Is it just me or are versions not exactly the most robust things around? (I'm thinking external methods here, and ftp access into a version, amongst others ;-) cheers, Chris
participants (2)
-
Chris McDonough -
Chris Withers