Starbug1の参考のために影舞を調べてみた

影舞のテーブル構成とか処理内容を調べてみました。postgresqlのところだけを、ななめ読み。全体のソースの印象は、すごく真面目に抽象化されていて、しっかりしたソースだと感じました。テーブルは、reports, messages, attachements という3つだけでした。各項目のカスタマイズ情報は、reporttype.xmlというファイルに格納されているようでした。reportsテーブルは、バグ1個につき1レコードに対応しています。messagesテーブルは、投稿、返信に対応しているようです。attachmentsテーブルは、添付ファイルです。ちょっと眺めただけですが、パフォーマンス対策で参考になる部分は、下のような感じでした。

  • reportsテーブルに初回投稿のメッセージIDと最新のメッセージIDを格納するフィールドがある。
    • Starbug1では、この構成になってないがために、最初の投稿とか最新の投稿を特定するために、サブクエリで、maxとか、countとかしてたのがダメなところでした。
  • カスタマイズによる項目の増減方法。
    • 影舞の方法は、正に、id:rayfillさんに教えていただいた方法でした。カラム追加、カラム削除を動的に発行するようです。

どう活かすか

で、Starbug1には、どう活かすかですが、今のところ考えていることをメモします。

  • 今は、ticketテーブルとreplyテーブルで、投稿と返信を別扱いしているが、影舞と同じように、投稿と返信をmessageテーブルで同列に扱うようにする。
  • ticketテーブルには、最初の投稿と、最新の投稿のmessage_idを持たせる。
  • elementテーブルを廃止する。投稿された値は、messageテーブルに格納する。field_1, field_2というようなカラム名でいいかな?
  • 管理ツールで項目を追加した場合は、messageテーブルにカラム追加するようにする。

なんか、参考というかコピーに近いかもしれない。

懸案事項というか自分の宿題

  • 影舞は、項目のメタ情報は、reporttype.xmlに書いてある。しかし、Starbug1は、項目のメタ情報もDB(element_typeテーブル)に格納されているので、そこら辺を有利に使うこともできるかもしれない。
    • ストアドプロシージャとかトリガを多用するとか。

今度は、Sqliteのマニュアル(ストアドプロシージャ、トリガあたり)を見なくては。

追記:sqlite3にストアドプロシージャは無いようでした。

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.