
UnQLite - An Embeddable NoSQL Database Engine - mmariani
http://unqlite.org/
======
andrewstuart
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.

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

~~~
SomeCallMeTim
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
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
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.

------
vertis
Discussion from last time this was posted:
[https://news.ycombinator.com/item?id=5750338](https://news.ycombinator.com/item?id=5750338)

~~~
mmariani
<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!

------
programminggeek
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.

------
gummydude
Is there an android client/driver/port?

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

