Renumberではリンクを移動しない

参照番号のハッシュ化は,コラッツ対応修正により,登録カード数の上限が1000のオーダーから10000を超えるようになったことを直接のきっかけとしている.しかし,そのことによって,「リンクがどこに置かれていてもまったく問題なく動作する」というNシステムの最大の特長が著しく損なわれるか,ないし制約を受けるようになった.テーブルにハッシュでアクセスするためには,そのレコードはテーブルの固定位置に配置されることが前提となる.それと,Nシステムの「リンク配置の自由度」は明らかに背反している.

参照番号のハッシュ化が後戻りのできない決定であるとすれば,どこかで折り合いを付けなくてはならない.参照番号のハッシュ化はゼルコバの木の最大構成要素である人名テーブルと結婚テーブルに関わるものではあるが,それ以外の要素ではこれまでと同様,配置の自由度は損なわれてはいない.テーブル並び替えというのは一覧画面出力に関わるものであり,人名/結婚テーブルのレコード並びとは独立であるはずなので,人名/結婚テーブル上のリンクが固定位置にあったとしても,実行可能であるはずだ.⇒どうもlookupテーブルを作り損なっているようだ.⇒NAMESORT::SortNameSubで「lookupを前詰めする@20230113」の論理にミスがあった.⇒修正して動作するようになった.

基準ソートの実行で選択カード数不一致が発生する.TOPOLOGY:RebuildCardListではUndoStartFlagがオンのときには選択リストから選択フラグを再設定し,オフのときにはフラグから選択リストを再構築している.どちらの場合も,フラグのカウントとリストのカウントは一致しなくてはならないのだが… リナンバーを実施した場合には,選択リストは無効にしなくてはならない.⇒いや,そういう動作になっているはずだ.⇒CARDTABLE::Renumberが間違っているのではないか?lookupに格納しているレコード番号を書き直している.⇒「Renumberではリンクを移動しない@20230116」で収まったようだ.

58点削除→ 基準ソート→ Undo→ Undoで大量のエラーが発生する.親リンク不整合,カード参照番号の重複,子インデックスが負,親番号不一致などの後,どこかで例外を起こしている.⇒MARGLINK:CheckMargLinkのエラー出力に誤りがあった.

カード削除単独,ないし,他のタイプのソートとの組み合わせではエラーは生じないので,原因が基準ソートにあることは明らかだ.おそらく,それもリナンバーしていることが最大の原因と思われる.⇒確かにそのようだ.ということは,リナンバーをUndoしたとき,元の状態に戻っていないということなのだろう.

リナンバーでは「リンクを移動しない」ことになっているから,変化しているのはカードの参照番号だけだ.⇒カードの参照番号はCardNumListのリストアで復元できているはずなのだが,参照番号を参照しているすべてのリストが復元されているかどうかが問題だ.いや,そもそもCardNumListが保全されていないのではないか?

UNDOSYSTEM::BackupPointDataのSORTREFNUMにSetUndoListを実行するようにしたが,エラーは収まらない.CardNumListを生成しているタイミングが悪いのではないか?⇒確かにそのようだ.⇒NAMESORT::NameNarabekaeの入口でBuildNumListを実行するようにして解決した.多分これで,ほぼ問題は解決したのではないかと思う.まだ,何か見落としがあるだろうか?


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA