Great reference for API design
Intro
Basically, designing a good API means it should be easily usable and it should make developing wrong things difficult. Since KVS already exist, we should manage user expectations well; they’ve already seen a lot of key-value stores, and we shouldn’t diverge from what’s already pretty common.
Emmanuel calls his KVS KingDB, I guess I’ll call mine QueenDB? Honestly, the name doesn’t matter as much as the code so yeah QueenDB It is.
Basic features of a KVS:
- open, close db
- read, write to db
- iterate over keys and values in a db
- offer a way to choose parameters
- offer a decent error notification interface That seems about right, we’re not dealing with documents like MongoDB, and we won’t have several fields since it’s a mere A->B entry, so we don’t need filtering features for search..
What's out there already:
To open and close db : a lot of different approaches, which were judged to be C-style, LevelDB creates a pointer for the db, calls open(db) then destroys the pointer as a method of closing it.. So, in QueenDB, we will keep the open and close methods
To read and write : honestly, just a get and set method, where we have the read/write options, the key and the value (as a ptr ofc for get, and by value for set). We could return an integer to see if the operation happened without an error.
To iterate : an iterator lol
To choose parameters : Kyoto has a tune_* method to be called directly on the database for every parameter, LevelDB has an Options class with different attributes (parameters) to set then to pass to the open method, you can also set every parameter and pass it by value to the put method (just check their source code). SQLite3 has a config method where you just pass flags (one at once), before initializing the database and opening it
LevelDB’s way is better because we don’t have to call a method to change the options, we can merely change the options class. It can also be shared among different databases. However, LevelDB passes these options as a 1st parameter so we always have to set them. Maybe, QueenDB will put it as a last parameter to make sure that if it doesn’t need to be set then we can skip it, and we’ll use method overloading with no options parameters.
To manage errors : LevelDB returns a Status object for every method and we can check using an ok method if no error has occurred. Kyoto Cabinet returns true or false, SQLite3 returns an integer too, same thing for Berkeley DB. LevelDB’s way seems much better, especially since the Status class has many attributes and it’s easy to use to test for errors.
Top comments (0)