Hibernateでマッピング定義

8月 1st, 2016 No comments

基本となるモジュールから、必要に応じた機能モジュールを拡張展開するようなヤリクチで開発を進めております。
で、運用サーバーにセットアップの際には、フル機能が動作する開発サーバーから、採用された機能分を選択的にセッティングすることになります。

っま、データベースに関しては、余分なデータはムシロ邪魔なので、初期化されたdbにテーブル作成やら外部制約やらのsql文をモジュール毎にファイルに作っておくことで、対応できますね。(システムの初期操作のための操作者は、システムに初期設定機能として、ワンクリックで生成できるようにしました)

で、システム本体、特に各コンフィグレーションも可能な限りモジュール毎に管理したいなぁ・・・と、納品完成間際のこのタイミングで、軽い気持ちで始めたら、案の定ハマッてしましました。

web.xmlやapplicationContext.xml系は、複数のファイルに分けられそうな部分を別立てにして、難なく完成。しかしハマッたのはhibernateの設定ファイルでした。といっても、分割自体が問題なのではなく、クラスの継承構造をどのように実装するか?の方法論みたいなコトで、「丁か?」「半か?」の2択しか許して貰えないhibernate君のイジワルが起因したモノでした。

mightyでは、管理する事象は大きく分けて3つです。記録の元帳に相当する、いわゆるマスター。そしてあらゆる記録(出来事)であるイベント。さらにそのイベントに関連した付随情報であるタグ(関連マスタも含む)で成り立っております。

で、この一元化されたイベント・タグにより、最大の特徴である「串刺し機能」が実装されますので、クラス構造もテーブル構造もかなり細分化されております。つまり継承のレベルが深かったり、同一構造の別クラスが多数見受けられたり・・です。

あ、今となっては、この点がキモでした。

hibernateの参考になるサイトに良く書かれているような3つの方針で、table-per-subclassを使ってマッピングしておったのですが、同一構造の別クラス・・・って、言われてみれば無駄なダミーフィールドを持たない理想的なtable-per-class-hierarchyってコトになるんですね(今に思えば)。

そろそろ核心部分ですが、table-per-subclassではマッピング定義でjoined-subclassがシバシバ採用されます。っま、追加されるデータの入ったtableと項目を足してゆく訳ですよね。対してtable-per-class-hierarchyではsubclassを使った記述でホイホイと兄弟分クラスをマッピングできちゃいます。で結果的に紛らわしいのは、このsubclassであってもjoinという記述を使えば、同じように追加されるtableと項目で子供クラスをマッピングできるんですね。ですがこのjoin君はあくまでもオマケ的なのでしょうか?SetやListが書けない。きっとcomponentを間にカマシて使えば何とかなりそうですが、そうするとクラス自体に手を加えなければならず・・・イヤです。

この地獄の混乱時点でのアセリまくった私の選択肢は以下の2つ

  1. joined-subclassでtable指定無しで動かないか?
  2. subclassでSetやListなどコレクションを入れられないか?

かなり前から、同一class定義内にjoined-subclassとsubclassは同居できないということは、書いてあり、知っており、もちろん避けていました。

仕様的にはjoined-subclassのパターンだし、discriminatorも不要だし、subclassで逃げるには工数かかりそうだし、よし、やはりjoined-subclassで行こう!!!!

結果、どうやってtable指定無しで動かしたのか?

はい、兄弟全員、親からはjoined-subclassしてますが、兄弟間では何もせずに、まったく同じ項目定義を重複して記述してあります。

ああ、カッコ悪い。

手が空いたら、hibernate関連の最新を調べたりして、このキモチ悪いのを解消しましょうね。>自分

Categories: Mighty構想 Tags:

数値のフォーマット

6月 10th, 2016 No comments

ajaxをコリコリやると、サーバー側でjavaをシコシコで、やはりクライアント側はjavaScriptでポチポチ・・・と。

で、javaScriptは変数のスコープとかで解釈が「あらっ」ってのもありますが、今回は数値を表示する際の書式の指定ですね。勘定系のシステムでは、整数を扱うことが多く、正規表現を使った方法ってのを参考に、チョチョイとやっておりました。

今回は小数点以下も持った数値を扱うので、これもチョチョイと思ったらサにあらず。今まで通りの3桁ごとカンマと同時に、小数の桁を指定するのが、「こんなこと」がエレガントにできないみたいでした。

で、以下のような関数を呼び出すことで自作しました。


//
// 数値のフォーマット
//
function numFormat(num, period) {
	var i = String(num).lastIndexOf(".");
	var strInt;
	var strPer;
	if(i<0) {	//小数点なし
		strInt = String(num).replace( /(\d)(?=(\d\d\d)+(?!\d))/g, '$1,' );
		strPer = parseFloat("0").toFixed(period);
	} else {	//小数点あり
		strInt = String(num).substring(0, i).replace( /(\d)(?=(\d\d\d)+(?!\d))/g, '$1,' );
		strPer = parseFloat(String(num).slice(i)).toFixed(period);
	}
	return	strInt + strPer.slice(1);
}

@param num 整形したい数値データ
@param period 表示したい小数以下の桁数
これで、numFormat(‘1234.1234’, 2) で、1,234.12 が返ります。

ヨシヨシ。

Categories: Mighty構想 Tags:

引数の配列・・・データ型によってはエラー(DWR)

5月 6th, 2016 No comments

ajax処理でDWRはとても便利ですが、よくハマルので「身が引き締まる思い(?)」です。

さて、今回はパラメータに配列を使った場合にチョイとヤラカシました。

以前にやったのは、ちゃんと上手く動作したのですよ。

hogeMng.hoge(param, function(result) { ….hoge…});
ここで、paramは受け側のjavaでlong[]で、問題なかった。

で、今度は同様な感じで、paramを受け側javaでString[]でやったら、「Input parameter probably is not an object. (Missing: {).」と、怒られちゃいます。

どうやらDWR君は配列がプリミティブ型であれば通るのに、オブジェクト型だとダメな感じです。

※ もちろん連想配列にして「クラス」としてパラメータ渡しするのはバッチリですが、たかだか文字列配列がダメ。

で、悩んで試して、落ちついた対処が、受け側のパラメータをString[]ではなくList<String>にすることで動作しました。

もっと、カッチョ良い方法もあるカモですが、「javascript側の配列は、javaではListで受ける」ってのでとりあえず許してね。

Categories: Mighty構想 Tags: