Anyone manage to compile this on OS X?
You'll need a compiler from MacPorts: it wants C++0x which Apple's gcc doesn't support yet.
LevelDB: a fast and lightweight key/value database library
61–70 of 82 posts
Re: LevelDB: a fast and lightweight key/value database library
#62What I would like to know is, is there support accessing values by nth-largest key? I had to roll my own b-tree library specifically to get this feature since nothing out-there had it.
Why not index size(key)? Then lookup the n-th largest key and then pull the values? eg. SELECT value from key_value_pairs order by size(key) LIMIT N
I don't think that's what the OP wants. The real result expected is supposed to be ordered by the value of the key itself rather than the size of the key.
Re: LevelDB: a fast and lightweight key/value database library
#63Was really psyched until I saw --std=c++0x in the Makefile. What 0x features does leveldb depend on, and can those dependencies be realistically removed?
The use of c++0x should be limited to the small AtomicPointer class in port_posix.h. The class uses for its implementation. If you can provide a different implementation of "acquire store" and "release load" for your architecture, you should be all set without the need for c++0x.
I suspect that you may find suitable code in the chromium source code. See leveldb's port_chromium.h.
Re: LevelDB: a fast and lightweight key/value database library
#64@sghemawat: Are you planning on implementing atomic CAS operations?
We have no such plans. The library is designed so that concurrency control is outside its scope. If I needed it for an application, I might consider using some application level code that looks like:
bool CAS(db, key, oldvalue, newvalue) {
lock some mutex;
read key's value from db;
bool result = (value == oldvalue);
if (result) write key=>newvalue to db;
unlock;
return result;
}
Re: LevelDB: a fast and lightweight key/value database library
#65This could be great news for iOS. AFAIK, this is the first K/V DB that could be built for iOS (c++) and has a free license that is compatible with the AppStore (Tokyo Cabinet uses LGPL and the author has shown no interest to me in adding a static linking clause, Berkeley DB requires an expensive commercial license, etc).
What advantages does this have over the built-in SQLite?
Re: LevelDB: a fast and lightweight key/value database library
#66I uses boost::atomic to make it usable without c++0x
http://www.chaoticmind.net/~hcb/projects/boost.atomic/
#include
class AtomicPointer { private: boost::atomic> rep_; public: AtomicPointer() { } explicit AtomicPointer(void v) { } inline void* Acquire_Load() const { return rep_.load(boost::memory_order_acquire); } inline void Release_Store(void* v) { rep_.store(v, boost::memory_order_release); } inline void* NoBarrier_Load() const { return rep_.load(boost::memory_order_relaxed); } inline void NoBarrier_Store(void* v) { rep_.store(v, boost::memory_order_relaxed); } };
Re: LevelDB: a fast and lightweight key/value database library
#67Re: LevelDB: a fast and lightweight key/value database library
#68This could be great news for iOS. AFAIK, this is the first K/V DB that could be built for iOS (c++) and has a free license that is compatible with the AppStore (Tokyo Cabinet uses LGPL and the author has shown no interest to me in adding a static linking clause, Berkeley DB requires an expensive commercial license, etc).
What advantages does this have over the built-in SQLite?
It stores key/value pairs instead of relational data. I've been looking for something like this for a while as a replacement to NSUserDefaults.
Re: LevelDB: a fast and lightweight key/value database library
#69Earlier quoted context omitted.
What advantages does this have over the built-in SQLite?
It stores key/value pairs instead of relational data. I've been looking for something like this for a while as a replacement to NSUserDefaults.
CREATE TABLE kv (key text PRIMARY KEY, value text);Re: LevelDB: a fast and lightweight key/value database library
#70Earlier quoted context omitted.
That's correct. We're using leveldb as the back-end for IndexedDB in Chrome.
Please enlighten me, in the LevelDB page it said: > Only a single process (possibly multi-threaded) can access a particular database at a time. But I presume Chrome is multiprocess by nature?
All leveldb access is done in the main process (which also handles UI, network, most file access, etc).