couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Kruthoff <>
Subject Re: when to use another document and when not to?
Date Mon, 21 Jul 2008 17:47:05 GMT
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

-- 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