On Dec 29, 2008, at 6:38 PM, Antony Blakey wrote:
>
> On 30/12/2008, at 12:51 AM, Damien Katz wrote:
>
>> The current rule maybe not the most intuitive to a newbie, but it
>> is far more consistent and easier to work with then when using the
>> deeper APIs.
>
> How is it 'far more consistent'. What measure of consistency are you
> using? Name identity is more cognitively fundamental than name
> contextuality. The consistency guaranteed by the asserting that a
> name is a name is a name is of a more fundamental form than the
> application of a different rule.
>
> How is it 'easier to work with'? How does using _id and _rev
> everywhere make it not easy? Surely it's not the difficulty of
> writing code?
>
>> The only 2 other workable solutions I see is to either stuff
>> everything special into a _meta structure or only use HTTP headers
>> for all CouchDB meta information. But after having spent much time
>> thinking about this issue, I think the current rule is the better
>> compromise.
>
> A simple rule is that every couch-domain value has a leading
> underscore. All technical issues disappear. Consistency ensues. Any
> objection to this must be aesthetic.
The current rule is that every couch-domain value has a leading
underscore when it appears in the root of a document. Your rule would
mean that throughout the API, everything that has special significance
should have an underscore. In views (key -> _key, value -> _value) in
urls ( GET /db/doc?_rev="...") and design docs (views -> _views, map -
> _map). That rule is simpler, but I think all the leading
underscores are ugly (aethetics) and require more unnecessary typing
(efficiency) and gain you no additional behaviors (functionality), and
all for the sake of consistency to a slightly simpler rule.
-Damien
|