Hacker News new | comments | show | ask | jobs | submit login
UnQLite - An Embeddable NoSQL Database Engine (unqlite.org)
49 points by mmariani 1149 days ago | hide | past | web | 10 comments | favorite



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.


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


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/


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.


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.


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


<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 – 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!


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.


Is there an android client/driver/port?


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: