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:43:55 GMT

On 23 Feb 2009, at 16:40, Patrick Antivackis wrote:

> May be i can start a wiki page on replication, but i think the
> http://couchdb.apache.org/docs/overview.html should be clarified too.

Hey yeah, feel free to add new pages and fi existing ones as you
see fit, thanks! :)

Cheers
Jan
--
(Still +1 for the rename :)

>
>
>
> 2009/2/23 Jan Lehnardt <jan@apache.org>
>
>>
>> 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