abOut.nsf

新旧かまわず、またお役立ち度にあまりこだわらずに、 拡張子がnsfであるNoSQLなデータベースファイルと、それを扱うコラボレーション製品に絡んでのあれこれを。

2020/05

昨年12月の実施、第20回の「のの会」でのトークを振り返ります。
「@関数Talk」としては第18回。@Dbcolumn・@DbLookupのシリーズが続いていたのですが、息切れしたので別の関数を挟むことにしました。


今回のネタは、@DocumentUniqueIDと@InheritedDocumentUniqueID。
ちなみに後者は名前の長さが目に付くことから、私は「@関数の中で最長だろう」とずっと思い込んでいました。この作文にあたってよくよく確認してみると、同率で3番目でした。

通常、@関数が返す値は、文字とか数値とか日時なのですが、
@DocumentUniqueID、@InheritedDocumentUniqueID を、そのままフォーム上で使うと、
戻ってくるのは黄色い文書リンクです。

しかし、この「文書リンク型」の利用法、どう役に立つのかはいまいち謎でした。
とくに@DocumentUniqueIDについてはクリックしても何も発生しない「自分へのリンク」です。

のの会当日、(Sさんからだったかな、)もしもNotesの文書それ自体がコピーされた場合に、
コピー後の新しい文書から、元の文書に飛べるのでは、とのご意見がありました。

改めて確認してみると、「表示用の計算結果(Computed for display)」でない限り、その通りに動きます。

また、それで思い出し検証したのですが、バージョン管理の設定を使用しているフォームでは
リンクが機能することを確認できました。

英語版画面で恐縮ですが、バージョン管理の設定とはこれです。

設定すると文書を編集し保存する都度、新規文書が追加されます。
「新規文書を返答文書に」「以前の文書を返答文書に」「新規文書を兄弟文書に」
の3通りから選択しますが、
「表示用の計算結果(Computed for display)」でなければ、新規文書からのリンクが以前の文書へのリンクとなりました。

バージョン管理の機能自体、そんなに頻繁に使用されているとは思いませんが、
もし機会があったらご参考に。

電車通勤しない生活が続いていますので、その間に残した宿題をさっと片付けたいところですが、ついついコロナ系のニュースばかりを眺め暮らす日々です。

昨年11月の「のの会」でのトークを振り返ります、「@関数Talk」としては17回目。
@DbColumn@DbLookupをセットで探索する第3弾となります。



"Recache"については前々回での認識不足もあって、改めておさらいをさせていただき、その有意性を確認しました。
なおP.17 - 19で紹介しているヘルプ記事ですが、のの会開催当時はリンク切れしていたものが
現在ではHCLさんのサイト内に移管・復活していますので、代わりにこちらをご参照ください。


スライド上は前後しますが、冒頭でおまけをつけ、@DbName、@ReplicaIDについて軽く触れました。
現在のNotesのアプリケーション(DB)を特定するための関数です。

「サーバー名とファイルパス」の形で返すのが@DbName、
「レプリカID」の形で返すのが、@ReplicaIDです。

@DBColumn や@DBLookupでは、
2番目の引数に@DbName・@ReplicaIDのどちらを使っても(あるいは””で略しても)、
現在のDBを指定したことになります。

現在のDBではなく、ほかのDBを指定したい場合は
「サーバー名とファイルパス」型・「レプリカID」型のいずれかで対象DBを明示するのですが、
どちらで明示するのがベターか、スライドの P.27 では明言しませんでした。

「サーバー名とファイルパス」型のほうがソースを見たときわかりやすいのですが
「レプリカID」型のほうが、複数サーバーで運用している環境では融通性が高いことになります。

↑このページのトップヘ