If the metadata was separate from the "user data" everywhere, as it is
in view results, the problem just simply goes away. But I realize
that won't be the solution. :)
My $0.02 as a new user - I think I agree with Jan here - consistency
is important.
I started really learning about CouchDB yesterday, so my memory of the
"journey" is clear, and the "special fields" thing did throw a WTF
exception... not because of the existence of _id and _rev in user data
(that threw the "OhGeeze..." exception), but because they were
inconsistently handled and presented in basic things like _all_docs/
The start of my thread yesterday ("newbie question #1") was really
about that - why "id" *and* "_id", "rev" *and* "_rev", how the
presence of "key" in _all_docs/ seems to be a leak from how views
work, why are view results so different than document results (e.g.
why you don't inject _rev, _id_ and key into the data part of the
view, why view/all is different format than db/_all_docs/...)
I do understand that as codebases evolve, APIs are going to change,
and when it's OSS, you always accrete users depending on "whatever is
there", so change is hard.
But this could be solved by versioning the API - put something in a
standard place in the URI to indicate that it's not the current API e.g.
GET v1/somedatabase/_all_docs
and this gives you the chance offer other APIs (like one for us
crackpots that insist that implementation metadata doesn't belong in
the user data :)
Dunno. Haven't used CouchDB in anger yet, so take all this w/ a grain
of salt, but all my observations and what I hope are taken as
constructive criticisms notwithstanding, I really am excited about
CouchDB.
geir
On Dec 29, 2008, at 8:14 AM, Jan Lehnardt wrote:
On 29 Dec 2008, at 13:41, Damien Katz wrote:
I disagree we should change this back. I don't know if anyone
remembers, but this is how I implemented long ago in the first
versions of the post-XML CouchDB. 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. If it's
in the root of a doc and it starts with underscore, it's reserved.
You don't see the reserved underscore fields anywhere else, only in
document top level.
My issue with this is when learning about CouchDB, documents come
first and the "special fields are prefixed with an underscore" rule
is taken up naturally. Later with views and query parameters, this
rule is broken. You could argue that when we teach documents, we
should make the actual rule more explicit and that is certainly
true, but we don't control the ways people pick up CouchDB. We
control the API however and are able to reduce WTF-factors.
-Damien
On Dec 28, 2008, at 2:21 PM, Jan Lehnardt wrote:
On 28 Dec 2008, at 14:32, Antony Blakey wrote:
On 28/12/2008, at 11:56 PM, Paul Davis wrote:
Why "id" and "rev" are used instead of "_id" and
"_rev" I couldn't really tell you. I hate to say "historical
reasons"
but I'm guessing that when Damien designed the view output he just
labeled then "id" and "rev" without the underscore because it's
not
needed to distinguish from the rest of the doc.
Desirable to change that (and any other inconsistencies) before a
1.0
This keeps coming up and I've been advocating this for a while now:
+1 for changing view result rows `rev` to `_rev` to avoid confusion.
CC'ing [email protected].
Cheers
Jan
--
