Error from sqlite3 initialising sqlite.

[MichaelBellBOM]

Describe the bug
When running coverage.
I get Couldn't use data file '/home/mbell/projects/api-aac/.coverage': Safety level may not be changed inside a transaction
This is because for certain builds of sqlite3 synchronous
To Reproduce
How can we reproduce the problem? Please be specific. Don't link to a failing CI job. Answer the questions below:

1. What version of Python are you using?
   3.10.4
2. What version of coverage.py shows the problem? The output of coverage debug sys is helpful.
   coverage==7.2.1
3. What versions of what packages do you have installed? The output of pip freeze is helpful.
   pytest==7.3.2
   pytest-cov==4.1.0
4. What code shows the problem? Give us a specific commit of a specific repo that we can check out. If you've already worked around the problem, please provide a commit before that fix.
   The problem is there is not exactly any visible code, this issue occurs when running:
   coverage json or pytest --json-report --json-report-file nosetests.json --cov tests/ tests/
   The reason this is occurring because of differences in the _sqlite3.so file even if the same version of sqlite3.
   If I run PYTHONPATH=. coverage json --debug=sql
   The out put is

Connecting to '/home/mbell/projects/api-aac/.coverage'
Executing 'pragma journal_mode=off'
Executing 'pragma synchronous=off'
EXCEPTION from execute: Safety level may not be changed inside a transaction
Couldn't use data file '/home/mbell/projects/api-aac/.coverage': Safety level may not be changed inside a transaction

If I change the installed libraries to run pragma synchronous=off before pragma journal_mode=off. Then everything works successfully

1. What commands should we run to reproduce the problem? Be specific. Include everything, even git clone, pip install, and so on. Explain like we're five!
   On Linux:
   Get a version of a _sqlite3.so file and put it in a root directory of the project.
   Make sure coverage is installed pip install coverage
   Run coverage json

Expected behavior
A clear and concise description of what you expected to happen.
Run coverage without sqlite triggered error.

Additional context
Using the _sqlite3.so binary directly as it has been taken from an appropriate environment to be used inside aws lambda for python3.10

[MichaelBellBOM]

_sqlite3.zip
Included a _sqlite3.so with this behaviour

[nedbat]

You said, "This is because for certain builds of sqlite3 synchronous". Is something missing there?

I don't understand why you are changing the _sqilte3.so file. How did you end up with a SQLite that is different?

[MichaelBellBOM]

Sorry I meant to say
This is because for certain builds of sqlite3 do not allow you to change pragma synchronous setting after a coomand has already been issued to the connection.

As for why how I ended up with a version of SQLite that is different. I do not know why it is different but I do know from working with the issue before that different OS's and different versions of python seems have differences in the _sqlite3.so that are used. I created this _sqlite3.so file by install (via yum) sqlite3 on a machine running amazon linux 2 and then running a make file to install python 3.10.

This provides me with a _sqlite3.so I can run inside aws lambdas for python 3.10, (the aws lambda defaults to not being able to load extensions while extensions are required for my use case.)

While I have figured out why the error occurs, I have been unable to determine the difference in the sqlite3 between that and other _sqlite3.so files that causes the error to trigger for this particular compile.

Note I believe that sqlite is identical, but there must be some different in the underlying mechanisms of accessing it in python that is different.

[nedbat]

Thanks! I've "fixed" this (ignore the error) in commit 2125136.

Strangely, SQLite offers a pile of compile-time settings, but they are identical between the working and broken .so versions:

$ python -m coverage debug sys
         sqlite3_sqlite_version: 3.37.2
             sqlite3_temp_store: 0
        sqlite3_compile_options: ATOMIC_INTRINSICS=1, COMPILER=gcc-11.3.0, DEFAULT_AUTOVACUUM,
                                 DEFAULT_CACHE_SIZE=-2000, DEFAULT_FILE_FORMAT=4,
                                 DEFAULT_JOURNAL_SIZE_LIMIT=-1, DEFAULT_MMAP_SIZE=0, DEFAULT_PAGE_SIZE=4096,
                                 DEFAULT_PCACHE_INITSZ=20, DEFAULT_RECURSIVE_TRIGGERS,
                                 DEFAULT_SECTOR_SIZE=4096, DEFAULT_SYNCHRONOUS=2,
                                 DEFAULT_WAL_AUTOCHECKPOINT=1000, DEFAULT_WAL_SYNCHRONOUS=2,
                                 DEFAULT_WORKER_THREADS=0, ENABLE_COLUMN_METADATA, ENABLE_DBSTAT_VTAB,
                                 ENABLE_FTS3, ENABLE_FTS3_PARENTHESIS, ENABLE_FTS3_TOKENIZER, ENABLE_FTS4,
                                 ENABLE_FTS5, ENABLE_JSON1, ENABLE_LOAD_EXTENSION, ENABLE_MATH_FUNCTIONS,
                                 ENABLE_PREUPDATE_HOOK, ENABLE_RTREE, ENABLE_SESSION, ENABLE_STMTVTAB,
                                 ENABLE_UNLOCK_NOTIFY, ENABLE_UPDATE_DELETE_LIMIT, HAVE_ISNAN,
                                 LIKE_DOESNT_MATCH_BLOBS, MALLOC_SOFT_LIMIT=1024, MAX_ATTACHED=10,
                                 MAX_COLUMN=2000, MAX_COMPOUND_SELECT=500, MAX_DEFAULT_PAGE_SIZE=32768,
                                 MAX_EXPR_DEPTH=1000, MAX_FUNCTION_ARG=127, MAX_LENGTH=1000000000,
                                 MAX_LIKE_PATTERN_LENGTH=50000, MAX_MMAP_SIZE=0x7fff0000,
                                 MAX_PAGE_COUNT=1073741823, MAX_PAGE_SIZE=65536, MAX_SCHEMA_RETRY=25,
                                 MAX_SQL_LENGTH=1000000000, MAX_TRIGGER_DEPTH=1000,
                                 MAX_VARIABLE_NUMBER=250000, MAX_VDBE_OP=250000000, MAX_WORKER_THREADS=8,
                                 MUTEX_PTHREADS, OMIT_LOOKASIDE, SECURE_DELETE, SOUNDEX, SYSTEM_MALLOC,
                                 TEMP_STORE=1, THREADSAFE=1, USE_URI

[MichaelBellBOM]

Thanks, much appreciated

[nedbat]

This is now released as part of coverage 7.3.0.