2011-08-17 27 views
1

次のユースケースを説明しましょう。newキーワードを使用してデータオブジェクトを作成するJPQLクエリがあります。 SELECT節では、データベースには知られていないが、それを照会する層に属性を挿入したいと考えています。JPQL SELECT句への属性の挿入

これは、SELECT句に属性またはパラメータインジェクションのこの種は、JPQLに働くかもしれない方法

EntityManager em; // Got it from somewhere 
boolean editable = false; // Value might change, e.g. depending on current date 

Query q = em.createQuery("SELECT new foo.bar.MyDTO(o, :editable) FROM MyObject o") 
      .setParameter("editable", editable); 

List<MyDTO> results = (List<MyDTO>) q.getResultList(); 

任意のアイデアのように見えるだろうか? JPAとJPA 2.0の両方のソリューションが適用可能です。

編集:パフォーマンスは重要な役割を果たしませんが、コードの明快さと清潔さが重要です。

答えて

2

それは、可能なベンダー拡張機能なしでは動作しません応じて仕様理由:

4.6.4入力パラメータ
...
入力パラメータのみ で使用することができますWHERE句またはHAVING句クエリ。

+0

ニース読んで、賞を授与します:-) – nre

4

結果のリストを繰り返し処理するだけでパフォーマンスの問題を測定し、それぞれの要素でセッターを呼び出したことがありますか。私はそれが反射を利用してMyObjectにインスタンスに各列を変換するのにかかる

  • それはデータベース(プロセス間コール、ネットワーク通信)を介してクエリを実行するのにかかる

    • に比べて時間という時間を推測
    • 、それは非常に高速になります反射に

    あなたのループを使用してMyDTOに各MyObjectにインスタンスを変換するのにかかる時間。

    パフォーマンスが心配な人は、Hibernateとリフレクションに頼るのではなく、返されたMyObjectインスタンスから手動でMyDTOインスタンスを構築する必要があります。

    保存は、簡単で、安全で、読みやすく保守的です。次に、パフォーマンスの問題がある場合は、それがどこから来たのかを検出するように測定します。その後、それだけで最適化します。

    +0

    私は特にパフォーマンスは心配していませんが、見栄えのよいコードについては心配していません。それを設計目標のように見てください。 – nre

    +0

    結果リストがかなり大きいという事実は無関係です。ループは要素の数に関係なく同じになります。私は、リファクタリングがコンストラクタシグネチャの変更をキャッチせず、リファクタリングが不可能なHQLクエリの内部に配置するよりも、MyDTOインスタンスのリスト(リファクタリングを有効にし、コンパイラによって安全性をチェックしたもの) 。 –

    +0

    リファクタリングが心配だったら、Criteria APIではなくJPQLをまったく使用しません。私はパフォーマンスの正当性を削除するために私の質問を編集しました。他の人が質問の中核に集中することを容易にします。 – nre

    関連する問題