v0.22.0

• Important Security Fix: The behavior of SET $x has been modified to match SELECT $x.
  • Security Risk: Previously, SET $x could be overwritten by a POST parameter named x.
  • Solution: Upgrade to SQLPage v0.22. If not possible, then update your application to use SET :x instead of SET $x.
  • For more information, see GitHub Issue #342.
• Deprecation Notice: Reading POST variables using $x.
  • New Standard: Use :x for POST variables and $x for GET variables.
  • Current Release Warning: Using $x for POST variables will display a console warning:

    Deprecation warning! $x was used to reference a form field value (a POST variable) instead of a URL parameter. This will stop working soon. Please use :x instead.
    

  • Future Change: $x will evaluate to NULL if no GET variable named x is present, regardless of any POST variables.
  • Detection and Update: Use provided warnings to find and update deprecated usages in your code.
  • Reminder about GET and POST Variables:
    • GET Variables: Parameters included in the URL of an HTTP GET request, used to retrieve data. Example: https://example.com/page?x=value, where x is a GET variable.
    • POST Variables: Parameters included in the body of an HTTP POST request, used for form submissions. Example: the value entered by the user in a form field named x.
• Two backward-incompatible changes in the chart component's timeseries plotting feature (actioned with TRUE as time):
  • when providing a number for the x value (time), it is now interpreted as a unix timestamp, in seconds (number of seconds since 1970-01-01 00:00:00 UTC). It used to be interpreted as milliseconds. If you were using the TRUE as time syntax with integer values, you will need to divide your time values by 1000 to get the same result as before.
    • This change makes it easier to work with time series plots, as most databases return timestamps in seconds. For instance, in SQLite, you can store timestamps as integers with the unixepoch() function, and plot them directly in SQLPage.
  • when providing an ISO datetime string for the x value (time), without an explicit timezone, it is now interpreted and displayed in the local timezone of the user. It used to be interpreted as a local time, but displayed in UTC, which was confusing. If you were using the TRUE as time syntax with naive datetime strings (without timezone information), you will need to convert your datetime strings to UTC on the database side if you want to keep the same behavior as before. As a side note, it is always recommended to store and query datetime strings with timezone information in the database, to avoid ambiguity.
    • This change is particularly useful in SQLite, which generates naive datetime strings by default. You should still store and query datetimes as unix timestamps when possible, to avoid ambiguity and reduce storage size.
• When calling a file with sqlpage.run_sql, the target file now has access to uploaded files.
• New article by Matthew Larkin about migrations.
• Add a row-level id attribute to the button component.
• Static assets (js, css, svg) needed to build SQLPage are now cached individually, and can be downloaded separately from the build process. This makes it easier to build SQLPage without internet access. If you use pre-built SQLPage binaries, this change does not affect you.
• New icon_after row-level property in the button component to display an icon on the right of a button (after the text). Contributed by @amrutadotorg.
• New demo example: dark theme. Contributed by @lyderic.
• Add the ability to bind to a unix socket instead of a TCP port for better performance on linux. Contributed by @vlasky.