couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cinnebar <>
Subject Re: Initial couchdb accounts feedback
Date Sun, 10 Jan 2010 18:24:39 GMT
technically it is the user db rather than the users db.

> _usr or _user would seem to make sense to me, since the _ is reserved
namespace in couchdb (e.g. _id and _rev).

> Yeah, "magic" fields should have a leading underscore to show they are
> in the reserved namespace, but let's not drop the 'e' in user, it's
> not the 60's anymore, we don't need to sacrifice readability to gain
> an extra byte.

i follow the logic of the pattern of underscoring feilds such as _id and
_rev but i dont think it follows that then the user db name should also be
underscored. if anything to maintain the pattern "roles" should be
underscored if its a reserved namespace field but i dont think this would be
necessarily justified.

what name is given to the user db appears to be more a question of common
practice and dogma in systems architecture rather than a sacrifice of
readibility. id and rev dont appear to sacrifice readibility.  convention
based on dogma is drag whichever era or social band spawned it.  succinct is
better for eg _id and _rev are readable but they are missing loads of

> 'usr' is typically from UNIX filesystem hierarchy, which is a horrendous

this relates more to the unix architecture than the particular use of 'usr'

>  I quite like using full english names where that doesn't mean wasting too
much space.

i agree but things like the name of the user db are structural underpinnings
rather than simple data so applying a naming convention to distinguish the
set actually improves readability and resolves other issues, in my

we will be using 'usr' to name the user db no matter what, for a number of
reasons that may be unique to our doc/system architecture at present, the
only issue we have is that changing the hardcoded default a) would be an
irritating manual correction on each realease or b) a patch to allow
overriding the default may compromise security to some degree.

the only reason i am posting on this thread is because the changes
significantly affect our use of couchdb.
more time is needed to look into the issues here but chris seems to be
moving fast so...

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message