With respect to a meta structure, I was going to make this comment
yesterday as I think Geir was arguing for this:
It seems to me that occam's razor argues for the simplicity of a
single JSON doc, rather that a "metadoc" envelope that contains
another JSON doc embedded in it. It's not clear to me that creating
this separation of concerns buys anything at all. The use of an
underscore to designate distinguished fields at the top level is a
fairly easy convention to get your arms around. It also provides a
nice convention for extensions, .eg. "_external". Does it blur the
distinction between data and metadata, yes but I think that's a good
thing.
Perhaps it's useful to turn the argument around and ask what having a
separate metadoc buys you? You now presumably store the unique id in
one JSON fragment and the actual doc in another, how does this
simplify the code?
I guess I'm not a big fan of metadata
On Dec 29, 2008, at 9:21 AM, Damien Katz wrote:
Yes, it is perfectly clear to a newbie, because it's the simplest
case. That's why I coded it this way initially, it seemed simpler.
What isn't immediately obvious is all the other special fields
that can appear in documents and in other contexts. How to make
that consistent? I tried, but couldn't keep it simple. The problem
was special names in various structures no longer have a simple
rule to follow, but instead you must know if this field appears in
a document at any time, then it starts with underscore in other
structures.
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. 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.
-Damien
On Dec 29, 2008, at 8:58 AM, Geir Magnusson Jr. wrote:
That rule would have been perfectly clear to me as a newbie.
+1
geir
On Dec 29, 2008, at 8:55 AM, Antony Blakey wrote:
On 29/12/2008, at 11:11 PM, Damien Katz wrote:
The problem was there where other reserved fields in documents
that started with underscore, but in other places the fields
wouldn't have an underscore. Keep track of which fieldname had
underscores and where became confusing. The rule was changed to
be simpler to understand and deal with.
A simpler rule is: _rev is the name no matter where it appears,
same with _id. I'd go so far as say that this kind of rule is so
fundamental to our idea of identity and naming, that it doesn't
even count as a rule. And there had better be a really good
reason to introduce a rule contrary to such an strongly implicit
and intrinsic concept.
And as far as 'Keeping track of which fieldname had underscores",
it would seem that the current situation is the worst, because
you have to keep track not based on identity e.g. _rev and _id,
but rather on context, which is a dynamic and more intellectually
demanding concept than semantic identity. Furthermore, in this
scheme, names must be mapped under structural transformation
(such as copying the _id and _rev fields from one context to
another), which complicates generic transformations.
IMO the name isn't "rev" with sometimes an underscore, rather the
name IS "_rev". Same with "_id".
A single name for a concept, lexically consistent, is less
cognitive load both initially and on an ongoing basis.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The ultimate measure of a man is not where he stands in moments
of comfort and convenience, but where he stands at times of
challenge and controversy.
-- Martin Luther King
