couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Carey" <>
Subject Re: when to use another document and when not to?
Date Mon, 21 Jul 2008 18:37:08 GMT
Thanks for the reply, I realise my question might not have been entirely clear.

Scoping the identity map on a per request / per block basis obviates
the concerns I might have had.


On Mon, Jul 21, 2008 at 6:47 PM, Troy Kruthoff <> wrote:
> 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 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 = => "futon", :color => "white")
>> divan = => "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 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
>> 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

View raw message