前ポスト

前置き

隙間時間を利用して書いているので精度の甘い箇所があれば、ご指摘いただけると幸いです。
まずEOLであるものは除外。
有償の機能については検討対象に含むが、実際に使用はしません、懐の問題で。
「まぁ、たぶん明記されてなくてもPostgreならいけるだろ」ぐらいの間抜けな理由で使用DBはPostgreに固定。

環境

ネットワーク環境的な問題から動作確認できていません。
gradleもmavenもリポジトリに接続できなくて動かないため推測記事になります、ご了承ください……
antでMithraGeneratorを叩けばいけるはずだけど、これは面倒くさい……

対応範囲

ORM	Transaction	Data Model	DSL
○	※1	※2	○

○:対応
×:非対応
※1:Geronimo JTAに依存
※2:バイテンポラルデータモデルをネイティブサポート

所感

「規約より定義」感
XMLからすべてを生み出す構成、テーブルDDLどころかインデックスDDLまでXMLの定義次第で生成される
DSLから感じる遅延評価の気配
テンポラルデータモデル、バイテンポラルデータモデルをサポートするが、使わなくてもよい
DSLからのSQL生成であるため、ユーザが挙動を熟知している必要がある
全体的に「高度にシステム化された内容を、明瞭な共通認識の下に生産する」ことを目的としたDSLっぽい

サンプル

単テーブル検索

EmployeeSearchTest.java

// 主キー検索
MithraManagerProvider.getMithraManager().executeTransactionalCommand(tx -> {
    Employee employee = EmployeeFinder.findOne(EmployeeFineder.id().eq(BigDecimal.ZERO));
});
// 全件検索
MithraManagerProvider.getMithraManager().executeTransactionalCommand(tx -> {
    EmployeeList list = new EmployeeList(EmployeeFiner.all());
});

Employee.xml

<MithraObject
    objectType="transactional"
    xmlns:xsi="http://www.w3.org/2001/XML-Schema-instance"
    xsi:noNamespaceSchemaLocation="mithraobject.xsd">

    <PackageName>jp.co.qualsyite.</PackageName>
    <ClassName>Employee</ClassName>
    <DefaultTable>employee</DefaultTable>

    <Attribute
        name="id"
        javaType="java.util.BigDecimal"
        columnName="id"
        primaryKey="true"
        primaryKeyGeneratorStrategy="SimulatedSequence">

        <SimulatedSequence
            sequenceName="employee"
            sequenceObjectFactoryName="jp.co.qualysite.ObjectSequenceFactory"
            hasSourceAttribute="false"
            batchSize="1"
            initialValue="0"
            incrementSize="1"/>
    </Attribute>
    <Attribute name="firstName"  javaType="java.lang.String" columnName="first_name"  nullable="false" maxLength="60" />
    <Attribute name="middleName" javaType="java.lang.String" columnName="middle_name" nullable="false" maxLength="60" />
    <Attribute name="lastName"   javaType="java.lang.String" columnName="last_name"   nullable="false" maxLength="60" />
    <Attribute name="from"       javaType="java.util.Date"   columnName="from"        nullable="false" />
    <Attribute name="thru"       javaType="java.util.Date"   columnName="thru"        nullable="false" />
    <Attribute name="in"         javaType="java.util.Date"   columnName="in"          nullable="false" />
    <Attribute name="out"        javaType="java.util.Date"   columnName="out"         nullable="false" />

    <Relationship
        name="posts"
        relatedObject="Post"
        cardinality="one-to-many">
            this.id = Post.employeeId
    </Relationship>
</MithraObject>

テーブル結合

要点

カバー範囲はORM+データモデルロジック
DSLはJava実装なのでIDEの補完機能が効く
データモデル側で車輪の再発明をする必要がないため、そこが強い
XMLでガチガチに固めるため、システムありきで構造がしっかりしている必要がありそう

ハマったポイント

ハマったっていうか動いてない。

後ポスト

2017年度 Java 永続化フレームワークについての考察(4) jOOQ

参考記事

Reladomo Kata

2017年度 Java 永続化フレームワークについての推測(3) Reladomo