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 <[email protected]> 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 <[email protected]> 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 >> >> >
