Couchbase Server 2.0.0 build 1530 contains important document behavior changes that may impact your existing applications. Specifically, this and future releases include changes the way document metadata is handled and exposed when working with Views and creating map and reduce functions in Couchbase Server.
In previous releases, the document supplied as the only argument
to the map()
function included special
fields with an additional prefix that provided information such
as the data type, flags, expiration and document ID. For
example:
{ "_id" : "contact_475", "_rev" : "1-AB9087AD0977F089", "_bin" : "...", "$flags" : 0, "$expiration" : 0, "name" : "Fred Bloggs", }
This representation has been changed so that the submitted document data and structure remain identical to the document stored and returned by the Views system.
The metadata is now supplied as a object and second argument to
the map()
function. The format of this
object is a JSON document with fields for each of the metadata
items previously incorporated in the main document. For example:
{ "id" : "contact_475", "rev" : "1-AB9087AD0977F089", "flags" : 0, "expiration" : 0, "type" : "json", }
The main flags and their contents remain the same. The
_bin
, $att_reason
have
been replaced with a single field, type
, that
indicates the document data type. For documents identified as
valid JSON, the field will have the value
json
. For non-JSON, the value will be
base64
.
The meta information for sample documents is now displayed separately, within a non-editable portion of the Web Console.
In addition to these changes, the format and information
supplied to the map()
function has changed.
To access only the document data within your View, you can use
the following map()
:
function(doc) { }
To access the document data and document metadata, including document ID and expiration time, use the two-argument format of the function:
function(doc,meta) { }
For example, to emit only document information from the View based on the following document structure:
{ "name": "John", "e-mail": "john@john.com" }
Create a view using only the document object:
function (doc) { emit(doc.name,null); }
To create a view that explicitly emits the document ID:
function (doc,meta) { emit(meta.id,doc.name); }
In addition, the doc
argument now contains a
base64 representation of the document data if the document is
not JSON. This can identified using the type
field of the meta
object. The default
map()
provided within the Administration
Web Console is now:
function (doc, meta) { if (meta.type == "json") { // If the document is JSON, sort by the schema var keys = Object.keys(doc); emit(["json", keys.length], keys); } else { emit(["blob"]); } }
This provides an example of how to process and output documents
that are valid JSON or binary documents, using the
meta
argument to identify the document data
type.
Existing client libraries continue to work with the new release without modification to the View or document update mechanisms and information.
New Features and Behaviour Changes in 2.0.0 Build #1554
Behavior Change: Identifying the content type of the document
can no longer be achieved by using the
doc._bin
field of the document object.
Instead, you should use the meta.type
field.
This will be set to json
for documents
identified as valid JSON documents. For documents that cannot be
identified as valid JSON, the field will be set to
base64
.
For more information, see 「ドキュメントメタデータ」.
Behavior Change: Document metadata is no longer included as
fields within the document supplied to the
map()
function as an argument within a
view. Instead, the function is now supplied two arguments, the
document data, and a second argument, meta
,
that contains the expiration, flags and an indication of the
document data type.
For more information, see 「ドキュメントメタデータ」.
Behavior Change: The document ID for a given document is no
longer available within the document object supplied to the
map()
. Instead of using
doc._id
you should now use the
id
field of the meta
object, meta.id
. The two-argument form of
the map()
must be used for this purpose.
For more information, see 「Map関数」.
Behavior Change: Because document metadata is now exposed within a separate structure, the Admin Console displays the sample document metadata separately from the main document content.
For more information, see 「ビューエディタの利用」.
Behavior Change: When deleting a design document, the
_rev
parameter is no longer required to
confirm the deletion.
For more information, see 「デザインドキュメントのREST API」.
Behavior Change: The map()
is now supplied
two arguments, doc
, which contains the
document data, and meta
, which contains the
document metadata.
For more information, see 「Map関数」.
Known Issues in 2.0.0 Build #1554
Installation and Upgrade
It is not possible to perform an upgrade between Couchbase Server 2.0 pre-releases including beta, or to perform an offline upgrade from Couchbase Server 1.8 to a pre-release or beta of Couchbase Server 2.0. To upgrade between these versions use cbbackup to backup your data, delete the existing installation, install the new version, and restore the stored data.
For more information, see 「バックアップとリストア」, 付録B Couchbase Serverのアンインストール.
Documents identified as Non-JSON stored within Couchbase Server may appear as binary, or text-encoded binary data within the UI.
Issues: MB-7069
During periods of moderate CPU load on the Couchbase Server
cluster, you may see warnings that IP address seems to
have changed. Unable to listen to node X.X.X.X
.
Command-line Tools
The cbbackup, cbrestore,
and cbtransfer command-line tools require the
zlib
module for Python to have been
installed. If Python was installed from source, you must have
enabled zlib
using the
--with-zlib
option during the build process.
Issues: MB-7256
For more information, see 「バックアップとリストア」, 付録B Couchbase Serverのアンインストール.
Indexing and Querying
Accessing a recently created view (with other, existing active views) may return a error if the corresponding design document and view definition have not been replicated across the cluster. The error return will be returned in error of the view output detailing the missing design document. The workaround is to add views and design documents to your node or cluster after you have performed rebalance. For more information about resolving issues with Couchbase Views, see 付録D ビューのトラブルシューティング(技術的背景).
Note also that stopping a rebalance operation on a cluster may take a long time if compaction and indexing operations are in progress on the cluster at the point of rebalance. Again, the workaround is to add views and index and query views after you have performed compaction or rebalance. For more information about rebalance, and considerations on when to rebalance, see 「クラスターの拡張と縮小(リバランス)」.