changes to shelf items fail silently?

[Steven Taschuk]

Quoth eichin at metacarta.com:
  [...]
> > of a key-value database on disk (dbm) and a generic object
> > serialization protocol (pickle).
> 
> While the __doc__ does say that, it isn't clear why that should cause
> this effect; serialization is just "how it is stored", and doesn't
> inherently imply "so you only get temporaries out".

Mm... yes, I see your point.  On the other hand, what I've
sketched is imho the obvious implementation.  Set a value in the
shelf, object gets pickled and written to disk; read a value from
the shelf, object gets read from disk and unpickled.  Very simple
to implement.  It really is just a combination of dbm and pickle.

Transparent persistence would be a much bigger deal (as is being
discussed below) -- so much so that it wouldn't occur to me to
expect it unless the documentation had some discussion of the
major issue, how changes are detected.

(Incidentally, in this sketch, "temporaries" is not an appropriate
term for the unpickled objects; it implies that the pickled object
in the shelf is the primary object, and the unpickled object in
memory an imperfect copy which lacks the true object's permanence.
I'd say it's the reverse: the in-memory object is the primary, and
the pickled bytestream in the shelf the imperfect copy, and not an
object at all (though of course it is convenient to speak of it as
if it is).)

  [...]
> > Now, what about shelved foobar.wombat objects?  Which of their
> > methods should cause commits?
> 
> Mmm, throw an exception if they don't "conform" to some interface.
> The reason I went down this path isn't that it silently discarded the
> changes, after all; I'd have been happy if it had non-silently told me
> (perhaps by having the references be non-mutable and cause exceptions
> to be thrown on changes, for example.)

Well, making an immutable view of an object is just as much
trouble as detecting changes for automatic commits.  How will the
wrapper know which methods of foobar.wombat objects to raise
exceptions for?

You could have some interface for this kind of thing (i.e., a way
to subscribe to "imminent mutation" announcements from an object,
and to interfere in those mutations, as Martelli suggests), and
allow only objects conforming to that interface to be shelved; but
one of the nice things about shelves is that they accept anything
picklable, which is pretty much anything.

(Actually, detecting changes after the fact is easier than
rejecting them beforehand.  A wrapper could pickle the object
after every method call or attribute change and compare the result
to what was read from the dbm database, committing if different. 
This would be very expensive but would detect all changes which
the shelf is capable of storing at all.)

-- 
Steven Taschuk                           staschuk at telusplanet.net
"I'm always serious, never more so than when I'm being flippant."
                            -- _Look to Windward_, Iain M. Banks