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 Wed, Feb 25, 2009 at 08:07:39PM +1030, Antony Blakey wrote:
> There's _id when it's not supplied in a PUT, but that would be supplied
> by the Location header in the result. The more I think about it, the more
> I like this idea.
>
> A lot more work on the client side though to deal with e.g.
On 25/02/2009, at 8:49 AM, Brian Candler wrote:
There's Content-Type (standard HTTP header in both directions), and
there's
_rev (or previous _rev). The latter can be in the URL for a PUT, and
perhaps
a header for a GET. If revisions were a document hash, there's the
standard
Content-MD5
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 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
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
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
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
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 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/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
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
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
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
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, j
On 24/02/2009, at 1:39 PM, Jeff Hinrichs - DM&T wrote:
scenario, master-slave -- slaves only keep the most recent, while the
master keeps complete. conflict resolution is handled solely by the
master.
scenario, first-among-equals -- multi-master where a single master is
used as the basis for co
On 24/02/2009, at 1:00 PM, Damien Katz wrote:
I think if we change from _rev to something else, _cc for
concurrency control is good. I'm not sure this is necessary.
Concurrency control describes how it got there, but it's not the thing
itself e.g. it's not 'the concurrency control' it's an
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=
>
>>
>> I think if we change from _rev to something else,
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=
>
> I think if we change from _rev to something else, _cc for concurrency
> control is good. I'm not sure this is neces
On Feb 23, 2009, at 8:45 PM, Chris Anderson wrote:
Would it be overly difficult to just add in the ability to keep a
full rev
history based on a config setting?
This would be a pretty big change. As Antony says, once you go down
that path a little, you end up at something that is not really
On 24/02/2009, at 12:15 PM, Chris Anderson wrote:
Would it be overly difficult to just add in the ability to keep a
full rev
history based on a config setting?
This would be a pretty big change. As Antony says, once you go down
that path a little, you end up at something that is not really
>> Would it be overly difficult to just add in the ability to keep a full rev
>> history based on a config setting?
This would be a pretty big change. As Antony says, once you go down
that path a little, you end up at something that is not really much
like Couch.
There's yet to be a really clear
On 24/02/2009, at 9:32 AM, Dean Landolt wrote:
Can you suggest how we improve the wiki docs to satisfy this? In my
opinion, the docs are clear* and the term is overloaded and
confusing.
* http://wiki.apache.org/couchdb/Document_revisions has
"You cannot rely on document revisions for any ot
On Mon, Feb 23, 2009 at 6:02 PM, Dean Landolt wrote:
> On Mon, Feb 23, 2009 at 10:30 AM, Jan Lehnardt wrote:
>
>>
>> On 23 Feb 2009, at 16:11, Patrick Antivackis wrote:
>>
>> For a reminder :
>>>
>>> revision (n)
>>> 1. the act or process of revising,
>>> 2. a corrected or new version of a book
On Mon, Feb 23, 2009 at 10:30 AM, Jan Lehnardt wrote:
>
> On 23 Feb 2009, at 16:11, Patrick Antivackis wrote:
>
> For a reminder :
>>
>> revision (n)
>> 1. the act or process of revising,
>> 2. a corrected or new version of a book, article, etc.
>>
>> For me this term is correct with the use in
t;>
>>>>
>>>>
>>>>>
>>>>>> -1 : This functionnality is interesting for some case studies
>>>>>
>>>>
>>>> - Make it much harder/verbose to get old revision
>>>>
>>>>
>>>> -1 : I don
ot; or "hobo
socks".
People won't know what they are, but at least they won't misuse
them.
-1 : revision seems the right term to me
-Damien
Begin forwarded message:
From: Damien Katz
Date: February 23, 2009 9:09:09 AM EST
To: u...@couchdb.apache.org
Sub
- Don't call them revisions, call them "turd blossoms" or "hobo socks".
>>>
>>>> People won't know what they are, but at least they won't misuse them.
>>>>
>>>>
>>> -1 : revision seems the right term to me
are, but at least they won't misuse
them.
-1 : revision seems the right term to me
-Damien
Begin forwarded message:
From: Damien Katz
Date: February 23, 2009 9:09:09 AM EST
To: u...@couchdb.apache.org
Subject: Re: Fail on a simple case on replication
Reply-To: u...@couch
>
-1 : revision seems the right term to me
>
>
>
>
>> -Damien
>>
>> Begin forwarded message:
>>
>> From: Damien Katz
>>> Date: February 23, 2009 9:09:09 AM EST
>>> To: u...@couchdb.apache.org
>>> Subject: Re: Fail on a simple ca
On Mon, Feb 23, 2009 at 6:16 AM, Damien Katz wrote:
> This is a very common misconception about the revision system. Any ideas how
> we can make this better?
>
> random ideas:
> - Don't call them revisions, call them "turd blossoms" or "hobo socks".
> People won't know what they are, but at least
-Damien
Begin forwarded message:
From: Damien Katz
Date: February 23, 2009 9:09:09 AM EST
To: u...@couchdb.apache.org
Subject: Re: Fail on a simple case on replication
Reply-To: u...@couchdb.apache.org
Revisions are made available as a convenience, but CouchDB doesn't
replicate old revis
mien Katz
Date: February 23, 2009 9:09:09 AM EST
To: u...@couchdb.apache.org
Subject: Re: Fail on a simple case on replication
Reply-To: u...@couchdb.apache.org
Revisions are made available as a convenience, but CouchDB doesn't
replicate old revisions, only the most recent. Also compaction will
remov
> - Don't call them revisions, call them "turd blossoms" or "hobo socks".
> People won't know what they are, but at least they won't misuse them.
+1 as revision is too tied up to CVS and friends. I'm no so sure about
turd blossoms though ;)
U
To: u...@couchdb.apache.org
Subject: Re: Fail on a simple case on replication
Reply-To: u...@couchdb.apache.org
Revisions are made available as a convenience, but CouchDB doesn't
replicate old revisions, only the most recent. Also compaction will
remove old revisions as well.
-Damien
O
51 matches
Mail list logo
