couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: Proposal: Extending immutability
Date Tue, 06 Jan 2009 04:38:46 GMT

On 06/01/2009, at 2:37 PM, Chris Anderson wrote:

> The first gotcha I can see for the db uuid, is that for a cluster,
> which we want to be a single logical db, even if there are many nodes
> involved, would it be better to have a uuid per physical couch
> instance, or a single uuid for the cluster?

The combination of uuid + doc id + doc rev must identify an immutable  
value. If the cluster provides that guarantee i.e. the illusion of a  
single consistent value space, then the uuid could be per-cluster.  
Presumably the cluster would have a mechanism to provide manage a  
shared uuid value - if not, then it's probably failed the previous test.

You would want a shared uuid for a cluster, otherwise some of the  
client benefit of the cluster is lost, because of a lack of value  
sharing.

>>> , I'm still missing the obvious use case for extending them to
>>> view rows.
>>
>> Completeness. ... It's a
>> clean theoretical idea.
>>
>
> Believe me I appreciate the notion of being able to treat
> id/rev/db-uuids tuples as canonical. I'm still having a hard time
> coming up with a concrete use case that can't be accomplished without
> them.

Consider an expensive data structure that is built from a view row. I  
would like to cache that structure. I can't just rely on the doc id, I  
need the rev of the document that mapped to that row. I may not have  
the rev in the value, or I may want to get the view row value only if  
needed. I may be writing this without being in control of the view  
definition.

Furthermore, I need the rev of the design document so that if the  
design document were to be update then my cache would continue to work  
correctly without needing to code anything. I want the id of the  
design document in the view result in case I've got a URL mapper in  
front of my cache that so that if that mapping changes I continue to  
work. I want the uuid of the database so that my cache works correctly  
if the database is recreated.

I'd like all of this to operate generically so I can publish the  
mother of all functional couch caches up as a library on github.

And maybe a completely generic value-tracking cache that works in the  
same way, but deals with caching resources that are functionally  
derived from a number of different inputs, some documents, some view  
results. When the identifiers of documents and view-results are  
immutable values with referentially transparent keys, all of this is  
easy. Without it, much domain-specific configuration needs to be done,  
which is open to errors.

And I'm 100% sure there are uses that I haven't even imagined.  
Anything that relies on immutability, referential transparency, value  
tracing etc, could possibly be applicable.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Every task involves constraint,
Solve the thing without complaint;
There are magic links and chains
Forged to loose our rigid brains.
Structures, structures, though they bind,
Strangely liberate the mind.
   -- James Fallen



Mime
View raw message