DocBase – Part 2
| December 23rd, 2009BRDocBase wasn’t really usable where I left off, so I’ve got a few tasks before it’s at least in a state where I can use it for development purposes.
### Id Assignment Once again, we will follow CouchDB’s example. Any document without an id will be assigned a UUID. Generating a UUID is pretty straight forward, and I added a class method on BRDocBase to make one as a string. Assigning the id can be a bit trickier. Right now, the interface is taking an NSDictionary when saving a document immutable. I could easily create a mutable copy and assign the id on that before saving it, but the consider the following situation:
NSDictionary* aDocument; // a document without an id
BRDocBase* docBase; // our document database
[docBase saveDocument:aDocument error:nil];
//Do more stuff with aDocument
[docBase saveDocument:aDocument error:nil]; // a new document is created
In this case, the second save would create a new document, which makes me think that simply making a mutable copy of the dictionary is the wrong solution. Instead, I’d rather just say that if the id isn’t set on the document when it’s being saved, the document needs to be mutable (an NSMutableDictionary in this case). I’ll consider not providing a mutable document in this case a development error, so I’ll just let an exception be raised rather than setting an error code.
Document Classes
Using NSDictionary is really convenient and easy, but in most cases there’ll need to be some logic in a document. So instead of dealing with a dictionary, a new protocol is introduced:
@protocol BRDocument<NSObject>
@required
@property (readwrite, copy) NSString* documentId;
-(NSDictionary*)documentDictionary;
-(id)initWithDocumentDictionary:(NSDictionary*)dictionary;
@end
Then I also added a category on NSDictionary to implement this protocol. However, a little extra is needed: once json is deserialized into a dictionary, we need to know what class of document to create, so a new special key is introduced: _type. If this is present in the document dictionary, I’ll create an instance of that class and initialize it with the dictionary.
Storage Implementation
I mentioned the problems with storing each document in a separate file last post. One option would be to store all the documents in one file. Although this would solve the case insensitive id problem, it would still have scalability issues. So, I decided on using basically a file-based hash table. It seems a good balance between simplicity and performance, so we’ll see how it goes. The number of buckets in the hash table will be hard-coded for now.
Deleting Documents
I somehow forgot about this last time, but it kind of needs the ability to delete documents in order to be useful. There’s nothing really complicated about this at all, except that in writing the test, I noticed that when we try to get a document that doesn’t exist, null is returned, but no error information is set. I believe the convention in Cocoa is to always set error information when a negative result is returned, so we’ll fix this as well.
What’s Next
Before DocBase is useful for development purposes there’s at least one more thing that needs to be done: searching. I’ll dive into that next post.