couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Antivackis <patrick.antivac...@gmail.com>
Subject Re: Fail on a simple case on replication
Date Mon, 23 Feb 2009 16:19:05 GMT
OK , upadated :
http://wiki.apache.org/couchdb/Document_revisions

Created :  http://wiki.apache.org/couchdb/Replication (need more work)

2009/2/23 Jan Lehnardt <jan@apache.org>

>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message