couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Fail on a simple case on replication
Date Mon, 23 Feb 2009 15:30:32 GMT

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 Couch

Damien is not saying the usage is wrong in CouchDB, but people
associate more with "revision" than he'd like. Hence the proposal.


> I think a good explanation of what a compaction/replication are  
> doing (ie
> removing  old rev, or replicating only current rev) is the right  
> solution to
> this misunderstanding

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 other purpose
than concurrency control." in bold letters.

I stated this in earlier discussions as well: Even if our documentation
were perfect, we don't control how people learn about CouchDB. We
only control the API and we should work hard to get it right.

The way it stands now, a lot of people new to CouchDB get it wrong
because "revision" is a familiar term and they associate the behaviour
they associate with it to them. That's how humans learn. In this case
we make the learning hard.

Cheers
Jan
--


> - Remove the ability to get old revisions
>>>
>>
> -1 : This functionnality is interesting for some case studies
>
> - Make it much harder/verbose to get old revision
>
>
> -1 : I don't see the utility of this
>
> - Make the api to get old revisions something like
>>> "?old_rev_that_might_still_be_on_disk=...."
>>
>>
> 0 :
>
>
>> - 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
>
>
>>
>>
>>
>>
>>> -Damien
>>>
>>> Begin forwarded message:
>>>
>>> From: Damien Katz <damien@apache.org>
>>>> Date: February 23, 2009 9:09:09 AM EST
>>>> To: user@couchdb.apache.org
>>>> Subject: Re: Fail on a simple case on replication
>>>> Reply-To: user@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
>>>>
>>>> On Feb 23, 2009, at 9:00 AM, Manolo Padron Martinez wrote:
>>>>
>>>> Hi:
>>>>>
>>>>> I'm trying to test the replication process with two local  
>>>>> database and I
>>>>> found that replication process don't work as it should (or as I  
>>>>> think it
>>>>> would)
>>>>>
>>>>> The case:
>>>>>
>>>>> 1º Create a db called t2.
>>>>> 2º Create a document called terminator.
>>>>> 3º Add a property to the document, so that makes a new revision,  
>>>>> with a
>>>>> property called speed and the value 1
>>>>> 4º Create a new db called t3.
>>>>> 5º Launch replication process from t2 to t3.
>>>>>
>>>>> In t3 should be a document with two revisions, and if I point to
>>>>> "t3/terminator?revs=true" appears two revisions. If I try to get  
>>>>> the
>>>>> last
>>>>> revision it works as it should but If I try to get the first  
>>>>> revision
>>>>> (the
>>>>> one without properties) I get a "not found" message.
>>>>>
>>>>> In t2 database, this works without problems so I think that is a  
>>>>> problem
>>>>> with replication.
>>>>>
>>>>> I've tried with debian , with the lastest in the web (0.8.1),  
>>>>> and the
>>>>> trunk
>>>>> svn version with the same results.
>>>>>
>>>>> Anyone could help me or the terminator will kill me? :-)
>>>>>
>>>>> Thanks in advance
>>>>>
>>>>> Manolo Padrón Martínez
>>>>>
>>>>
>>>>
>>>
>>


Mime
View raw message