I guess I can answer my own question, Chris' app in the database[1]
idea is a scenario where a user might clone the app then tweak the
design docs.
[1] http://jchris.mfdz.com/code/2008/11/my_couch_or_yours__shareable_ap
On Jan 5, 2009, at 1:27 PM, Robert Dionne wrote:
Interesting proposal. A question:
First, I'm a little confused by the use of the phrase referential
transparency as I understand the more technical definition in the
FP literature (call a function twice on the same input and get the
same output), but I think I see the intended meaning, please
clarify if you have another meaning.
Do you have applications and/or envision use cases that are
dynamic enough that you want to track design doc changes? It seems
to me these are more a development time concern.
On Jan 5, 2009, at 8:26 AM, Antony Blakey wrote:
I've cc'd this to couchdb-user, because I think this discussion
belongs on -dev, but everyone watches -user.
One of the great features of Couch is the use of optimistic
locking i.e. rev as a bedrock mechanism, and the way this is
permeated through the API. The combination of id + rev is a
reference to an immutable value (with some caveats, one subject of
this proposal). This means that you get caching for free. By
keying off id + rev, you can cache the document along with any
(functional) derived values. Additionally you can trivially
memoize functions of multiple documents using that mechanism.
I use this to good effect in my application, where I aggressively
cache the documents (which are sometimes large) and therefore
don't need the document content in queries. To take advantage of
this however this means that my views need to include the _rev as
the value, and transformation that would normally happen in the
map happens in the client.
It would be very useful to have the rev returned wherever an id is
returned, specifically in view results. You could then use a view
without include_docs, and get the ids and revs. You can keep a
cache (per view, pre db) of the results. The actual view results
only need to be fetched on a cache miss, which can be driven by
the cache machinery.
The nice thing is that all of this caching machinery can be
transparently interposed. Except when the view definition is
changed. So I also propose to have the rev and id of the design
doc returned in the view results. And for completeness, every
database should be assigned a UUID when it is created. This UUID
should be provided in the dbinfo, and for every view and view-like
result.
This means that from every view result you can construct a list of
universally unique references to immutable values e.g. DB UUID +
(View id + rev) + (Document id + rev). A form of referential
transparency - and with a cache and a little bit of 100% generic
machinery, it can be true referential transparency. Clients don't
have to watch/be notified about changes to design docs, or even
database creation/deletion. Systemwide transparent caching in
particular becomes trivial.
So, in summary I propose:
1. Provide the document rev whenever the id is returned, such as
view results i.e. not in the document, but in the per-row hash.
2. Provide the design document id and rev in view results i.e. in
the top level hash.
3. Add a UUID to databases, and provide that in view results i.e.
in the top level hash, and all other database operation results.
I think you could do this even with reduce results, but I haven't
though a lot about it.
I think this generalised the current API in a very useful way,
that will greatly simplify, and hence 'robustify' client code.
Although I haven't checked the implementation code, my experience
so far suggest this isn't difficult.
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
