hnsからtDiaryの移行に関して(格闘編)

~~現在、取り組み中。~~

tDiary自体をあまり知らないのであるが、なんでも1.3,1.4系では、
日記ファイルがバイナリで保存されているらしい。
なので、1.5系を使って、なんとかならないものかと模索したい。
幸いにも私自身hnfを使いこなしていなかった(笑)ので、なんとかなるかも?

なるほど、tdiaryのディレクトリ内のdefalutio.rbを使っちゃえば、書き出しに関しては問題なさげ。あとは、hnfをパースして、変換するだけじゃ（っていうかここが肝なのね。）ところで、tdiary2に拡張タグみたいなのってないのかな～。（っていうか自分でほげればいいわけか)
と思ったんですが、結構面倒臭い感があります。いまいちよくわからん。Dirtyにすれば、storeされるみたいだけど、何故かうまくいかないです。
第２案としては、IOクラス(pgsql版)を作って、そとからSQLでガンと突っ込んだほうが、衝突とか考えなくてもいいし、メンテ性もいいかもしれない。
- これで行こうかと思う。TDiary::DefaultIOを直接継承して、storeとrestoreとcalenderをとりあえず書けばなんかいけそうな気がするので....(ところで、もしかして車輪の再発明してないか?と思う。既に誰かやってそうでやってなさそうな気がしますので...)
- でもよくよく考えるとDB化すると、namazuでは全文検索できないな～。まあ、DBなので全文検索自体は実装すればできるのだけれども。

当初pgsqlを直接使ってましたが、せっかくなのでDBI/DBDを使うことにしました。この方が、pgsql依存性を極力排除できるわけだし(使いやすいし)
現実装案では、テーブルは、4つです。
現実装案では、私のhnfで使用していたものを簡便に移行できるようにするため、下記拡張を検討しています。
- BOOKを使用可能にする。
- CATEをなんとかサポートしたい。
- 全文検索をなんとか入れたい。
  - plugin squeezeを使って生成した静的HTMLをnamazuにかければいいことがわかりました。

DBがらみの下記、問題を修正した。
- comment DB, Refer DBがINSERT文で適当に書いたので、重複して登録されている。
- comment, Referのrestoreが全データを引っ張るので遅すぎる
- Referのカウントにバグあり。
BOOKサポートのため、適当なpluginを作成した。
とりあえずhnfから強引に移行してみた。いくつか不具合があるが、基本的にはOKっぽい。しかし、データ多すぎて劇重です。DB含めて効率化しないと駄目だなこりゃ。

きたさんのところに、カテゴリ機能追加パッチがあるのを発見。（何ともタイムリー）これ、マージして、PostgresIO.rb(もとい、DBI/DBD IOなんですが)に含めれば、完全移行が可能だろう。

ここで現バージョンをいじって頂いて、バグを報告してくださる方がいらっしゃれば幸いです
- なお、バッグエンドがDBのせいか遅いです。
- 見た目は、普通ですが、全てデータはDBに収められます。
- 変なタグとか, SQLに弱い構文とか入れて遊んでくれるとうれしいです。
  - クロスサイトスクリプト脆弱性は多分ありますので、そういう行為はやめてください。

なお、バグなどの報告は、下記に書いてくれる（あるいは、ダンプ結果を貼り付ける
だけでもいいです）とうれしいです。

＜＜バグ報告＞＞