So I was wondering about the capabilities of built in filters, whether mango based ones or otherwise.
I would like to add an option to PouchDB replication that only replicates the currently active documents but still handles deletions properly, so basically implementing a filter that ignored any deleted doc with the ability to pass in a query parameter that is the update_seq at the time the replication started so deletions after the replication started are still passed. The idea is that deletions that happen before the replications start are not transfered, but docs after that all operate as normal. One possibility is that PouchDB can write a design document with the filter and deal with all this itself, thats some extra complexity with the downside of how slow filters are. Another is that PouchDB can do this filtering client side, while we would still be transferring data we dont need, ignoring them coming out of the changes feed is hugely cheaper than fully processing them. However having something built in on the couch side would be a nice bonus here, would this be covered by the functionality mentioned here? On 16 April 2016 at 14:13, Adam Kocoloski <kocol...@apache.org> wrote: > For those who might not be following the blow-by-blow in JIRA and GitHub, > the Mango-based approach is now implemented and merged: > > https://github.com/apache/couchdb-couch/pull/162 > > It turned out to be a very compact and clean addition. Well done Nick! > > Cheers, Adam > > > On Mar 23, 2016, at 1:35 AM, Michael Fair <mich...@daclubhouse.net> > wrote: > > > > Looks like it. > > > > Though I was thinking these functions could operate over a list of lists, > > not just two lists. > > > > > > On Tue, Mar 22, 2016 at 8:12 PM, Adam Kocoloski <kocol...@apache.org> > wrote: > > > >> HI Michael, in the Mango world I think your intersection example would > be > >> satisfied by > >> > >> { “_readers”: { “$in”: user.authTokens } } > >> > >> Cheers, Adam > >> > >>> On Mar 22, 2016, at 5:37 PM, Michael Fair <mich...@daclubhouse.net> > >> wrote: > >>> > >>> What about some list operation functions? > >>> like "[one of the things in this list] is a member of [the things in > that > >>> list]"? > >>> > >>> One of the use cases I often see, and have wanted myself is per > document > >>> user authorization. Without trying to solve everything all at once, > >> being > >>> able to efficiently compare membership multiple lists as a filter would > >> be > >>> generically useful. > >>> > >>> > >>> Imagine the _users document contained "authTokens" which is simply a > list > >>> of strings or numbers that the user is authorized as. > >>> > >>> These authTokens would most likely represent group names that the user > >>> belonged to. The list is flat, not hierarchical. If a user is a > member > >> of > >>> Group 1, and Group 1 is a member of Group 2; then the authTokens list > >> will > >>> have both Group 1 and Group 2 in the list. (databasename_authTokens > would > >>> contain a database specific list of tokens.) > >>> > >>> How the list gets assigned is outside the scope here (let's just say > >>> there's either a management app or the app itself has to do it). > >>> > >>> Each doc then has an "_readers" list. It represents the list of > >> authTokens > >>> that have been given permission to read the document. > >>> > >>> > >>> The filter query could then be something like > "intersect(user.authTokens, > >>> doc._readers).length > 0" the intersect command returns a list of > >>> overlapping list members; the length of that list being the count of > >>> members in common; and being greater than 0; means there was at least > one > >>> match. > >>> > >>> > >>> > >>> Other functions would be: > >>> union: A list that is the combination of all lists with duplicates > >> removed > >>> filter: A list made from the first list, with all members of the other > >>> lists removed > >>> intersect: A list of only things in all lists > >>> outersect: A list of only things that exist on one of the lists > >>> member: A boolean where the length of the intersect > 0 (this would be > >>> better used in the example above) > >> > >> > >
