couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Carey" <paul.p.ca...@gmail.com>
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.

Paul

On Mon, Jul 21, 2008 at 6:47 PM, Troy Kruthoff <tkruthoff@blit.com> 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 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
>
>

Mime
View raw message