Add support for sqlite strict mode.

[fire]

For review. I am not sure how to enable strict mode. I added the lines options: "STRICT" to force strict mode.

This fixes problems with uuids, booleans and datetimes on strict mode. We must use the correct sql types.

Help on how to run the test suite.

defmodule Uro.Repo.Migrations.CreateUsers do
  use Ecto.Migration

  def change do
    create table(:users, primary_key: false, options: "STRICT, WITHOUT ROWID") do
      add :id, :uuid, primary_key: true
      add :email, :string, null: false
      add :password_hash, :string

      add :username, :string
      add :display_name, :string

      add :email_notifications, :boolean, default: false

      add :profile_picture, :string
      add :is_admin, :boolean

      timestamps()
    end

    create unique_index(:users, :username)
    create unique_index(:users, :email)
  end
end

https://www.sqlite.org/draft/stricttables.html

[fire]

The tests pass but looking for ideas on how to test strict mode and how to enable strict mode as a config option.

[fire]

@warmwaffles nudge

[warmwaffles]

@fire I had a bit of a family emergency come up over the weekend. I'll be able to take a look at this tomorrow.

[warmwaffles]

I like these changes. My BIGGEST concern is backwards compatibility with existing sqlite databases that were using this prior to the change.

[warmwaffles]

@fire according to the sqlite documentation, the table option is all you need. There is no way to enable it by default upon opening an sqlite database.

Generally speaking I love strict types, but I do appreciate that sqlite allows us to specify custom types in the database in the way we do.

But I say let's merge this.

[fire]

Can you help make strict table test?

[fire]

Ready to go!

[warmwaffles]

Yea @fire I'll throw together some tests and commit them to main after this is merged.

[warmwaffles]

@fire when I get some time today, I'll sling together some more integration tests for strict vs non strict. Once that's done, I'll cut major release since this does break backwards compatibility some what.

[warmwaffles]

@fire I added a note to the changelog about the breaking change under the unreleased section. I think I am going to cut a v1.0.0-rc1 and that can be tested out for a bit.

[warmwaffles]

@fire so I have been chatting with @jeregrine about strict mode. Is there a specific hard requirement as why it is necessary or just a nice to have?

One of the reasons I originally left out the strict mode was being able to handle TEXT_DATETIME differently than just TEXT but also make it apparent to anyone who dumped the schema that the field is intended to be a DATETIME.

Another thing we sort of lose is the ability to specify a field as an ARRAY aka store it as json but deserialize with json_array() and the ability to specify that a field is a JSON field.

[fire]

I wanted to be able to enforce strict and I didn't think starting a fork was the right answer.

Is there something we can do about the loss?

[fire]

The request for sql strict mode is because I was using postgresql and most other sql engines don't offer the type flexibility of sqlite. So the reasoning are more religious in nature to match what the consensus sql developers have.