Jiemamyインサイドfor contributors

～第一回 地豆の会～

都元ダイスケ2008.05.21 (Wed)

今日は地豆な話• JiemamyはEPLで公開されるOSS。

• AmaterasERDの派生ソフトウェア扱い。

• コミット時点で以下に同意として扱う。• OSSとして公開されること。• 著作者人格権の不行使。• 著作権(財産権)の譲渡。

• 著作権は、NPO等の代表となる権利主体を用意できない為、私が管理します。

• 杞憂だとは思いますが、関係者が増えると色々なので。

必修科目

• Jiemamy概論

• オーバービュー

• モデル構造解説

• J-core/*.core.model

• Mavenプラグイン概論

オードブル

Jiemamyの構成

•まず、repositoryに置いてあるプロジェクトをざっと見てみますか。

• jp.xet.jiemamy.core• jp.xet.jiemamy.dialect• jp.xet.jiemamy.porter• jp.xet.jiemamy.eclipse• jp.xet.jiemamy.eclipse.helper• jp.xet.jiemamy.porter.ui• jiemamy-maven-plugin• jp.xet.jiemamy.eclipse.feature• jp.xet.jiemamy.release• jp.xet.jiemamy.site• jiemamy-tutorial• jp.xet.jiemamy.converter• jp.xet.jiemamy.ant

Eclipse非依存の本当にcore部分

Eclipse UI部分

Eclipse プラグインリリース作業関係

チュートリアルや実験中プロジェクト等

Maven プラグイン部分

コンポーネント略称定義

• jp.xet.jiemamy.core•って毎度書くのはアレなので。•こいつは「J-core」って呼びます。

• jp.xet.jiemamy部分を「J-」にします。•J-eclipseHelper = jp.xet.jiemamy.eclipse.helper

•その他例外的なのもあるけど空気読んでw

• J-core内の、特にmodelの話

• あと、軽くJ-mavenの話をしまーす。

今日は

中心機能部分

• J-core•モデルの定義•dialectやporterのinterface定義

• J-dialect•各SQL方言の実装

• J-porter•各インポート/エクスポート機能の実装

簡単な構成

モデル・その他中心機能(J-core, dialect, porter)

Eclipse API Maven API

maven-jiemamy-plugin

(J-maven)

Jiemamy Eclipseプラグイン(J-eclipse等)

同じ機能（インターフェイス）を、Eclipse側とMaven側から利用しているだけ。

言葉で説明すると•モデル等の中心機能があって、このinterfaceを使って、• Eclipseプラグイン部分と、• Mavenプラグイン部分が各々、• モデルの編集や、• 別表現からモデルへの入力(import)、• モデルから別表現への出力(export)等

• を行う訳です。

中心機能は特殊な環境に非依存

•だから、同じモデルと機能をEclipse / Maven両者から使える。

• 中心機能を操作する別のインターフェイスを作れば、別の使い方だってできる。

• ここまでで何か質問ありますかー？

必修科目

• Jiemamy概論

• オーバービュー

• モデル構造解説

• jp.xet.jiemamy.core/*.core.model

• Mavenプラグイン概論本日のメイン

AbstractModel

• 全てのModelはこのクラスを親に持つ。

• 永続化の為にSerializableを実装。

• newされた時に、long型のidが乱数で生成され、equals識別に使用される。

• ObserverパターンのSubject（監視対象）となる。（リスナ登録が可能）

• 変更時にPropertyChangeEvent発生

PropertyChangeListener◆Request for comment◆

• java.beansパッケージの標準API• JavaBeansのプロパティ変更を監視• Subjectが保持するListが変更された時は？• 現状、Subjectがイベントを発生

• Subjectが破棄（削除）された時は？• 現状、やはりSubjectがイベント発生• ホントは親がイベント発生させるべき。

RootModel• その名の通り、全ての根になるモデル。

• 直接のシリアライズ対象。

• DatabaseModelのリストを持つ。

• かつて血迷った結果w

• 複数のDBモデルを持つ可能性を考えてた。要らないかもしれない。

• 現状、Listだけど1つしか保持しない。

DatabaseModel

• 一枚のER図を表現するモデル。

Collectionを持つモデルのaccessor◆Request for comment◆

• モデルにCollectionが多く含まれている。• スマートな作り方は無いだろうか。class DB { // host側 private List<Table> tables; public void addTable(Table table) { tables.add(table); } ...}---- clientからdb.addTable(table);

class DB { // host側 private List<Table> tables; public List<Table> getTables() { return tables; }}

---- clientからdb.getTables().add(table);

host側にmethodが増え複雑に見える原因

client側が非直感的Event発生できない

ダイアグラム系モデル

•ダイアグラム = Node + Connection

• ERダイアグラム = Entity + Relation

extends extends extends

Node系モデルダイアグラム上に表示される

全てのノード（DBに直接関係するとは限らない)

DBに直接関係する要素のモデル付箋

AbstractNodeModel• ダイアグラム上の表示される”■”一般。

■→■(source)→(target)

StickyModel ～ 付箋

•内容文とそのaccessorメソッド。

• 超簡単。

AbstractEntityModel

• Nodeの中でも、特にEntity

• 全部Stringだ。難しくない。

ViewModel ～ ビュー

• StickyModelと似たり寄ったり。• ここでSQLパーサが欲しい → 簡易実装定義文から以下の情報を取得したい。• このViewが持つカラム• 依存(参照)しているTable

• J-dialectも絡んで来る。

TableModel ～ テーブル

•複雑に見えるかもしれないけど、冷静に見れば簡単なはず。

Node系モデルまとめ

ColumnModel (1)

• ColumnModel extends DefinitionModel

• ほとんど実装はDefinitionModel内にある。

• すまん、この辺が一番複雑なんだ。

• なので、まずはDefinitionModelいくよ。

DefinitionModel (1)• 型ってあるよね。INTとかVARCHARとか。• そいつらは、DataTypeという型。• この型は、オプションと名前がつくよね。foo VARCHAR(16) とか。

• これがDefinitionModel

DefinitionModel (2)

• ColumnModelとDomainModelは、どちらも、型に名前やオプションをつけた「定義」なんだ。だからDefinition。

DomainModel ～ ドメイン

•ドメインは「定義」かつ、VARCHAR等と対等な「データ型」なのだ。

ColumnModel (2) • で、やっとColumnModel。

• Definitionに「所属するテーブル」が追加されただけ。

InheritanceColumnModel

• 継承により親から引き継いだカラム。

• この辺複雑なので、スライドに書きにくい。

Definition系モデルまとめ

めっっっさ、混乱してるはずです。

•だって俺も難しいもん。

•ここら辺で、質問を受け付けておきますw

Connection系モデルダイアグラム上に表示される

全てのコネクション（DBに直接関係するとは限らない)

DBに直接関係するコネクションの

モデル

まだ存在

しないけど、

付箋とTableを繋ぐ

説明用のコネクション

等

AbstractConnectionModel

• ダイアグラム上の表示される”→”一般。

■→■(source)→(target)

ベンドポイント

AbstractRelationModelとInheritanceModel

• 中身は、ほぼカラっぽ。

• 接続元と先があって、bendpointsがあるだけだからね。

• 特別な機能が無いから。

ForeignKeyModel

• マッピング（後述）

• あとは物理名とか論理名とか。簡単。

• matchTypeとinitiallyCheckTimeは、enumにすべきだな、と今思ったw

ForeignKeyMapping (1)

• FKはEntity同士を繋ぐタダの「線」

• 外部キー ＝ targetの主キーカラムがsourceの「あるカラム」に制約を付与。

• targetが複合キーの場合、制約は複数。

• だからFKは、これのListを持つ。

ForeignKeyMapping (2)

• 制約を受けるカラム & 参照先カラム。

Connection系モデルまとめ

あとは雑多 (1)

• 峠は越えましたよ。

• これらのクラスは、EclipseAPIにもあるが、依存させない為に、自前で用意してある。

あとは雑多 (2)

• 物理データベース（実際のDB）

あとは雑多 (3)

• アウトライン用のモデルをまとめるフォルダみたいなもの。

こいつら

以上、モデル解説でした。

• indexとかrecordとかを飛ばしたし、

• その他小さいクラスはあるんですが、

• ここまで把握できれば、

• Javadoc見ながら読めます。多分...

モデルの構造◆Request for comment◆

• SerializeにはXStreamを使用している。• [T1]―(C)→[T2] のserializeの順番は...• RootModel#databases• DatabaseModel#nodes (T1, T2)• TableModel#sourceConnections (C)• ForeignKeyModel#target (T2)

• T1の定義が終わらぬウチにT2の定義が始まってしまう → XMLのネストが深い

シリアライズ方法◆Request for comment◆

• 現状、全モデルをRootModelから掘り続けて、芋づる式にシリアライズ。

• 1スキーマに1データ(DML)セット

• 複数のデータセットを扱いたい。

• しかし、モデルが更に肥大化する。

じゃあ、ファイル分ける？◆Request for comment◆

• 単純に分割するだけでは整合性に課題。• ではjarファイルの様に、実はZIP方式?• スキーマ定義ファイル• スキーマプレゼンテーション1, 2, 3...• データセットファイル1, 2, 3...

• データファイルは圧縮されて小さくなるし、扱いやすくなる。

• けど、データファイルがバイナリ化。• コミットしてdiff取れるメリットが...

必修科目

• Jiemamy概論

• オーバービュー

• モデル構造解説

• jp.xet.jiemamy.core/*.core.model

• Mavenプラグイン概論デザート

アレコレ言わずにコード嫁FileInputStream inputStream = new FileInputStream(inputFile);

　JiemamySerializer serializer = SerializerFactory.getSerializer();　RootModel rootModel = serializer.deserialize(inputStream);

　Porter porter = (Porter) Class.forName(exporter).newInstance();

　porter.setParameter(parameter);　porter.execute(rootModel);

泣いても喚いてもこれだけだ。

ここで読み取らなければいけないこと。

•モデルの復元（デシリアライズ）方法。

• あとは、Porterのインスタンスに、パラメータとモデルを渡してexecute。

• これで「何かが起こる」。

• 何が起こるかはporter次第。

• この場合は「SQLを吐く」。

ついでだからPorter見とくか。FileOutputStream sqlFileOs =　　　　　　　　　new FileOutputStream(sqlFile);OutputStreamWriter sqlWriter =　　　　　　new OutputStreamWriter(sqlFileOs, "UTF-8");

Dialect dialect = dbModel.getDialect();String sql = dialect.createSQL( dbModel, drop, dml, schemaName);

sqlWriter.write(sql);

こんだけやん。

ここで読み取らなければいけないこと。

• DatabaseModelは、DBの種類情報、つまりDialectを持ってて、getDialect()できる。

• あとは、Dialect#createSQL() に「モデル」と「少々のオプション(boolean)」を与えれば、SQLが得られる。

結局

•結構複雑なモデルがあって、

• それをSQLに変換する。

• その変換ロジックはDialect#createSQLメソッドに実装されている。

• さて、その実装内容は...?

• SQL生成ロジックコース！

• SQL生成ロジック総論

• どんなinterfaceを持ってるの？

• 標準SQLの実装はどうなってるの？

• SQL方言各論

• MySQL, PostgreSQL等

• 個別に見てみようの会！

次回予告！

ご清聴ありがとう ございました。