Changing Frameworks
Volume Number: 14
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.
Conclusions
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.