couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Goacher <julian.goac...@gmail.com>
Subject Re: Proposal regarding reserved names
Date Sat, 31 Oct 2009 15:07:31 GMT
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 <paul.joseph.davis@gmail.com>wrote:

> On Thu, Oct 29, 2009 at 7:19 PM, Julian Goacher
> <julian.goacher@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
>

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