> Big ditto here, but I wanted to add that we implemented a runtime identity
> map and it is working pretty well... e.g. if you abstract all the GET
> requests to couch, you can check to see if your hash already has the id to
> at least eliminate calling couch twice for the same doc.id in a single
> session.
That's interesting. I'm writing (yet another) Ruby library for
CouchDB, but had shied away from using an identity map in case I
unintentionally came to depend on it for correctness as opposed to
just performance.
Continuing with the Twitter metaphor, consider the following.
class User
has_many :followers
end
futon = User.new(:name => "futon", :color => "white")
divan = User.new(:name => "divan")
futon.followers << divan
divan.followers << futon
futon.followers[0].followers[0].color=("black").save
If the indirect reference to futon via the followers chain loads a new
object, a subsequent call to futon.save would fail as it's revision
would lag that in CouchDB. If, however, all objects are loaded via an
identity map, the call to futon.followers[0].followers[0] would simply
return the same instance as futon itself, and a later call to
futon.save would succeed.
An identity map can't grow arbitrarily large, and entries must be
excised at some point. My fear was that when the size limits of the
identity map are not reached (as would typically happen in
development), it would be all too easy to write code that accidentally
depended on entries being found. In production, where map misses might
occur, behaviour could be different.
Having said all that, I'm a complete newb in this field and maybe I'm
worrying about the equivalent of UUID collisions?
Paul