Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Excluding channels from replication using sync_gateway/bychannel filter #1960

Closed
adamcfraser opened this issue Jul 14, 2016 · 4 comments
Closed

Comments

@adamcfraser
Copy link
Collaborator

adamcfraser commented Jul 14, 2016

There are scenarios where users would like to synchronize "all channels except X" - particularly for the case where the set of desired channels changes frequently.

To address this case, we could allow excluded channels to be defined when using the by channel filter using the format channels = ["- channelname"] - in this case the changes feed will return all channels the user has access to except for the specified channel.

A concern is that a combination of excluded and included channels doesn't really make any sense - setting channels=["channelA" "-channelB"] isn't meaningful, since "-channelB" means everything except channelB (including channelA) will already be included.

An alternative approach would be to define a sync_gateway/exceptchannel filter for this scenario.

@adamcfraser
Copy link
Collaborator Author

@adamcfraser adamcfraser added this to the 1.4 milestone Jul 14, 2016
@adamcfraser
Copy link
Collaborator Author

adamcfraser commented Jul 14, 2016

The exclude filter wouldn't be compatible with admin API requests, or requests by users that have * channel access, since changes processing isn't based on a set of channel feeds in those scenarios (which could be excluded) - it's instead based on working the * channel feed. The performance overhead to exclude results from the * feed on a record-by-record basis isn't feasible.

@househippo
Copy link

@adamcfraser I think this is touching on CBL being aware of channels they have access to.

@adamcfraser adamcfraser modified the milestones: 2.0, 1.4 Sep 7, 2016
@adamcfraser adamcfraser removed this from the 2.0.0 milestone Mar 14, 2017
@adamcfraser
Copy link
Collaborator Author

Closing this, as the complexities listed above outweigh the potential benefit. Can reopen if there's a specific use case that can't be handled otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants