Z Object Publishing Environment

Search | Download | Documentation | Resources | Members




Join Zope.org
Log in

Developer Home
Get Involved!
The Fishbowl

 Zope Exits

Zope Newbies

page served by app2

Proposals Table of Contents Last edited by jheintz on Feb 23, 2001 2:32 pm

HashingSupport Proposal

Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the HashingSupportDiscussionx to make comments.


John D. Heintz (jheintz@isogen.com)


When using the ZODB for object persistence in a non-Zope context it is very useful to be able to use Persistent objects as keys into dictionaries. By default Persistent (and ExtensionClassx) objects don't support __hash__ because is is not well defined.

Proposed Solution

Provide implementations of HashablePersistentx and HashablePersistentMappingx that support hashing persistent objects by identity over the entire existence of the object. That is from creation through multiple activations from Connection caches.

This can be achieve by:

  • implementing a HashablePersistent(Persistent) class that implements __hash__ to mean: return hash(self._p_oid) if present else return id(self).

  • implementing a HashablePersistentMappingx class that accepts HashablePersistentx objects as keys and treats newly created objects (that is no _p_oid value) specially.

  • patch ZODB/Connection.py to enable the HashablePersistentMappingx instances to re-index those HashablePersistentx objects with newly generated _p_oid values.

Risk Factors

  • Performance degredation during commit. Connection.py has to perform an additional check for each object stored in the Storage.


The scope is limited to a modification of Connection.py and an additional module to include HashablePersistentx and HashablePersistentMappingx.

The intended usage of this module is generally for application developers using ZODB for custom persistence.


A patch to Connection.py and HashingSupport.py module. See http://www.zope.org/members/jheintz/HashingSupport

jim (Feb 19, 2001 4:18 pm; Comment #1)

This is really problematic. I'm not keen on taking a hit for this on each object.

htrd (Feb 20, 2001 4:57 am; Comment #2) Editor Remark Requested

Why do you need to support objects with no oid? Is it to have dictionaries that contain objects that will never be persisted? or to support newly created objects that dont yet have an oid, but will do very soon? I think this second case could be handled better by providing a way to oid-ize a new object. iirc, you can do this today with subtransactions.

jheintz (Feb 23, 2001 2:32 pm; Comment #3)

jheintzx jim: By "hit" are you referring to the hasattr() call? Or do you mean the _p_commitHook()? I assumed that the hasattr() would be really fast and might be exceptable because its time would be small than pickling and transport.

htrd: Thanks for the suggestion. I think its a great idea and will use that instead. How I didn't think of it myself... ;) That's why we do this in the fishbowl.

Unless anyone has a problem in a few days I'll move this into the DeferredProposalsx section.

View source HashingSupport
Advanced Actions / History
Visitor: Anonymous User
Jump to:
... by pagename prefix or search term.
For a plain search:
Privacy policy       Printable Page       Feedback about Zope.org