5 ms·

UnQLite - An Embeddable NoSQL Database Engine

49 points by mmariani 13y ago

programminggeek 13y ago
I've been wanting something like this for a while. I've been using my own just straight JSON flat files to store things, which works out pretty well for getting something out the door fast, or coding without an internet connection.
jasonjayr 13y ago
Oracle's recent licensing shenanigains aside, How is this different from BerkleyDB, or any of the old DBM variants, or Kyoto Cabinet?
- SomeCallMeTim 13y ago
  Licensing is a key issue. BerkeleyDB is AGPL and was previously under another strong copyleft license, neither of which could you embed in a commercial product without paying. Kyoto Cabinet is also GPL. Again, no-go for a commercial product. TOKYO Cabinet, on the other hand, is LGPL, so it at least CAN be embedded, but it's described as inferior to Kyoto. [1] Regardless, if you want something to embed, it's not always easy when you have a huge pile of source with a build system that doesn't match your own. Another feature they describe is that the entire code base comes as a massive (1.3Mb) C file with no dependencies. That's a big win for "drop in the project and build." Not making any claims for how good this particular library is, but at least it would be marginally interesting if I wanted a persistent key-value store in an app. The other go-to option is SQLite, which has a similar massive C file for easy embedding (and an even more permissive license: "Released to the Public Domain"), but SQLite's code is 4.8Mb. Size does matter, so SQLite needs to offer me some advantage to justify its size. The data I store in most apps locally doesn't require JOINs. [1] http://fallabs.com/tokyocabinet/ http://fallabs.com/tokyocabinet/
  - epo 13y ago
    Well commented C code should be huge! To say that "size does matter" and only mention source code size is ... Well, I shall be charitable and assume you are having a bad day.
    - SomeCallMeTim 13y ago
      cloc can answer the question definitively: $ cloc sqlite3.c 1 text file. 1 unique file. 0 files ignored. http://cloc.sourceforge.net v 1.58 T=2.0 s (0.5 files/s, 70228.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C 1 9585 46745 84126 ------------------------------------------------------------------------------- $ cloc unqlite.c 1 text file. 1 unique file. 0 files ignored. http://cloc.sourceforge.net v 1.58 T=0.5 s (2.0 files/s, 119944.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C 1 314 18670 40988 ------------------------------------------------------------------------------- SQLite seems to have more verbose comments, but still has more than 2x the lines of code. If you want to build both on the same platform and compare binary size, be my guest.
gummydude 13y ago
Is there an android client/driver/port?
- SomeCallMeTim 13y ago
  One C file with no dependencies? Should be a trivial build and interface wrap using the NDK.
vertis 13y ago
Discussion from last time this was posted: https://news.ycombinator.com/item?id=5750338 https://news.ycombinator.com/item?id=5750338
- mmariani 13y ago
  <rant>The previous discussion is a sad display of what HN has become. Clearly most of the posters didn't go further than reading a few pages from the project's website. When instead they should've read some of the project's well commented C source code as anyone would expect from a group that's comprised of hackers. For instance http://unqlite.org/db/unqlite_doc_intro.c http://unqlite.org/db/unqlite_doc_intro.c – Luke, read the source!</rant> Now I'd like to get back to the topic, Unqlite. The project's documentation is objective and adequate to serve as a quick reference during the development of projects that use this library. The scripting language that goes with this DB feels very intuitive, its's apparently is very fast, and it has a small footprint. Its zipped source code with tests are a 23KB download, impressive. Later this week I will build a small test app with this database to develop a more informed opinion of this library. Anyhow, I'm really glad that we finally have a reasonable licensed alternative to Tokyo Cabinet and BDB. Big kudos to the author of this project. Keep up the good work!
andrewstuart 13y ago
It's strange that he named it unqlite which is the logical name for what Richard Hipp didn't/might've developed had he developed a JSON database build on his unql spec. I understand that the author got the nod from Richard Hipp, but it's still hard to understand why he named it thus.

49 points by mmariani 13y ago

I've been wanting something like this for a while. I've been using my own just straight JSON flat files to store things, which works out pretty well for getting something out the door fast, or coding without an internet connection.

jasonjayr 13y ago

Oracle's recent licensing shenanigains aside, How is this different from BerkleyDB, or any of the old DBM variants, or Kyoto Cabinet?

SomeCallMeTim 13y ago
Licensing is a key issue. BerkeleyDB is AGPL and was previously under another strong copyleft license, neither of which could you embed in a commercial product without paying. Kyoto Cabinet is also GPL. Again, no-go for a commercial product. TOKYO Cabinet, on the other hand, is LGPL, so it at least CAN be embedded, but it's described as inferior to Kyoto. [1] Regardless, if you want something to embed, it's not always easy when you have a huge pile of source with a build system that doesn't match your own. Another feature they describe is that the entire code base comes as a massive (1.3Mb) C file with no dependencies. That's a big win for "drop in the project and build." Not making any claims for how good this particular library is, but at least it would be marginally interesting if I wanted a persistent key-value store in an app. The other go-to option is SQLite, which has a similar massive C file for easy embedding (and an even more permissive license: "Released to the Public Domain"), but SQLite's code is 4.8Mb. Size does matter, so SQLite needs to offer me some advantage to justify its size. The data I store in most apps locally doesn't require JOINs. [1] http://fallabs.com/tokyocabinet/ http://fallabs.com/tokyocabinet/
- epo 13y ago
  Well commented C code should be huge! To say that "size does matter" and only mention source code size is ... Well, I shall be charitable and assume you are having a bad day.
  - SomeCallMeTim 13y ago
    cloc can answer the question definitively: $ cloc sqlite3.c 1 text file. 1 unique file. 0 files ignored. http://cloc.sourceforge.net v 1.58 T=2.0 s (0.5 files/s, 70228.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C 1 9585 46745 84126 ------------------------------------------------------------------------------- $ cloc unqlite.c 1 text file. 1 unique file. 0 files ignored. http://cloc.sourceforge.net v 1.58 T=0.5 s (2.0 files/s, 119944.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C 1 314 18670 40988 ------------------------------------------------------------------------------- SQLite seems to have more verbose comments, but still has more than 2x the lines of code. If you want to build both on the same platform and compare binary size, be my guest.

gummydude 13y ago

Is there an android client/driver/port?

SomeCallMeTim 13y ago
One C file with no dependencies? Should be a trivial build and interface wrap using the NDK.

vertis 13y ago

Discussion from last time this was posted: https://news.ycombinator.com/item?id=5750338 https://news.ycombinator.com/item?id=5750338

mmariani 13y ago
<rant>The previous discussion is a sad display of what HN has become. Clearly most of the posters didn't go further than reading a few pages from the project's website. When instead they should've read some of the project's well commented C source code as anyone would expect from a group that's comprised of hackers. For instance http://unqlite.org/db/unqlite_doc_intro.c http://unqlite.org/db/unqlite_doc_intro.c – Luke, read the source!</rant> Now I'd like to get back to the topic, Unqlite. The project's documentation is objective and adequate to serve as a quick reference during the development of projects that use this library. The scripting language that goes with this DB feels very intuitive, its's apparently is very fast, and it has a small footprint. Its zipped source code with tests are a 23KB download, impressive. Later this week I will build a small test app with this database to develop a more informed opinion of this library. Anyhow, I'm really glad that we finally have a reasonable licensed alternative to Tokyo Cabinet and BDB. Big kudos to the author of this project. Keep up the good work!

andrewstuart 13y ago

It's strange that he named it unqlite which is the logical name for what Richard Hipp didn't/might've developed had he developed a JSON database build on his unql spec. I understand that the author got the nod from Richard Hipp, but it's still hard to understand why he named it thus.