Ver.7.0 の DB は Ver.6.x 以前の DB と比べて大きく変化している. ここでは,Ver.6.x 以前の DB ファイルを Ver.7.0 形式に変換するための手順を述べる.
本体 | 既定のインストール先 | データフォルダ | DB | ファイル名 | レジストリ | Log | ファイル名 | レジストリ | ||
Ver.2.0 | PSS2 | Datas | pdb | DBv3.pss | Pss/DBv3/filename | N/A | N/A | N/A | ||
Ver.3.0 | Pss2 | Datas | pdb | DBv3.pss | Pss/DBv3/filename | pdblog0 | translog.txt | Pss/Options/LogPath | ||
Ver.4.0 | Pss2 | Datas | pdb | DBv3.pss | Pss/DBv3/filename | pdblog0 | translog.txt | Pss/Options/LogPath | ||
Ver.4.1 | Pss2 | Datas | pdb | DBv3.pss | Pss/DBv3/filename | pdblog0 | translog.txt | Pss/Options/LogPath, PointfilePath | ||
Ver.4.2 | Pss2 | Datas | pdb | DBv3.pss | Pss/DBv3/filename | pdblog1 | translog.psslog | Pss/Options/LogPath | ||
Ver.4.3 | Pss2 | Datas | pdb | database.pssdb4 | Pss/DBv3/filename | pdblog1 | translog.psslog | Pss/Options/LogPath | ||
Ver.5.x | Pss5 | data | pdb2 | database.pssdb5 | Pss5/database/filename | pdblog2 | translog.psslog5 | Pss5/Options/LogPath | ||
Ver.6.x | Pss5 | data | pdb2 | database.pssdb6 | Pss5/database/filename6 | pdblog2 | translog.psslog5 | Pss5/Options/LogPath | ||
Ver.7.0 | PSS7 | data | pdb3 | database.pssdb7 | PSS7/config/database-path | - | - | - |
DB と Log は 2004.03.22 現在における,DB/Log 操作ライブラリ名称を示す.ただし,pdblog2 は pdblog2.h/cpp で実装され,pdblog ネームスペースに存在する.
上記の表を見る限り,Ver.4.1 以前の DB/Log は pdb/pdblog0 で操作できる.ファイル名も統一されているため,Ver.2.0〜Ver.4.1 は pdb/pdblog0 で統一的に操作可能である. Ver.4.2〜Ver.4.3 は,Log が pdblog1 に変更されている. ただし,Ver.4.3 以前はレジストリエントリが統一されているので,同一のレジストリエントリからファイル名を取り出し,拡張子に応じて履歴操作ライブラリを変更することで対応できる.
Ver.5.0 からは DB/Log ともに UNICODE 対応のために大幅な変更がなされているが,レジストリエントリも別のものになっているので,対応は容易だろう. Ver.5/6 の違いは DB の形式が異なることであるが,ライブラリは同一のものを使っている.そのため,拡張子に応じて pdb2::Tree::load5/save5 と pdb2::Tree::load6/save6 を使い分けることになる.
いずれにせよ,Log については Ver.6 用に pdblog0 -> pdblog1, pdblog1 -> pdblog2 変換ライブラリが pdblog_translator.h 用意されている.レジストリエントリや拡張子に応じて適切な変換ライブラリを用いることで,pdblog2 形式に変換することが可能であろう.
DB の変換についても同様であるが,変換ライブラリについては実は不要であり,pdb2 の load5 メソッドで pdb 形式(つまり非UNICODE形式)ファイルを扱うことが出来る. つまり,レジストリエントリや拡張子に応じて適切な読み込みメソッド (load5 or load6) を用いることで,pdb2 形式に変換することが可能となる.
DB のアップデートと Log のアップデートに分けて実行する.
pdb2 や pdblog2 オブジェクトが取得できれば,次は pdb3 オブジェクトへの変換である. (以下略)
PSS7 の新バージョンがリリースされたときなどには,DB7 同士のアップデートが必要となる. これは pdb3 レイヤーではなく,SQLiteDB を直接操作することにより実装する.
アップデートすべきテーブルは下記の4テーブルである.
ここで,問題データそのものである question と,それを含む section を分離して考えるべきである.
ユーザの欲求としては,
が考えられる.
A は従来の DB6 同士のアップデートで実現できていた部分であり,B は限定的に実現できていた部分である.
今回のDB構成では,一定以下の qid に対しては同期が保証されているため,B は比較的容易に実現できるが, A に対しては eid の制約がないため,完全な形でのアップデートは難しい. B が「比較的」であるのは,「既存の問題集の更新」が「問題の修正」のみではなく, 「問題の追加」であった場合には,section-table を更新する必要があるためである.
A, B それぞれを個別に実現するための手法を述べる.
A の実現手法:
B の実現手法:
以上をふまえ,question テーブルに対しては無条件にアップデートを行うこととし,それ以外に対しては適宜ユーザへの確認を行いながら追加・更新処理を行うこととする.
PSS 本体において,起動時に下記の手順で行われる
PSS 起動シーケンス:
DB アップデート手順:
以下検討中.