danieltdt
Add dbm methods
Some of the other dbm libraries have a lot of hash-like methods such as has_key?, each, etc. Should consider adding some of these.
I've been tinkering here: https://github.com/larsch/unqlite-ruby/commits/dbm-methods-2, but not all methods are added yet. Looking for comments before I go ahead with more of them.
Comparing to GDBM, here are the methods:
Exists: #close, #delete, #fetch, #store
Straight forward: ::open, #[], #[]=, #closed?, #each, #each_key, #each_pair, #each_value, #has_key?, #include?, #key?, #member?
Would be convenient: #clear, #empty?
Possible but somewhat complex: #delete_if, #has_value?, #invert, #keys, #length, #reject, #reject!, #select, #shift, #size, #to_a, #to_hash, #update, #value?, #values, #values_at, #key, #replace.
The last group are all for Hash-like behaviour, but most are not that simple to implement, and have non-obvious runtime complexity. E.g. #size would have to iterate over all elements to count them (GDBM does that too). Some of them could be done in Ruby instead of C (e.g. to_hash, values_at, etc.).
I think it is a good idea and we should implement that, but not now. Initially, I was thinking to implement at least the basis of unqlite so people could use unqlite on its fullness. We have some other functionalities that we could implement before working on a better api, such as the exception handling refactor (that @djurczak mentioned on #5), the bind of the cursor iterator functions, the bind of the bd config, the bind of the others functions of key/value store...
So, I really like those dbm with that hash api support, but I think we have to bind other functions before making this api.
I agree with holding off the more esoteric methods for now (values, length, has_value?), but I'd really like to merge some of the essentials, like [], []=, each, and include? which makes writing unittest easier and more Ruby-esque.
Hmm you are right, maybe doing the tests with each and []= before refactoring would be much easier... Let's try to add those methods
I've gone ahead and pushed my work. Let me know any problems.
I've done a cursor interface in the best Ruby style I could come up with, but let me know any ideas. Not that useful since only hash & mem kv_engines are supported by unqlite right now, but good for completeness nonetheless.
I don't really have a lot of motivation to work on the Jx9 stuff, since my own primary need is a fast key-value store with a portable file format (which gdbm doesn't provide).
On Thu, Aug 1, 2013 at 2:57 PM, Daniel Teixeira [email protected]:
Hmm you are right, maybe doing the tests with each and []= before refactoring would be much easier... Let's try to add those methods
— Reply to this email directly or view it on GitHubhttps://github.com/danieltdt/unqlite-ruby/issues/9#issuecomment-21934268 .