Volume Number: 14 (1998)
Issue Number: 3
Column Tag: Rhapsody

Handling a Changing Framework

by Kris Jensen

What to do when the latest update to your framework no longer provides an object essential to your project

Data storage and retrieval is an important part of most computer applications. In some cases, writing a document to a file is sufficient; in others, the information to be stored and retrieved is more complex, and your program may rely on a package of objects that implement data storage and retrieval for you. What do you do if that set of objects is no longer available?

This article shows how the modularity of object-oriented programming allows one to quickly modify programs without modifying code by plugging in a different set of objects and how the high-level Foundation Kit objects can be used to quickly code interim solutions.

An OS update broke our application

Stone Design's database management application, DataPhile, suffered from an updated OS removing objects essential to the application. DataPhile was originally built using the Indexing Kit package of data storage and indexing objects, a package that was included with the original NeXTSTEP programming tools. The Indexing Kit was never problem-free at its higher levels, and, at its lower levels, was difficult to port to other platforms. As NeXTSTEP became OPENSTEP and migrated to other hardware, the Indexing Kit disappeared.

DataPhile needed a new back-end. While we were researching the possibilities for replacing or porting the Indexing Kit, we also wanted to show that we could get the front-end up and running under OpenStep and Rhapsody. The solution was a quick and dirty back-end built using OpenStep Foundation Kit objects. We did not, at this point, want to change DataPhile's data storage paradigm, nor did we want to build a functional and efficient b-tree package; we just wanted to "plug in" some quickly built objects that would provide the surface functionality that we had been using in the Indexing Kit. Efficiency, either in space or time, was not an issue; speed in implementing something that would allow us to demo our front-end under Rhapsody was our goal.

An advantage of working in an object-oriented environment is that you can use a speedily-written, temporary set of objects that provides the functionality of the objects that are no longer available or provides a general storage model that works for your application. Later, you can re-implement the objects more efficiently. Or you can use your objects as glue to implement your storage model using another set of objects. As long as you don't change your objects' interface, you don't need to touch the rest of your code.

Our solution may interest you if:

• You're porting an application and your data storage package is not available for your new platform.
• You're developing an application and you haven't yet decided on what you're going to use for your data storage needs.
• You're developing a small-scale project and you need a simple, free persistent data store.

Implementing a fix with Foundation Kit

Our solution followed these steps:

1. Identify which classes and methods in the obsolete package are being used. We used five classes: IXStore, IXStoreFile, IXStoreDirectory, IXBTree and IXBTreeCursor and we used most of the public API of those classes. Our data storage model was based on being able to store key-value pairs (with the keys and values being of any size) and to retrieve the values either directly (via the key) or sequentially.
2. Implement those classes and methods. Don't worry about how they "really" work; our goal is to provide functionality without modifying our client code. For example, IXStore was based on the idea of "blocks" of storage; I kept the idea of blocks, but they just became id's used for access into a dictionary.
3. To do the implementation, figure out what you need to do and look for Foundation Kit classes that will provide that functionality. We needed three things: to store key-value pairs to disk and to access those pairs directly (by key value) and sequentially. The Foundation Kit includes NSPPLs (persistent property lists). The NSPPL class description in the Rhapsody Foundation Kit documentation, states:

"Like serialization, a persistent property list stores data in a binary format, provides fast access, and is lazy. It also allows you to make incremental changes to an NSPPL (even one that contains tens of megabytes of data), while still ensuring that your data is never corrupted. In this sense, an NSPPL is analogous to a database. Because of their ability to incrementally store and retrieve data, NSPPLs are particularly well-suited for working with large amounts of data (that is, data that has several elements, that occupies a large number of bytes, or both)."

NSPPLs can store NSDictionaries and NSArrays. NSDictionaries provide fast key-value lookup, but don't allow sequential access in any kind of sorted order. NSArrays can provide sequential access. I decided to use an NSPPL to implement an IXStoreFile, an NSDictionary to implement an IXStoreDirectory, and both an NSDictionary and an NSArray to implement an IXBTree.

IXStore is "a transaction based, compacting storage allocator designed for data-intensive applications." and IXStoreFile puts the storage on disk. For a temporary back-end, I decided to forego transactions and compacting and concurrency control and just implement the calls my client code used: the transaction calls from IXStore and the initialization methods from IXStoreFile. Even though I didn't plan to implement transactions, I didn't want to remove the transaction-oriented code from DataPhile, so the methods had to be there.

IXStoreDirectory and IXBTree conform to the IXBlockAndStore protocols, which use the notion of a handle to a block of storage. Because of this, I kept the idea of block numbers allocated by IXStore, but eliminated the idea of blocks as constant-sized storage units (meaning that something stored in an IXStore might extend over multiple blocks). Instead, each IXStore client would be assigned a block number which would provide access to that client's storage. So in IXStore and IXStoreFile, I needed to map block numbers to data. Since an NSPPL incorporates an NSDictionary to provide access to its storage, I decided to use that dictionary to store block number / data pairs.

I initially planned for the stored data to be the actual structures needed by the store clients: 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 b-tree. It's a fairly standard undergraduate computer science project to write a b-tree program, but this is for a quick back-end, 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 b-tree) 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 b-tree.

Putting all this together, I have a cover for the parts of the Indexing Kit that we needed (b-trees, cursors, and storage) that will allow us to continue to develop the DataPhile front end while we look for a replacement back end. It's not particularly robust or efficient, but it was built very quickly using Foundation objects. When we decide on another storage package, we can rewrite the guts of the cover objects without rewriting the code that uses the cover objects. You can take a look at my b-tree solution in the example code provided at the MacTech ftp site ftp://ftp.mactech.com/.

I also found that a simple way to store and index record objects of some type is to create a b-tree that maps an id number to an NSData that holds the record (serialized in whatever way you wish). Then create index b-trees that map keys (have your records create their own keys) to the record id number. This is demonstrated in the sample code that uses the b-tree code.

Kris Jensen, at the time an attorney for the State of California, bought an Apple II in 1980. It changed her life. She taught herself BASIC, started taking computer science courses, moved to New Mexico, entered the Ph.D. program in Computer Science at the University of New Mexico, bought a Macintosh, passed her comprehensive exams, became president of the local Apple Users Group in Albuquerque, met Andrew Stone, got NeXT representatives to demonstrate the NeXT cube at a users group meeting, joined Andrew in becoming NeXT developers, and didn't finish her Ph.D. because she was designing and writing NeXTSTEP software. Kris is happy to be back in the Macintosh world with Rhapsody. In her spare time, Kris calls square dances around the country.