The best forums to get answers to your questions the Zope and Plone mailing lists (I am cc'ing the main zope list in case anyone else has ideas). The collector is not a discussion forum or a place to discuss application code. "Write-on-read" means that objects are changed when they are viewed. If this happens on nearly every request, then the size of the database will balloon. Since writing to an object is very easy in Zope and can happen in a myriad of ways, you will need to do a bit of debugging to determine where in your application (or a third party add-on) this is happening. This is not debugging Zope, it is debugging your app. -Casey On Wed, 5 May 2004 23:07:32 +0300 Turkia M <turkia@james.hut.fi> wrote:
hello, you are probably right. what I was hoping for was any advice on how to fix the database to a consistent state. we are losing 3 months of work here. i was not expecting to have to debug zope and plone to finish this project and i may not have enough experience to do that, at least not with this timetable.
anyway, i tried to create a new plone instance, copy-paste the data to the new instance and remove the mentioned products and the old instance. at first the db size returned to normal. however none of the users in plone object's acl_users could log in anymore. and after running a script that was intended to fix owner attributes of objects in member directories the db exploded again and it didn't fix the login problem. i'll include the script if it helps any. btw. using recursive=1 somehow froze the whole system. i didn't really understand what the "writes occur for read requests" means. i recall CMFBibliography gave some error on read-only attributes but i don't have that information anymore. thanks, mika
from Products.PythonScripts.standard import html_quote request = container.REQUEST RESPONSE = request.RESPONSE
import string Members = context.Members r=[] for i in Members.objectIds(): try: u = container.portal_membership.getMemberById(i); m = getattr (Members, i) except: pass else: if u is not None: context.plone_utils.changeOwnershipOf(m, i, recursive=0) r.append(i + " changed") else: r.append(i + " not changed") return string.join (r,'\n')
On Wed, 5 May 2004, Collector: Zope Bugs, Features, and Patches ... wrote:
Issue #1314 Update (Reject) "ZODB size explosion" Status Rejected, Database/bug critical To followup, visit: http://zope.org/Collectors/Zope/1314
============================================================== = Reject - Entry #2 by Caseman on May 5, 2004 9:58 am
Status: Pending => Rejected
It is highly unlikely that this is a Zope bug. Given your description it is almost certainly due to one of the products you mentioned or your application's use of them. These types of problems are common in applications where database writes occur for read requests (which is generally a bad idea).
Suggestion: Perform various read requests in your application, and check your undo log. If it contains entries for these requests, look to see where the database write is occuring.
I am rejecting this bug because I do not see evidence that the cause is Zope itself and not application or other third party code. If you can find further evidence to the contrary, feel free to reopen this issue.________________________________________ = Request - Entry #1 by mtz on May 5, 2004 2:19 am
Uploaded: "analyze_py_output" - http://zope.org/Collectors/Zope/1314/analyze_py_output/view A strange problem where database size was originally about 6MB but after installing I18NLayer (first release 0.5.5, then CVS) and CMFBibliography (CVS HEAD) the db suddenly grew up to 300 MB. Packing returned it to about 35MB, but growth rate was not fixed, and trivial changes double or triple the size. Problem seems to be related to OOBTree.OOBucket and_IOBTree.IOBucket taking most of the space (see below).
==============================================================