couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Date Sun, 04 Jan 2009 16:40:20 GMT
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.


Mime
View raw message