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
Roman Milner wrote:
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?
You could use a ZODB storage that doesn't support undo's like BerkelyDB. Or change your structure so that each albums is a persistent object as opposed the entire set of them and then just store them in various (nested if nesc) object managers.
Roman Milner wrote:
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.
The way I'm reading this, you have this entire database of albums and tracks as a sinle object in your ZODB. Don't do that. Refactor your product to use subobjects of your Jukebox object as albums, and subobjects of those as tracks. Then, only a small amount of data gets rewritten on each transaction. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
participants (3)
-
Kapil Thangavelu -
Roman Milner -
Steve Alexander