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
