Major Description
Currently Eventing limits the source of mutation to a bucket in 6.X and a single collection (more succinctly a bucket,scope,collection tuple). Where a set of drop downs allow the collection to be selected.
Listen To Location bucket.scope.collection
| Bucket | Scope | Collection |
|---|---|---|
| my_src_bkt V | _default V | _default V |
Consider a use case for a data cleansing function (remove old data, remove nulls, etc.) assume that we have a single (1) scope "say "prod" with fifteen (15) collections and want to run ther same function on each collection.
The current design requires 15 duplicate functions and is inefficient in both resources and processing. A single function could easily do this as follows using a wild card:
Listen To Location bucket.scope.collection
| Bucket | Scope | Collection |
|---|---|---|
| my_src_bkt V | prod V | * |
In this case the Eventing function would get all the mutation for bucket: my_src_bkt scope: prod in the mutations meta arg for OnUpdate(doc,meta) would be enhanced (in eventing to have another property say "src: { my_src_bkt, prod, collection_1 }" as follows:
{
|
cas: "1611785303022829568"
|
datatype: "json"
|
expiration: 0
|
flags: 33554438
|
id: "evtest0::1"
|
seq: 46430
|
vb: 557,
|
src: { my_src_bkt, prod, collection_1 }
|
}
|
The hard part is making the bucket alias be wildcard aware and referencing it, but this might be done under the hood based upon the new "src" property.
I this case I might have fifteen collections collection_1 through collection_15 but my common function will process mutations for all of them with one DCP connection set.
Of course since Eventing runs as full admin security is fine, however the wild card shuld be only allowed when RBAC is implemented only if the user has rights to the full scope.
