Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Message-Id: <E839F3D7-72E7-444F-B628-FAA9AA071AB9@pobox.com>
From: "Geir Magnusson Jr." <geir@pobox.com>
To: user@couchdb.apache.org
In-Reply-To: <9c00d3e00901040835w404480f9odcdec25105a79a38@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Changing rev to _rev in view results (Was: Re: newbie question
 #1)
Date: Sun, 4 Jan 2009 11:40:20 -0500
References: <0743DF91-9015-43DD-9A0F-7E79D6DF4632@gmail.com>
 <154D8F25-87B3-49DC-9D80-6C68C946ECAF@gmail.com>
 <34FCDB16-6D06-4401-BCD8-0B053E2E935E@gmail.com>
 <48250456-2512-46BD-85E1-464457DBC995@pobox.com>
 <ACABD1CE-2E8E-491A-95C0-959820FBAA08@gmail.com>
 <AC6694DA-BA29-4D7E-A90E-31ABD10E1A9F@pobox.com>
 <A8DDC611-3621-4BCA-B053-3CDE0308AEE6@gmail.com>
 <20090102034756.GJ2520@tumbolia.org>
 <62D1E488-D052-4389-B61C-3FBD0D24F4AC@gmail.com>
 <FBAC923F-7F73-4200-B444-9CCB51A209F0@gmail.com>
 <9c00d3e00901040835w404480f9odcdec25105a79a38@mail.gmail.com>

exactly :)

On Jan 4, 2009, at 11:35 AM, Michael Fellinger wrote:

> On Fri, Jan 2, 2009 at 9:30 PM, Robert Dionne <bob.dionne@gmail.com>  
> wrote:
>> When it comes to design I think there are always tradeoffs. This is  
>> where
>> intuition and experience count. In my opinion separating metadata  
>> from the
>> user's data is a more complex approach. It creates two parts to the
>> document, they have to be handled separately and it creates the  
>> need for two
>> kinds of API calls for the two types of data.  It seems like a good
>> approach, however it's very easy to look at an existing  
>> implementation and
>> see how things "ought" to be done.
>>
>> The current implementation has a nice simplicity to it that I would  
>> not
>> readily advocate changing. My first impression is that it reminded  
>> me of
>> Berkeley DB on steroids. The convention governing the use of the  
>> _id is not
>> that hard to deal with and it doesn't prevent one from handling  
>> JSON docs
>> that come from elsewhere. It seems that converting data from one  
>> database
>> system to another always involves some transformation.
>
> For what it's worth, I'd love to see a separation of data and data
> about data, and I'd also like to propose a change to map functions:
>
> function(doc, meta){ emit(doc.title, [meta.id, meta.ref]); }
> function(doc){ emit(doc.title); }
>
> That way people who are complaining about having to type doc.doc.title
> can have their peace of mind as well.
>
> I might see the whole issue very limited, but it makes absolutely the
> most sense to me, everybody can stop worrying about which data is
> allowed in the data part and the metadata can grow in any direction.
> Nobody is annoyed by prefixing _ anymore (symetric API) and there is
> little technical need anymore for validating documents (as long as
> they can be serialized to valid JSON) before putting them into the db.
>
> ^ manveru
>
>> This discussion reminds me of Perlis' epigram(#15) that everything  
>> should be
>> built top down, except the first time.
>>
>>
>> On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>>
>>>
>>> On 02/01/2009, at 2:17 PM, Noah Slater wrote:
>>>
>>>> I appreciate you're frustrated with the current situation Antony,  
>>>> but I
>>>> think
>>>> it's unfair for you to be claiming any kind of consensus without  
>>>> a vote.
>>>
>>> That post wasn't meant to be a criticism. Apologies if it felt  
>>> like it
>>> was.
>>>
>>> There isn't a clear consensus in this thread, which to my mind  
>>> reflects
>>> the fact that there are trade-offs that don't have objective  
>>> evaluation
>>> measures.
>>>
>>> I fully support the idea that a product should reflect the vision  
>>> and
>>> opinion of a very small group. Abstracting from my preference for  
>>> a more
>>> robustly theoretical approach to API desig, the holistically best  
>>> result is
>>> likely to arise from this model. So I don't e.g. mean 'gatekeeper'  
>>> in a
>>> negative way.
>>>
>>>> I would
>>>> be interested in seeing a patch, explanation, and vote. I've  
>>>> already
>>>> expressed
>>>> my agreement with many of the points you've raised, and I'm not  
>>>> the only
>>>> one.
>>>
>>> I was only referring to a lack of expressed support for a fully  
>>> reflexive
>>> model.
>>>
>>> It's never been clear to me that there is a process for voting - the
>>> decision making process within the commit group seems opaque.
>>>
>>>> It's pretty pointless for us to keep sending emails over proposed  
>>>> changes
>>>> to the
>>>> code without actually seeing the changes.
>>>
>>> I think a change to the API could be decided without reference to  
>>> the code
>>> implementing that change. In fact, IMO the API *should* be  
>>> considered
>>> separately from the code implementing that change. Otherwise APIs  
>>> will tend
>>> to be decided not on the basis of design, but on the amount of  
>>> effort some
>>> person is prepared to spend to demonstrate it, and hence code  
>>> inertia, often
>>> resulting in expedient solutions. This means that good, but  
>>> expensive ideas,
>>> can be lost.
>>>
>>> The models under discussion have evolved from simple name identity  
>>> by
>>> using '_id' and '_rev' everywhere, to a '_meta' wrapper, to Geir's  
>>> fully
>>> reflexive model.
>>>
>>> So I'd prefer to get buy-in to a model or principles, at which point
>>> anyone could implement it. That's what I tried to do with the  
>>> change to the
>>> FS layout to support i18n, the committable implementation of which  
>>> is my
>>> focus right now.