Robert Dionne
Chief Programmer
[email protected]
203.231.9961
On Feb 24, 2009, at 5:52 AM, Jan Lehnardt wrote:
Hi Patrick,
On 24 Feb 2009, at 09:06, Patrick Antivackis wrote:
Oh and by the way, in a use case where there is only one database
and you
don't use compaction because you want to keep everything, well
_rev is a
revision that can be used to see the history of the document.
You still shouldn't and that's what's in the documentation :) Just
because
you can tie a skateboard to a car and drive on the highway would make
one hell of a fun ride, you are not advised to do so. :)
I really don't
see the point of renaming an attribute to make it harder to
understand it's
role.
The suggestion here is to rename to make it _easier_ to understand
because the connotations "revision" comes with are not entirely
valid for CouchDB.
I agree that this is important to fix. It is too easy to assume
CouchDB supports revision history. A lot of folks made this mistake,
myself included. It's really internal state needed for concurrency
control, yet it's exposed to users and required to be maintained in
the document. So it needs to be called something that reflects this
internal use, like "_int_bit" or "_token" or "_cc_uid"
It's like all politically correct terminology where you use a stupid
expression in order to be as neutral as possible.
You have a point here, it is about avoiding conflict. But I don't
think
we're looking for a neutral term here, but one with a better name.
I'd go with _access_token if it weren't too long. _rev is nice and
short
and _token might as well be _wibble. API design is hard.
Cheers
Jan
--
IMO if you change this
attribute name it's even better to remove all possibilities to a
access a
previous rev if still there, and change it's value by a timestamp
Regards
2009/2/24 Antony Blakey <[email protected]>
On 24/02/2009, at 12:51 PM, Antony Blakey wrote:
The project founder and the PMC, are all committed to that
replication
model, which is derived from Notes.
BTW I'm the only one in the community that has expressed any
strong desire
to change this - I'm not implying any community division, just
pointing out
that it's both an historical artifact, and accepted by the major
contributors and committers.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Plurality is not to be assumed without necessity
-- William of Ockham (ca. 1285-1349)
