隱藏資料庫設計:出貨 template 前先鎖設計

你把一個 template 交給客戶或裝到對方伺服器,不想讓人看到、改到裡面的表單公式和 LotusScript——這就是「隱藏資料庫設計」在做的事。它一勾下去,官方的說法是「disables all design operations and hides all formulas and scripts」:View → Design 消失、表單/檢視/agent 不能看不能改、公式與程式碼看不到、設計也不能複製。這篇講它怎麼做(透過 Replace Design 勾「Hide formulas and LotusScript」,或繼承一個設計已隱藏的 template)、關掉了哪些操作、為什麼它不是「加密鎖」(對有 Designer/Manager 權限的人不是永久防線,要配 ACL)、一個沒有退路的重點——沒有「取消隱藏」這回事,你一定要自己留一份沒隱藏的 template,以及隱藏設計會擋住 agent 變更、要怎麼用 @Command[AgentEnableDisable] 處理。

模板繼承:為什麼你改的設計半夜被蓋回去

你改了某個資料庫的表單,隔天早上改的東西不見了——因為那個庫「Inherit design from template」,伺服器的 Designer task 半夜把 master template 的設計蓋回來了。這篇講 Domino 的模板繼承到底怎麼運作:master template 是什麼(NTF + 「Database is a template」)、資料庫怎麼靠 Design 分頁的「Inherit design from template」綁上去、設計怎麼透過伺服器的 Designer task(load design,預設每天凌晨 1 點跑、每台伺服器都要有 template 的 replica)流下去、Refresh Design 與 Replace Design 差在哪,以及怎麼用「Prohibit design refresh or replace」加「Propagate」擋住不想被覆寫的元素——還有幾個實務陷阱:private agent/folder 不能進 template、icon/About/Using 預設不繼承。

NIFNSF:把 view index 搬出 NSF

NSF 肥大,一半是附件(交給 DAOS 搬出去),另一半常常是 view index(檢視索引)。NIFNSF(把檢視索引移出資料庫)就是對付後者的:它把一個庫的 view index 從 .nsf 裡搬出去、存成獨立的 .ndx 檔,讓 NSF 變小、備份還原變快(.ndx 單檔可到 1TB)。這篇講它在做什麼、為什麼它跟 DAOS 一樣「一定要先開 transaction logging」、還要 ODS 51 以上、12.0.2 起怎麼在 Server 文件的 NIFNSF 分頁設(對應舊的 notes.ini NIFNSFEnable／NIFBasePath／CREATE_NIFNSF_DATABASES)、怎麼用 load compact -c -nifnsf on 逐庫開、show dir -nifnsf 怎麼查——以及為什麼「用 -c 開」又把我們帶回 DBIID 那條規則。

DBMT:一條指令收掉 compact、updall、fixup

維護指令那篇教你一個個下 compact、updall、fixup;但正式環境沒人半夜手動下——傳統做法是排一堆 Program document 每晚跑。Domino 9 起的 dbmt(database maintenance tool)把這些收成一條:官方說它「relieves the administrator of the need to run the Updall task」,一個 task 就做掉 compact + updall +(必要時)fixup,還能用執行緒數、時間窗、每幾天壓一次來控節奏。這篇講 dbmt 在做什麼、怎麼從 Program document 跑、compact 面(-ct／-cnd／-tl／-range／-force)與 updall 面(-ut／-ftiNdays)的關鍵開關,以及 -ods 這個會做 copy-style、換掉 DBIID 的特例——為什麼它跟交易日誌、ODS 升級綁在一起。

Domino 內建 Backup task:12 版終於自帶備份還原

Domino 12 之前,想做資料庫層級的備份還原,得自己接第三方(走 C API Toolkit)的工具;12 版起,Domino 內建了 Backup 與 Restore 兩個 server task,用一個 dominobackup.nsf 設定資料庫就能排程備份、按需還原單一資料庫。這篇講它是什麼、為什麼它跟 DAOS 一樣「一定要先開 transaction logging」、怎麼用 Configuration view 的平台預設設定文件建一份 config(Main/Backup/Snapshot/Restore/Prune/Notification 分頁)、怎麼用 load backup 的開關(-b/-t/-i/-s/-p)排程跑、以及怎麼從 Database Inventory 還原——包含一個很容易踩的雷:還原到 data 目錄之外會換掉 DBIID、讓之前的交易日誌失效。

DAOS:把附件搬出 NSF

同一個附件在幾十份文件、甚至好幾個資料庫裡各存一份,NSF 就是這樣肥起來的。DAOS 把附件搬出 NSF、在伺服器上去重存成一份 .nlo 檔,文件裡只留一張叫「ticket」的引用。這篇講它怎麼運作(存檔當下就去重、不是事後維護)、為什麼開它之前一定要先開 transaction logging、Server 文件 DAOS 分頁怎麼設(base path、minimum size、defer deletion)、資料庫怎麼加入,以及 tier 2 把冷附件搬去 S3;最後提醒:附件搬走後,NSF 還要 compact 才真的瘦下來。

Domino 交易日誌:開了就不用 routine fixup

維護指令那套規則裡,「有沒有開 transaction logging」一直是那個決定你該下哪個參數的分支——有日誌別 routine 跑 fixup、compact 要用 -b 保留 DBIID、換過 DBIID 要立刻補備份。但交易日誌到底是什麼、為什麼它能一次翻掉這麼多規則?這篇講清楚:它把資料庫變更先寫進一個 log,當機重啟時自動回放、所以 logged 資料庫根本不需要一致性檢查(也就不用 routine fixup);三種 style(circular／linear／archived)各自的取捨;以及為什麼「重建資料庫」的操作(copy-style compact、對損毀跑 fixup、第一次開日誌)會換掉 DBIID、讓舊 log 失效、逼你補一次完整備份。

XPages 效能：為什麼 computed 一次提交被算好幾遍

在 XPages 的 computed 值或 rendered 公式裡擺個 println，按一下按鈕，它卻跑了五六遍——這不是 bug，是 XPages 每次提交都跑整輪 JSF 生命週期，而 #{}（compute dynamically）的 value binding 每被讀一次就重算一次、跨多個階段加起來就是好幾遍。這篇講三個把 computed 重算壓下來的旋鈕：#{}（每次重算）vs ${}（載入算一次、靜態），rendered（在 tree 裡、每階段都算）vs loaded（根本不建進 tree、全程跳過），以及它們各自的使用時機與 ${} 的 caveat。

document1.getDocument(true) 的 true 到底在做什麼

XPages SSJS 裡 document1.getDocument() 和 document1.getDocument(true) 到處都有人用，但那個 true（applyChanges）到底套用了什麼、什麼時候非加不可、什麼時候加了也是多餘？加錯邊的代價很實在：少加，你可能存了一份漏掉程式剛改的值的文件；多加，則是憑直覺亂下。這篇把 getDocument() 與 getDocument(true) 的差別講清楚：true 是把 data source 的待套改動（控制項輸入 + 程式 setValue）flush 進 backend 文件；一般送出事件裡 Update Model Values 早就把畫面值同步進去了、多半不用加；真正需要 true 的是你做了程式改動、或要直接對 backend 文件動作時。附上 save() 與 getComponent().getValue() 的分工。