[
https://issues.apache.org/jira/browse/COUCHDB-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-260.
--
Resolution: Fixed
applied in r747679
> Support for reduce views in _list
> --
[
https://issues.apache.org/jira/browse/COUCHDB-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viacheslav Seledkin updated COUCHDB-249:
Attachment: (was: couch_view_updater.erl)
> Treat output rows of views as docu
[
https://issues.apache.org/jira/browse/COUCHDB-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viacheslav Seledkin updated COUCHDB-249:
Attachment: couch_view_updater.erl
> Treat output rows of views as documents for o
Devs,
Some of you have seen the work that's been going on over at the
CouchApp project. The project started as a thought experiment to see
what can be accomplished using only CouchDB as an app server. It turns
out to raise interesting questions for Couch, especially around REST,
hypermedia, and li
On 25/02/2009, at 2:55 PM, Chris Anderson wrote:
Reiterating: I think the clean solution is to remove the API for
loading docs at a particular rev. Instead we allow only the loading of
all conflicted revs (or of course the HEAD rev). I'll wait for people
to say why this is a bad idea before I s
On Tue, Feb 24, 2009 at 8:45 PM, Antony Blakey wrote:
>
> On 25/02/2009, at 2:55 PM, Chris Anderson wrote:
>
>> Reiterating: I think the clean solution is to remove the API for
>> loading docs at a particular rev. Instead we allow only the loading of
>> all conflicted revs (or of course the HEAD r
On 25/02/2009, at 2:55 PM, Chris Anderson wrote:
Reiterating: I think the clean solution is to remove the API for
loading docs at a particular rev. Instead we allow only the loading of
all conflicted revs (or of course the HEAD rev). I'll wait for people
to say why this is a bad idea before I s
On Tue, Feb 24, 2009 at 9:52 AM, Chris Anderson wrote:
> On another note, I was thinking about it some more, and I think that
> renaming _rev to _cc would be a huge pain in the ass for a lot of
> people (who don't go around abusing it) and it can probably be
> avoided.
>
> The only valid use case
On 25/02/2009, at 1:40 AM, Jan Lehnardt wrote:
Instead of asking how community votes would be factored into the
final result,
you constructed a hypothetical that frames the PMC as a
dictatorship, doing as
it pleases regardless of community feedback. You then use this
hypothetical to
draw t
On 25/02/2009, at 8:52 AM, Brian Candler wrote:
On Tue, Feb 24, 2009 at 01:48:56PM +0100, Jan Lehnardt wrote:
However, you must then be prepared for your database to be a single
file
which grows without bounds. If CouchDB wants to support this
model, it
would
be helpful if the data were sto
[
https://issues.apache.org/jira/browse/COUCHDB-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Lenz reassigned COUCHDB-183:
Assignee: Christopher Lenz
> No pagination in Futon for reduce views
> ---
On Tue, Feb 24, 2009 at 01:48:56PM +0100, Jan Lehnardt wrote:
>> However, you must then be prepared for your database to be a single
>> file
>> which grows without bounds. If CouchDB wants to support this model, it
>> would
>> be helpful if the data were stored in chunks which can be backed up
>
On Tue, Feb 24, 2009 at 11:17:20PM +1030, Antony Blakey wrote:
>
> On 24/02/2009, at 11:09 PM, Brian Candler wrote:
>
>> On a random tangent: has anyone considered a CouchDB-like system where
>> documents are raw blobs, rather than JSON? ISTM that:
>
> You'd need some way to attach/inject the metad
[
https://issues.apache.org/jira/browse/COUCHDB-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Lenz resolved COUCHDB-255.
--
Resolution: Fixed
I've upgraded the included MochiWeb to r97 in r747575.
> Update Moc
On Tue, Feb 24, 2009 at 4:05 PM, Damien Katz wrote:
>
> On Feb 24, 2009, at 2:13 PM, Paul Davis wrote:
>>
>> I'm a fan of the no-metadata-in-documents concept, but there are some
>> issues both philosophical and practical. Philosophically speaking, as
>> pointed out by the HTTP headers thread, we
On Tue, Feb 24, 2009 at 4:31 PM, Dave Bordoley wrote:
>> The real kicker is how do we support clients lacking HTTP-fu. For
>> instance, a quick google [1] suggests that XHR probably isn't capable
>> of dealing with multipart messages. There's an obvious middle ground
>> that could allow different
> The real kicker is how do we support clients lacking HTTP-fu. For
> instance, a quick google [1] suggests that XHR probably isn't capable
> of dealing with multipart messages. There's an obvious middle ground
> that could allow different versions to be returned via URL parameters
> though, and th
[
https://issues.apache.org/jira/browse/COUCHDB-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676419#action_12676419
]
Christopher Lenz commented on COUCHDB-255:
--
I've updated the vendor branch in r74
On Feb 24, 2009, at 2:13 PM, Paul Davis wrote:
I'm a fan of the no-metadata-in-documents concept, but there are some
issues both philosophical and practical. Philosophically speaking, as
pointed out by the HTTP headers thread, we may be abusing headers when
we consider some of the more CouchDB
On 24 Feb 2009, at 20:54, Shaun Lindsay wrote:
Hey all,
We've been discussing the best way to handle releasing the Lounge
code and
we have some questions that you, the couch devs, might be able to
help out
with:
1. What license is preferred? Since Couch is an Apache project, the
Apache
Hey all,
We've been discussing the best way to handle releasing the Lounge code and
we have some questions that you, the couch devs, might be able to help out
with:
1. What license is preferred? Since Couch is an Apache project, the Apache
license is probably appropriate, however, since the Loung
[
https://issues.apache.org/jira/browse/COUCHDB-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-183:
-
Attachment: futon_reduce_pagination.2.diff
Updated patch for latest trunk (r747465). Also the n
On Tue, Feb 24, 2009 at 1:13 PM, Damien Katz wrote:
> I'll once again state my objection to the newlines, which is actually kind
> of weak.
>
> If we compute the revids deterministically (hash the canonical doc
> contents), then when we return the document back to the client, we can send
> as an i
That's Ok Noah. Right now, all I've got are some vague ideas, no code.
I've stated my case, unless someone else has stronger objections (or
actual code) I'm fine to leave it as is.
-Damien
On Feb 24, 2009, at 1:19 PM, Noah Slater wrote:
On Tue, Feb 24, 2009 at 01:13:31PM -0500, Damien Kat
On Tue, Feb 24, 2009 at 10:25:40AM -0800, Chris Anderson wrote:
> What I mean is that there's nothing wrong with calculating revs-hashes
> in a Couch specific way. Bonus points if that way is easy to implement
> for client libs.
Aye, in the docs you simply put:
Hashes are to be calculated [with
On Tue, Feb 24, 2009 at 10:24 AM, Chris Anderson wrote:
> I think we have the freedom to get funny with the
> JSON responses.
Please pretend I was articulate and correct with this sentence. Thanks. ;)
What I mean is that there's nothing wrong with calculating revs-hashes
in a Couch specific way.
On Tue, Feb 24, 2009 at 10:13 AM, Damien Katz wrote:
> I'll once again state my objection to the newlines, which is actually kind
> of weak.
>
> If we compute the revids deterministically (hash the canonical doc
> contents), then when we return the document back to the client, we can send
> as an
On Tue, Feb 24, 2009 at 01:13:31PM -0500, Damien Katz wrote:
> I'll once again state my objection to the newlines, which is actually
> kind of weak.
Sorry for jumping the gun there Damien.
If you would like to retroactively veto the change, I can back it out.
--
Noah Slater, http://tumbolia.org
I'll once again state my objection to the newlines, which is actually
kind of weak.
If we compute the revids deterministically (hash the canonical doc
contents), then when we return the document back to the client, we can
send as an integrity hash the same revid, because it is already pre-
On Tue, Feb 24, 2009 at 06:39:32PM +0100, Jan Lehnardt wrote:
> or just commit the damn patch :)
Committed as r747465. Rock on.
--
Noah Slater, http://tumbolia.org/nslater
[
https://issues.apache.org/jira/browse/COUCHDB-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noah Slater closed COUCHDB-107.
---
Resolution: Fixed
Patch edited and committed as r747465.
> [PATCH] End JSON responses with newline
[
https://issues.apache.org/jira/browse/COUCHDB-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676350#action_12676350
]
Chris Anderson commented on COUCHDB-255:
One thing to take into account here is th
[
https://issues.apache.org/jira/browse/COUCHDB-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676348#action_12676348
]
Chris Anderson commented on COUCHDB-266:
Thanks cmlenz!
> PUTting json docs > 1MB
On Tue, Feb 24, 2009 at 5:52 AM, Jeff Hinrichs (JIRA) wrote:
> PUTting json docs > 1MB causes Uncaught error in HTTP request:
> {exit,{body_too_large,content_length}}
> --
>
> Key:
On Tue, Feb 24, 2009 at 9:50 AM, Jan Lehnardt wrote:
>
> They are tracked in the HTTP layer right now. I think what you're asking for
> is collecting the same stats one layer down for potential clients that don't
> use
> the HTTP API?
>
> The same applies to the `document_*` keys. Maybe they shoul
On Tue, Feb 24, 2009 at 3:50 AM, Damien Katz wrote:
>
> With Chris Andersons's "show" document and "list" view work, we have the
> beginnings of that.
>
I was just going to reply with this point. The only thing I see as
missing to make CouchDB fully "RESTful" is hypermedia. When the
representatio
On 24 Feb 2009, at 18:34, Damien Katz wrote:
I'd suggest
- to move the `document_*` keys from `httpd` to `couchdb`,
Yes.
- to rename `httpd` to `http`.
I think because replication also makes http requests, it should stay
as is.
Is there anything else that you think should look diffe
On 24 Feb 2009, at 18:34, Noah Slater wrote:
On Tue, Feb 24, 2009 at 09:30:40AM -0800, Chris Anderson wrote:
OK actually - I have a new opinion about the newlines stuff. Since I
really don't care all that much, and I don't see a canonical JSON
format happening anytime soon, I'm fine with retur
On Feb 23, 2009, at 9:51 AM, Jan Lehnardt wrote:
On 22 Feb 2009, at 15:06, Jan Lehnardt wrote:
I mentioned this in an earlier mail but I'd like to bring it up
again,
since your input is needed here. Metrics are identified with a
tuple `{Module, Key}`. `Module` is the module that initiates t
On Tue, Feb 24, 2009 at 09:30:40AM -0800, Chris Anderson wrote:
> OK actually - I have a new opinion about the newlines stuff. Since I
> really don't care all that much, and I don't see a canonical JSON
> format happening anytime soon, I'm fine with returning newlines at the
> end of our responses.
I go to sleep for 8 hours, and this is the thanks I get! ;)
But on a more serious note, I think we should pull a hedge fund move,
(or maybe quantum entanglement?) and add to the newline patch, some
lines that would change the color of the CouchDB logo from red to
blue.
OK actually - I have a new
@jan
And, it looks like they're doing both...?
"Because of the replication lag we mentioned earlier, however, you
might not see the change you just made! This experience is very
confusing for a user and also leads to double posting. We got around
this concern by setting a cookie in your browser w
On 24 Feb 2009, at 17:03, Zachary Zolton wrote:
Thanks for the reply! It looks like they go into the more advanced
Bayou consistency, and Byzantine failure modes, but I don't think I'll
need to cover that soon...
But a more important question:
If I have two couch servers: A and B
And, I want
Thanks for the reply! It looks like they go into the more advanced
Bayou consistency, and Byzantine failure modes, but I don't think I'll
need to cover that soon...
But a more important question:
If I have two couch servers: A and B
And, I want to load-balance users between them, would it be the
On 24 Feb 2009, at 16:49, Zachary Zolton wrote:
As a developer (without an advanced degree :^P) trying to understand
Eventual Consistency, I happened upon these slides:
http://www.cs.berkeley.edu/~istoica/classes/cs268/06/notes/20-
BFTx2.pdf
I know consistency models are a hot topic around
As a developer (without an advanced degree :^P) trying to understand
Eventual Consistency, I happened upon these slides:
http://www.cs.berkeley.edu/~istoica/classes/cs268/06/notes/20-BFTx2.pdf
I know consistency models are a hot topic around here, so I thought
I'd ask if this would make a good in
On 24 Feb 2009, at 14:02, Noah Slater wrote:
On Tue, Feb 24, 2009 at 10:48:31PM +1030, Antony Blakey wrote:
On 24/02/2009, at 10:34 PM, Noah Slater wrote:
On Tue, Feb 24, 2009 at 10:14:04PM +1030, Antony Blakey wrote:
I'm a bit confused about this. Excuse me while I tread carefully.
It
see
[
https://issues.apache.org/jira/browse/COUCHDB-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Lenz reassigned COUCHDB-255:
Assignee: Christopher Lenz
> Update MochiWeb
> ---
>
>
On 25/02/2009, at 12:45 AM, Noah Slater wrote:
On Wed, Feb 25, 2009 at 12:29:08AM +1030, Antony Blakey wrote:
My suggestion arising from this is that voting a community vote where
everyone states their case and casts a vote is followed by a PMC
decision. It seems (to me) confusing to have this
On Wed, Feb 25, 2009 at 12:29:08AM +1030, Antony Blakey wrote:
> My suggestion arising from this is that voting a community vote where
> everyone states their case and casts a vote is followed by a PMC
> decision. It seems (to me) confusing to have this multi-class voting
> system which conflates t
[
https://issues.apache.org/jira/browse/COUCHDB-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676285#action_12676285
]
Christopher Lenz commented on COUCHDB-266:
--
For the record, here's the MochiWeb i
[
https://issues.apache.org/jira/browse/COUCHDB-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Lenz resolved COUCHDB-266.
--
Resolution: Fixed
Fix Version/s: 0.9
Patch applied in r747381.
> PUTting json
On 24/02/2009, at 10:35 PM, Jan Lehnardt wrote:
No, you're absolutely right on the "Accept the patch" branch. But
there are enough community -1s to keep this open. A single
community -1 should be addressed in an ASF vote.
My suggestion arising from this is that voting a community vote where
[
https://issues.apache.org/jira/browse/COUCHDB-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676278#action_12676278
]
Christopher Lenz commented on COUCHDB-266:
--
First, here's a simple way to reprodu
[
https://issues.apache.org/jira/browse/COUCHDB-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Lenz reassigned COUCHDB-266:
Assignee: Christopher Lenz
> PUTting json docs > 1MB causes Uncaught error in HTTP
PUTting json docs > 1MB causes Uncaught error in HTTP request:
{exit,{body_too_large,content_length}}
--
Key: COUCHDB-266
URL: https://issues.apache.org/jira/brow
I'm sure this is of no interest to anyone. I've replied privately.
On 24/02/2009, at 11:32 PM, Noah Slater wrote:
No, it most certainly was not just a question.
Instead of asking how community votes would be factored into the
final result,
you constructed a hypothetical that frames the PMC a
2009/2/24 Jan Lehnardt
>
> On 24 Feb 2009, at 13:52, Patrick Antivackis wrote:
>
>> 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
>>>
On 24 Feb 2009, at 13:52, Patrick Antivackis wrote:
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
On Tue, Feb 24, 2009 at 10:48:31PM +1030, Antony Blakey wrote:
> On 24/02/2009, at 10:34 PM, Noah Slater wrote:
>> On Tue, Feb 24, 2009 at 10:14:04PM +1030, Antony Blakey wrote:
>>> I'm a bit confused about this. Excuse me while I tread carefully. It
>>> seems that the community vote is clearly a m
Hi Jan,
>
> 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 :)
On 24 Feb 2009, at 13:39, Brian Candler wrote:
On Tue, Feb 24, 2009 at 09:06:09AM +0100, 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
On 24/02/2009, at 11:09 PM, Brian Candler wrote:
On a random tangent: has anyone considered a CouchDB-like system where
documents are raw blobs, rather than JSON? ISTM that:
You'd need some way to attach/inject the metadata in both directions.
Antony Blakey
-
CTO, Linkuistics Pty
On Tue, Feb 24, 2009 at 09:06:09AM +0100, 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.
This is a good
On 24/02/2009, at 10:34 PM, Noah Slater wrote:
On Tue, Feb 24, 2009 at 10:14:04PM +1030, Antony Blakey wrote:
I'm a bit confused about this. Excuse me while I tread carefully. It
seems that the community vote is clearly a majority to accept the
patch.
If the end result of this vote is that w
[
https://issues.apache.org/jira/browse/COUCHDB-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676254#action_12676254
]
Christopher Lenz commented on COUCHDB-265:
--
For the record, the proper way to iss
On 24 Feb 2009, at 12:54, Antony Blakey wrote:
On 24/02/2009, at 10:11 PM, Robert Dionne wrote:
I read this thesis ages ago, and technically you are correct, if
somewhat pedantic. I think CouchDB captures the just of being REST-
ful and certainly from a marketing perspective it's timely.
Robert Dionne
Chief Programmer
dio...@dionne-associates.com
203.231.9961
On Feb 24, 2009, at 6:54 AM, Antony Blakey wrote:
On 24/02/2009, at 10:11 PM, Robert Dionne wrote:
I read this thesis ages ago, and technically you are correct, if
somewhat pedantic. I think CouchDB captures the jus
On 24 Feb 2009, at 12:44, Antony Blakey wrote:
On 23/02/2009, at 3:17 AM, Jan Lehnardt wrote:
Collecting:
On 23 Jan 2009, at 23:42, Noah Slater wrote:
* Accept the patch (or a modified version) and add newline chars
+1: 7 (2 binding)
-1: 3 (2 binding)
* Reject the patch (and any modifie
On Tue, Feb 24, 2009 at 10:14:04PM +1030, Antony Blakey wrote:
> I'm a bit confused about this. Excuse me while I tread carefully. It
> seems that the community vote is clearly a majority to accept the patch.
> If the end result of this vote is that we don't follow that vote because
> it's only the
On Feb 24, 2009, at 6:44 AM, Antony Blakey wrote:
On 23/02/2009, at 3:17 AM, Jan Lehnardt wrote:
Collecting:
On 23 Jan 2009, at 23:42, Noah Slater wrote:
* Accept the patch (or a modified version) and add newline chars
+1: 7 (2 binding)
-1: 3 (2 binding)
* Reject the patch (and any modi
On 24/02/2009, at 10:11 PM, Robert Dionne wrote:
I read this thesis ages ago, and technically you are correct, if
somewhat pedantic. I think CouchDB captures the just of being REST-
ful and certainly from a marketing perspective it's timely.
That's why I say it's a marketing issue. Surely w
Robert Dionne
Chief Programmer
dio...@dionne-associates.com
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
On Feb 24, 2009, at 6:26 AM, Antony Blakey wrote:
On 24/02/2009, at 9:29 PM, Jan Lehnardt wrote:
CouchDB documents are limited to JSON (application/json) as the
content, that doesn't make the API less RESTful. If that's not the
right answer, I don't understand what you mean.
application/js
On 23/02/2009, at 3:17 AM, Jan Lehnardt wrote:
Collecting:
On 23 Jan 2009, at 23:42, Noah Slater wrote:
* Accept the patch (or a modified version) and add newline chars
+1: 7 (2 binding)
-1: 3 (2 binding)
* Reject the patch (and any modified version) and do not add
newlines chars
+1: 3
Robert Dionne
Chief Programmer
dio...@dionne-associates.com
203.231.9961
On Feb 24, 2009, at 6:26 AM, Antony Blakey wrote:
On 24/02/2009, at 9:29 PM, Jan Lehnardt wrote:
CouchDB documents are limited to JSON (application/json) as the
content, that doesn't make the API less RESTful. If tha
On 24/02/2009, at 9:29 PM, Jan Lehnardt wrote:
CouchDB documents are limited to JSON (application/json) as the
content, that doesn't make the API less RESTful. If that's not the
right answer, I don't understand what you mean.
application/json doesn't define the semantics of the payload e.g. h
On 24 Feb 2009, at 11:44, Antony Blakey wrote:
On 24/02/2009, at 9:02 PM, Jan Lehnardt wrote:
Hi Antony,
On 24 Feb 2009, at 00:34, Antony Blakey wrote:
OTOH, one should use the correct term and not redefine existing
terms to suit one's own purpose. In a tangentially related way,
the u
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 should
On 24 Feb 2009, at 04:09, Jeff Hinrichs - DM&T wrote:
On Mon, Feb 23, 2009 at 8:43 PM, Chris Anderson
wrote:
On Mon, Feb 23, 2009 at 6:30 PM, Damien Katz
wrote:
Maybe we should change that use from ?rev... to ?conflict=
If we follow your _cc idea, we could change from ?rev= to ?cc=
On 24/02/2009, at 9:02 PM, Jan Lehnardt wrote:
Hi Antony,
On 24 Feb 2009, at 00:34, Antony Blakey wrote:
OTOH, one should use the correct term and not redefine existing
terms to suit one's own purpose. In a tangentially related way, the
use of the term RESTful wrt CouchDB is a marketing
On 24 Feb 2009, at 04:08, Chris Anderson wrote:
On Mon, Feb 23, 2009 at 1:31 AM, Christopher Lenz
wrote:
Providing a reason for your -1 on accepting the patch would be a
good start
;)
Personally, I don't think this whole thing is very important, but I
don't
see any harm in adding t
Hi Antony,
On 24 Feb 2009, at 00:34, Antony Blakey wrote:
OTOH, one should use the correct term and not redefine existing
terms to suit one's own purpose. In a tangentially related way, the
use of the term RESTful wrt CouchDB is a marketing abomination.
I've heard that before. CouchDB's
On 23 Feb 2009, at 20:48, Noah Slater wrote:
On Mon, Feb 23, 2009 at 10:20:12AM +0100, Jan Lehnardt wrote:
Now I'm confused, you wrote, but didn't send the RESULT mail? :)
I had replied, but managed to reply to myself instead of the list.
I have _so_ been there before :)
Cheers
Jan
--
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. I really don't
see the point of renaming an attribute to make it harder to understand it's
85 matches
Mail list logo
