この前書いた
squeryl2scalikejdbc の設計構想
の続きの話
"scalikejdbc-mapper-generator-core_2.10" % "1.5.2" を使ってみたが、やはりもっと細かくカスタマイズできないとSquerylのからの変換は無理なのだが、諦めて独自に作るか、カスタマイズできるように改造してpull reqすべきか
2013-04-07 02:38:01 via web
@xuwei_k あれは変換先のクラスのフィールド型を generator 側で決めてしまえる前提なので、今回のように変換先の型が決められていてそれに mapping しないといけない場合にはかなり変えないとダメそうですね。
2013-04-07 08:16:38 via TweetDeck to @xuwei_k
@xuwei_k かといって、普通のユーザが mapping 先の情報を設定で渡して使うユースケースはちょっと考えづらいので、本体にその拡張ポイントがあることが有益かどうかは微妙かも。コンセプトが違うということで独自でつくるのがいいのかもしれませんね。
2013-04-07 08:19:06 via TweetDeck to @seratch
というわけで作り始めました
https://github.com/xuwei-k/squeryl2scalikejdbc
ところで、この前思いついたこの方法
「依存ライブラリが頻繁に新しいversionでるけど大抵はソース互換性がある」というライブラリを「依存ライブラリのversion上げただけのものpublishするの面倒」だから、それをわざわざsbt pluginにして、ユーザー側で毎回コンパイルすればいいのでは？とか思いついたが
2013-04-05 12:59:22 via web
をためしてますが(ソースコードはresourceディレクトリに入れておいて、ユーザー側で使うときにコンパイル)
https://github.com/xuwei-k/squeryl2scalikejdbc/blob/b8bfc10ba37a/src/main/scala/Plugin.scala#L31-L40
毎回scriptedを実行しないとコンパイルエラー分からなくて、テンポが微妙になるので、開発中はちょっと不便ですね・・・
