Your Daily Epsilon of Math を毎日更新

Your Daily Epsilon of Math を毎日更新するのに結構時間が掛かっている.始業時バックアップの日付が0時を回って翌日の日付になってしまうようになった.もう,これが常態と認めるしかないだろう.参照番号とレコード番号の切り分けというのは,一通り収まったのではないかと思う.何か抜けているところはあるだろうか?とりあえず,フィックスできるところをすべてフィックスしてしまうことにしよう.「仮修正」が20箇所ある.⇒ここで,もう一度バックアップを取っておこう.

  1. lookupを前詰めする@20230113
  2. maxRecordではmaxrecordを返す@20230113
  3. lookupを自動更新する@20230112
  4. MakePartialListを廃止する@20230111
  5. lookupテーブルは一度だけ生成される@20230111
  6. MakeRecordでupdateflagをリセット@20230110
  7. UpdateRecordFuncの改造@20230110
  8. UNDOでリンクテーブルを保全しない@20230109
  9. CallGetRecordNumをlookup対応に変更@20230110
  10. SendUpdateDataの引数仕様変更@20230110
  11. 参照番号を永久コード化する@20230109

ここで一度バックアップを取り直す.

▲リンクテーブル全体にアクセスするとき,ダイレクトにアクセスするのと,lookupを経由するのとどちらが効率的か?

結婚テーブルのlookupの操作を確認する.⇒結婚リンクテーブルでも,lookupは生成されているが,有意な使い方はされていないのではないだろうか?実際,MARGTABLEではCARDTABLEと異なり,lookupの更新さえ行われていない.結婚テーブルからlookupを完全に排除してもよいのではないかと思うのだが…⇒MARGTABLE::MakingLookUpを完全にNOPにしても問題なく動作している.

lookup自体は基本クラスのBASETABLEのコンストラクタで生成しているので,作られてしまうのは避けられないが… MARGTABLE::MakingLookUpという関数は廃絶しても問題ないと思う.MARGTABLE::Renumberというのも不用なのではないか?⇒MARGTABLE::Renumberを廃止した上で,基準ソート時のRenumberを復活させてみよう.⇒FAMILYTREE::AppendFileではMARGTABLE::Renumberを使っている.これは必要なのではないか?ただし,この呼出には,「この論理はチェックを要する @@2017-09-22 」という書き込みがある…

基準ソート時にリンバーするというのは悪い仕様ではないので,復活させるのが妥当と思われるが,結婚テーブルではlookupを使わないという方針なので,もし,AppendFileで結婚参照番号のリナンバーが必要であるということになるとすれば,作り変える必要がある.ただし,アペンドした時点で重複しない参照番号が発行されているとすれば,あえてリナンバーする必要もないようにも思われる.この点に関しては現時点では保留としておく.

▲TOPOLOGY::GetRecordはlookup未対応@20230110なのではないか?⇒GetRecordに引数で渡されるlong* tableには2つのタイプがある.いずれもlong配列だが,lookupはレコード番号,他のテーブルは参照番号なので同一に操作することはできない.⇒これに対処するためには,TOPOLOGY::GetRecordの引数を仕様変更して,long*ではなく,longtable*を受け渡しするようにするしかない.⇒GetRecordの引数の仕様を変更したが,コンパイルエラーになったのは,TOPOLOGY::GetActiveRecordだけだ.

部分図やlookupでは何を使っているのだろう?COUPLING::MakeRecordを使っているのかもしれない.MakeRecordはGetRecordでも使われている.MakeRecordを呼び出している箇所をすべてGetRecordに統一するとよいのではないだろうか?

コメントを残す

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

CAPTCHA