我使用的是 Python2.7 的dumbdbm
,但这个问题也适用于 Python3 的dbm.dumb
。
文档说:
dumbdbm.sync()
同步磁盘目录和数据文件。该方法由 Shelve 对象的 sync() 方法调用。
我有三个问题:
一个——也许是最好的——如果不是唯一的话——回答文档中没有特别解决的此类问题的方法是阅读源代码(当它可用时,就像它在这里一样)。
该dumbdbm.py
文件应该在您的/Python/Lib
目录中,也可以通过 Mercurial 源代码修订控制系统在您的浏览器中在线查看:
https://hg.python.org/cpython/file/2.7/Lib/dumbdbm.py
首先要注意的是私人_Database
课程开头的冗长评论——这就是dumbdbm
数据库的真正含义——因为它似乎通常处理您问题的总体主题:
class _Database(UserDict.DictMixin):
# The on-disk directory and data files can remain in mutually
# inconsistent states for an arbitrarily long time (see comments
# at the end of __setitem__). This is only repaired when _commit()
# gets called. One place _commit() gets called is from __del__(),
# and if that occurs at program shutdown time, module globals may
# already have gotten rebound to None. Since it's crucial that
# _commit() finish successfully, we can't ignore shutdown races
# here, and _commit() must not reference any globals.
通过阅读它们的源代码,可以找到有关特定方法的深入信息。鉴于此,我认为您的问题的答案将适用于 Python 2.7 版:
如果我不打电话sync
,磁盘文件会更新吗?
从前面的评论中,听起来只要您的程序优雅地关闭它就可以了。
除此之外,它取决于已调用的方法。有些可能,但只是部分。例如,它看起来__setitem__()
确实如此,具体取决于该项目是用于全新密钥还是现有密钥。对于后一种情况,在处理它们的部分末尾有一条评论说(意识到这_commit()
只是 的另一个名称sync()
):
请注意,现在
_index
可能与目录文件不同步:_setval()
并且_addval()
不要更新目录文件。这也意味着磁盘上的目录和数据文件处于相互不一致的状态,并且它们将保持这种状态直到_commit()
被调用。请注意,如果程序崩溃(因此_commit()
永远不会被调用),这将是一场灾难(对于数据库而言)。
这个函数是否总是将数据写回磁盘,而不是相反?
sync()
/_commit()
似乎没有将任何数据从磁盘加载回内存。
如果我打电话close
怎么办?
close()
只需调用_commit()
然后将所有内部数据结构设置为None
,防止任何进一步的数据库操作。
总之,对于这里的元主题有点幽默,我建议你阅读Learn to Read the Source, Luke。