Import/Export機能を実装した。

場所マスタ(純粋に場所の情報だけを格納するテーブル)、場所データ(場所と人を紐付けているテーブル)を分離したデータ構造を考えていたんだが、やってると次から次へと修正したい事が出てきて困る。

今回も、pw.standard.action.*系のクラスをpw.action.*に、pw.standard.item.*系のクラスをpw.item.*に変更した。
クラスパスが変わるから、当然actionsettingsマスタテーブルに記述されているクラスパスも変更しなきゃならんので、面倒くさいけどアホみたいに手作業でUpdate文を書いて変更していた。
んが、そのうちactionsettingsテーブルのカラムの一つである、argumentsカラムの名称が気にくわなくなってきたのでparametersにしようとしたんだけども、それをやるには一回テーブル削除してもう一回全部のデータを登録しなおしになる。
いや、SQL文でカラム名の変更とかできるんだろうけども、今後のことを考えたら、やっぱりこのタイミングでImport/Exportができるようにしとくのがよかろうと思い、結局PWExportCsvActionとPWImportCsvActionを実装することに。

PWExportCsvActionは、paramtersにSQLファイルを指定しておき、実行時には出力先CSVファイルパスを指定してデータをExportする。

PWImportCsvActionは、paramtersに対象テーブルとマップするPWItemのクラスパスを指定しておき、実行時には入力元CSVファイルのパスを指定してデータを目当てのテーブルにImportする。

実際に動かしてみて、めでたくarguments→parametersに名称変更したテーブルにデータをImportすることができた。

対応しているデータ型はまだ少ない。Int型のカラムとかあったら多分例外で落ちると思うw
といっても、PWConverterインタフェースを各データ型に対応する形で実装したクラスを追加すればそれほど悩むことなく対応できるような作りにしてあるので、必要に応じて増やしていけばいいやと思っている。
エラーはわかりやすく出力された方がいいと思うけども。

さて、住所関連の実装をしていてコマンドラインが少々厳しくなってきた。
そろそろGUIについて考えていこうと思う。

あ。あと、マスタ系に対して「それ以外のテーブル」の呼称も考えないといかんなぁ。みなさん普通はなんてSuffixをつけてるのかねぇ?