1. 62
  1. 7

    I wrote recordlite recently to declaratively manage table/views in SQLite for semi-structured data. This is very similar to the technique you use.

    1. 3

      So you’re saying we should stop parsing our own JSON inputs and push everything into a ‘in-memory’ SQLite DB as an input buffer and then read from there? I’m okay with that.


      1. 4

        SQLite is a very accessible (low effort) & powerful REPL.

        1. 3

          I’m doing it as an on-disk database (mostly so that you can change your mind later and glean more data out of the JSON should you need to), but sure yeah whatever

          1. 1

            I’m totally ok with this too, I’d trust the SQLite devs with… most things more than many other devs. I feel like learning how to use SQLite specifically should be required for all CS/IT students, it’s just so versatile.

            Why am I not surprise this comment was made by you mankyKitty <3

          2. 3

            Hm I didn’t know about json_extract, interesting. sqlite has added all sorts of stuff recently! I remember playing with the window functions recently which weren’t available until 9/2018 apparently: https://github.com/oilshell/blog-code/blob/master/data-frames/run.sh#L125

            I think I first heard about sqlite in 2007, but there have been big improvements since then. Not to mention hardware got faster.

            1. 2

              This is pretty neat, never knew about these things (including generated columns at the end)

              Thank you for sharing

              1. 2

                wheretrue, the hidden apex predator of the SQLite realm