Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1283)
Subject: Re: Adding fields to _user db
From: Nathan Vander Wilt <nate-lists@calftrail.com>
In-Reply-To: <20121005091019.7e166a00@svilendobrev.com>
Date: Thu, 8 Nov 2012 11:34:05 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B2FEF1C-621B-4D9C-B501-4507425000C3@calftrail.com>
References: 
 <CALOE=ztS2-ZqAAPESH3=otkY9zmCBR1FcjAqNci7=tWLF2p1=A@mail.gmail.com>
 <20121005091019.7e166a00@svilendobrev.com>
To: user@couchdb.apache.org

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
>=20
> 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.
>=20
> if internaly it is not any special than other databases, it should be
> no big deal storing couple of fields extra.=20
> syncpoint is using it this way.=20
>=20
> But i dont know about overdoing it, say adding attachments e.g. photo?
> will that screw anything?=20
>=20
> 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..
>=20
> svil
>=20
>=20
> i intend to do same anyway.
> On Fri, 5 Oct 2012 03:49:52 +0200
> Wordit <wordituk@gmail.com> wrote:
>=20
>> 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).
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> Marcus