NULevelDB is an Objective-C wrapper for Google's C++ leveldb key-value store library.

The wrapper is currently quite simple, in that it provides only a single functional wrapper class: NULDBDB (wraps leveldb::db).

You can create a new key-value store with -initWithLocation:, or remove it with -destroy.

leveldb supports saving key-value pairs. NULDBDB exposes this support with three basic methods:
- (void)storeValue:(id<NSCoding>)value forKey:(id<NSCoding>)key;
- (id)storedValueForKey:(id<NSCoding>)key;
- (void)deleteStoredValueForKey:(id<NSCoding>)key;

This basic support is also extended with an object serialization interface with similar semantics. Objects which conform to the NULDBSerialization protocol can use the object interface:
- (void)storeObject:(NSObject<NULDBSerializable> *)obj;
- (id)storedObjectForKey:(NSString *)key;
- (void)deleteStoredObjectForKey:(NSString *)key;

In addition, you may optionally adopt the NULDBPlistTransformable protocol in classes in your object graph. This is a convenient way to improve performance by electing to store a branch of the graph as a single value (in other words, flatting a number of nodes in one branch into a single leaf node). This does not mean that all child nodes of your transformable instance must support plist transformation. They may still support either NULDB-style serialization or NSCoding.

Serialized objects are stored independently of your object graph using tokens. This is true whether they are properties of serialized objects or plist-transformable objects.

When a class supports multiple encoding techniques, they are prioritized as follows:
- plist transformation
- NULDB serialization
- NSCoding

The object storage interface currently expects strings for keys, but this is not strictly necessary.

Keys and values of string, data or dictionary type (including transformed objects) are stored using the best storage format for each of those classes when they are converted to raw data for use by the underlying leveldb library.

Performance testing reveals raw storage, loading and deletion performance about three times that of Core Data. Of course, you lose most of the power of Core Data, including sophisticated searching, KVC/KVO/bindings (and array controllers), guaranteed uniqueing, undo and more. Some of these could be added to NULevelDB in future. Perhaps NULevelDB could be used to create a new Atomic Store type. See the Tests folder for benchmarking test apps.

Consider the code to be licensed the same as whatever leveldb itself is using. I haven't gotten around to putting the license on every file.