JavaEE 7 JPA 2.1の新機能コンバータ - しんさんの出張所 はてなブログ編
JPAのバージョンは2.1と前バージョンから0.1しか上がっていないが、非常にいいものが追加されている。 2.1の目玉機能としてはストアド呼び出しが可能になったとかあるのだろうが、基本ストアド使いたくないのでおいらは無視する。 で、地味・・・ではなくド派手なのにあまり語られない新機能もある。 それがコンバータだ。やっときた！ これはどういうものかというと、たとえば、DB上には文字列で保存をして、Entity上はIntegerで保持するといったもの。 もちろん、ラッパクラス以外でもふつうに使えるので、アプリケーションに合わせて積極的にコンバータを作っておくと既存のDBを変更せず、かといってそれにEntity操作が引きずられない、非常に良いものが出来上がる。 コードは昨日のエントリのJPA2.0のサンプルをもとに変更してみよう。 addressという文字列型には都道府県が入っていたので、そこに
QuerydslでJPAが思ったよりも捗る - 水まんじゅう2
先日、 [twitter:@seratch]さんから教えていただいたQuerydslがすごい良かったので記事として書きます。 http://www.querydsl.com/ JPAにおける課題 JPAではJPQLとCriteriaという二つのクエリ記述言語があります。 しかしながら、それぞれ使い勝手という意味では難のあるものでした。 JPQL JPQLは以下のような、SQLライクなクエリ記述言語です。 select new com.github.megascus.EmployeeBean(e.code, e.name, e.age) from Employee as e where name like 's%'SQLライクに記述することができるため、SQLが理解できる人にとっては理解しやすいという利点があります。 しかしながら、JPQL自体はただの文字列で定義する必要があります。 そのた
JPAの@Embeddableの使い道 - 達人プログラマーを目指して
JPAには@Embeddableというアノテーションがありますが、このマッピング機能をうまく活用しているチームはどれくらいあるのでしょうか？私が今まで適用してきた使い方は結局以下の2通りの使い方のいずれかに集約できると思います。 1.属性の多い巨大なテーブルに対するエンティティを入れ子に構造化されたクラスとして扱う これはちょうどCOBOLにおいて巨大なレコードをばらばらの独立項目として扱うのではなく、値の塊ごとに集団項目として一まとまりの変数としてまとめて考えるという発想に近い考え方です。たとえば、COBOLでは以下のように従業員レコードを固まりで分割して定義できます。 DATA DIVISION. WORKING-STORAGE SECTION. 01 EMPLOYEE. 05 EMP-NO PIC 9(7). 05 EMP-NAME 10 FIRST-NAME PIC X(15).
Old Tech Per: 10 Tips on JPA Domain Modelling
This post is a collection of tips on what I think is good advice, when domain modelling in Java with JPA as ORM mapping technology. Do you agree? Do you have extra advice? Please let me know! Here they come, in no particular order. 1. Put Annotation on Methods, not Attributes If using annotations on attributes, JPA engine will set directly in the attributes using reflection, hereby by-passing any
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
