Not sure if I understand exactly what your asking, but as long as all
initiation consults the map, which knows to consult couch on a key-
miss, the behavior will be the same regardless if the document is
already loaded in the map. We found that in practice it is better to
generate doc id's client side, and to stage all transactions in
memory, because it a) performs better and b) makes relating objects
brain dead simple.
As for the size of the im, we intend the im to only live for the
duration of a single web-request. For backend daemons etc, the im
runs in the scope of a block so it can be controlled, such as:
database :test do
#im is scoped here
end
-- troy
On Jul 21, 2008, at 10:08 AM, Paul Carey wrote:
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
