Re: [ZODB-Dev] Python properties on Persistent objects
Mikko Ohtamaa wrote: This isn't right: a z3c.form form is just a view like any other. It is looked up on the context and the request. In Dexterity (which I assume you're using?), that's going to be the content object. Sorry, I think I mixed with zope.formlib. In any case I hope to find the answer to the orignal question. The original pattern which I copied is is here: http://code.google.com/p/getpaid/source/browse/Products.PloneGetPaid/trunk/Products/PloneGetPaid/preferences.py That code is insane. Really insane. It's generating classes and doing custom adapter factories that inject a _v_ variable into a persistent object temporarily. I wouldn't try to copy it at all. I would run away. I *think* what may be happening here is that most of the vocabularies in plone.app.vocabularies have code like this: context = getattr(context, 'context', context) This hack is there to support the IAdding view use case where the context of the add form is another view and the first real content object from which you can acquire stuff is self.context.context. We're moving away from that in favour of not acquiring tools and not using views-on-views, which are evil anyway. Hence, the 'context' property in StoreSettings, which I presume is used as the context for a form, is being cajoled into being the Plone site root. But that's using a hack to trick a hack into doing different hackery. This is getting far off topic for the ZODB list, but if you can explain what problem you're actually trying to solve, I'm sure we can come up with a suggestion that is less of an architecture spacewalk. When you start having to ask the ZODB list, maybe it's time to think whether you could find a simpler solution. :-) I don't think I am doing it incorrectly. The other reason of using this pattern is that the behavior factory does not need to have a write or (an extra) object load if the behavior is never set on the context object. The default object returned by factory acts similar than the persistent object and I can set the behavior defaults using zope.schema - I don't need to do if not set logic anywhere else in my code. There is no reason you can't get this don't-write-unless-necessary behaviour in a much more sane way. In fact, it ought to be the default. To help you, I'd need a more comprehensive understanding of what you're doing and why, though. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Python properties on Persistent objects
That code is insane. Really insane. It's generating classes and doing custom adapter factories that inject a _v_ variable into a persistent object temporarily. I wouldn't try to copy it at all. I would run away. But I thought this was *the* Zope way and the brightest minds in the community have obviously written the code :) In any case, the persistent + property issue has received some awareness until it bits someone's ass again. I am going back to the drawing board and my behaviors. property set = always starts transaction even though nothing is being written -Mikko ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Python properties on Persistent objects
On Wed, Dec 16, 2009 at 7:12 PM, Mikko Ohtamaa mi...@redinnovation.com wrote: I need to have little clarification should properties work on Persistent objects. Properties work with persistent objects with one limitation that I'm aware of. The __setattribute__ method used by the persistent base class assumes that any attribute assignment modifies the object's persistent state. A property that doesn't modify state or that modifies volatile state will fool it. Conceivably, one could override __setattribute__ to handle such properties, but doing so would require great care. I don't recommend it. Jim -- Jim Fulton ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Python properties on Persistent objects
Properties work with persistent objects with one limitation that I'm aware of. The __setattribute__ method used by the persistent base class assumes that any attribute assignment modifies the object's persistent state. A property that doesn't modify state or that modifies volatile state will fool it. Conceivably, one could override __setattribute__ to handle such properties, but doing so would require great care. I don't recommend it. Great, thanks! I already assumed so, but now this little feature is officially confirmed. -Mikko ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] ZODB 3.9/3.8 incompatibility (was Re: Data.fs size grows non-stop)
On Thu, Dec 10, 2009 at 8:12 PM, Marius Gedminas mar...@gedmin.as wrote: On Thu, Dec 10, 2009 at 02:07:06PM -0500, Jim Fulton wrote: On Thu, Dec 10, 2009 at 1:50 PM, Marius Gedminas mar...@gedmin.as wrote: On Thu, Dec 10, 2009 at 12:41:11PM -0500, Jim Fulton wrote: On Thu, Dec 10, 2009 at 11:54 AM, Marius Gedminas mar...@gedmin.as wrote: In 3.9 for FileStorage, if you give a starting tid that is toward the end of the file, it will scan backward, saving a lot of time. Ah, but how can I get a valid tid that is toward the end of the file? I assume that if I give a tid that doesn't exist, I'll get an error -- which is the behavior oldstate() exhibits -- rather than the next existing transaction after that timestamp, or I could fudge by getting the current timestamp and subtracting 24 hours. No, the iterator starts at the first transactions who's tid is = the start tid. So, guess a time and use repr(ZODB.TimeStamp.TimeStamp(...)) Cool! Thank you, Marius Gedminas -- another way is to use the fstools.prev_txn starting at the end of the file to grab the newest transactions, the script i send to the list last week uses it to poke a large zodb to just get the contents of the last 20 transactions without iterating through the whole thing or guessing a timestamp. https://mail.zope.org/pipermail/zodb-dev/attachments/20091207/531fc1e4/attachment.obj cheers, kapil ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] Locating backrefs of persistent objects
I'd like to implement the following feature for zodbbrowser: given a persistent object X, find all other persistent objects that have references to it. My use case for this is debugging: e.g. given a log entry that mentions a conflict error about an OOBTreeBucket, I'd like to know which OOBTree object contains it, and what object wraps the OOBTree, and at that point I usually see a container with a __name__ and __parent__ and can figure out what's going on. I realize that ZODB doesn't keep track of backreferences, so the only way to get that is to do a full object traversal, which is expensive in both CPU and memory. Given all that, what's the best (most efficient) way of computing the backreferences either for a single object, or for _all_ objects in the ZODB (that I could then cache for later use)? * implement something by hand, by using storage iterators and extracting forward references from each pickle or * implement something by hand, by doing graph traversal (BFS/DFS) starting from the root object or * reuse existing object graph traversal routines of the ZODB garbage collector ? Is there existing code I could use for inspiration? zodbex? zc.zodbgc? Bits and pieces of ZODB itself? The wishlist bug for this feature is here: https://bugs.launchpad.net/zodbbrowser/+bug/497758 Marius Gedminas -- Linux don't need no steenkin' viruses. The users can destroy the system all by themselves -- Peter Dalgaard in comp.os.linux.misc signature.asc Description: Digital signature ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Locating backrefs of persistent objects
On Thu, Dec 17, 2009 at 4:06 PM, Marius Gedminas mar...@gedmin.as wrote: I'd like to implement the following feature for zodbbrowser: given a persistent object X, find all other persistent objects that have references to it. My use case for this is debugging: e.g. given a log entry that mentions a conflict error about an OOBTreeBucket, I'd like to know which OOBTree object contains it, and what object wraps the OOBTree, and at that point I usually see a container with a __name__ and __parent__ and can figure out what's going on. I realize that ZODB doesn't keep track of backreferences, so the only way to get that is to do a full object traversal, which is expensive in both CPU and memory. ... ? Is there existing code I could use for inspiration? zodbex? zc.zodbgc? Bits and pieces of ZODB itself? zc.zodbdgc's multi-zodb-check-refs script will optionally produce a database of reverse references that your browser could use. Note that building this database can take a very long time. Jim -- Jim Fulton ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Locating backrefs of persistent objects
Marius Gedminas wrote: I'd like to implement the following feature for zodbbrowser: given a persistent object X, find all other persistent objects that have references to it. RelStorage has this functionality, but I don't know how we ought to expose it. Start a pack to update the graph, then query the object_ref table. Turn on pack-dry-run if you only want to update the table and don't want to pack. I'd like to make RelStorage implement some Python API for listing backreferences, but no such API has been defined. Shane ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
