These are chat archives for scalikejdbc/ja

24th
Mar 2016
lyrical logical
@lyricallogical
Mar 24 2016 03:29
SelectSQLBuilder 見る限り on で何か複雑なことしたかったら append しろって感じなのかな
outer join で where に書けない条件書くときにちょっと不便
Manabu Nakamura
@gakuzzzz
Mar 24 2016 06:26
on に SQLSyntax 渡せる版がある https://github.com/scalikejdbc/scalikejdbc/blob/3ca2cfea5d5578e0578158520131edda82b6186d/scalikejdbc-interpolation/src/main/scala/scalikejdbc/QueryDSLFeature.scala#L408 ので そのまま on に sqls"複雑なクエリ" を書いて貰えれば。

あるいは

on(sqls.eq(a.id, b.id).and.eq(a.foo, c.bar).and.isNull(a.deletedTime))

みたいな感じでも

lyrical logical
@lyricallogical
Mar 24 2016 06:38
override あったのか、いいですね
ここ where と同じ conditional でいい気がするけど RDMBS によって微妙に違ったりするだろうし面倒なこと考えずに sqlsyntax が一番か
まあ on は節だし式(をあらわすクエリ(のsyntax))を貰う API なのは全うですね…
しかし querydsl はお仕事仲間には難しいだろうということで見送られるのだった(おしまい)
Kazuhiro Sera
@seratch
Mar 24 2016 14:32
gakuzzzz さんの #423 ってメリットあるのはもちろんわかるんですけど、どうなんでしょうね。さほどでもないような気がしてきたのですけど。
それとは別に pull request のお作法的にもう少しメリットを示す説明なりテストケースなりがあってほしい感。
Manabu Nakamura
@gakuzzzz
Mar 24 2016 16:30
enum的なやつとかIDクラスみたいなラッパーなどの独自型つかった際に、全部 setObject に丸め込まれて事故るケースが両手では足りないぐらい見かけてるので、それを解決できるなら何でもよいです。 #423 は互換性も無くなるしログ書き出しとかも微妙になるしアレ以外でもっとすっきり解決できるのであれば全然それで。
確かに pull request 適当すぎですね……。
Kazuhiro Sera
@seratch
Mar 24 2016 23:02

全部 setObject に丸め込まれて事故るケース

これは JDBC が食えなさそうな型を setObject しようとしたときに warning 出すとかでもかなり気づけるような気がしますね。