When we decompose a larger collection into a number of separate fine-grained objects, we will have multiple classes of objects on the shelf. Because they are independent objects, they will lead to separate sets of CRUD operations for each class. In some cases, the objects are independent, and operations on an object of one class have no impact outside that individual object. In some relational database products, these become cascading operations. Removing a Blog entry can cascade into removing the related Post entries.

In our previous example, the Blog and Post objects have a dependency relationship. The Post objects are children of a parent Blog; the child can't exist without the parent. When we have these dependent relationships, we have a more entangled collection of operations to design. Here are some of the considerations:

• Consider the following for CRUD operations on independent (or parent) objects:
  • We may create a new, empty parent, assigning a new primary key to this object. We can later assign children to this parent. Code such as shelf['parent:'+object._id] = object creates a parent object in the shelf.
  • We may update or retrieve this parent without any effect on the children. We can perform shelf['parent:'+some_id] on the right side of the assignment to retrieve a parent. Once we have the object, we can perform shelf['parent:'+object._id] = object to persist a change.
  • Deleting the parent can lead to one of two behaviors. One choice is to cascade the deletion to include all the children that refer to the parent. Alternatively, we may write code to prohibit the deletion of parents that still have child references. Both are sensible, and the choice is driven by the requirements imposed by the problem domain.
• Consider the following for CRUD operations on dependent (or child) objects:
  • We can create a new child that refers to an existing parent. We must also decide what kind of keys we want to use for children and parents.
  • We can update, retrieve, or delete the child outside the parent. This can include assigning the child to a different parent.

As the code to replace an object is the same as the code to update an object, half of the CRUD processing is handled through the simple assignment statement. Deletion is done with the del statement. The issue of deleting children associated with a parent might involve a retrieval to locate the children. What's left, then, is an examination of retrieval processing, which can be a bit more complex.

Searching, scanning, and querying are discussed in the next section.