c# - Is this a reasonable approach to a .NET custom role provider for a solution utilising couchbase? -

c# - Is this a reasonable approach to a .NET custom role provider for a solution utilising couchbase? -

i'm looking @ putting .net role provider couchbase utilize in project. i'm looking model in 2 document types.

the first document type simple list of of roles available in application. makes easy back upwards add, delete, getallroles etc. document have fixed key per application, "applicationname_roles" known codes point of view , retrievable.

the sec document maps user role, example

{ "type": "roleprovider.user-role", "user": "user1", "role": "role1", "application": "app1" }

the key document type of format "applicationname_roles_username_rolename", making mutual operation of testing if user in particular role trivial , quick.

to back upwards getrolesforuser or getusersinrole methods of .net role provider i'm looking @ using view of form.

function (doc, meta) { if(meta.type != 'json') { return; } if (doc.type == "roleprovider.user-role") { if(doc.application && doc.user && doc.role) { emit([doc.application, "user:" + doc.user, doc.role]); emit([doc.application, "role:" + doc.role, doc.user]); } }}

so every user role mapping 2 rows emitted view. first allows query view roles user in. sec users in role. .net provider needs prefix either "user:" or "role:" based on wether or not querying getrolesforuser or getusersinrole filter downwards on needs.

so question, seems reasonably trivial , logical, first time i've worked couchbase , wondered if falling traps this? obvious alternative approach utilize 2 views, in reading i've seen mentioned best maintain number of design documents downwards , number of views within downwards well, see perry krug's reply in couchbase views per bucket discussion, in mentions trying 'generate multiple different queries off of 1 index'. i'm wondering if approach i've described above prescribing perry saying, or if i'm tricking myself , going cause myself pain downwards line.

thanks pointers.

(note: resurrecting ancient question because it's not been answered yet, , might involvement else.)

your approach in general sound. but, unless you're experiencing performance issues, stick 1 view per query type in case. while combining multiple queries single view cut down amount of work couchbase needs build views, increment cost of each query, have scan index that's twice large. if you're not using many other views @ same time, maintain views separate. in fact, set them in different design documents, couchbase process them concurrently different indexer threads. there's no need prematurely optimize performance problem doesn't exist yet; go straightforward solution first, optimize if necessary.

if run performance problem query reads, may need consider moving views key/value based approach. specifically, storing separate document every application-user , application-role pair, , appending list of roles former , users latter. means end maintaining indexes yourself, give order of magnitude improvement in read latency. take @ this blog maintaining sets append operations.

yes, see irony in advocating against premature optimization in 1 paragraph , suggesting performance optimization in next. i'd emphasize should first test whether view approach gives acceptable performance - , reasonable applications - , if does, stick because it's much more straightforward. if find need improve performance after all, start looking sec alternative.

c# couchbase roleprovider couchbase-view