underscores in json keys

[francisco treacy <fr...@gmail.com>]

Hi,

I'm storing documents like this in CouchDB 0.9

{"_id":"_design/surf","_rev":"1-455975032","_type": "mytype" }

without any problem.

However apparently it does not work on CouchDB 0.9.1:

Response while PUTting:  HTTP 500:
{"error":"doc_validation","reason":"Bad special document member:
_type"}

Could you tell me what the policy is for underscored keys, is it
allowed or not? Has this changed between releases?
I would like to keep my Scala CouchDB client up-to-date.

Thank you,

Francisco

Re: underscores in json keys

[Brian Candler <B....@pobox.com>]

On Wed, Aug 26, 2009 at 06:16:10PM -0400, Paul Davis wrote:
> 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.

I had a think about this a while back. I reckoned that $ was the best prefix
to use, since it keeps the Javascript use simple - no square brackets
required.

  doc.$created
  doc.$updated
  etc

But right now I'm using a separate member for user data as Paul also
suggested:

  {"created":...,
   "updated":...,
   "settings":{"user":"stuff"}
  }

Re: underscores in json keys

[francisco treacy <fr...@gmail.com>]

Makes sense.

Thanks, Paul.

Francisco

2009/8/27 Paul Davis <pa...@gmail.com>:
> On Wed, Aug 26, 2009 at 6:03 PM, francisco
> treacy<fr...@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
>

Re: underscores in json keys

[Paul Davis <pa...@gmail.com>]

On Wed, Aug 26, 2009 at 6:03 PM, francisco
treacy<fr...@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

Re: underscores in json keys

[francisco treacy <fr...@gmail.com>]

Oh, ok.

This means the cornerstone of my library is built upon a bug :)

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?)

Anyways thanks!

Francisco


2009/8/26 Paul Davis <pa...@gmail.com>:
> On Wed, Aug 26, 2009 at 10:33 AM, francisco
> treacy<fr...@gmail.com> wrote:
>> Hi,
>>
>> I'm storing documents like this in CouchDB 0.9
>>
>> {"_id":"_design/surf","_rev":"1-455975032","_type": "mytype" }
>>
>> without any problem.
>>
>> However apparently it does not work on CouchDB 0.9.1:
>>
>> Response while PUTting:  HTTP 500:
>> {"error":"doc_validation","reason":"Bad special document member:
>> _type"}
>>
>> Could you tell me what the policy is for underscored keys, is it
>> allowed or not? Has this changed between releases?
>> I would like to keep my Scala CouchDB client up-to-date.
>>
>
> The 0.9.0 behaviour is a bug. You should be able to see it by trying
> to store an integer value like {"_type": 2} which should be rejected.
>
>> Thank you,
>>
>> Francisco
>>
>
> HTH,
> Paul Davis
>

Re: underscores in json keys

[Paul Davis <pa...@gmail.com>]

On Wed, Aug 26, 2009 at 10:33 AM, francisco
treacy<fr...@gmail.com> wrote:
> Hi,
>
> I'm storing documents like this in CouchDB 0.9
>
> {"_id":"_design/surf","_rev":"1-455975032","_type": "mytype" }
>
> without any problem.
>
> However apparently it does not work on CouchDB 0.9.1:
>
> Response while PUTting:  HTTP 500:
> {"error":"doc_validation","reason":"Bad special document member:
> _type"}
>
> Could you tell me what the policy is for underscored keys, is it
> allowed or not? Has this changed between releases?
> I would like to keep my Scala CouchDB client up-to-date.
>

The 0.9.0 behaviour is a bug. You should be able to see it by trying
to store an integer value like {"_type": 2} which should be rejected.

> Thank you,
>
> Francisco
>

HTH,
Paul Davis