Spring Data JPA provides repository support for the Jakarta Persistence API (JPA). It eases development of applications with a consistent programming model that need to access JPA data sources.
関連エンティティのfetch方法を指定する設定値をデフォルト値から変更した方がよいケースの具体例について。
現在、JavaEEで作っているアプリケーションに画面を追加する事になり、それまではJPAのJPQLを使ってのcreateQueryで済んでいたのですが、今回はGROUP BYとかUNIONとかでSQLを作る必要があり、JPQLでは無理そうなのでcreateNativeQueryで実装する事にしました。 で、最初はcreateQueryをcreateNativeQueryに置き換えてSQL文を噛ませばいいかなと思っていたのですが、どうやら結構違うらしい。。 一つ目の違いは、createQueryならテーブル定義に沿って作ったEntityに直接入れる事が出来ますが、ちょっと複雑なSQLだと問い合わせ結果に一致したEntityを作る事自体が難しい。 二つ目はバインド変数の違い。createQueryならバインド変数は[:PARAM]のように文字として指定して下記のように変数をセットして結果を取得
こんにちわ、みけです。 最近、ずっとJava8のDate and Time APIをいじってきましたが、 多分、これでおわりです。 今日は新APIと古いAPIの相互変換についてです。 java.time.Instant 新APIと古いAPIでの相互変換はjava.time.Instantを経由して行います。 @RunWith(Enclosed.class) public class DateTimeTest { //ゾーンなしフォーマット private static final DateTimeFormatter withoutZone = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss"); //ゾーンつきフォーマット private static final DateTimeFormatter withZone = DateTimeF
はじめに JPAでのロックの基本は楽観的ロック(Optimisstic Loc)です。楽観的ロックは、アノテーションを使って、すべてのエンティティにあらかじめ適用しておくことができます。 楽観的ロックでは、ロックが有効になるのは、トランザクションの最後、つまり、データがコミットされる時です。したがって、トランザクションの途中では、他のトランザクションが同じデータを読み込んだり、あるいは更新してコミットしてしまうこともあり得ます。 そこで、コミットする直前、同じレコードを他のトランザクションが更新していないかどうか調べます。ここで何もなければ、それでOK、データをコミットして終わりです。 しかし、運が悪ければ、他のトランザクションがすでにデータを更新したことが分かり、処理を継続できなくなります。OptimisticLockExceptionという例外を投げてトランザクションを失敗させ、変更は
少し前に検証したものだが、改めて整理。 テーブルAとテーブルBを結合した結果を取得したい場合に、普通にSpring DataのRepositoryを作って@Query のメソッドを定義してもうまくいかない。 例えば以下のようなクエリは表現できない。
テーブル構成 CDとアーティストが多対多で紐づているとします。 ER図で下記のようになっているとします。 ソース CDのエンティティ @Entity @Table(name = "cd") public class Cd implements Serializable { private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Basic(optional = false) @Column(name = "id") @Getter @Setter private Integer id; @Getter @Setter @Column(name = "title") private String title; @Getter @Sette
「永続化」の意味 EntityManagerのメソッドで操作したエンティティは、いったんEntityManagerの永続性コンテキストに配置されます。例えば、メソッドcreateでエンティティに対する「新規登録」の操作を行っても、その時点ではデータベースへの書き込みは行われません。実際には、「このエンティティは、データベースに新規登録するデータである」というマークを付けて永続性コンテキストに配置されるだけです。これがオブジェクトの「永続化」であり、EntityManagerによってデータベースへの格納が可能になった状態であることを意味しているのです。 JSFとの親和性が高いJPA JPAはJava EEの一部であることから、Java EEの他のAPIと容易に組み合わせて使えるよう工夫されています。例えば、JSF(JavaServer Faces)を使用すると、JPAの扱いがとても簡単になり
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問題の解決策
前エントリで、NativeQuery・JPQL・CriteriaAPIのどれが一番速いのかパフォーマンス比較を行い、NativeQuery悪くないじゃん、と結論づけました。そして、JavaEE AdventCalendar 2013を取りまとめて頂いた@megascusさんや、このネタを書く発端となった@yoshioteradaさんを始めとする多くの方々にコメントを頂きました。ありがとうございました。 その中で、JPQLをNamedQueryで宣言しておくと、起動時にプリコンパイルされるのでパフォーマンスが向上する、との情報を頂いたので、再実験してみました。 今回使用したソースはこちら 前回との差分を簡単に振り返っておくと、まず、JPQL文をfindProductという名前をつけて、EntityクラスにNamedQueryとして宣言しました。 @Entity @Table(name="pr
前回までJPAの使用方法を解説してきた。今回は、JPAを利用する上で、テーブルの主キーおよびエンティティのIDの設計で考慮しておくべき事柄を説明する。 複合主キーの定義方法 IDの定義方法を検討をするために、まずJPAでの複合主キーの定義方法を解説する。 エンティティのIDは、永続性コンテキストの中でエンティティを一意に識別する値である。また、EntityManger#find の引数にIDを渡すことからわかるように、JPAでは ID は1つのオブジェクトでなければならない。 そのため、@Embeddable アノテーションを付与した複合主キーを表すクラスを定義する必要がある。(エンティティクラスの内部クラスとすることが多い) @Embeddable public static class PK { @Column(length = 10) private String name; @Co
やりたいこと Spring JPAを使ってMaster-Slave構成の時にSELECTはSlave,その他はMasterサーバへアクセスする ミドルウェア,フレームワーク ReplicationDriver MySQL 5.6 Spring 3.2.8 hibernate テストの構成 Customer.java エンティティクラス CustomerRepository.java JpaRepositoryを継承したクラス. findなどを行います CustomerService.java CustomerRepositoryを呼び出します Testクラス CustomerServiceを呼び出します コードは下記に https://github.com/hachi-eiji/spring-jpa-practice/ 実現方法 ReplicationDriverはautoCommit=f
この記事はJava EE Advent Calendarの18日目のエントリです。昨日はn_agetsuさんのApache Shiro を使ってみましたでした。 Webサービスやソーシャルゲームのボトルネックになりやすいのがデータベースアクセスです。そしてこれらのサービスではデータベースにMySQLが多く使われています。 高負荷なMySQLの負荷分散の一つにデータベースをマスター/スレーブのレプリケーション構成にしてINSERT/UPDATE/DELETEなど更新系のクエリはマスターに対して行い、スレーブにマスターの更新内容をレプリケート、SELECTなど参照系のクエリはスレーブのデータベースにクエリを発行して負荷分散を行う手法があります。 このエントリではそのようなマスター/スレーブのレプリケーション構成のMySQLにJPAを使ってクエリを発行する方法をご紹介します。 MySQLのJDB
Abstract This chapter includes details of the JPA repository implementation. The JPA module of Spring Data contains a custom namespace that allows defining repository beans. It also contains certain features and element attributes that are special to JPA. Generally the JPA repositories can be set up using the repositories element: <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.spr
エンティティ間の結合を表現する 現在サンプルとして使用しているデータベースにおいて、担当者マスタテーブルには MGR_ID というカラムがあります。これは外部キーとして同じ担当者マスタテーブルの担当者IDカラムを参照しており、上司である担当者の担当者IDを入力することになっています。これを JPA で表現してみましょう。 package jp.mydns.akanekodou.entity; import java.io.Serializable; import java.util.Date; import java.util.List; import javax.persistence.Entity; import javax.persistence.FetchType; import javax.persistence.Table; import javax.persistence.I
前回は、Entity Beanの1対1対応を使いました。 今回は1対n対応を使ってみます。 Entity Bean "Person" と Entity Bean "Card" を結び付けてみます。 それぞれが持つフィールドは以下のようにします。 "Person" id プライマリ・キー name 名前 cards 持っているカード(複数可) "Card" id プライマリ・キー companyName カード会社名 サンプルコードは以下の通りです。 @Entity public Person implements Serializable { public Person(...) { cards = new ArrayList<Card>(); Card card1 = new Card(); card1.setCompanyName(...); card1.setPerson(this)
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く