These are chat archives for scalikejdbc/ja

15th
Feb 2015
kenji yoshida
@xuwei-k
Feb 15 2015 00:14 UTC
というわけで例のものを実装してる最中なので、横からツッコミ入れたい方はこちらへ scalikejdbc/scalikejdbc#359
Shuya Tsukamoto
@tsukaby
Feb 15 2015 03:38 UTC
おおお、凄い。
Shuya Tsukamoto
@tsukaby
Feb 15 2015 06:33 UTC
tsukaby/scalikejdbc#1
こんな感じでmapper-gen-allするときでもクラス名を変更できる機能が欲しいなーと思っているのですが、どうでしょうか
ちなみにそもそも付けてOKなのかどうか分からないし、binary compatibilityでtestがコケてぐぬぬ・・って状態です。
Kazuhiro Sera
@seratch
Feb 15 2015 08:08 UTC
うーん、mapper-generator はリポジトリ分けようかな。ライブラリ本体のリリースサイクルと同じである必要性が最近はほとんどないし。
最新の core との互換性がテストされている必要が基本的にはない。ソースコード互換を極力維持しているので生成したコードが違うバージョンの scalikejdbc でも動くべきだろうし。
mapper-generator を分離すると scripted test がなくなって本体の Travis build もシンプルになるというメリットがある。
あ、話それましたが
Kazuhiro Sera
@seratch
Feb 15 2015 08:13 UTC
この suffix サポートの方法は微妙な印象。
第一引数が suffix であるのは当たり前な感じがしないし、少なくともパラメータの渡し方は --suffix Mapper みたいに出来た方がいいですね。
Shuya Tsukamoto
@tsukaby
Feb 15 2015 08:16 UTC
なるほど。次のオプションが出てきたときとかうーんという感じだなーとは自分でも思ってたのですが・・・。scoptとかのCLI option parserは使ったことがあるのですが、これとかsbtでも使えるんでしょうか
Kazuhiro Sera
@seratch
Feb 15 2015 08:18 UTC
それも微妙そうな気はするので、どうなんでしょうね。
よしださんが scripted test を整備してくれているのはありがたいのですが sbt プラグイン以外の手段で実行できるようにしてもいいんじゃないかと思わなくもない。sbt プラグインでないとダメなものではないので。
ところでこの機能、本当に必要ですかね。IDEA のリファクタリングとかで変えても知れてるような。
Shuya Tsukamoto
@tsukaby
Feb 15 2015 08:24 UTC
必要かどうかで言うと、現状は1個ずつ個別にgenerateするbashスクリプトで何とかなっているので、必須ではないのですが。便利かな、と思いまして。良さげな解が無いので、現状維持がベストって感じでしょうか
sbtコマンドを何度も叩くので若干生成が遅いという欠点はあるのですが。
Kazuhiro Sera
@seratch
Feb 15 2015 08:28 UTC
それは sbt "scalikejdbc-gen FooMapper" "scalikejdbc-gen BarMapper" とかでもよさそうですね。
Shuya Tsukamoto
@tsukaby
Feb 15 2015 08:29 UTC
なるほど
Kazuhiro Sera
@seratch
Feb 15 2015 08:29 UTC
"scalikejdbcGen foo FooMapper" だったか。
kenji yoshida
@xuwei-k
Feb 15 2015 08:30 UTC
たしかに、mapper-generatorのせいで最近つらいので、分けるメリットのほうが大きい気もするけど、バイナリ互換がなぁ
Shuya Tsukamoto
@tsukaby
Feb 15 2015 08:31 UTC
あざます!リポジトリ分ける問題もあるようですし、一旦自分のPRは下げますー
kenji yoshida
@xuwei-k
Feb 15 2015 08:31 UTC
そもそもscalikejdbc本体じゃなく、自身のリポジトリへのPRになってるような・・・
Shuya Tsukamoto
@tsukaby
Feb 15 2015 08:32 UTC
あ、はい。そうしました。test通らないしまずは見て頂くだけにしようかなと。
そこは別にdestが本家でもOKだったんですね
Kazuhiro Sera
@seratch
Feb 15 2015 08:33 UTC
まあその状態だと merge はされませんけどw
Shuya Tsukamoto
@tsukaby
Feb 15 2015 08:33 UTC
w
Kazuhiro Sera
@seratch
Feb 15 2015 08:36 UTC
mapper-generator-core が library に依存しているので、もし分けるとしたらバージョニング体系を明確に分けないと混乱するな。play のやつは play のバージョンに寄せればいいだけだったので明確だったけど。
kenji yoshida
@xuwei-k
Feb 15 2015 08:38 UTC
バイナリ互換を維持しやすいようにするためには、継承をできるだけ減らしたり、traitをできるだけclassにする作業が必要・・・
Kazuhiro Sera
@seratch
Feb 15 2015 08:39 UTC
その問題は mapper-generator-core は今のままで sbt plugin だけを分けてしまう、かつ mapper-generator-core の最新を参照させるとかでもいいのかも。
kenji yoshida
@xuwei-k
Feb 15 2015 08:50 UTC
あーやるなら確かに、それでいいですね。バイナリ互換が完全に解消するわけではないけど、本体側のビルドは楽になりそう?
でも mapper-generator-core を変更したときに、scripted-test が書けなくなるから、今 scripted-test でやってることを普通のテストでやる必要がでてくるか
kenji yoshida
@xuwei-k
Feb 15 2015 11:05 UTC
suffixじゃなく、もっと汎用的に、データベースのテーブル名を受け取ってクラス名を返す SettingKey[String => String] を提供すればいい気がしてきた
kenji yoshida
@xuwei-k
Feb 15 2015 12:06 UTC
たぶん出来た xuwei-k/scalikejdbc@9dbe14c (テスト通ったらpull reqする