 |
| I initially planned for the stored data to be the actual structures needed by the store clients: that is, for example, to store the IXBTree's structure (an NSDictionary of key/data pairs) directly in the root dictionary. However, all NSDictionaries stored directly in an NSPPL must use NSStrings as keys: this didn't match the IXBTree's paradigm of arbitrary data for both keys and data. So I used the rootDictionary of the NSPPL to map block numbers to NSData objects; the NSData contained an archived version of the object to be stored. IXStoreDirectory "provides access to store clients by name instead of by block handle." This obviously called for an NSDictionary mapping names to a structure that would keep track of an object, its class, and its block number. An IXBTree "provides ordered associative storage and retrieval of untyped data. It identifies and orders data items, called values, by key using a comparator function". The information in an IXBTree can be accessed directly by key or sequentially, by using an IXBTreeCursor to traverse the btree. It's a fairly standard undergraduate computer science project to write a btree program, but this is for a quick backend, so I decided to use prefab parts. Direct access could be provided by an NSDictionary mapping NSData keys to NSData values. Sequential access could be provided by a sorted NSArray of keys. The sorted array could be built easily by using the sortedArrayUsingFunction NSArray method. A cursor can be represented as an integer index into the sorted key array. It can be positioned (for a key that's in the btree) using the method indexOfObject. If the key is not already present, positioning becomes a little more complicated; I implemented a quick and dirty binary search on the array contents. If contents are added to or deleted from the key array, any cursors pointing into the array become invalid; I use an NSNotification to notify the IXBTreeCursors that are accessing the btree. |