incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Date Wed, 31 Dec 2008 13:40:08 GMT

On 31/12/2008, at 11:07 PM, Robert Dionne wrote:

> I understand the issue. I noted the use of _id versus id myself and  
> wasn't that put off by it, just seemed a quirk of the implementation.

Implementations quirks shouldn't be materialized in the API. They're a  
red flag that says "this wasn't designed", and IMO are always regretted.

But these aren't implementation quirks - Damien did think about this  
issue, I just think he weighted the competing issues wrongly.

> I realize you've likely written a lot of code a this point and have  
> run into reuse issues. It's not unusual to have different names for  
> the same thing if the context is different.

It's not unusual for APIs to be not as good as they could be,  
sometimes because of lack of thought, sometimes lack of knowledge.

I guess one either regards the fundamental nature of name identity to  
be important, or not. No value judgement intended.

>> 5. Use a '_meta' wrapper for the metadata. I don't see any  
>> technical cons, and IMO is by far the cleanest model. Name identity  
>> is preserved, it's arbitrarily extensible without scalability  
>> concerns, and is structural rather than lexical.
>
> It is clearly cleaner and has it's advantages, however I have to  
> agree with an earlier poster; "Putting them in a _meta group might  
> encourage aggregation and manipulation of the bookkeeping metadata  
> separately from the document, which to me sounds like a recipe for  
> trouble."

It might encourage, or might not. Orthogonally, however, what's wrong  
with treating and manipulating metadata separately from the document?  
To give a concrete example, I manipulate _id and _rev separately from  
the 'rest' of the document now, because _id + _rev uniquely identify  
an immutable value, and that value (the document) can be cached, keyed  
on _id + _rev, with no concern about cache invalidation. It's  
fantastic. Chris Anderson was surprised that I would want _id and _rev  
in a view that doesn't supply the document, and then allow my users to  
write to the document on that basis. That's an example of where  
someone (with much more Couch expertise than me) was guided by their  
own context and uses, to not see a particular way of using the system.  
That's no disrespect to Chris, but rather an indication that the  
application of general principals are a better way to do API design  
than the extrapolation of one's own experience or use cases. My goal  
is a design methodology driven as much as possible by an algebra of  
design principles. This has been done before in e.g. in programming  
language design, of which API design is a form. Sorry, pet topic of  
mine :/

IMO there are good reasons to allow the document and it's metadata to  
be separated cleanly, and even if I *couldn't* think of any use cases,  
the idea that one should discourage it without having rock solid  
technical reasons for saying that it *must* not be done, I think is  
wrong.

> This would be a more complex design than the current use of the  
> underscore at the top level of documents and would definitely  
> encourage a quite different implementation. I don't know the  
> internals enough yet to comment on this. The code there to date is  
> remarkably terse for what it does but this may just reflect the use  
> of Erlang.

Even if it's a bit more work for the implementation, I think the  
cleanliness that results is worth it. An implementation is built once,  
and used many times, and it's the uses/users of the system that should  
have priority.

BTW: That's not a criticism of the gatekeepers - I know they agree  
with this principle, because they've agreed to accept a more  
complicated file system layout implementation in order that database  
and design document/view names can be arbitrary.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The fact that an opinion has been widely held is no evidence whatever  
that it is not utterly absurd.
   -- Bertrand Russell



Mime
View raw message