• Embedded Entities
• Related Documents
• List of Keys
• Relationship Documents

See the presentation for more details. This topic is also covered in the MapReduce Views for SQL Users chapter in the second edition of Writing and Querying MapReduce Views in CouchDB.

In Celebration of *Day Against DRM*
Save 50% on ALL Ebooks & Videos

Having the ability to download files at your convenience, store them on all your devices, or share them with a friend or colleague as you would a print book, is liberating, and is how it should be. If you haven’t tried a DRM-free ebook or video, we encourage you to do so now. And if you’re already a fan, take advantage of our sale and add to your library.

For one day only, you can save 50% on all O’Reilly, No Starch, and Rocky Nook ebooks and videos. Use code: DRMFREE

Ebooks from oreilly.com are DRM-free. You get free lifetime access, multiple file formats, free updates. Deal expires May 4, 2012 at 11:59pm PT and cannot be combined with other offers.

Unlike relational databases, document databases like CouchDB and Couchbase do not directly support entity relationships. This talk will explore patterns of modeling one-to-many and many-to-many entity relationships in a document database. These patterns include using an embedded JSON array, relating documents using identifiers, using a list of keys, and using relationship documents.

Additionally, this talk will address how each entity relationship pattern equates to its equivalent in a relational database. I’ll be discussing the relevant differences between document databases and relational databases such as:

• Document databases do not have tables
• Each document can have its own schema
• There is no built-in concept of relationships between documents
• Views/indexes are queried directly instead of being used to optimize more generalized queries
• A column within a result set can contain a mix of logical data types
• There is typically no support for transactions across document boundaries

This talk is based on the MapReduce Views for SQL Users chapter that I’ve added to the second edition of Writing and Querying MapReduce Views in CouchDB.

“What’s the future of CouchDB? It’s Couchbase.” —Damien Katz

“The future of CouchDB is CouchDB.” —Noah Slater

First of all, don’t panic. The Apache CouchDB project is thriving. There are plenty of core contributors who are dedicated to the project. If you’re using CouchDB, you’re fine. If you’re considering using CouchDB, you’ll be fine. CouchDB has a bright future ahead of it. Couchbase has repeatedly said that they’re not the CouchDB company, so this shouldn’t be a surprise to anyone.

My interpretation of this announcement is that CouchDB is forking. Going forward, you’ll have two choices, either Apache CouchDB or Couchbase Server. The road map for Apache CouchDB will continue to be determined by community consensus. The road map for Couchbase Server will be determined by Couchbase, the company.

CouchDB has two futures: CouchDB and Couchbase Server. Traditionally, forking a project in this manner has been considered a Bad Thing. From The Jargon File entry for forked:

An open-source software project is said to have forked or be forked when the project group fissions into two or more parts pursuing separate lines of development (or, less commonly, when a third party unconnected to the project group begins its own line of development). Forking is considered a Bad Thing — not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs/XEmacs split, the fissionings of the 386BSD group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore.

In my humble opinion, forking should no longer be considered a Bad Thing. Distributed revision control systems, such as Git, have made it much easier to merge changes back-and-forth between forked projects. If an individual or organization wants to take a project in a different direction, great! It sounds like Couchbase Server will be designed to meet a set of needs that are not being met by CouchDB. If so, a fork is perfectly appropriate as now both sets of needs can be met.

5. CouchDB and Domain-Driven Design

This post covered two topics that are of great interest to me. Document databases like CouchDB have much potential when it comes to domain-driven design. The post outlined some techniques for serializing domain objects into CouchDB documents.

4. Addressing the NoSQL Criticism

I heard a lot of NoSQL bashing this year at OSCON. As a result, I decided to write a rebuttal to many of the criticisms that I heard. This post inspired a lively comment thread.

3. Testing PHP 5.4

This was a short post on how to help the PHP Quality Assurance Team by running the tests for the latest development version of PHP 5.4. It covered downloading, compiling, and running the tests. Most importantly, it also covered reporting your test results.

2. Exploring RabbitMQ and PHP

I was exploring the possibility of using RabbitMQ for an upcoming project. I decided to post some notes on my experience getting started with RabbitMQ and integrating it with PHP. I haven’t ended up using RabbitMQ in production yet, but I’m confident that I’ll end up using it at some point.

1. CouchDB jQuery Plugin Reference

I had been frustrated by the lack of documentation for the CouchDB jQuery plugin—so decided to write my own. After I wrote the blog post, Max Ogden pointed me to Dale Harvey‘s documentation generator for jquery.couch.js and a copy of the generated jQuery CouchDB documentation. Max and Dale are also working on a more flexible jquery.couch2.js.

You can instead download the PDF version, if you’d prefer.

If you were in this session, please give me feedback on Joind.in.

If you were in this talk, please give me feedback on SpeakerRate.

Related links:

• Offline Apps
  • HTML5 Web Storage
  • Local Storage
• “Native” Mobile Web Apps
  • jQuery Mobile
  • PhoneGap
  • Building iPhone Apps with HTML, CSS, and JavaScript
  • Building Android Apps with HTML, CSS, and JavaScript
• CouchDB and Couchbase
  • CouchDB
  • Couchbase
  • “Ground Computing”
• CouchApp Examples
  • Grocery Sync
    • Couchapp code
    • iOS code
    • Android code
    • Presentation about Couchbase Mobile
  • Monocles
    • Demo
    • Code
    • ReadWriteHack Interview with Max Ogden: Part 1, Part 2
  • CatMapper
    • Demo
    • Code
• CouchDB jQuery Plugin
  • Same-Origin Policy
  • CouchDB jQuery Plugin Reference
  • jQuery CouchDB jsDoc Reference
• couchapp command line tool
• CouchApp Building Blocks
  • Evently
  • Mustache
  • Pathbinder
• Alternative CouchApp Tools
  • node.couchapp.js
  • Kanso Framework
  • soca
  • Reupholster
• Hosting
  • Iris Couch
  • Cloudant
• CouchDB & CouchApp Resources
  • CouchApp Wiki
  • CouchDB Wiki
  • CouchDB: The Definitive Guide
  • Writing and Querying MapReduce Views in CouchDB
  • Scaling CouchDB
  • Beginning CouchDB

In this talk we’ll see how to build CouchApps using CouchDB, Javascript, and HTML5. We’ll look at related tools such as the couchapp command ine tool, the Evently jQuery plugin, the CouchDB API jQuery plugin, the CouchApp Loader, Pathbinder, and the Mustache templating framework.

Aggregates are groupings of associated Entities and Value Objects. Within an Aggregate, one member is designated as the Aggregate Root. External references are limited to only the Aggregate Root. Aggregates should follow transaction, distribution, and concurrency boundaries. Guess what else is defined by transaction, distribution, and concurrency boundaries? That’s right, JSON documents in CouchDB.

Let’s take a look at an example Aggregate, that representing a blog entry and related metadata. Note that the following UML diagrams are for classes in PHP, but it should be easy enough to translate these examples to any object-oriented programming language. We’ll start with the Entry Entity, which will serve as our Aggregate Root:

-----------------------------------------
|                 Entry                 |
-----------------------------------------
|+ id : string                          |
|+ rev : string                         |
|+ title : Text                         |
|+ updated : Date                       |
|+ authors : Person[*]                  |
|+ content : Text                       |
-----------------------------------------
|+ __construct(entry : array) : void    |
|+ toArray() : array                    |
-----------------------------------------

The Text Value Object:

----------------------------------------------
|                    Text                    |
----------------------------------------------
|- type : string                             |
|- text : string                             |
----------------------------------------------
|+ __construct(type : string, text : string) |
|+ toArray() : array                         |
----------------------------------------------

The Date Value Object:

--------------------------------------
|                Date                |
--------------------------------------
|- timestamp : integer               |
--------------------------------------
|+ __construct(timestamp : integer)  |
|+ __toString() : string             |
--------------------------------------

The Person Value Object:

-------------------------------------------------------------
|                           Person                          |
-------------------------------------------------------------
|- name : string                                            |
|- uri : string                                             |
|- email : string                                           |
-------------------------------------------------------------
|+ __construct(name : string, uri : string, email : string) |
|+ toArray() : array                                        |
-------------------------------------------------------------

I recommend serializing each Aggregate, starting with the Aggregate Root, into a JSON document. Control access to Aggregate Roots through a Repository. The toArray() methods above return an associative array representation of each object. The Repository can then transform the array into JSON for storage in CouchDB. Let’s take a look at the EntryRepository:

---------------------------------
|        EntryRepository        |
---------------------------------
|                               |
---------------------------------
|+ get(id : string) : Entry     |
|+ post(entry : Entry) : void   |
|+ put(entry : Entry) : void    |
|+ delete(entry : Entry) : void |
---------------------------------

Here’s an example of what the Aggregate’s object graph might look like, serialized as a JSON document:

{
    "_id": "http://bradley-holt.com/?p=1251",
    "title": {
        "type": "text",
        "text": "CouchDB and Domain-Driven Design"
    },
    "updated": "2011-08-02T15:30:00+00:00",
    "authors": [
        {
             "name": "Bradley Holt",
             "uri": "http://bradley-holt.com/",
             "email": "bradley.holt@foundline.com"
        }
    ],
    "content": {
        "type": "html",
        "text": "<p>I've found CouchDB to be a great fit for…</p>"
    }
}

You can also provide access to CouchDB views through Repositories. In the above example, this could be through the addition of an index(skip : integer, limit : integer) : Entry[*] method to the the EntryRepository (note that this is a naive pagination implementation, especially on large data sets—but that’s beyond the scope of this blog post). For more complex views, you may want to create a separate Repository for each CouchDB view.