Modeling Tree-Structured Namespaces
The chapter model in OLE DB assumes that each level of a hierarchy can be modeled by a single rowset. While this is a natural and efficient way to model homogeneous hierarchies (such as a Customers->Orders->OrderDetails hierarchy), it becomes a limitation when dealing with more general hierarchies that arise in tree-structured namespaces. For example, an e-mail inbox is a collection of items. Each item can be of a different type, such as an e-mail message, a calendar entry, a journal entry, or a folder. Therefore, to model hierarchies of heterogeneous collections in OLE DB requires more flexibility than rowset objects alone can provide.
In OLE DB 2.5, this can be done using a combination of row and rowset objects. When row objects are used to model tree-structured namespaces, each node in the tree can be modeled by a row object, which belongs to the rowset of its siblings. One of the columns in this row object can be the rowset that contains all the children of this node. In this situation, the row object is also used as a scoping mechanism. Operations performed on the row object apply to the subtree rooted at the node represented by the row object.
In working with tree-structured namespaces, there is a frequent need to perform move, copy, or delete operations on the subtree rooted at the current node. For example, a copy operation might need to copy not only the given node but the entire subtree rooted at that node.
The row object has an optional interface, IScopedOperations, with methods that allow data modification and navigation operations to be performed within the scope of a given node (row object). IScopedOperations is derived from IBindResource.
This topic is a part of:
This section contains the following topics: