This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dannu
Recipients
Date 2002-05-10.00:47:40
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=83092

I'd suggest not changing shelve at all but providing 
a "cache-commit" dictionary (ccdict) which can wrap a
shelf-instance (or any other simple dictish instance)
and provides the 'non-surprising' behaviour. 

Some proof of concept code for the following
properties is provided here

http://home.trillke.net/~hpk/ccdict.py

Current properties are:

- ccdict wraps a dictionary-like object which
  in turn only needs to provide
  __getitem__, __setitem__, __delitem__,has_key

- on first access of an element
  ccdict makes a lookup on the underlying
  dict and caches the item.
- the next accesses work with the cached thing.
  Unsurprising dict-semantics are provided.

- deleting an item is deferred and actually happens
  on commit() time. deleting an item and later on
  assigning to it works as expected (i.e. the assignment
  takes preference).

- commit() transfers the items in the
  cache to the underlying dict and clears
  the cache.Prior to issuing commit
  no writeback to the underlying dict happens.

- deleting an ccdict-instance does *not* commit any  
changes. You have to explicitely call commit().
If you want to work readonly, don't call commit.

- clear() only cleares the cache and not the underlying
  dict 

- you can explicitely prune the cache (via cache.keys()
etc.) before calling commit(). This lets you
avoid writing back unmodified objects if this
is an issue.

It seems quite impossible to figure out automagically
which objects have been modified 
and so the solution is to do it explicitely 
(or don't commit for readonly).

holger
History
Date User Action Args
2007-08-23 15:13:06adminlinkissue553171 messages
2007-08-23 15:13:06admincreate