PHP SQLite PRAGMA journal_mode = wal и только для чтения
Я прочитал, что режим WAL позволяет пользователям читать во время сеанса записи.
Поэтому у меня должно быть 3 сессии для чтения данных и одной записи одновременно. Это звучит как хорошая вещь для моего использования, поэтому я решил, что должен определить тип сеанса, чтобы система знала, является ли этот сеанс считывателем или писатель, использующий флаг соединения.
http://php.net/manual/en/sqlite3.open.php#refsect1-sqlite3.open-parameters
Здесь говорится, что если сессия не закрыта чисто, что -shm а также -wal файлы не удаляются
https://www.sqlite.org/tempfiles.html#write_ahead_log_wal_files
После сеанса чтения временные файлы не удаляются, что означает, что сеанс не был чисто закрыт, несмотря на вызов функции close и возвращение trueпочему файлы не удаляются при использовании SQLITE3_OPEN_READONLY флаг? Должен ли я вообще использовать флаг?
Решение
Вы связали концепцию SQLite «читатели» и «писатели» со способностью драйвера PHP SQLite3 открывать файл только для чтения.
С использованием SQLITE3_OPEN_READONLY флаг заставит PHP блокировать все операции записи с предупреждением:
Предупреждение: SQLite3 :: exec (): попытка записи базы данных только для чтения в …
Это может быть полезно, если вы хотите, чтобы из вашего приложения не происходило никаких записей (возможно, в качестве меры безопасности). Но это не относится к читателям и авторам SQLite.
Как указал CL все процессы, обращающиеся к базе данных в режиме WAL, должны иметь права на запись. Это явно документированный:
Кроме того, если нескольким процессам требуется доступ к базе данных в режиме WAL, то все процессы должны выполняться под идентификаторами пользователя или группы, которые дают им доступ на запись к файлам базы данных, файлу WAL, файлу общей памяти -shm и каталогу, в котором они находятся.
И упоминается как недостаток в верхней части этой страницы:
Невозможно открыть базы данных WAL только для чтения. Процесс открытия должен иметь права на запись для файла общей памяти wal-index «-shm», связанного с базой данных, если этот файл существует, или же доступ на запись в каталог, содержащий файл базы данных, если файл «-shm» не существует.
SQLite сам решает, является ли процесс читателем или писателем, когда он получает команду для выполнения. Например, если один процесс выполняет SELECT, затем INSERT, затем SELECT опять это меняется от читателя к писателю к читателю. SQLite будет обрабатывать блокировку (потенциально блокируя другие процессы) автоматически. (Обратите внимание, что это упрощенное объяснение, которое может сильно отличаться при разных режимах работы базы данных.)
Для ваших целей вы не должны использовать SQLITE3_OPEN_READONLY флаг.
Другие решения
Других решений пока нет …