The next-gen SQLite won't look like SQLite(gist.github.com)
15 pointsby radarroark4 hours ago3 comments
  • DougN73 hours ago
    I wouldn’t call this next-gen SQLite. How can it be when the “QL” of SQLite is “Query Language” and this doesn’t have one? This is an object serialization library.
    • beardyw2 hours ago
      Exactly. SQLite is in use in millions[1] of places, all using SQL. If you want something else don't try to steal the name.

      [1] this figure is based on no research

    • 3 hours ago
      undefined
    • delegate3 hours ago
      Not really. This db allows traversing the (deeply nested) data structures without loading them into memory. Eg. In Clojure you can do ``` (get-in db [:people "john" :address :city]) ```

      Where `:people` is a key in a huge (larger than memory) map. This database will only touch the referenced nodes when traversing, without loading the whole thing into memory.

      So the 'query language' is actually your programming language. To the programmer this database looks like an in-memory data structure, when in fact it's efficiently reading data from the disk. Plus immutability of course (meaning you can go back in history).

  • explodes3 hours ago
    Point 1 may be a problem if you're embedded. Otherwise, enjoy the fact that the 150,000 lines of c-code are some of the most tested lines of code on the planet.

    Point 2 doesn't tackle the reasons why there is a mismatch between in-memory representation and tabular data. Some benefits include the wins obtained from a schema built to utilize "normal form". Object databases have their place, but so do fully normalized database tables.

    Point 3 doesn't strike me as useful. I don't find myself reverting rows to previous points in history that often, if I ever have. Tracking versions of rows is useful. I would argue that "reverting" is not, since the reverting would be better tracked by adding a new version as a forward update.

    Overall, sure, a new, "light weight", object database that uses data structures* may have a place somewhere. But to replace SQLite? I think not.

    *The Java API gives me the same recoil as Java JSON API. Pulling out data key by key feels like pulling teeth tooth by tooth.

  • damnitbuilds3 hours ago
    This looks like Python's pickling: https://docs.python.org/3/library/pickle.html