Re: [ZODB-Dev] blob todos
On Jun 8, 2007, at 1:15 PM, Christian Theune wrote: Hi, Am Freitag, den 08.06.2007, 13:13 -0400 schrieb Jim Fulton: FileStorage doesn't play anything forward on startup. It does throw away partial or uncommitted transactions. I don't see any significant harm in leaving extra blob files around and they would eventually be removed through packing. We do need to take a little extra care in the packing code to deal with this possibility though. So I can just remove this todo? Sure. Although, it would be nice to add a todo inside the pack method, which wants to be refactored, to take the possibility of extra files for uncommitted transactions into account. The current wildly inefficient blob pack algorithm would not have a problem, but likely refactorings would. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] blob todos
On Jun 8, 2007, at 12:36 PM, Christian Theune wrote: Hi, (this goes mostly to Jim) I just noticed that the blob.py has a todo list at the end of it. We shouldn't let it stay there. Here are some comments about the various entries: # To do: # # Production # # - Ensure we detect and replay a failed txn involving blobs forward or # backward at startup. # # Jim: What does this mean? Chris McDonough came up with this, I'm not quite sure. It has something todo how FileStorage recovers when starting up AFAIR. FileStorage doesn't play anything forward on startup. It does throw away partial or uncommitted transactions. I don't see any significant harm in leaving extra blob files around and they would eventually be removed through packing. We do need to take a little extra care in the packing code to deal with this possibility though. # Far future # # More options for blob directory structures (e.g. dirstorages # bushy/chunky/lawn/flat). # # Make the ClientStorage support minimizing the blob # cache. (Idea: LRU principle via mstat access time and a # size-based threshold) currently). I can put those into launchpad as blueprints. +1 # Savepoint support # = # # - A savepoint represents the whole state of the data at a certain point in #time # # - Need special storage for blob savepointing (in the spirit of tmpstorage) # # - What belongs to the state of the data? # #- Data contained in files at that point in time # #- File handles are complex because they might be referred to from various # places. We would have to introduce an abstraction layer to allow # switching them around... # # Simpler solution: : Didn't you (Jim) do this? Yes. Non-optimistic savepoints now work AFAIK. Interestingly, they were mostly implemented already. Good catch wrt this to-do list. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] blob todos
Hi, Am Freitag, den 08.06.2007, 13:13 -0400 schrieb Jim Fulton: FileStorage doesn't play anything forward on startup. It does throw away partial or uncommitted transactions. I don't see any significant harm in leaving extra blob files around and they would eventually be removed through packing. We do need to take a little extra care in the packing code to deal with this possibility though. So I can just remove this todo? # Savepoint support # = # # - A savepoint represents the whole state of the data at a certain point in #time # # - Need special storage for blob savepointing (in the spirit of tmpstorage) # # - What belongs to the state of the data? # #- Data contained in files at that point in time # #- File handles are complex because they might be referred to from various # places. We would have to introduce an abstraction layer to allow # switching them around... # # Simpler solution: : Didn't you (Jim) do this? Yes. Non-optimistic savepoints now work AFAIK. Interestingly, they were mostly implemented already. Ok, then I'll throw that todo away. Good catch wrt this to-do list. Thanks, no problem. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
