A couple of BRDocBase changes
| January 23rd, 2010I’ve been using BRDocBase fine in development for a few weeks. While it’s nowhere near complete, I haven’t had any real need for new features or performance improvement for my modest needs until now. ### Document Change Flag
The first thing I wanted was a change flag on documents. This will be the first optional method on the BRDocument protocol. If the property doesn’t exist on a document object, everything will proceed as it did before. I went with the property name isDocumentEdited since that’s the method name on NSDocument. I’m not really going for any kind of BRDocument to NSDocument parity but I decided a familiar name was best.
One important functional change is that if the document implements the property and it’s not set, the saveDocument:error: method will not save the document. At first, I had save doing absolutely nothing with the document if the flag was set, this caused a small issue with new documents though. Currently, a nil return value means an error occurred and the error object is appropriately set. So now there are a few options:
- Return nil with no error set
- Go ahead and set the id, but still don’t save the document
- Ignore the
isDocumentEditedflag in this case and save the document - Return nil with an error
- Raise an exception
I went with the 4th option. The first is the worst in my mind since it forces a user of BRDocBase to account for a nil error even when nil is returned from save. The other options aren’t really bad. Since this is really kind of an odd situation and I consider it a developer error (new documents should be automatically set as edited) I may at some point change it to raise an exception. Although exceptions aren’t used a lot in Cocoa, a developer error warrants an exception in my mind.
A New Hash Algorithm
While I was in the code I realized that my in-memory storage of documents that had been retrieved had a possible problem. To make saves quicker, internally I’m storing documents similar to the file based stored. There’s a top dictionary keyed by the bucket ids containing dictionaries itself mapping documentId to the document object. But since the bucket number is generated by hashing the documentId, if the inner dictionary happens to have the same number of buckets as the file based storage, we’d end up with 100% collisions in the dictionary.
That led me to think of a less likely, but way more serious problem. What if Apple changed the hash algorithm on NSString? I wouldn’t think this is likely, but the structure of BRDocBase storage is dependent on Apples internal implementation. So rather than depend on this, to assign bucket numbers I now use a a different hash algorithm: FNV-1. I saw other, more complicated and faster algorithms, but I don’t really need ultimate speed for my purposes. Of course this means that any document database I have is now useless. Since it’s still early in development, I didn’t bother writing something to convert my existing databases and just trashed them.
Finally, I put BRDocBase up on github. It’s available here BRDocBase