You are viewing the documentation for Play 1. The documentation for Play 2 is here. JPA 永続化Play は、JPA エンティティの管理を容易にするとても便利な一連のヘルパを提供します。 いつでも素の JPA API に立ち返ることができることに 注意 してください。 JPA エンティティマネージャの開始Playは、 @javax.persistence.Entity アノテーションで注釈されたクラスをひとつ以上見つけた場合、自動的に Hibernate エンティティマネージャを開始します。とは言え、JDBC データソースを正しく設定していない場合、エンティティマネージャの開始は失敗してしまうので、確実に設定してください。 JPA エンティティマネージャの取得JPA エンティティマネージャが開始されている
JPAのトランザクションについてまとめました。 エンティティマネージャの種類 コンテナ管理 EJBコンテナがライフサイクルを管理 DI or JNDI lookupにより取得 アプリケーション管理 アプリケーションのコード上で生成・破棄 EntityManagerFacutory # createEntityManager() により生成 EntityManager # close() で破棄 エンティティマネージャが利用できるトランザクションマネージャの種類 JTAトランザクション 自動的にEJBコンテナ管理のJTAトランザクションに参加することができる JPA設定ファイル(persistence.xml)に、transaction-typeとして"JTA"を指定する リソースローカルトランザクション DBの持つトランザクション管理機能を直接使用する EntityManager # ge
Entity Graphs とは Entity Graph の構成 Graph アノテーションと Graph API 簡単な利用例 Fetch Graph と Load Graph Attribute Node の定義 Subgraph の定義 Subgraph の複数参照 継承構造の Graph 定義 ルート継承構造の Graph Map Key Subgraphs タイプセーフな属性定義 Entity Graph の取得 名前付きの Entity Graph への追加 Entity Graph の利用 Entity Graphs とは JPA 2.1 では Entity Graph を使うことで fetch 計画を指定できるようになりました。これにより query や find で取得する対象ををカスタマイズできるようになります。同じ Entity から様々なデータの見せ方が必要で、時
OutOfMemoryErrorの主な要因例として、DBMSからデータを取得しすぎがあります。 LASYフェッチによるN + 1 問題を回避するために、結合先テーブルの要素を一気に持ってくるJOIN FETCHを使ったところ、引き換えにJavaヒープ使用量が多くなるのはよくあるケースです。 以下のような、1つのIssueに対して複数のIssueAttributeを持つ1対多関連のエンティティの操作を例に、OutOfMemoryErrorを少しでも避ける方法を考えてみます。 @Entity public class Issue implements Serializable { private static final long serialVersionUID = 1L; @Id @GeneratedValue private int issueId; private String tit
はじめに これはJPAを解説する連載の5回目です。 うっかりすると、JPQLでは予期しなかった大量のSQLが発行されてしまう場合があります。これは “N+1” 問題と言われているものですが、解決のためには次のような4つの選択肢があります。 JPQLでJOIN FETCHを使う Criteria API(JPQLをプログラムとして書く)でFetch Joinを記述する Named Entithy Graph を使う Dynamic Entity Graph を使う ここでは、1.のJPQLによる方法について解説します。また、そのほかの方法も、この後の章で順次、詳しく解説する予定です。 N+1問題とは 次のような具体的な例で考えましょう。 // すべてのEmployeeエンティティを得る TypedQuery<Employee> query = em.createQuery("SELECT e
The detail of JPA 20 1. Java Persistence API の詳細ついて日本オラクル Fusion Middleware 製品事業統括本部シニア Java エバンジェリスト寺田 佳央 (http://yoshio3.com) 1 | Copyright © 2011, Oracle and/or it’s affiliates. All rights reserved. 2. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量
JPAとは JPA(Java Persistence API)とはJavaEEのために定義された永続化(persistence)に関するAPI仕様です。JPAはAPI仕様なのでJPA単体では動きません。JPAを実装したHibernateやEclipseLinkなどのO/R Mapperが必要になります。 N+1問題とは N+1問題とはO/R Mapperを利用した際にSQL文が意図せず大量に発行されてしまう問題です。この問題はO/R MapperによるSQL文の自動生成に起因します。Object側の関連も含めてデータを取得する場合に、O/R Mapperは下記のようにN+1回SELECT文を発行してしまいます。 TableからN個のRecordを取得するためにSELECT文を1回発行 N個のRecordが関連するデータを取得するためにSELECT文を1回ずつ、計N回発行 N+1問題の解決策
I want to output the SQL generated by EclipseLink to the console, during development. However, I could only do so using the logging level FINE. I have a complex domain model composed of many classes, so much that deployment takes a considerable ammount of time when the log verbosity is on the FINE level, since EclipseLink outputs its analysis of the whole model. Is there a way to get the SQL witho
前エントリで、NativeQuery・JPQL・CriteriaAPIのどれが一番速いのかパフォーマンス比較を行い、NativeQuery悪くないじゃん、と結論づけました。そして、JavaEE AdventCalendar 2013を取りまとめて頂いた@megascusさんや、このネタを書く発端となった@yoshioteradaさんを始めとする多くの方々にコメントを頂きました。ありがとうございました。 その中で、JPQLをNamedQueryで宣言しておくと、起動時にプリコンパイルされるのでパフォーマンスが向上する、との情報を頂いたので、再実験してみました。 今回使用したソースはこちら 前回との差分を簡単に振り返っておくと、まず、JPQL文をfindProductという名前をつけて、EntityクラスにNamedQueryとして宣言しました。 @Entity @Table(name="pr
環境構築 JPA の基本的な話 JPQL の話 Criteria API の話 コード マッピング方法だけを確認しやすいようにした一覧を作成しました。 JPA マッピングカタログ - Qiita はじめに オブジェクト指向で考えられたドメインモデルと、正規化などを考慮して考えられたリレーショナルデータベースのテーブルでは、データの持たせ方に違いが生まれる。 この違いをインピーダンスミスマッチと言う。 インピーダンスミスマッチを解決するには、データベースから取得したレコードをオブジェクトにマッピングする処理が必要になる(さらに、永続化するときは逆変換が必要)。 オブジェクトとテーブルの構造が1対1で対応していれば、この変換はそこまで大変ではない。 しかし、そうでない場合、変換を自力で実装するのは非常に骨が折れる。 O/R マッパーはこの変換を自動でやってくれるフレームワークで、 JPA では
Everything goes into this Blog. I will share my views of current issues, IT project experiences (technical view) , my hobbies and etc into my blog. I will try my best to update it frequently. I been trying to debug the following error for days, and it drive me nuts! The problem: JPA refuse to compile one of my NamedQuery, and throws the following error: Error compiling the query [UserVO.findByUser
先週書いたエントリJava EE6標準の範囲でフルスタックのWebアプリケーションが簡単に作成できることを確かめてみました。 - 達人プログラマーを目指してで、Java EE6の標準仕様を使うだけで、かなりシンプルにデータのCRUD処理を行うアプリケーションが作成できることを紹介しました。ただし、前回は全体のアプリケーションを紹介しただけなので、細かい仕掛けについては解説しきれませんでした。今回は、前回に引き続き特にJPAを使ったデータベースアクセスの部分がどうなっているのかをもう少し掘り下げて解説してみたいと思います。 なお、この場で宣伝ですが、8月10日(水)にGlassfishユーザーグループの勉強会にてお話をさせていただくことになりました。 GlassFish Japan Users Group 勉強会 2011 Summer : ATND 私はJava EE6を使った開発について
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く