Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of francisco.treacy@gmail.com
 designates 209.85.220.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=amFs12llo/gZhJ9bfRj7clz0qPZ7omAmnL+kWAVKbo4vLwCBGt4cMs1y4nYXCAVnM4
         g5h727slwmcXEBj5G5NBkR/tgK0ULBQRSFbaYFjx3yxkATP5VyeHhp3G6ZCIZOKhtLZL
         OAk0cdK8x9y8qBe0saxoUvuBYZNV4Ock+puDc=
MIME-Version: 1.0
In-Reply-To: <e2111bbb0908261516k10b515ddr58c195e2357de442@mail.gmail.com>
References: <41c8480f0908260733o14970a39nbf1e2f8f4742fd7b@mail.gmail.com>
	 <e2111bbb0908260737j355dc848lcc80c954ce7383a8@mail.gmail.com>
	 <41c8480f0908261503i7f4206dbl64597d88c5574834@mail.gmail.com>
	 <e2111bbb0908261516k10b515ddr58c195e2357de442@mail.gmail.com>
Date: Thu, 27 Aug 2009 00:30:54 +0200
Message-ID: <41c8480f0908261530v1f7f1cb0oe3810e73e7bdead3@mail.gmail.com>
Subject: Re: underscores in json keys
From: francisco treacy <francisco.treacy@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Makes sense.

Thanks, Paul.

Francisco

2009/8/27 Paul Davis <paul.joseph.davis@gmail.com>:
> On Wed, Aug 26, 2009 at 6:03 PM, francisco
> treacy<francisco.treacy@gmail.com> wrote:
>> Oh, ok.
>>
>> This means the cornerstone of my library is built upon a bug :)
>
> I wouldn't say that. There's nothing that keeps your library from
> reserving a prefix for its internal use. You're free to use anything
> like $ or # or even use a _ suffix.
>
>> Is there any way I can define such a key, in order to interfere as
>> less as possible with library user's data? (i was thinking perhaps
>> externals some way to define some "reserved" keys?)
>
> The only two approaches would be convention and nesting. If you want
> to make sure you can store anything at all with the library, the only
> real answer is to create an object like {"_id": "foo", "user_data":
> ...} but just using another non-underscore prefix wouldn't be too far
> out of the question. Granted you might want to see if anyone else has
> nominated one for consistency across libraries.
>
> HTH,
> Paul Davis
>