業務でのhibernate(HQL)経験

hibernateを使用する、ある程度大規模なプロジェクトに参加しました。

複数の会社で構成されているプロジェクトでした。うちは下のほうです;;

O/Rマッピングツールについてです。

HQLを使用しない状況では、hibernateを使用することで非常に便利になると思いますが、今回私が担当した機能は、ちがっていましたので、HQLを結構書くことになりました。そのときに苦労した点をメモします。


設計がSQLベースなので実装時にHQLへの変換が必要だった。

設計は、テーブル定義書を元に行なわれているので、詳細設計書は、実際のテーブル名とフィールド名を使って、SQLを日本語にしたようなかたちで記述されていました。

だから、SQLによる実装であれば、ストレスなくコーディングできたと思われます。これは、設計の進め方の問題でした。

(発注元は、NativeSQLを、原則として使ってほしくないでしょうから使えないものとして。。)


SQLとHQLの知識が必要

HQLって、一見よくできているようにも見えますが、SQLを知らない人には使えないと思います。

Hibernateリファレンス・ドキュメントのHQLの説明にも、「SQLと同じ意味で使われ、同じ意味を持っています。」みたいな説明があるから、SQLの知識を前提にしているようです。それ自体は当たり前なのかもしれませんが、HQLの目指している場所が曖昧なのではないかと感じました。


HQLのフロントエンドが無い。インタプリタ的に実行できない。

SQLなら、SQL*PLUSなどでSQLを投げてSQLが正しいか確認できるのに、HQLのシンタックスが正しいかを調べるには、書いてるアプリを実行するしかない。(インタプリタ的に実行する方法を知らないだけ?)


SQLの方言が使えない。

そのプロジェクトで使用しているDB固有のSQL方言を使えれば、もっと楽できたのに、HQLでは書けませんでした。(from句でのサブクエリとか)


設定ファイルを気軽に変更できない状況にあった。

単純結合でない結合を行うには、設定ファイルに結合するフィールドを指定するとおもうんですが、設定ファイルは共通チームが取りまとめているので、変更するためのコスト(依頼手続きなど)がかかってしまう。


これらは、作る側のhibernateについての知識が不足していたことにもよるとは思うのですが、O/Rマッピングツールを別のプロジェクトで使うのは躊躇してしまうのが現状です。O/Rマッピングツールって今以上に浸透していくんでしょうかね?

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.