Announcement

Collapse
No announcement yet.

SQLite 3.40 Released With WASM Support For Web Browsers, Recovery Extension

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

  • SQLite 3.40 Released With WASM Support For Web Browsers, Recovery Extension

    Phoronix: SQLite 3.40 Released With WASM Support For Web Browsers, Recovery Extension

    While Microsoft is celebrating the GA release today of SQL Server 2022, open-source developers have SQLite 3.40 premiering today as the newest version of this embed-friendly SQL database implementation widely used by many cross-platform applications and other software for lightweight SQL database engine needs...

    https://www.phoronix.com/news/SQLite-3.40-Released

  • #2
    SQLite have very few data types, it has like TEXT, INTEGER, and REAL. It doesn't have boolean or datetime, so when you reverse engineer a database (turn an existing database into code for use by a ORM) it cannot generate classes that use datatypes available in the programming language so you end up with shitty generated classes where dates are string and booleans are integers.

    Comment


    • #3
      The other big change with SQLite 3.40 is introducing a recovery extension. While SQLite database files are known to be very robust, in the rare chance they become corrupted there is at least now this means of attempting to recover as much data as possible.
      While I'm sure they didn't just add this functionality just because I can, I have literally never seen SQLite crash or corrupt data, even in case of a system crash. The code is extremely robust and insanely well tested. The documentation is also very extensive and nice to read.

      Comment


      • #4
        Originally posted by uid313 View Post
        SQLite have very few data types, it has like TEXT, INTEGER, and REAL. It doesn't have boolean or datetime, so when you reverse engineer a database (turn an existing database into code for use by a ORM) it cannot generate classes that use datatypes available in the programming language so you end up with shitty generated classes where dates are string and booleans are integers.
        SQLite is a tool, not a miracle solution. If you use your tools wrong, then of course the outcome is not great. SQLite databases are not designed to be reverse-engineered. They deliberately use weak and dynamic typing (dynamic typing has the potential to break your reverse-engineering even more), leaving the handling of more complex types to the application.

        Comment


        • #5
          SQLite has been on a roll lately. v3.39 netted a 2.3% CPU use reduction. v3.40 gave us another 1% CPU use reduction. Should be a win for devices that run on battery or have weaker CPUs. I remember looking at the graph detailing this performance improvement (https://www.sqlite.org/cpu.html) but it hasn't been updated in a long time.

          Comment


          • #6
            Originally posted by uid313 View Post
            SQLite have very few data types, it has like TEXT, INTEGER, and REAL. It doesn't have boolean or datetime, so when you reverse engineer a database (turn an existing database into code for use by a ORM) it cannot generate classes that use datatypes available in the programming language so you end up with shitty generated classes where dates are string and booleans are integers.
            It might be an issue with the ORM rather than with SQLite. I'm using Pony in python and I have zero issues with data types not supported by SQLite, because the ORM does its job and handles all the conversions...

            Comment


            • #7
              Wasm support is neat! Well done! I am looking forward for sqflite (flutter) with browser support!

              Comment


              • #8
                Originally posted by JackLilhammers View Post

                It might be an issue with the ORM rather than with SQLite. I'm using Pony in python and I have zero issues with data types not supported by SQLite, because the ORM does its job and handles all the conversions...
                The ORM can't figure out the data types to use because SQLite hasn't dedicated data types for many common data types such as char, bool and datetime.

                Comment


                • #9
                  Originally posted by uid313 View Post
                  SQLite have very few data types, it has like TEXT, INTEGER, and REAL. It doesn't have boolean or datetime, so when you reverse engineer a database (turn an existing database into code for use by a ORM) it cannot generate classes that use datatypes available in the programming language so you end up with shitty generated classes where dates are string and booleans are integers.
                  If you are using Sqlite with a ORM you will probably generate sub optimal statements because the optimizers is quite limited. There are actually subtypes but they are rarely used. Sqlite has a type for blobs too.

                  PS I think ORMs are workaround for people who dislike SQL. ;-)

                  Comment


                  • #10
                    Originally posted by patrick1946 View Post
                    PS I think ORMs are workaround for people who dislike SQL. ;-)
                    Yeah, I do dislike SQL. With SQL you are writing database-specific SQL since every database server has slightly different SQL language so with a ORM you abstract that way and make the code more portable.
                    The ORM's query planner probably optimize better than most people.
                    With a ORM you can have the compiler ensure that the references columns and tables actually exist, everything is strongly typed.

                    I love ORMs and am glad I don't have to deal with raw SQL too often.

                    Comment

                    Working...
                    X