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
