■
コメントありがとうございます。
1:Nは、最初の1:Nだけでよくてネストした1:Nは、要らないと思います。
冷静に考えると、Listを取った時に、それぞれにNの部分が結びついてくるのは、Many-To-Manyですね。
後回しにします。要望が無ければ実装しない方向で…。
追記:
何度か読み直してるうちにちょっと話が噛合ってないカモ…と思ったり。
論理削除も。構想は、まこたんのとこに書いてあったと思う。
個人的には、1:Nよりも論理削除のほうがニーズは大きいと思ったりする。
うう…申し訳無いです…。見つけられません…。
恐らく僕のイメージしてる論理削除と何か違う感じなのかと思います。
機能としてイメージが全く湧いてコナイです。ハイ。もう少し探してみます。
もしかして、1:Nマッピングとは全く関係無い、と言うか違う機能を言ってるのかな…。
MLとかでアンケート取ってみてもいいかも知れず。
Maya風に…と言うか、ある程度実装の方向性がまとまったらメーリングリストに流します。
追記:
もしや、ここも噛合って無い…とか？
1:Nマッピングの実装と、論理削除の実装のどっちを優先するか
メーリングリストで聞いた方が良いとはぶさんは仰ってるんじゃ…。
ああ、きっとそうだ…そうに違いない…。
早く論理削除の構想を書いた部分を探さないと…。
lazy-loadingではなく、一回のフェッチで取得します。lazy-loadingしたければ、個別にDaoを呼び出せば良いと考えています。
この部分は踏襲します。lazy-loadingは手を出すと深みにハマりそうだからです。
但し、頭の片隅に置いて置く事はします。S2Pagerのようなプラグインが作れるかもしれない感じに仕上がると良いかナァ………。
1:Nの1を取ってくるクエリとNを取ってくるクエリを分けてしまう…と言うのもアリかなぁ…とか。
只、今現在僕自身がS2DAOのやたらクエリを自動的に発行しない部分が
不安材料が少なくて良いと思っているので、
クエリを分けるという考え方にはちょっと消極的です。
SQLを自動生成しない時に、Nを取ってくる為のSQLを記述するファイルの名前も
何やらアヤシゲになりそうですし。
N:1,1:Nマッピングはデフォルトだとどっちも有効です。
この部分は、アンケートをしてみて、その結果次第かなぁ…と。
N:1よりも1:Nマッピングは、振り回すと危険な感じがするからです。
個人的には、既にちゃんと動いているBEANアノテーションで指定しているクラスに
1:Nマッピングを追加しただけでOutOfMemoryErrorとか、
そういうのはチョト寒いかな…と思います。
メソッドごとに有効にしたいマッピングを選びたい場合があります。常に関連するすべてのデータが欲しいわけではないためです。
そんな時に使うのが、QUERYアノテーションのjoin句です。joinの後に、有効にしたいマッピングのプロパティ名を指定します。複数ある場合には、カンマで区切ります。
かなり分かり易くて良いと思います。
QUERYアノテーションなので、SQLの自動生成時のみ有効…と言う風になるかと思います。
外部結合するのか、内部結合するのか、も選べるようにした方が良いかなと思います。
少なくともBEANアノテーションで指定したクラスに対応するテーブルのレコードは取れた方が良いので、
基本は外部結合かな…と…ちなみに、N:1マッピングの実装は外部結合になっています。
アンケートの材料になるか、ちょと微妙カモ…。
RELNOアノテーションは、1:Nマッピングの時と同様、必須になるかと思います。
少し気になっているものの、何故気になっているのか、自分で理由は分からない事。
要は、メモ書きです。
