couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <m...@boutiquing.com>
Subject Re: Replication filter ignoring deleted docs or changed values
Date Sun, 10 Jul 2011 20:38:55 GMT
This is similar to the problem that replication conflicts don't make
the old versions available so it is impossible to know what changed,
which makes it near impossible to resolve a conflict.

On Sun, Jul 10, 2011 at 11:35 AM, Zachary Zolton
<zachary.zolton@gmail.com> wrote:
> Mitja,
>
> Perhaps you could record in some other field that the doc with type
> "bar" used to be type "foo".
>
> Then way you can filter the replication by docs where:
>  type == "foo" || type == "bar" && old_type == "foo"
>
> This should then replicate docs that change their type from "foo" to "bar".
>
> To give any better advice, I'd need to hear more concretely what
> you're trying to do here.
>
> -Zach
>
> On Sunday, July 10, 2011, Mitja Kleider <mitja@kleider.name> wrote:
>> On Sat, 2011-07-09 at 17:26 -0500, Zachary Zolton wrote:
>>> Could you change your filter to something like this?
>>>
>>> function(doc) {
>>>   return doc._deleted || doc.type == 'foo';
>>> }
>>>
>>> That way you replicate all deleted docs.
>>
>> That would work, thanks. I tried to avoid replicating millions of
>> deleted documents together with a few hundred documents passing the
>> filter.
>>
>> A solution might be this validate_doc_update function on the target
>> database:
>>
>> function(newDoc, oldDoc, userCtx) {
>>     if (newDoc._deleted === true && !oldDoc) {
>>         throw({forbidden: 'do not create deleted docs'});
>>     }
>> }
>>
>> This way all deleted documents will be transmitted, but at least not
>> written if there is no previous revision.
>>
>>
>> The problem for changed values remains: when the source database changes
>> type='foo' to type='bar', the target database keeps the old revision
>> with type='foo'.
>>
>>
>> Mitja
>>
>>
>

Mime
View raw message