7.3.2. ユニバーサルDAO¶

7.3.2.1.1. SQLを書かなくても単純なCRUDができる¶

JPAアノテーションをEntityに付けるだけで、SQLを書かなくても、以下の単純なCRUDができる。 SQL文は、JPAアノテーションを元に実行時に構築する。

• 登録/一括登録
• 主キーを指定した更新/一括更新
• 主キーを指定した削除/一括削除
• 主キーを指定した検索

Entityに使用できるJPAアノテーションについては、 Entityに使用できるJPAアノテーション を参照。

7.3.2.1.2. 検索結果をBeanにマッピングできる¶

検索では、 データベースアクセス(JDBCラッパー) と同様に、SQLファイルを作成し、SQL IDを指定した検索ができる。 さらに、ユニバーサルDAOでは、検索結果をBean（Entity、Form、DTO）にマッピングして取得できる。 Beanのプロパティ名とSELECT句の名前が一致する項目をマッピングする。

Beanに使用できるデータタイプについては、 Beanに使用できるデータタイプ を参照。

7.3.2.3.1. ユニバーサルDAOを使うための設定を行う¶

ユニバーサルDAOを使うためには、 データベースアクセス(JDBCラッパー) の設定に加えて、 BasicDaoContextFactory の設定をコンポーネント定義に追加する。

<!-- コンポーネント名は"daoContextFactory"で設定する。 -->
<component name="daoContextFactory" class="nablarch.common.dao.BasicDaoContextFactory" />

7.3.2.3.2. 任意のSQL(SQLファイル)で検索する¶

任意のSQLで検索したい場合は、データベースアクセスの SQLをファイルで管理する と同様に、 SQLファイルを作成し、SQL IDを指定して検索する。

UniversalDao.findAllBySqlFile(User.class, "FIND_BY_NAME");

SQLファイルは、検索結果をマッピングするBeanから導出する。 上の例のUser.classがsample.entity.Userの場合、 SQLファイルのパスは、クラスパス配下のsample/entity/User.sqlとなる。

SQL IDに「#」が含まれると、「SQLファイルのパス#SQL ID」と解釈する。 下の例では、SQLファイルのパスがクラスパス配下のsample/entity/Member.sql、 SQL IDがFIND_BY_NAMEとなる。

UniversalDao.findAllBySqlFile(GoldUser.class, "sample.entity.Member#FIND_BY_NAME");

7.3.2.3.3. テーブルをJOINした検索結果を取得する¶

一覧検索などで、複数のテーブルをJOINした結果を取得したい場合がある。 このような場合は、非効率なため、JOIN対象のデータを個別に検索せずに、 1回で検索できるSQL と JOINした結果をマッピングするBean を作成すること。

7.3.2.3.4. 検索結果を遅延ロードする¶

大量の検索結果を扱う処理では、メモリが足らなくなるため、検索結果をすべてメモリに展開できない。 以下のようなケースがある。

• ウェブで大量データをダウンロードする
• バッチで大量データを処理する

そのような場合は、ユニバーサルDAOの遅延ロードを使用する。 遅延ロードを使用すると、ユニバーサルDAOとしては1件ずつロードするが、 JDBCのフェッチサイズによってメモリの使用量が変わる。 フェッチサイズの詳細は、データベースベンダー提供のマニュアルを参照。

遅延ロードは、検索時に、 UniversalDao#defer メソッドを先に呼び出すだけで使用できる。 遅延ロードでは、内部でサーバサイドカーソルを使用しているので、 DeferredEntityList#close メソッドを呼び出す必要がある。

// try-with-resourcesを使ったclose呼び出し。
// DeferredEntityListはダウンキャストして取得する。
try (DeferredEntityList<User> users
        = (DeferredEntityList<User>) UniversalDao.defer()
                                        .findAllBySqlFile(User.class, "FIND_BY_NAME")) {
    for (User user : users) {
        // userを使った処理
    }
}

7.3.2.3.5. 条件を指定して検索する¶

検索画面のように、条件を指定した検索をユニバーサルDAOでも提供している。

// 検索条件を取得する
ProjectSearchForm condition = context.getRequestScopedVar("form");

// 条件を指定して検索する
List<Project> projects = UniversalDao.findAllBySqlFile(
    Project.class, "SEARCH_PROJECT", condition);

7.3.2.3.6. 型を変換する¶

ユニバーサルDAOでは、 @Temporal を使用して、 java.util.Date 及び java.util.Calendar 型の値をデータベースにマッピングする方法を指定できる。 他の型については、任意のマッピングは不可能であるため、Entityのプロパティは、データベースの型及び使用するJDBCドライバの仕様に応じて定義すること。

また、ユニバーサルDAOは、自動生成したSQLをDBに送信する場合はJPAアノテーションの情報を使用するが、任意のSQLをDBに送信する場合はJPAアノテーションの情報は使用しない。 そのため、型変換については、以下のようになる。

Entityから自動的に生成したSQLを実行する場合

データベースへの出力時

• @Temporal が設定されているプロパティについては、@Temporalに指定された型へ変換する。
• 上記以外については、データベースアクセス(JDBCラッパー) に処理を委譲して変換する。

データベースから取得時

• @Temporal が設定されているプロパティについては、@Temporalに指定された型から変換する。
• 上記以外はEntityの情報を元に、値が変換される。

任意のSQLで検索する場合

データベースへの出力時

• データベースアクセス(JDBCラッパー) に処理を委譲して変換する。

データベースから取得時

• Entityから自動的に生成したSQLを実行する場合と同様の処理を行う。

7.3.2.3.7. ページングを行う¶

ユニバーサルDAOの検索は、ページングをサポートしている。 ページングは、検索時に、 UniversalDao#per メソッド、 UniversalDao#page メソッドを先に呼び出すだけで使用できる。

EntityList<User> users = UniversalDao.per(3).page(1)
                            .findAllBySqlFile(User.class, "FIND_ALL_USERS");

ページングの画面表示に必要な検索結果件数といった情報は、 Pagination が保持している。 Pagination は、 EntityList から取得できる。

Pagination pagination = users.getPagination();

7.3.2.3.8. サロゲートキーを採番する¶

サロゲートキーを採番する場合は、以下のアノテーションを使用する。

• @GeneratedValue
• @SequenceGenerator
• @TableGenerator

ユニバーサルDAOでは、 javax.persistence.GenerationType のすべてのストラテジをサポートしている。

GenerationType.AUTO

@Id
@Column(name = "USER_ID", length = 15)
@GeneratedValue(strategy = GenerationType.AUTO)
public Long getId() {
    return id;
}

• データベース機能に設定された Dialect を元に採番方法を選択する。 優先順位は、IDENTITY→SEQUENCE→TABLEの順となる。
• SEQUENCEが選択された場合、シーケンスオブジェクト名は”<テーブル名>_<採番するカラム名>”となる。
• シーケンスオブジェクト名を指定したい場合は、 @SequenceGenerator で指定する。

GenerationType.IDENTITY

@Id
@Column(name = "USER_ID", length = 15)
@GeneratedValue(strategy = GenerationType.IDENTITY)
public Long getId() {
    return id;
}

GenerationType.SEQUENCE

@Id
@Column(name = "USER_ID", length = 15)
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq")
@SequenceGenerator(name = "seq", sequenceName = "USER_ID_SEQ")
public Long getId() {
    return id;
}

• シーケンスオブジェクトの名前は @SequenceGenerator で指定する。
• sequenceName属性を省略した場合、”<テーブル名>_<採番するカラム名>”となる。

GenerationType.TABLE

@Id
@Column(name = "USER_ID", length = 15)
@GeneratedValue(strategy = GenerationType.TABLE, generator = "table")
@TableGenerator(name = "table", pkColumnValue = "USER_ID")
public Long getId() {
    return id;
}

• レコードを識別する値は @TableGenerator で指定する。
• pkColumnValue属性を省略した場合、”<テーブル名>_<採番するカラム名>”となる。

7.3.2.3.9. バッチ実行(一括登録、更新、削除)を行う¶

ユニバーサルDAOでは、大量データの一括登録や更新、削除時にバッチ実行ができる。 バッチ実行することで、アプリケーション稼働サーバとデータベースサーバとのラウンドトリップ回数を削減でき、パフォーマンスの向上が期待できる。

バッチ実行は以下のメソッドを使用する。

• batchInsert
• batchUpdate
• batchDelete

7.3.2.3.10. 楽観的ロックを行う¶

ユニバーサルDAOでは、 @Version が付いているEntityを更新した場合、自動で楽観的ロックを行う。 楽観的ロックで排他エラーが発生した場合は、 javax.persistence.OptimisticLockException を送出する。

排他エラー時の画面遷移は、 OnError を使用して行う。

// type属性に対象とする例外、path属性に遷移先のパスを指定する。
@OnError(type = OptimisticLockException.class,
         path = "/WEB-INF/view/common/errorPages/userError.jsp")
public HttpResponse update(HttpRequest request, ExecutionContext context) {

    UniversalDao.update(user); // 前後の処理は省略。

}

7.3.2.3.11. 悲観的ロックを行う¶

ユニバーサルDAOでは、悲観的ロックの機能を特に提供していない。

悲観的ロックは、データベースの行ロック（select for update）を使用することで行う。 行ロック（select for update）を記載したSQLは、 UniversalDao#findBySqlFile メソッドを使って実行する。

7.3.2.3.12. 排他制御の考え方¶

排他制御に使用するバージョンカラムをどのテーブルに定義するかは業務的な観点により決める必要がある。

バージョン番号を持つテーブルは、排他制御を行う単位ごとに定義し、競合が許容される最大の単位で定義する。 たとえば、「ユーザ」という大きな単位でロックすることが業務的に許容されるならば、ユーザテーブルにバージョン番号を定義する。 ただし、単位を大きくすると、競合する可能性が高くなり、更新失敗(楽観的ロックの場合)や処理遅延(悲観的ロックの場合)を招く点に注意すること。

7.3.2.3.13. データサイズの大きいバイナリデータを登録（更新）する¶

OracleのBLOBのように、データサイズの大きいバイナリデータを登録（更新）したい場合がある。 ユニバーサルDAOだと、データをすべてメモリに展開しないと登録（更新）できないため、 データベースが提供する機能を使ってファイルなどから直接登録（更新）すること。

詳細は、 バイナリ型のカラムにアクセスする を参照。

7.3.2.3.14. データサイズの大きいテキストデータを登録（更新）する¶

OracleのCLOBのように、データサイズの大きいテキストデータを登録（更新）したい場合がある。 ユニバーサルDAOだと、データをすべてメモリに展開しないと登録（更新）できないため、 データベースが提供する機能を使ってファイルなどから直接登録（更新）すること。

詳細は、 桁数の大きい文字列型のカラム(例えばCLOB)にアクセスする を参照。

7.3.2.3.15. 現在のトランザクションとは異なるトランザクションで実行する¶

データベースアクセス(JDBCラッパー) の 現在のトランザクションとは異なるトランザクションでSQLを実行する と同じことを、ユニバーサルDAOで行う方法を説明する。

個別トランザクションを使用するには、以下の手順が必要となる。

1. コンポーネント設定ファイルに SimpleDbTransactionManager を定義する。
2. SimpleDbTransactionManager を使用して、新たなトランザクションでユニバーサルDAOを実行する。

以下に使用例を示す。

コンポーネント設定ファイル

コンポーネント設定ファイルに SimpleDbTransactionManager を定義する。

• connectionFactory プロパティに ConnectionFactory 実装クラスを設定する。 ConnectionFactory 実装クラスの詳細は、 データベースに対する接続設定 を参照。
• transactionFactory プロパティに TransactionFactory 実装クラスを設定する。 TransactionFactory 実装クラスの詳細は、 データベースに対するトランザクション制御 を参照。

<component name="find-persons-transaction"
    class="nablarch.core.db.transaction.SimpleDbTransactionManager">

  <!-- connectionFactoryプロパティにConnectionFactory実装クラスを設定する -->
  <property name="connectionFactory" ref="connectionFactory" />

  <!-- transactionFactoryプロパティにTransactionFactory実装クラスを設定する -->
  <property name="transactionFactory" ref="transactionFactory" />

  <!-- トランザクションを識別するための名前を設定する -->
  <property name="dbTransactionName" value="update-login-failed-count-transaction" />

</component>

実装例

コンポーネント設定ファイルに設定した SimpleDbTransactionManager を使って、ユニバーサルDAOを実行する。 なお、 SimpleDbTransactionManager を直接使うのではなくトランザクションを制御する、 UniversalDao.Transaction を使用すること。

まず、 UniversalDao.Transaction を継承したクラスを作成する。

private static final class FindPersonsTransaction extends UniversalDao.Transaction {

    // 結果を受け取る入れ物を用意する。
    private EntityList<Person> persons;

    FindPersonsTransaction() {
        // SimpleDbTransactionManagerをsuper()に指定する。
        // コンポーネント定義で指定した名前、またはSimpleDbTransactionManagerオブジェクトを指定できる。
        // この例では、コンポーネント定義で指定した名前を指定している。
        super("find-persons-transaction");
    }

    // このメソッドが自動的に別のトランザクションで実行される。
    // 正常に処理が終了した場合はトランザクションがコミットされ、
    // 例外やエラーが送出された場合には、トランザクションがロールバックされる。
    @Override
    protected void execute() {
        // executeメソッドにUniversalDaoを使った処理を実装する。
        persons = UniversalDao.findAllBySqlFile(Person.class, "FIND_PERSONS");
    }

    // 結果を返すgetterを用意する。
    public EntityList<Person> getPersons() {
        return persons;
    }
}

そして、 UniversalDao.Transaction を継承したクラスを呼び出す。

// 生成すると別のトランザクションで実行される。
FindPersonsTransaction findPersonsTransaction = new FindPersonsTransaction();

// 結果を取得する。
EntityList<Person> persons = findPersonsTransaction.getPersons();

7.3.2.4.1. DatabaseMetaDataから情報を取得できない場合に対応する¶

データベースによっては、シノニムを使用している場合や権限の問題で、 java.sql.DatabaseMetaData から主キー情報を取得できない場合がある。 主キー情報を取得できなくなると、主キーを指定した検索が正しく動作しない。 そのような場合は、 DatabaseMetaDataExtractor を継承したクラスを作成して対応する。 主キー情報をどのように取得するかはデータベース依存のため、製品のマニュアルを参照すること。

作成したクラスを使用するには、設定が必要となる。

<!--
sample.dao.CustomDatabaseMetaDataExtractorを作成した場合の設定例
コンポーネント名は"databaseMetaDataExtractor"で設定する。
-->
<component name="databaseMetaDataExtractor" class="sample.dao.CustomDatabaseMetaDataExtractor" />

7.3.2.4.2. ページング処理の件数取得用SQLを変更する¶

ページング 処理では、実際の範囲指定レコードの取得処理の前に、件数取得SQLが発行される。 件数取得SQLは、デフォルトでは元のSQLを SELECT COUNT(*) FROM で包んだSQLとなる。 元のSQLが ORDER BY 句を含むなど処理負荷が大きいSQLで、負荷軽減のため ORDER BY 句を外したいといった場合には、 使用しているダイアレクトをカスタマイズし、件数取得SQLを変更することで対応する。

件数取得SQLを変更する場合は、プロジェクトで使用しているダイアレクトを継承した上で、 Dialect#convertCountSql(String, Object, StatementFactory) の実装を変更する。

実装例

以下に nablarch.core.db.dialect.H2Dialect をカスタマイズする例を示す。 この例では、元のSQLと件数取得SQLのマッピングをコンポーネントに設定し、件数取得SQLを変更している。

補足

プロジェクトごとに適切なマッピングルールを検討すること。

public class CustomH2Dialect extends H2Dialect {

    /**
     * 件数取得SQLのマッピング
     */
    private Map<String, String> sqlMap;

    /**
     * {@inheritDoc}
     *
     * 件数取得SQLのマッピング内に{@code sqlId}に対応するSQLIDが存在すれば、
     * それを件数取得SQLとして返却する。
     */
    @Override
    public String convertCountSql(String sqlId, Object params, StatementFactory statementFactory) {

        if (sqlMap.containsKey(sqlId)) {
            return statementFactory.getVariableConditionSqlBySqlId(sqlMap.get(sqlId), params);
        }

        return convertCountSql(statementFactory.getVariableConditionSqlBySqlId(sqlId, params));
    }

    /**
     * 件数取得SQLのマッピングを設定する。
     *
     * @param sqlMap 件数取得SQLのマッピング
     */
    public void setSqlMap(Map<String, String> sqlMap){
        this.sqlMap = sqlMap;
    }
}

カスタマイズしたダイアレクトは、コンポーネント設定ファイルで設定する必要がある。 以下に、カスタマイズしたダイアレクトをコンポーネント設定ファイルに設定する例を示す。 この例では、件数取得SQLのマッピングを <property> 要素で設定している。

<component name="dialect" class="com.nablarch.example.app.db.dialect.CustomH2Dialect">
  <property name="sqlMap">
    <map>
      <entry key="com.nablarch.example.app.entity.Project#SEARCH_PROJECT"
             value="com.nablarch.example.app.entity.Project#SEARCH_PROJECT_FORCOUNT"/>
    </map>
  </property>
</component>