couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: any good way of filtering out your own _changes?
Date Thu, 04 Oct 2012 10:08:22 GMT
On 4 October 2012 10:51, svilen <> wrote:
> ah bandwidth nor speed doesnt matter, correctness does.
> it's about not processing something that was already processed (e.g.
>  because of new message, email was sent. and should not happen again.
> or the document just written was on screen, and should not be "news" to
> this same user/app)
> what do u mean.. "incoming update doesn't force a refresh" ... it
> should do a refresh, how user would see it then.. i am even thinking
> that in some cases my own changes can be handled same as external
> updates.. but not in all case.
> svil
> On Thu, 4 Oct 2012 10:20:56 +0200
> Dave Cottlehuber <> wrote:
>> On 4 October 2012 08:35, svilen <> wrote:
>> > so noone to suggest something?
>> >
>> >> > so i have a local db that replicates bidirectional with several
>> >> > others. an app uses local db, listens to _changes and also puts
>> >> > things sometimes. Any way to avoid it seeing it's own changes?
>> >
>> >> > i guess i can put a manual field e.g. "source" to *each*
>> >> > document or something... but that's not very neat. but may be
>> >> > the only way, hmmm - e.g. how to differ between different copies
>> >> > of same app.. running in parallel.
>> >
>> > svil
>> I keep thinking that the right way to do this is to handle messages in
>> such a way that an incoming update doesn't force a refresh. This would
>> mean keeping a list of posted doc ids and simply removing them from
>> the list of pending "reverse updates" when they did come in. Depending
>> on what UI you are using, something like backbone's models might even
>> take care of that for you.
>> It's a question of volume - do you want to replicate *all* docs (easy,
>> no load for filtered replication), and absorb a little more network
>> bandwidth, or do you want to add an extra field, save the bandwidth,
>> and then use filtered replication which will mean running an
>> additional check on every replicated document for every user for every
>> chat room?
>> The former is IMHO far better. Although using an erlang filter would
>> be wicked fast.
>> Some reading for you around hooking couch to backbone:
>> A+
>> Dave

Pseudo code goes here:

when the user creates an event "new chat message"
- update the UI immediately
- stash the doc id in an array
- send an async update to the appropriate DB

when the _changes feed has a new doc event:
- check if the id is in the array
    - if so, skip the UI update
    - remove the id from the array (so it doesn't get larger over time)
- if not, update the UI accordingly.

Again, read the provided links, in particular
has a chat application that does exactly what you're asking for. But
you can implement the approach without backbone etc.


View raw message