Actually, we have two different versions (current and beta) of the software,
working against the same ZODB. We are just developing new features
on top of the beta version.
Fearing that it was due to some changes done by a programmer
we have disabled the "beta version" but the growing of the DB is still
there...and since our last email we've got 5GB more (71GB now) .... We
are a bit worried
since the disk space is 102GB and the application is widely used here
at CERN and
for outsiders too.
So, up-to-now we are afraid that it is not a problem with any
modifications in the code....and
no clue about it.
We are trying to pack to see the difference with the data.fs file.
Jim, I am still running your script "class_stats.py".....and it seems it
is going to take a while yet....
Thank you so much for your help. More ideas appreciated!
Alan Runyan wrote:
>> I'd just like to add that there's some changes that can be related to this:
>> - we had some classes inheriting from Persistent that now inherit from
>> something else as well (but no extra arguments are being added, AFAIK);
>> - we added some zope.interface definitions to some Persistent classes;
>> maybe this causes some kind of behavior that we were not aware of?
> I doubt it. Thousnads of people are doing this and do not report the same
> What is more likely is that a programmer is changing a persistent object
> very often. One of the downsides of the ZODB is that it is so transparent
> it is possible to unwillingly make database changes.
> A design pattern for RDBMS is to have 2 pools. READ pool and WRITE pool.
> Often the READ pool comes from some replica and WRITE is to the master.
> I'm unsure this pattern would work for ZODB. I know Malthe was thinking
> about this but unsure if he had anything concrete.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org