【科技新聞】Obsidian 1.0 – 個人知識庫應用

愛愛愛黑曜石。該工具在美學上令人愉悅，內置 vim 模式出奇地好（光標閃爍時出現一些小故障） – 但最重要的是，插件社區獲得了蛋糕。

最後，一個帶有不錯 API 的筆記應用程序允許我提取元數據並將指標發佈到 CloudWatch，使我能夠跟踪關鍵指標並以圖形方式[0] 回顧我的“第二大腦”的歷史趨勢。我過去嘗試過的以前的筆記應用程序（例如 Zettlr、Bear）缺乏 Obsidian 培養的充滿活力的開發者社區。

向創始人和黑曜石團隊致敬！

[0] – https://digitalorganizationdad.substack.com/p/stop-zettelkas…

在 Obsidian、Roam、Amplenote 和 Reflect 之間，這無疑是過去幾年筆記的黃金時代。很難記住，僅在 5 年前，Evernote、Notion 和 Bear 等第二代筆記應用程序是唯一可行的選擇，除非您想要 OneNote 或 Workflowy 等第一代應用程序。

這套新的快速移動筆記應用程序可能最有趣的是，它們似乎都是由 3 人或更少人的團隊構建的。 Obsidian 似乎已經憑藉三人團隊登上了頂峰，而且沒有明顯的風險投資資金。任何支持小公司和熱情的程序員的人都應該欣賞 Obsidian 證明最好的工具不必由最大的團隊構建。反之更甚。

恭喜，還有：該死的狗屎！！多年來，沒有任何應用程序將我的日常生活改變到這種程度。

我每天早上在我的屋頂甲板上使用 Obsidian 來記錄我的日記（當然，通過插件自動化），然後整天在我的辦公桌上使用我的日常 WTF 等等等等信息捕獲工具。

當然，我希望它有更多的功能（保持折疊/展開狀態，即使是盡最大努力，可能不會永遠持續下去！內置 git 支持，因為蘋果讓插件開發人員在移動設備上做起來太難了！ ) 但它只是“標準”降價和圖像文件的事實幾乎消除了我所有的抱怨。

我也使用付費的 Sync 插件（即使它是標准文件和文件夾；完全可以自己完成！完全可以使用 SyncThing！等等！）所以它在我所有的機器和虛擬機上。非常適合您每年只接觸的東西的系統管理員日誌，例如爸爸的 iMac。

對於尚未嘗試過的 HN 讀者：基本上是千禧一代的 VisiCalc，除了文字。

Starlink 衛星的那些長而直線的車隊令人著迷。我可以看到其中一些散佈在地球上。它們在什麼時候開始分裂成不相關的軌道？

期待使用該網站嘗試在夜間發現衛星。看到夜空中的物體被人們放置在那裡，有一種奇怪的刺激感。

如果地球在默認縮放中為 750 像素寬，則每個像素為 10mi/16km。國際空間站的比例圖像大約為像素的 1/150。

我真的不知道我在看什麼，但感覺很科幻，我很喜歡。

我也想知道，他們是如何追踪這麼多物體的？誰真正追踪他們？維護跟踪系統需要多少成本（能源、工程師）？

編輯：這些都是模擬軌道嗎？某處是否有一個大的“軌道登記處”？什麼是“光束”？

此版本包括我添加的一項功能 [1] 以支持引用完整性觸發器中的部分外鍵更新！

這對於跨多個表使用非規範化租戶 ID 的模式很有用，這在多租戶應用程序中可能很常見：

 CREATE TABLE tenants (id serial PRIMARY KEY); CREATE TABLE users ( tenant_id int REFERENCES tenants ON DELETE CASCADE, id serial, PRIMARY KEY (tenant_id, id), ); CREATE TABLE posts ( tenant_id int REFERENCES tenants ON DELETE CASCADE, id serial, author_id int, PRIMARY KEY (tenant_id, id), FOREIGN KEY (tenant_id, author_id) REFERENCES users ON DELETE SET NULL );

這個架構有問題。當你刪除一個用戶時，它會嘗試將 posts 表上的 tenant_id 和 author_id 列都設置為 NULL：

 INSERT INTO tenants VALUES (1); INSERT INTO users VALUES (1, 101); INSERT INTO posts VALUES (1, 201, 101); DELETE FROM users WHERE id = 101; ERROR: null value in column "tenant_id" violates not-null constraint DETAIL: Failing row contains (null, 201, null).

當我們刪除一個用戶時，我們真的只想清除posts表中的author_id列，而我們希望保持tenant_id列不變。我添加的功能是一個小的語法擴展來支持這樣做。您可以為 ON DELETE SET NULL / ON DELETE SET DEFAULT 操作提供顯式列列表：

 CREATE TABLE posts ( tenant_id int REFERENCES tenants ON DELETE CASCADE, id serial, author_id int, PRIMARY KEY (tenant_id, id), FOREIGN KEY (tenant_id, author_id) -- Clear only author_id, not tenant_id REFERENCES users ON DELETE SET NULL (author_id) -- ^^^^^^^^^^^ );

我最初在將數據庫轉換為使用複合主鍵以準備遷移到 Citus [2] 時遇到了這個問題，它需要為我們創建的每個外鍵添加自定義觸發器。現在它可以完全由 Postgres 處理！

[1]： https://www.postgresql.org/message-id/flat/CACqFVBZQyMYJV%3D…

[2]： https ://www.citusdata.com/

SQL MERGE 看起來很棒！我希望到時候我能記住它，而不是編寫 3 個單獨的查詢。

編輯：關於 MERGE 的 Postgres 文檔：https ://www.postgresql.org/docs/15/sql-merge.html

> PostgreSQL 15 允許用戶使用調用者而不是視圖創建者的權限創建查詢數據的視圖。這個名為 security_invoker 的選項添加了額外的保護層，以確保視圖調用者擁有使用底層數據的正確權限。

謝謝各位好心的朋友。當使用帶有視圖的行級安全性時，這是一個巨大的 QOL 改進，也是我將從 Postgres 13 升級到 15 的首要原因。