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 Mon, 12 Jan 2009 06:45:39 GMT
--- Revised Proposal ---------

Each document, whether canonical or derived, has a globally unique  
identity consisting of a UUID and the document ID.

In the case of a canonical document, the UUID is the UUID of the  
database (or cluster), which is assigned when a database is created.

In the case of a (derived) view map result, it is the UUID of the map  
function (not the design doc), which is assigned to each map function  
(i.e. view) in a design doc when the design doc is created or updated.

Furthermore, there is a triple {UUID, document id, document rev} that  
globally identifies a document at a given point in time. The key  
characteristic being that a {UUID, id, rev} identifies an immutable  
value.

------------------------------

I have a real-life use-case for this.

My project stores a number of XHTML documents that use microformat  
markup. The documents rarely change, but they can. I have views that  
provide derived documents using E4X to reflect on the microformat  
markup. In my client I produce further derived results from the view  
values.

Each web page query requires the in-client derived results from a  
number of these documents, which come in from a view query. The ideal  
situation would be if I could query the view, omitting the value  
(minor detail, but potentially beneficial), and receive the key,  
document id, document rev, and a UUID as described below, that  
globally qualifies the document id.

Thus I could easily cache my derived results, knowing that I have  
value-based cache keys. Furthermore I can easily cache functional  
combinations of such identified fragments, using simple multi-key memo- 
ization.

I can build this as 100% generic caching/transformation middleware  
that allows me to register functional transformations, as long as  
couch provides the appropriate details independent of the structure of  
the value returned from the view.

I can't rely on etags, because they are dependent on the view query  
parameters e.g. start/end keys.

I don't want to put the _rev into the view result - it doesn't belong  
there because it's not part of the domain data, and to do so is a  
hack. My view results are not structured.

I don't want to have to hook into a notification mechanism to detect  
design doc and database changes. The design docs can change when new  
versions of the software is deployed into a running system. The system  
shouldn't have to restart in this situation.

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

A Man may make a Remark –
In itself – a quiet thing
That may furnish the Fuse unto a Spark
In dormant nature – lain –

Let us divide – with skill –
Let us discourse – with care –
Powder exists in Charcoal –
Before it exists in Fire –

   -– Emily Dickinson 913 (1865)



Mime
View raw message