compared with
Version 3 by Mark Nunberg
on Mar 25, 2013 16:12.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (1)

View Page History

h3. API Inputs

The view API inputs consist of feeding string data into an opaque parser context. The parser context will also be set up with callbacks which will be invoked upon receipt of each parsed view row, or on a parse error.

* Opaque parse context (API function to initialize/create this)
* Error callback
* Row callback

h3. API Output

* Row Callback
** Will contain a single row only
* Error Callback
** Will contain an error code, as well as the raw text for the response
* Parse context
** Will contain non-row meta-data returned in the view result, as well as any HTTP metadata (such as the return code)

h3. Usage Model

The usage model for the incremental row parsing is slightly more involved as it requires setting up two different callbacks. Generally speaking however, the receipt of each view row is to follow the semantics of responses for something like a multi-get, in that a new callback is invoked for each row.

One is required to create a "view row parser context" (which may be re-used) which allocates the necessary handles for the parser object. Then incoming data is fed into the buffer (a convenience HTTP callback may be provided to allow for this boilerplate to be performed transparently). When sufficient data has been fed and at least one row has been internally delimited by the parser, the row callback is invoked. If an error occurs during parsing, the error callback is invoked.

h3. Example Code


h2. Common Flag/Datatype handling

 This may be a simple set of macros to set/unset flags

h2. C+\+ Wrappers

It might be prudent to also create proper C+\+ wrappers around libcouchbase, so that one may be able to do something like:

LCB::Result& result = lcb->get("foo");