Z Object Publishing Environment

Search | Download | Documentation | Resources | Members

Search  

 

 Guest

Join Zope.org
Log in


Developer Home
Get Involved!
The Fishbowl
Resources
Proposals
Projects


 Zope Exits

ZopeZen
Zope Newbies
Appwatch.com


page served by app2

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

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.

Contact

John D. Heintz (jheintz@isogen.com)

Problem

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.

Scope

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.

Deliverables

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:
SearchPage
 
 
Privacy policy       Printable Page       Feedback about Zope.org