[seasar-s2dao-dev:79] Re: Next S2Dao

[kubo]

久保です。

> ...(略)
> @Fetch("bbb", fetches=@Fetch("ccc")
> List<Aaa> find(...);
> ならプロパティのbbb、プロパティbbbのプロパティcccも同時に取得する。
> 
> というのでどうでしょう。
> この方式なら、予期せぬデータが取得されることはなく、
> 開発者のイメージ通りにデータが取得されると思うので、
> 問題はないと思います。

おお。。。

それならば、例えばS2Dao-CodeGenを使った場合において、
FK情報から生成したEntity間のRelationをフルに活用することが可能ですし、
ひがさんの提案する「継承によるJoin指定」(すいません呼び名が不明で...)
も同時に利用可能です。非常に相性がいいと思います。

DBFluteの場合は、ちょっと変わりますが、
S2Daoが「ManyToOne形式でEntityにMappingする機能」があって、
そこに渡すJOIN情報の部分をDicon切り替えの独自カスタマイズする
ポイントさえあれば、現状の仕様を満たしつつ、
「継承によるJoin指定」も利用可能です。

# DBFluteはDaoメソッドの引数で結合先を決定しているため、
# 上記のとおりなのです。(CBは自動生成)
#   AaaCB cb = new AaaCB();
#   cb.setupSelect_Bbb(); // 親(BBB)の結合
#   cb.setupSelect_Ccc().withDdd(); // 親(CCC)と親(DDD)の結合
#   dao.selectList(cb);

色々意見を尊重して頂いて本当にありがとうございます。



> ちなみに、Relno系は廃止しようと思っています。
> もともと、SQLファイルを書いた場合でも、N:1マッピングが
> 可能なようにあのような仕様にしていたのですが、
> SQLファイルを書くときは、DTOへのフラットなマッピングで
> 十分だと思うからです。

そうですね。
SQLファイルの場合にN:1マッピングが不要なのは同感です。


余談ですが、Aliasに指定するRELNOは、自動生成ツールと相性が悪く、
開発途中でFKが追加されたときに、番号が変わってしまい一気に
動かなくなるので、「外だしSQLはN:1マッピングしないで」
とプロジェクトの規約にしていました。



-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
kubo   <jazzflute ＠ mbn.nifty.com>
jflute <http://d.hatena.ne.jp/jflute>
株式会社ビルドシステム <http://www.buildsystem.co.jp>
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/