Adding custom views to users database

[peteruithoven]

Superlogin has configuration to create design docs (defined in files) to public and private databases. This enables including this code in version control, use linting tools, our own IDE's etc. It also enables more easilly starting a new database.

Superlogin doesn't however seem to have a way to add design docs and/or views to the users database. It seems to only load it's own design doc: https://github.com/Doodle3D/superlogin/blob/master/lib/index.js#L49-L52

Would be great if we could include a config that would point to additional design docs for this database.

[clariontools]

@peteruithoven - Generally the design doc of the userDB (aka sl-users) covers all the needs of all the code and functionality contained in superlogin code. This would not be the case for public or private dbs as part of your application logic. So the first concern is that by changing the userDB design doc you could break functionality of superlogin inadvertently. I am curious about the use cases of such a feature.

Also, it would be a bit different for the userDB which already has a predefined design doc, are you suggesting a complete replacement, or some sort of additive capability when it is first created?

[peteruithoven]

Definitely additive, maybe even with a warning when replacing existing views, to prevent as you mention existing functionality. Our biggest usecase was performing analytics, being able to retrieve relevant user information. This requires getting very application specific data, think of payment plan, etc.

[clariontools]

@peteruithoven - Yeah, in fact I have written a bunch of code in highly customized profile.js, but while I am loading that up with all sorts of data, I didn't get to the point yet of thinking about performing analytics or other administrative processes on the server side. I agree, the warning would be a good thing if replacing any existing views.

I will probably circle around to this when I get to the point of using all the data I am cramming into the userDB. In the meantime, the big issue facing superlogin is how to proceed with enhancements like this in the absence of "Master Colin Skow" :calendar:

[peteruithoven]

To add to the above, stuff get's more tricky when you need information from the all the users their private database. We for example liked to see how many documents they created in their database.

This meant after queering the users database also needed to query each user's private database, which as you can guess is really time consuming. One plan we had was to add some derived data to the user doc. This derived data can easily be updated by the application and than we only need one query on a custom view.

[clariontools]

I guess if you use Cloudant, they have features to aggregate data across individual user dbs, so that may eventually make its way into CouchDB :crossed_fingers: , but it is a bit scary to think about doing that sort of thing with CouchDB at the moment.

This derived data can easily be updated by the application and...

So would you then update the derived data from the user private dbs to the "sl-users" via a superlogin endpoint or through some other mechanism? What is the benefit of using "sl-users" versus another shared CouchDB database to store all the aggregate data with a relation to the _id of "sl-users"?

[peteruithoven]

So would you then update the derived data from the user private dbs to the "sl-users" via a superlogin endpoint or through some other mechanism?

So for example beside adding a document to their private database we would also update a field in their user doc in the users database.

What is the benefit of using "sl-users" versus another shared CouchDB database to store all the aggregate data with a relation to the _id of "sl-users"?

Because we'd keep as much of the user's data in one place, in their user doc.