Org Roam 数据库总是全量重建, 可能的修复方法

所以评估了下使用的成本和使用的收益,我选择暂时搁置org-roam :joy:

denote 最大的优势在于它的命名的格式,有时间戳,index,title和tag。一看文件名就知道大概的内容。

基于该命名方式可以很方便的作筛查和排序。

搞数据库有啥明显的好处?

方便索引, 内容不多的时候没影响, 内容多到一定程度后搜索和统计速度更快.

感觉就是把org-mode的headline提升到了文件名 :joy:

1 个赞

这个类容多是什么数量级? denote 有人测了下一万笔记没啥性能缺馅。

还是有区别,headline 只是denote 中的title,没有其他信息。

denote 还是文件命名方式,如果使用org roam 也按照这一命名方式执行,应该也可以。

headline行也有tag,我不知道index是什么,但是时间戳也只是命名习惯的问题。

anyway,感谢推荐,听上去这个方案更适合习惯多个小文件的用户。对我来说层级也是笔记管理的重要部分,denote不太适合我的需求。

这个我也没好好测试过,我存放org内容的sqlite数据库文件最多的时候有40多M,后来vacuum等整理了一遍现在有26M

图片

如果把这些都导出成纯文本文件,内容太多我现在也不知道该用什么样的规则来管理这些文件了

纯文本的话,26M,那笔记量应该很大了。

主要是一个org文件会存很多份导致的, 即使内容只改了一个字, 也当作一个版本存一份, 开始是想类似本站的贴子一样实现 历史记录的功能 , 后面就完全是怕丢了

个人在使用 org-roam 一段时间后的感受

痛点:

1 - windows 系统中,启动 emacs 的同时自动同步 org-roam 数据,导致 org 文档打开时乱码。所以目前关闭了自动同步 org-roam 数据,改为启动 emacs 后手动同步。

2 - windows 系统中,通过 org-roam 生成的 org 文档,在被 ripgrep 搜索到关键字打开时,会失败、无法被打开。

优点:
1 - 关联式笔记,的确可以促发主动学些、记忆。虽然这一点完全可以被 ripgrep 取代,但 org-roam 更直观。

2 - 使用 org-roam 搜索关键词时,自动在闭环内查找,省去了范围设置,效率也因范围的固定而相对提高。

总结:
目前,个人使用 org-roam 的范围只限固定内容、无需频繁修改的笔记中。还用于一些关联性特别强的笔记中。大多还是使用原生org + ripgrep 比较多。

这两个痛点疑似都与字符编码有关,我在Windows上用Org-roam和ripgrep,没有出现这类问题

1 - windows 系统中,启动 emacs 的同时自动同步 org-roam 数据,导致 org 文档打开时乱码。所以目前关闭了自动同步 org-roam 数据,改为启动 emacs 后手动同步。

试试设置org-mode的字符编码,同时开启自动revert功能:

(use-package lazy-revert
  :ensure nil
  ;; :quelpa (lazy-revert :fetcher github
  ;;                      :repo "yilin-zhang/lazy-revert")
  :hook (after-init . lazy-revert-mode)
  ;; Optional
  :config
  (setq auto-revert-verbose t ; let us know when it happens
        auto-revert-use-notify nil
        auto-revert-stop-on-user-input nil
        ;; Only prompts for confirmation when buffer is unsaved.
        revert-without-query (list ".")))
(add-to-list 'file-coding-system-alist '("\\.org\\'" . utf-8))

2 - windows 系统中,通过 org-roam 生成的 org 文档,在被 ripgrep 搜索到关键字打开时,会失败、无法被打开。

试试设置ripgrep的字符编码

(add-to-list 'process-coding-system-alist
                        '("[rR][gG]" . (utf-8 . gbk-dos)))

还有些其他可能有用的字符编码设置:

(prefer-coding-system 'utf-8)
(setq default-buffer-file-coding-system 'utf-8)
(set-default 'process-coding-system-alist
             '(("[pP][lL][iI][nN][kK]" gbk-dos . gbk-dos)
               ("[cC][mM][dD][pP][rR][oO][xX][yY]" gbk-dos . gbk-dos)))
4 个赞

哇~太感谢了! :smiley:这两大痛点终于不会再戳我啦!!! :+1:

历史记录定时git add & commit 是不是更合适?

org文件都存数据库,不在使用文件系统管理org文件,git也就用不上了,其实我理解git也是一个数据库(好像有个什么包可以用写sql的方式查git的记录),只是还需要把文件批量导出后查看

居然是用数据库存org😂

我会更倾向:用文件系统管理org文件,这样版本管理、同步、跨设备都有更好的兼容性。如果有需要,再把org-mode中的大纲及其对应的属性、标签等信息存到数据库,类似org-roam,满足进阶的高级搜索。用适合的工具做适合的事情,用起来会更顺手

是不是用数据库存org之后,org-agenda、搜索等功能都不能用emacs的,都要根据sqlite结构重写?

没有用org-agenda,搜索根据结构重写,我自己做搜索界面还是比较满意的 image image

用begin-src形式把搜索执行的sql语句也一并在org里显示出来,这个工具我在考虑有没有可能用其它语言(如go)实现,这样减少一些部署时的环境依赖,如果能搞定的话在开源出来

有点像网站的思路

感觉您是只要了org-mode的标记语法,相关的函数功能好多都要重新实现

就是拿做的网站来改的,自用不想写html+css+js,又发现写org比写htm+css+js舒服太多,于是就用org-mode来做前端了,我大概是第一个这么做的人