1

以只读方式打开

我在文件系统上有一个 sqlite3 文件，该文件属于与运行读取过程不同的用户。我希望读取过程能够以只读模式读取文件，所以我传递了 SQLITE_OPEN_READONLY。我希望这能奏效。当然，这个想法是只读模式适用于我们不想写入的文件？

当我准备我的第一份陈述时，我得到

unable to open database file

同样，如果我运行sqlite3命令行工具，我会得到相同的结果，除非我使用 sudo。这似乎向我证实了问题在于可写性而不是其他任何问题。

日志文件

这个问题的答案似乎表明，如果周围有日志文件，那么只读访问是不可能的。

为什么会有日志文件？因为另一个进程正在写入文件，所以我的用户进程正试图以只读方式打开它。为此，我使用了Write-Ahead Logging，它产生两个日志文件，-shm和-wal. 确实，如果我停止写入过程并删除日志文件，我的用户进程可以以只读模式打开它。

不兼容？

所以我有两种情况：

  • 如果文件既属于写入进程又属于只读进程，则预写日志记录使进程 A 可以写入，而进程 B 可以只读

  • 如果文件属于写进程但不属于只读进程，则阻止只读进程以只读方式打开。

我如何实现这两个？把它拼出来，我想要：

  • 写入进程拥有数据库
  • 只读进程不拥有数据库
  • 只读进程无法写入数据库
  • 在数据库上启用了预写日志记录

似乎是一组简单的要求，但我看不到明显的解决方案。

**编辑：**按照这个文档，看起来这是不可能的。你能建议任何替代方法来实现上述目标吗？

4

2 回答 2

1

是的 WAL 日志数据库不能以只读方式打开，显式或以其他方式（即在数据库文件对进程只读的情况下）。

如果您要求绝对不允许只读进程修改数据库文件，那么唯一想到的就是写进程维护一个非 WAL-journal 数据库的附加副本。

底线：据我所知，WAL 和只读无法完成。

于 2012-08-30T09:43:42.960 回答
0

我认为文档所说的是 WAL 数据库本身可能不存在于只读媒体上，这并不一定意味着您不能使用SQLITE_OPEN_READONLY。事实上，我已经成功地打开了两个连接，一个读写连接以及一个使用 SQLITE_OPEN_READONLY 的连接，都在 WAL sqlite 数据库上。这些工作得很好。INSERT我使用只读连接测试了一个查询，该语句正确返回了数据库为只读的错误。

只需确保数据库存储在具有写访问权限的某些介质上，因为需要创建和维护 -shm 文件，因此即使是“仅就绪”连接也可能实际上将某些内容物理写入磁盘 - 这不一定意味着它可以使用 SQL 修改数据。

于 2017-03-12T14:19:11.843 回答