incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <nate-li...@calftrail.com>
Subject Re: Adding fields to _user db
Date Thu, 08 Nov 2012 19:34:05 GMT
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 <wordituk@gmail.com> 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


Mime
View raw message