Assuming that username == doc._id constrains how you can use the sl_users couch database. about superlogin

[tohagan]

Hmmm ... Maybe I just need to chat with you sometime. I think theses username are the session generated ones so probably can ignore my rant.

[colinskow]

CouchDB databases are very cheap. I never contemplated a compelling use case where there would be an advantage to mixing other types of docs into the sl_users database. Any custom object that has a 1:1 relationship with a user, you can safely put inside the user doc.

If you have a use case where there is a huge advantage to mix other documents into sl_users tell me about it, and I'll see what we can do to accommodate.

[colinskow]

If you want to chat, I am in #SuperLogin on the PouchDB Slack. Afternoon California time works best. Let me know when and we can set a time.

[tohagan]

Yes I understand disk space cost is very small (16k for an empty db). I understand the security model reasons for having per user dbs. I've spent the last 10 months studying everything I can find about CouchDb and PouchDb.

In my case I need to create view(s) that emit/reduce user and group objects (many to many) in the one view so these object types must share the same database. My users also have different roles per group and may eventually have additional attributes on this M:M relation. I will likely use "per user" databases as well but groups and many other shared data objects of my schema won't fit here. I will need to support replication of these and many other shared object types to other couch servers (not pouch) and having multiple replications that don't preserve object insert sequence order would be painful. I also want to be able to perform single updates with multiple doc types using bulk_update (like a transaction) which I can't do if the db is split into multiple dbs. I may also need to watch changes to these shared objects in a single change feed. I also want to only create a single validation doc in this db to manage the schema (not split it up into "per object type" databases).

So in short there are many reasons to use a single couch db for shared data. I'm sure other devs will hit the same issues. This generally means you need to use _id prefixes to avoid key collisions and ensure efficient per type queries using startkey/endkey based of the prefix which avoids overheads of maintaining a view index for each object type.

Cheers,
Tony

On 26 Apr 2016, at 4:52 pm, Colin Skow [email protected] wrote:

CouchDB databases are very cheap. I never contemplated a compelling use case where there would be an advantage to mixing other types of docs into the sl_users database. Any custom object that has a 1:1 relationship with a user, you can safely put inside the user doc.

If you have a use case where there is a huge advantage to mix other documents into sl_users tell me about it, and I'll see what we can do to accommodate.

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub

[colinskow]

To summarize our Slack discussion, I am going to check for type === 'user' in the CouchDB views, and we will add an optional prefix to the user _id. We will also provide a conversion script to prefix the users in the database.

[tohagan]

Thanks Colin.