Announcement

Collapse
No announcement yet.

SQLite 3.38 Released With Improved JSON Support, CLI Enhancements

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SQLite 3.38 Released With Improved JSON Support, CLI Enhancements

    Phoronix: SQLite 3.38 Released With Improved JSON Support, CLI Enhancements

    SQLite 3.38 was released as the first major update of 2022 for this popular embedded SQL database library...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    SQLite is sooo good for prototyping. Anyone that uses it on Android or IOS can speak up more about it? I am working on an app and considering using Sqlite to cache things or store things locally, and have it sync data with a server. Is this overkill for an app?

    Comment


    • #3
      an interesting phoronix benchmark could be:

      nim( c -r) with sqlite : count # of inserts in a minute and count # of queries in a minute
      vs nim+mysql ( same counts ) vs python+sqlite vs golang+sqlite
      maybe throw in zig + amalgamation sqlite
      also maybe vlang+vsql memory db vs phix lang+psqlite vs crystal + crystal-sqlite3




      Comment


      • #4
        Originally posted by Babuloseo View Post
        SQLite is sooo good for prototyping. Anyone that uses it on Android or IOS can speak up more about it? I am working on an app and considering using Sqlite to cache things or store things locally, and have it sync data with a server. Is this overkill for an app?
        Last I checked, they intended SQLite to replace fopen(3) as your first choice when not needing to read a pre-existing file format. (i.e. As a portable way to bring back how various pre-UNIX operating systems supported structured files at the OS level.)

        Unless you're asking whether the "caching/storing locally" part is overkill, the answer is "No, it's not overkill".

        SQLite should be your first choice in any situation where you need to rewrite part of a structured file without rewriting the whole thing (eg. as an alternative to something like a plain old .json file when you need to update a specific field without loading the whole file, modifying it in memory, and then writing the whole thing back out to disk)

        For example, I've managed to accidentally corrupt things like BerkeleyDB when I needed a simple key-value store (i.e. a persistent dict/hashmap) but SQLite with a dead-simple table schema never let me down.

        (It was originally designed at General Dynamics for a U.S. Navy contract, it's mind-bogglingly well-tested including a proprietary test suite with 100% MC/DC you can pay for access to, the choice to use it is one of the layers of redundant safety measures in some avionics, and it's one of four formats the U.S. Library of Congress recommends for storing data sets long-term. It's hard to find something more highly-recommended for an on-disk format for structured data that needs to be modified in-place.)
        Last edited by ssokolow; 24 February 2022, 05:12 AM.

        Comment


        • #5
          Originally posted by Babuloseo View Post
          SQLite is sooo good for prototyping. Anyone that uses it on Android or IOS can speak up more about it? I am working on an app and considering using Sqlite to cache things or store things locally, and have it sync data with a server. Is this overkill for an app?
          In my software engineering class about 8 years ago we used SQLite for the database for our iOS development projects. I made a mock store selling retro games and the app read from a database using objective C function calls to the SQLite db. This was before swift took over for objective C so I don't know about modern iOS development but it was so simple back in the day that this kid who wasn't very good at coding could figure it out!

          Comment


          • #6
            Maybe they should consider renaming the project.

            I think they are past the "lite" stage, but I guess everything is relative...

            Comment


            • #7
              Originally posted by ssokolow View Post
              SQLite should be your first choice in any situation where you need to rewrite part of a structured file without rewriting the whole thing (eg. as an alternative to something like a plain old .json file when you need to update a specific field without loading the whole file, modifying it in memory, and then writing the whole thing back out to disk)
              That was my only usage on Android. Between Android 2.2 and 4.0 I'd root my phone and use SQLite to edit the database of the Settings app to unlock tethering. Literally changing a single 1 to a 0. I learned my lesson and quit buying phones from AT&T.

              That was back in the day when I had unlimited 3G with no limits. I miss that plan.

              Comment


              • #8
                Originally posted by Raka555 View Post
                Maybe they should consider renaming the project.

                I think they are past the "lite" stage, but I guess everything is relative...
                Yeah, it's definitely relative when you look at every other mainstream SQL solution.
                But also I hate conflating features for bloat. Just because something does a few more things than it needs to doesn't make it bloated. Bloat is when something does something inefficiently or does something that it simply doesn't need to do. JSON is the biggest industry standard for structured data and many applications work directly with JSON files, so making any database work directly with it is pretty much common sense now. To have a database use any other format would be fracturing your ecosystem and excluding some languages from working with it. Every language ever made has a JSON implementation these days. Adaption isn't bloat.

                Comment


                • #9
                  Originally posted by Ironmask View Post
                  Yeah, it's definitely relative when you look at every other mainstream SQL solution.
                  It's still an embedded database that adds only a few hundred kilobytes to your compiled binary, doesn't handle write concurrency very well compared to non-"lite" SQL databases, and lacks bells and whistles like PostGIS. Sounds pretty "SQLite" to me.

                  Comment

                  Working...
                  X