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 <[email protected]>wrote: > On Thu, Oct 29, 2009 at 7:19 PM, Julian Goacher > <[email protected]> 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 >
