couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Volker Mische <volker.mis...@gmail.com>
Subject Re: Erlang vs JavaScript
Date Sun, 18 Aug 2013 11:54:59 GMT
On 08/18/2013 08:42 AM, Alexander Shorin wrote:
> On Sun, Aug 18, 2013 at 10:22 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> On Fri, Aug 16, 2013 at 9:58 PM, Alexander Shorin <kxepal@gmail.com> wrote:
>>
>>> On Fri, Aug 16, 2013 at 11:23 PM, Jason Smith <jhs@apache.org> wrote:
>>>> On Fri, Aug 16, 2013 at 4:49 PM, Volker Mische <volker.mische@gmail.com>
>>>> wrote:
>>>>>
>>>>> On 08/16/2013 11:32 AM, Alexander Shorin wrote:
>>>>>> On Fri, Aug 16, 2013 at 1:12 PM, Benoit Chesneau <bchesneau@gmail.com
>>>>
>>>>>> wrote:
>>>>>>> I agree, (modulo the fact that I would replace a string by a
binary
>>> ;)
>>>>>>> but
>>>>>>> that would be only possible if we extract the metadata (_id,
_rev)
>>> from
>>>>>>> the
>>>>>>> JSON so couchdb wouldn't have to decode the JSON to get them.
>>> Streaming
>>>>>>> json would also allows that but since there is no guaranty in
the
>>>>>>> properties order of a JSON it would be less efficient.
>>>>>>
>>>>>> What if we split document metadata from document itself?
>>>>
>>>>
>>>> I would like to hear a goal for this effort? What is the definition of
>>>> success and failure?
>>>
>>> Idea: move document metadata into separate object.
>>>
>>
>> How do you link the metadata to the separate object there? Do you let the
>> application set the internal links?
>>
>> I'm +1 with such idea anyway.
> 
> Mmm...how I imagine it (Disclaimer: I'm sure I'm wrong in details there!):
> 
> Btree:
> 
>     ----+----
>    |        |
>  --+--    --+--
> |    |  |    |
> *    *  *    *
> 
> At the node we have doc object {...} for specific revision. Instead of
> this, we'll have a tuple ({...}, {...}) - first is a meta, second is a
> data.
> So I think there wouldn't be needed internal links since meta and data
> would live within same Btree node.
> For regular doc requesting, they will be merged (still need for `_`
> prefix to avoid collisions?) and returned as single {...} as always.

We could also return them as separate objects, so the view function
becomes: function(doc, meta) {}.

Couchbase does that and from my experience it works well and feel right.

Cheers,
  Volker


Mime
View raw message