エンティティに複雑なプロパティを使用する場合。 例えば、列挙型。 テーブルにマッピングされる、データが列挙型である場合の iBATISの定義の仕方。 まあ、列挙型でなくても、Hnadlerを登録すれば、ほぼ自由なことができる。 今回は、iBATIS Wikiにある例をチョット変更してみた。 How do I use a Custom Type Handler with complex property (Type Safe Enumeration) Reportというテーブルをマッピングする。 このテーブルは、frequencyというType Safe Enumerationなプロパティを含む。 テーブル定義： CREATE TABLE REPORT ( ID VARCHAR(5), NAME VARCHAR(25), DESCRIPTION VARCHAR(1000), FREQUENC
クラス(Java) と テーブル (RDB) とを対応させて、さらにそれぞれの中での関係を表現する、というのがいわゆる Object/Relational マッピングの考え方です。それだけ、よりきめの細かなモデルの表現ができるわけですが、実現方法もそれだけ複雑にはなります。 複雑な SQL で表されるような RDB 側のモデルに対しては、Java 側での実現もそれだけ複雑な形にはなります。 iBATIS の場合、クラス(Java) と SQL の実行結果 (結果セット) との対応、と割り切ってしまっているので、どんな複雑な SQL だろうがそんなに複雑にはなりません。 結果セットは必ずひとつの値の集合、もしくはその値の集合のリストになるので、それの値それぞれに対応したクラスを作ればいいわけです。極端に簡単に言えば、SQL の実行結果は単一行(スカラ値) か複数行のテーブルと解釈できるので、
shin3tky blog: Struts 2 + Spring 2 + iBATIS 連携設定
2009年2月22日 Struts 2 + Spring 2 + iBATIS 連携設定 新しいプロジェクトを Struts 2.0 + Spring 2.0 + iBATIS 2.3 で組むことにしたので、初期の連携設定のメモを残します。Eclipse (Ganymede) の Dynamic Web Project のディレクトリ構造を前提に書いています。 検討途上では、Struts 2.0 + Guice 1.0 + JPA + Hibernate 3 (Core, Annotations, Entity Manager) も考えましたが、JPA, Hibernate は、その難しさが分かるほど使い込んではおらず、動作の見通しがよくトラブル対応の経験もある iBATIS にしました。iBATIS は最終的に実行される SQL が確実にコントロールでき、キャッシュの機構もシンプルです
まずは、iBATISでSELECTを実行させたいと思います。 iBATIS本体の入手 本家サイトからDLしてください。 現在（2009年1月8日）では、2.3.4が最新になっています。 その他必須Jarたち 今回は、MySQLに接続するので、MySQL Connectorが必要です。 また、JakartaのDBCP、Poolを使用してコネクションをプールするので、以下の必要です。 Jakarta DBCP Jakarta Pool あればよいJar（たぶん必須だと思う） また、必須ではないですが、Log4jがあると、iBATISが発行するSQLを見ることができるので、DLしておきましょう。 Log4j ※Log4jは1.3系や、2.0系がありますが、1.2系で全然問題ないので、こっちを使いましょう。 また、toString用として、Commons LangのToStringBuilderを
■キャッシュ SqlMapConfig.xmlに<settings> Elementを書かないと デフォルトではキャッシュは有効だが有効にならない。 謎。 今回使用したソース マッピングファイルで定義する。 （SqlMapXmlファイル） cacheModel id・・・ID type・・・キャッシュのタイプ flushInterval・・・キャッシュの生存期間。 以下を設定できる milliseconds seconds minutes hours flushOnExecute 実行されたらキャッシュをクリアするステートメントのID おすすめはMEMORYらしい キャッシュのタイプ MEMORY メモリーの量に応じて、クリアされたりする。 ガベージコレクタに依存したキャッシュ <cacheModel id="product-cache" type="MEMORY"> <flushInte
はじめに Apache iBATISはSQLを利用することに注力したフレームワークです。高機能なO/Rマッピングフレームワークに比べて簡単に理解でき、レガシーなJDBC、ResultSetを使ったプログラミングから簡単に乗り換えられます。特にSQLを多用する人には使いやすいフレームワークです。 この記事は前回、前々回の記事の続編です。今回はiBATISの機能を拡張する方法として、検索結果をCSVデータとして出力する方法と、データベースのデータから任意のデータ型に交換する方法を紹介します。 iBATISの基本的な内容は、以前の記事を参考にしていただけると分かりやすいと思います。 過去の記事 iBATISを使ったO/RマッピングによるDBアクセスの実例 iBATISを使ったO/RマッピングによるDBアクセスの実例 2 対象読者 Javaの基本をマスターしている人 SQL文を理解している人 必要
はじめに iBATISはSQLを利用することに注力したフレームワークです。高機能なO/Rマッピングフレームワークに比べて簡単に理解でき、レガシーなJDBC、ResultSetを使ったプログラミングから簡単に乗り換えられます。 特にSQLを多用する人には使いやすいフレームワークです。 この記事は前回の「iBATISを使ったO/RマッピングによるDBアクセスの実例」の続編です。前回はSELECT、INSERT、UPDATE、DELETEの基本的な記述方法についてサンプルを紹介しました。今回はSELECT文に注目し、検索結果のマッピングと動的SQLの記述方法について説明します。 iBATISの基本的な内容は、前回の記事を参考にしていただけると、分かりやすいと思います。 対象読者 Javaの基本をマスターしている人 SQL文を理解している人 必要な環境 iBATIS 2.3.0、J2SE 5.0の
はじめに iBATISはSQLを利用することに注力したフレームワークです。高機能なO/Rマッピングフレームワークに比べて簡単に理解でき、レガシーなJDBC、ResultSetを使ったプログラミングから簡単に乗り換えられます。 特にSQLを多用する人には使いやすいフレームワークです。 SQLは使いたいがJDBCは低レベルすぎる 高機能なO/Rマッピングフレームワークは難しすぎる ソースコードからSQLを分離したいが動的なSQLの実装も必要 このようなケースで、iBATISは特に有効です。 本記事では、たくさんのサンプルソースを解説することで、「iBATISを使えばこんな風に書ける」ということが分かるようにしています。環境設定や、設定ファイルについての細かい説明は簡略化してあります。 対象読者 Javaの基本をマスターしている人 SQL文を理解している人 必要な環境 iBATIS 2.3.0、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
