The built-in validation function prevents you from storing *other* document types in the _users database. I don't know of any problems, in practice, to storing additional fields *within* user documents. You should prefix them (or isolate them within an app-specific key) however, to avoid issues should CouchDB assign a future meaning to a field name you picked.
The catch, though, is that these fields will not currently be passed via the "userCtx" field to validation, filter, show/list, etc. functions as you might expect. There was some discussion of this at one point, and perhaps a JIRA ticket was filed, but if you need to pass additional data to design doc functions you'll need to resort to creative use of the roles array for now ;-) regards, -natevw On Oct 4, 2012, at 11:10 PM, svilen wrote: > +1 on the question > > i am still undecisive whether to use _users (and put all profile > data there), make separate db, and live with the ~joins, or use > completely separate (~already made) non-couchdb thing - in my case it's > no much difference. > > if internaly it is not any special than other databases, it should be > no big deal storing couple of fields extra. > syncpoint is using it this way. > > But i dont know about overdoing it, say adding attachments e.g. photo? > will that screw anything? > > i am thinking that if it gets too big it will be because of number of > users not because single user-data is big. but i may be wrong.. > > svil > > > i intend to do same anyway. > On Fri, 5 Oct 2012 03:49:52 +0200 > Wordit <[email protected]> wrote: > >> I've read before that you are not supposed to store any other data in >> the _users database except what's already there. Thing is, I need to >> use a nickname for users since their email address is their username >> (that's what BrowserId, Google OpenID etc use). >> >> Adding a nickname field should be the easiest way to hide their >> email/username. I've tried creating a hash of the username in a >> profile document and storing the nickname there, but it makes things >> very complex (e.g. see my post about CommonJS) and uses more >> resources. >> >> Design-wise it makes most sense to me to store the nickname in the >> _users db since this is directly related to the user's identity. Their >> actual username, being an email address, needs to be hidden. Is there >> a good reason not to do this? >> >> Marcus
