librime-lua: sync throws `Error opening db '...': IO error: lock .../...userdb/LOCK: already held by process` when both `Memory` and `table_translator@...` use the same dict
Based on rime-fast-xhup and this issue, I use the following to write one custom word to the userdb.
dict_ns = 'melt_eng'
-- in init
env.mem = Memory(env.engine, Schema('double_pinyin_flypy'), dict_ns)
...
-- in func
dict.text = inp
dict.custom_code = inp.." "
dict.comment = '(to add)'
local ph = Phrase(env.mem, "en_custom", seg.start, seg._end, dict)
yield(ph:toCandidate())
Although it has the advantage of loading the committed word automatically without re-deploy, but it will throw Error opening db '...': IO error: lock .../...userdb/LOCK: already held by process error when sync in Fcitx5, etc., but not in weasel where the latter probably solves with this situation inherently. Then we can use file module to manually append the entry to the YAML or txt file, but that will need re-deploy.
Is there one way to avoid the above error but also keep the above advantage?
About this issue
- Original URL
- State: closed
- Created 3 months ago
- Comments: 30 (10 by maintainers)
玩了一会 leveldb,用做临时的词典的话,刚刚能用。
导入导出不成问题,但权重可能有点麻烦,让 GitHub Copilot 根据样例写了个大概:
leveldb.lua.txt
但还是想搞清楚这个 issue 提到的问题如何解决
请教一个问题,这个 leveldb 的数值可以像 librime 的 userdb 借助 librime cli 导出、合并吗?@shewer
似乎 rime_dict manager 导出的是只有文件头的空内容,
倒是发现用
能获取一份内容。是不是只能在 lua 里面这些合并、导出的操作。
比如说这个根据 sample 做小小改动的脚本 https://github.com/hchunhui/librime-lua/issues/330#issuecomment-2063339939
Weasel 在同步的时候,会进入【维护模式】,释放占用的文件资源。或许因此不会出现 LOCK 的情况。
不清楚这种维护模式是否是所有前端都有的逻辑,也不清楚在这种维护模式下,lua 是否会按设计释放资源。
那我不太清楚了,我的
weasel0.15.0 没有这个问题,weasel代码我没怎么看过,具体为啥会(帮助/不)解锁 LOCK 不太清楚。我这里试过了,把 Memory 关掉后,其他全部不动,不会出现上述报错,可以正常 sync 了 (否则 LOCK 相关用户词典无法 sync)。您的情况我不是太清楚,可能和我的有点区别。
您提到 stroke,看到您写的
search.lua代码(已 merge 到 rime-ice),可能和ReverseLookup有关系,本质上应该都和 db 有关,属于同一类问题 (目前我只在反查里看到有用过stroke)。 我 Reverse 词典基本上不用,不是太懂。 在这里感谢您给 rime-ice 写的那么多 lua 代码,方便了 lua 新手写 lua 代码。嗯,感谢您的建议。目前我也是这样处理的(见 imfuxiao/Hamster#593)
如果沒用 LevelDb 就不用在意