Codecov Report

Merging #347 (71b6c38) into main (213a0ff) will increase coverage by 0.00%. The diff coverage is 100.00%.

:exclamation: Current head 71b6c38 differs from pull request most recent head 1a7ef2f. Consider uploading reports for the commit 1a7ef2f to get more accurate results

```diff @@ Coverage Diff @@

main #347 +/-

======================================= Coverage 96.51% 96.52%
======================================= Files 5 5
Lines 2270 2271 +1
======================================= + Hits 2191 2192 +1
Misses 79 79
```

| Impacted Files | Coverage Δ | | |---|---|---| | sqlite_utils/cli.py | 95.73% <100.00%> (ø) | | | sqlite_utils/utils.py | 93.68% <100.00%> (+0.03%) | :arrow_up: |

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 213a0ff...1a7ef2f. Read the comment docs.

If I'm going to skipIf() those tests I need a way to check if pysqlite3 is being used.

A short term fix would be to skip those tests against pysqlite3 - but longer term it would be good to address the underlying issue, particularly for the WAL ones (the FTS ones aren't too worrying since if you deliberately try and break the FTS table it's not hugely problematic if you corrupt your database).

Some interesting test failures in the version that runs with pysqlite3: =========================== short test summary info ============================ FAILED tests/test_cli.py::test_enable_wal - assert 0 == 1 FAILED tests/test_cli.py::test_disable_wal - pysqlite3.dbapi2.OperationalErro... FAILED tests/test_fts.py::test_rebuild_fts[searchable] - pysqlite3.dbapi2.Dat... FAILED tests/test_fts.py::test_rebuild_fts[searchable_fts] - pysqlite3.dbapi2... FAILED tests/test_wal.py::test_enable_disable_wal - pysqlite3.dbapi2.Operatio... ================== 5 failed, 750 passed, 3 skipped in 15.20s =================== https://github.com/simonw/sqlite-utils/runs/4360759085

The WAL errors look like this: E pysqlite3.dbapi2.OperationalError: cannot change into wal mode from within a transaction Triggered by a call to db.enable_wal()

The FTS errors are caused by tests that try to deliberately corrupt the FTS index by running fresh_db["searchable_fts_data"].delete_where() - and then rebuilding it using rebuild_fts(): ``` @pytest.mark.parametrize("table_to_fix", ["searchable", "searchable_fts"]) def test_rebuild_fts(fresh_db, table_to_fix): table = fresh_db["searchable"] table.insert(search_records[0]) table.enable_fts(["text", "country"]) # Run a search rows = list(table.search("tanuki")) assert len(rows) == 1 assert { "rowid": 1, "text": "tanuki are running tricksters", "country": "Japan", "not_searchable": "foo", }.items() <= rows[0].items() # Delete from searchable_fts_data fresh_db["searchable_fts_data"].delete_where() # This should have broken the index with pytest.raises(sqlite3.DatabaseError): list(table.search("tanuki")) # Running rebuild_fts() should fix it

  fresh_db[table_to_fix].rebuild_fts()

tests/test_fts.py:277:

sqlite_utils/db.py:1947: in rebuild_fts self.db.execute(

self = <Database \<pysqlite3.dbapi2.Connection object at 0x7fd95d299c30>> sql = "INSERT INTO searchable_fts VALUES('rebuild');" parameters = None

def execute(
    self, sql: str, parameters: Optional[Union[Iterable, dict]] = None
) -> sqlite3.Cursor:
    "Execute SQL query and return a ``sqlite3.Cursor``."
    if self._tracer:
        self._tracer(sql, parameters)
    if parameters is not None:
        return self.conn.execute(sql, parameters)
    else:

      return self.conn.execute(sql)

E pysqlite3.dbapi2.DatabaseError: database disk image is malformed ```

Took a bit of experimenting to get both mypy AND flake8 to ignore the same line. The incantation that worked was this one:

https://github.com/simonw/sqlite-utils/blob/f990e134aa8219b687ff6c261330f36824b5df36/sqlite_utils/utils.py#L8

Order here matters - this did NOT work for both tools:

python from sqlite3.dump import _iterdump as iterdump # noqa: F401 # type: ignore

https://github.com/simonw/sqlite-utils/blob/93b059dd230eae9eaae472b7fbabd4a66feeb79d/.github/workflows/test.yml#L11-L20

This configuration means that the numpy=0, Python=3.10, os=Ubuntu build will additionally use pysqlite3 with the SQLite 3.37.0.

It's failing right now: https://github.com/simonw/sqlite-utils/runs/4360593156 - because pysqlite3 doesn't provide .iterdump().

I can use the workaround from this comment: https://github.com/coleifer/pysqlite3/issues/24#issuecomment-982081267

It failed on other Python versions with mypy: sqlite_utils/utils.py:8: error: Cannot find implementation or library stub for module named "sqlite3.dump" sqlite_utils/utils.py:8: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports

Here's the test run that's installing pysqlite3 and that version of SQLite: https://github.com/simonw/sqlite-utils/runs/4360663292

To keep things simple for the moment I'm only going to add one extra thing to the matrix, and it will be a run of the tests against SQLite 3.37.0 using pysqlite3 on Linux only.

I can use this mechanism: https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#example-including-new-combinations

I have a working recipe for compiling it for macOS here: https://github.com/simonw/sqlite-utils/issues/344#issuecomment-982006544

For the moment I think I'll combine two problems into one, and just add a single matrix alternative that uses pysqlite3 running SQLite 3.37.0 - only on macOS and Linux so I don't have to figure out how to compile it for Windows.

This is the implementation: https://github.com/simonw/sqlite-utils/blob/213a0ff177f23a35f3b235386366ff132eb879f1/sqlite_utils/db.py#L1236-L1241

Documented here: https://sqlite-utils.datasette.io/en/latest/python-api.html#strict

Here's a modified version of the dump command that works even with pysqlite3:

```python @cli.command() @click.argument( "path", type=click.Path(exists=True, file_okay=True, dir_okay=False, allow_dash=False), required=True, ) @load_extension_option def dump(path, load_extension): """Output a SQL dump of the schema and full contents of the database""" db = sqlite_utils.Database(path) _load_extensions(db, load_extension) # pysqlite3 doesn't implement .iterdump() from sqlite3.dump import _iterdump

for line in _iterdump(db.conn):
    click.echo(line)

```

Ideally I'd like an extra set of matrix options for different versions of SQLite.

I can use pysqlite3 for this, but it isn't a completely compatible drop-in replacement - turns out it doesn't support the iterdump() method for example, see https://github.com/coleifer/pysqlite3/issues/24

Need to figure out a good pattern for testing this in CI too - it will currently skip the new tests if it doesn't have SQLite 3.37 or higher.

I haven't documented db.supports_strict yet (I documented table.strict) because there wasn't an obvious section of the documentation for it.

I need to remember to document it once I add documentation for the strict=True parameter.

I'm going to add that as db.supports_strict.

Here's a function that detects if strict is supported or not: ```python import secrets import sqlite3

def supports_strict_tables(db = None): if db is None: db = sqlite3.connect(":memory:") try: table_name = 't{}'.format(secrets.token_hex(16)) with db: db.execute("create table {} (name text) strict".format(table_name)) db.execute("drop table {}".format(table_name)) return True except: return False ```

Made myself a test strict table like so:

```pycon

import pysqlite3 conn = pysqlite3.connect("/tmp/strict-table.db") conn.execute("create table foo (id integer primary key, name text, weight real) strict") <pysqlite3.dbapi2.Cursor object at 0x104317340> cursor = conn.cursor() with conn: ... cursor.execute("insert into foo (name, weight) values ('Lila', '2.31')") <pysqlite3.dbapi2.Cursor object at 0x10331e1f0> conn.close() ``` Uploaded that to: https://static.simonwillison.net/static/2021/strict-table.db

From the STRICT docs:

The SQLite parser accepts a comma-separated list of table options after the final close parenthesis in a CREATE TABLE statement. As of this writing (2021-08-23) only two options are recognized:

• STRICT
• WITHOUT ROWID

So I think I need to read the CREATE TABLE statement from the sqlite_master table, split on the last ), split those tokens on , and see if create is in there (case insensitive).

Is there a need for an introspection function for telling if a SQLite table is in strict mode or not? How would that work?

I'm leaning towards silently ignore if SQLite version doesn't support it. That means that the first time you attempt to use strict=True we will need to run a test against the database connection to see what version of SQLite it uses, then cache the result to avoid making the same call again for the same connection.

What should happen if you attempt to use strict=True against a SQLite version prior to 3.37.0?

An obvious error would be best... but how about silently ignoring it on older versions instead? That would match how we handle deterministic=True for registering functions:

https://github.com/simonw/sqlite-utils/blob/126703706ea153f63e6134ad14e5712e4bbcb8ae/sqlite_utils/db.py#L372-L380

https://github.com/simonw/sqlite-utils/blob/93c7fd9868fed3193a1732b39bfac539e5812b0b/tests/test_register_function.py#L34-L37

There are a few places that the strict=True option could go:

• table.create() and table.create_table_sql()
• The Database() constructor, to turn it on for all created tables
• The .insert() / .insert_all() etc family of methods that can implicitly create tables

I'll definitely implement the first one, and likely the second one too. I'm on the fence with regards to the third one.

This worked: cd /tmp mkdir sqlite-3.37 cd sqlite-3.37 wget 'https://www.sqlite.org/2021/sqlite-amalgamation-3370000.zip' unzip sqlite-amalgamation-3370000.zip git clone https://github.com/coleifer/pysqlite3/ cp sqlite-amalgamation-3370000/sqlite3.[ch] pysqlite3 cd pysqlite3 python3 setup.py build_static build bdist_wheel This gave me a file here:

pysqlite3 % ls -l dist total 1872 -rw-r--r-- 1 simon wheel 956557 Nov 29 12:38 pysqlite3-0.4.6-cp39-cp39-macosx_10_15_x86_64.whl That wheel only works when installed for Python 3.9 (it failed to install in a Python 3.10 virtual environment) - but pip install /tmp/sqlite-3.37/pysqlite3/dist/pysqlite3-0.4.6-cp39-cp39-macosx_10_15_x86_64.whl gave me a working pysqlite3 - and the following worked:

```pycon

import pysqlite3 pysqlite3.connect(":memory:").execute("select sqlite_version()").fetchall() [('3.37.0',)] And if I install `sqlite-utils` in the same virtual environment this works: % sqlite-utils memory 'select sqlite_version()' [{"sqlite_version()": "3.37.0"}] ```

I'm going to build my own pysqlite3 wheel with the latest SQLite to try this out, following the instructions on https://github.com/coleifer/pysqlite3

From that page:

If you try to open a database containing the STRICT keyword in an earlier version of SQLite, it will not recognize the keyword and will report an error (except as noted below.

[...]

Because of a quirk in the SQL language parser, versions of SQLite prior to 3.37.0 can still read and write STRICT tables if they set "PRAGMA writable_schema=ON" immediately after opening the database file, prior to doing anything else that requires knowing the schema.

There isn't any way to do this with sqlite as far as I know. The only option is to insert the right number of ? placeholders into the sql template and then provide an array of values.

FWIW I've written some web components that consume the json api and I think it's a really nice way to work with datasette. I like the combination with datasette+sqlite as a back-end feeding data to a front-end that's entirely javascript + html.

TIL: https://til.simonwillison.net/datasette/reuse-click-for-register-commands

Thanks to https://stackoverflow.com/a/45514541/6083 I found the right pattern: ```python from datasette import hookimpl from git_history.cli import cli as git_history_cli

@hookimpl def register_commands(cli): cli.add_command(git_history_cli, name="git-history") ``` I think this is a little bit too obscure to add to the Datasette documentation - I'll turn it into a TIL instead.

Just trying to use git_history_file produces this error:

TypeError: Attempted to convert a callback into a command twice.

Codecov Report

Merging #1537 (fcfaec1) into main (48f1199) will decrease coverage by 0.06%. The diff coverage is n/a.

```diff @@ Coverage Diff @@

main #1537 +/-

========================================== - Coverage 91.90% 91.83% -0.07%
========================================== Files 34 34
Lines 4434 4434
========================================== - Hits 4075 4072 -3
- Misses 359 362 +3
```

| Impacted Files | Coverage Δ | | |---|---|---| | datasette/views/index.py | 96.42% <0.00%> (-1.79%) | :arrow_down: | | datasette/database.py | 92.93% <0.00%> (-0.75%) | :arrow_down: |

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 48f1199...fcfaec1. Read the comment docs.