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