You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Julian Goacher <ju...@gmail.com> on 2009/10/29 23:47:20 UTC
Proposal regarding reserved names
Hello,
With respect to http://wiki.apache.org/couchdb/Reserved_words: I'm a
developer currently writing an application framework layered over couchdb.
The framework needs to annotate user documents with additional state
information. Prior to recent releases, my framework used property names
beginning with an underscore to store these annotations (following the
convention that such names are separate from the user data). As things
stand, this is no longer possible, but I was wondering if the couchdb dev
team would consider allocating a specific property name - e.g. something
like _meta - specifically for this use case. The idea would be that the
property could then be used by third party developers to house any values
considered orthogonal to the document data.
Example:
{
"_meta":{
"plink_framework_property_a": 23,
"plink_framework_property_b": "2009-10-29T00:00:00Z"
}
}
Regards,
/julian
Re: Proposal regarding reserved names
Posted by Julian Goacher <ju...@gmail.com>.
Using a $ prefix is my fallback position.
My proposal is predicated on the idea that the user is aware of the _
contract - i.e. they know they are using couchdb. I'm looking for a way to
piggyback on the convention that such names are private or system names, and
trying to avoid adding a new convention - e.g. using a $ prefix.
Are there particular technical considerations against such a property, or is
it just a desire to avoid cluttering up the namespace?
(Also, would it be preferable to move this conversation to the dev list?)
Regards,
/julian.
On Fri, Oct 30, 2009 at 10:44 AM, Brian Candler <B....@pobox.com> wrote:
> On Thu, Oct 29, 2009 at 11:19:18PM +0000, Julian Goacher wrote:
> > I think this is a slightly different use case though. The framework sits
> as
> > a layer between the user and the db; I don't want the user to wrap their
> > data to use the framework. Rather, I want to annotate a user generated
> > document with additional data - which is essentially what the existing
> > underscored names currently do.
>
> I make the following observation: if you don't want to wrap the user's
> object, then you must already have a contract with your user that the
> object
> they are storing must not have any property starting with an underscore
> (because that would be rejected by CouchDB).
>
> So why not just extend this contract to say that they cannot have a
> property
> called $meta or meta_ or some other property name that you reserve?
>
> Regards,
>
> Brian.
>
Re: Proposal regarding reserved names
Posted by Brian Candler <B....@pobox.com>.
On Thu, Oct 29, 2009 at 11:19:18PM +0000, Julian Goacher wrote:
> I think this is a slightly different use case though. The framework sits as
> a layer between the user and the db; I don't want the user to wrap their
> data to use the framework. Rather, I want to annotate a user generated
> document with additional data - which is essentially what the existing
> underscored names currently do.
I make the following observation: if you don't want to wrap the user's
object, then you must already have a contract with your user that the object
they are storing must not have any property starting with an underscore
(because that would be rejected by CouchDB).
So why not just extend this contract to say that they cannot have a property
called $meta or meta_ or some other property name that you reserve?
Regards,
Brian.
Re: Proposal regarding reserved names
Posted by Chris Anderson <jc...@apache.org>.
On Sat, Oct 31, 2009 at 8:07 AM, Julian Goacher
<ju...@gmail.com> wrote:
> OK, I know this is a fairly minor issue, and I have workable alternatives so
> I'm not going to push this too hard, but I'm going to try making one last
> pitch for this in the hope of garnering some interest.
>
> My proposal has to be understood from the perspective of a library
> developer, not an application developer. Given any application based on
> couchdb, my library performs a support function for that application - in
> this case, providing workflow functionality. As part of its operation, the
> library needs to record a small amount of state information related to each
> document. There are many ways to record this data, but recording it on the
> document directly seems the easiest and most natural way.
>
The problem with opening up a user-controlled _annotation namespace
is: how you can you be sure other libraries aren't stepping on your
library's toes in there? The underscore doesn't really make it
special, if anyone can write to it.
The desktopcouch project has been working on some guidelines for
interoperability [1] between multiple applications dealing with the
same documents (think about using simultaneously, a web-based and a
desktop-based interface to your address book.)
They have a similar field they call application_annotations. You might
want to explore this discussion to see how other engineers have solved
a similar problem.
[1] http://groups.google.com/group/desktop-couchdb/browse_thread/thread/e72c8966f48d532d/8a09d2fdb1f2d0e3
> I certainly wouldn't see this as 'punching a hole' in
> the reserved word scheme - its simply allocating part of the scheme for a
> particular usage.
>
> Anyhow, I'll leave it at that.
>
Keep up the interest, and also remember that patches are what really
counts for CouchDB.
Best,
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Proposal regarding reserved names
Posted by Julian Goacher <ju...@gmail.com>.
OK, I know this is a fairly minor issue, and I have workable alternatives so
I'm not going to push this too hard, but I'm going to try making one last
pitch for this in the hope of garnering some interest.
My proposal has to be understood from the perspective of a library
developer, not an application developer. Given any application based on
couchdb, my library performs a support function for that application - in
this case, providing workflow functionality. As part of its operation, the
library needs to record a small amount of state information related to each
document. There are many ways to record this data, but recording it on the
document directly seems the easiest and most natural way.
Now, rightly or wrongly, I tend to see couchdb's reserved words as being in
a 'document annotation' namespace. The information stored in these
properties is used exclusively at the moment by couchdb for managing its own
state. My proposal is really asking the question whether the is an argument
for opening up a small section of that namespace for use by third-party
developers of libraries based on couchdb, for adding annotations specific to
their requirements. I certainly wouldn't see this as 'punching a hole' in
the reserved word scheme - its simply allocating part of the scheme for a
particular usage.
Anyhow, I'll leave it at that.
Thanks,
/j
On Fri, Oct 30, 2009 at 3:01 AM, Paul Davis <pa...@gmail.com>wrote:
> On Thu, Oct 29, 2009 at 7:19 PM, Julian Goacher
> <ju...@gmail.com> wrote:
> > Hi Paul,
> >
> > I think this is a slightly different use case though. The framework sits
> as
> > a layer between the user and the db; I don't want the user to wrap their
> > data to use the framework. Rather, I want to annotate a user generated
> > document with additional data - which is essentially what the existing
> > underscored names currently do.
>
> If you have a layer between the user and the db then I don't see what
> would be cleaner than using a nested object. Otherwise your user has
> to face the fact that none of their top level members are able to be
> underscore prefixed. There might be implications for M/R I guess, but
> that'd depend on how much framework there is.
>
> Bottom line, I'm not sure how much its gonna be worth it to special
> case _meta as a not reserved member. I'd need to be a bit more
> convinced before I'd say that punching a hole in the underscore prefix
> rule would be ok. As it is, you could just as well do $meta or
> something else without a difference.
>
> Paul Davis
>
Re: Proposal regarding reserved names
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Oct 29, 2009 at 7:19 PM, Julian Goacher
<ju...@gmail.com> wrote:
> Hi Paul,
>
> I think this is a slightly different use case though. The framework sits as
> a layer between the user and the db; I don't want the user to wrap their
> data to use the framework. Rather, I want to annotate a user generated
> document with additional data - which is essentially what the existing
> underscored names currently do.
If you have a layer between the user and the db then I don't see what
would be cleaner than using a nested object. Otherwise your user has
to face the fact that none of their top level members are able to be
underscore prefixed. There might be implications for M/R I guess, but
that'd depend on how much framework there is.
Bottom line, I'm not sure how much its gonna be worth it to special
case _meta as a not reserved member. I'd need to be a bit more
convinced before I'd say that punching a hole in the underscore prefix
rule would be ok. As it is, you could just as well do $meta or
something else without a difference.
Paul Davis
Re: Proposal regarding reserved names
Posted by Julian Goacher <ju...@gmail.com>.
Hi Paul,
I think this is a slightly different use case though. The framework sits as
a layer between the user and the db; I don't want the user to wrap their
data to use the framework. Rather, I want to annotate a user generated
document with additional data - which is essentially what the existing
underscored names currently do.
Regards,
/julian.
On Thu, Oct 29, 2009 at 10:59 PM, Paul Davis <pa...@gmail.com>wrote:
>
> Julian,
>
> There have been a few discussions on this. In the past the suggestion
> has always been to nest any user specified data in an object to avoid
> name collisions. Something akin to:
>
> {
> "_id": "foo",
> "_rev": "2-32acbd",
> "plink_framework_property_a": 23,
> "plink_framework_property_b": "2009-10-29T00:00:00Z",
> "body": {
> // user data here
> }
> }
>
> Paul Davis
>
Re: Proposal regarding reserved names
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Oct 29, 2009 at 6:47 PM, Julian Goacher
<ju...@gmail.com> wrote:
> Hello,
>
> With respect to http://wiki.apache.org/couchdb/Reserved_words: I'm a
> developer currently writing an application framework layered over couchdb.
> The framework needs to annotate user documents with additional state
> information. Prior to recent releases, my framework used property names
> beginning with an underscore to store these annotations (following the
> convention that such names are separate from the user data). As things
> stand, this is no longer possible, but I was wondering if the couchdb dev
> team would consider allocating a specific property name - e.g. something
> like _meta - specifically for this use case. The idea would be that the
> property could then be used by third party developers to house any values
> considered orthogonal to the document data.
>
> Example:
>
> {
> "_meta":{
> "plink_framework_property_a": 23,
> "plink_framework_property_b": "2009-10-29T00:00:00Z"
> }
> }
>
>
> Regards,
>
> /julian
>
Julian,
There have been a few discussions on this. In the past the suggestion
has always been to nest any user specified data in an object to avoid
name collisions. Something akin to:
{
"_id": "foo",
"_rev": "2-32acbd",
"plink_framework_property_a": 23,
"plink_framework_property_b": "2009-10-29T00:00:00Z",
"body": {
// user data here
}
}
Paul Davis
Re: Proposal regarding reserved names
Posted by Jan Lehnardt <ja...@apache.org>.
On 29 Oct 2009, at 23:47, Julian Goacher wrote:
> Hello,
>
> With respect to http://wiki.apache.org/couchdb/Reserved_words: I'm a
> developer currently writing an application framework layered over
> couchdb.
> The framework needs to annotate user documents with additional state
> information. Prior to recent releases, my framework used property
> names
> beginning with an underscore to store these annotations (following the
> convention that such names are separate from the user data). As things
> stand, this is no longer possible, but I was wondering if the
> couchdb dev
> team would consider allocating a specific property name -
For the record, suggestions for the future of CouchDB should be sent
to the dev@ mailing list.
Cheers
Jan
--
> e.g. something
> like _meta - specifically for this use case. The idea would be that
> the
> property could then be used by third party developers to house any
> values
> considered orthogonal to the document data.
>
> Example:
>
> {
> "_meta":{
> "plink_framework_property_a": 23,
> "plink_framework_property_b": "2009-10-29T00:00:00Z"
> }
> }
>
>
> Regards,
>
> /julian