couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dionne <>
Subject Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Date Fri, 02 Jan 2009 12:30:42 GMT
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.

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.
> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
> The intuitive mind is a sacred gift and the rational mind is a  
> faithful servant. We have created a society that honours the  
> servant and has forgotten the gift.
>   -- Albert Einstein

View raw message