Slick vs ScalikeJDBC
- seratch_ja
- 12734
- 5
- 9
- 3
@seratch 「普段LL言語でORMを使っているからORMが良い、SQLに近いDSL()。それにSlickはplay次期標準でしょ?マイグレーションもcreateでし易いのはGood。for式なんかでいろいろ書けるのも便利」派というのと
2013-09-04 10:26:53@seratch 「ScalikeJDBCのDSLは悪くないし、生産性重視で書いたクエリ吐いてデータ量増えた際に重くなった嫌な経験が多いので、ある程度物理設計を見ながらコードを書けた方がいい。SlickはDSLがScala寄りすぎて返って分かりにくい」派みたいな感じですね。
2013-09-04 10:27:22@seratch そして3人での議論なのに、僕が「僕ほとんどDynamoDBしか触らないのでRDB部分はどっちでもいいです。口出ししないからお二人で好きにどうぞ」といって多数決採択も放棄したら議論が終わらなくなりました。
2013-09-04 10:29:23@seratch そして終わらないのでいい加減どっちかに加担しようかと思ったんですが、ほんとどっちでもいいのでどちらを推すかアミダクジで決めたいぐらい迷ってます…w
2013-09-04 10:30:14@BlackPrincessW なるほど。Slick が Play2 の標準っていうのを重視する人は ScalikeJDBC にしたとしておそらく納得しきれないでしょうね。私のスタンスとしては一度 Slick でやってみて「無理だわ」って思ったならこちらへどうぞ、ですw
2013-09-04 10:38:01Slick vs Scalikejdbc平和条約を来週木曜日に締結することが決定した。これから1週間は支配権を争ってコードをコードで洗う無慈悲な戦争が行われる…
2013-09-04 11:46:26え、 slick にも HList と型レベル自然数が入るの・・・ https://t.co/axCaKGBfbY
2013-09-12 03:40:15とりあえず、なんとなく予想できた結末だけどSlickもscalikeJDBCも素晴らしいよ、ってことになってて
2013-09-12 13:45:06しかし、決めきれない理由として 開発の活発さがSlickが上 scalikejdbcは利用数の問題から未知の問題にぶつかるリスクはSlickより大きいよね というリスクヘッジの部分をどうするか。自分たちでぶつかって解決する余力あるかなってところで議論になってて
2013-09-12 13:51:39SlickはSlickで~とか*とかdisられてて、これやるならそもそもscalaじゃなくてrailsの方がいいんじゃないかという飛び火議論があり
2013-09-12 14:04:58Slickは開発が活発といってもバグフィックスが積極的に行われてるわけではないのでやばい系のバグにあたったときのリスクはむしろ高い気がする。
2013-09-12 14:08:50認識としては、.netのlinqに慣れてたりactive recordの楽さに慣れてるコンテキストから、 せっかくScalaでやるならscalikejdbcを使ってやりたい。 けど、単なるアーキテクチャの影響がプロジェクトの遅延を招くかもしれないので怖い という感じか。
2013-09-12 14:09:06で、なんかもう「俺たちやりきった。どっちも一長一短あるし、後はリスクとかも踏まえて決めて号令出してくれ。でも触ってみた感じscalikejdbcを使いたい」という感じだったので
2013-09-12 14:11:57scalikejdbcのトラブル事例が少ないのが怖い もうちょっとgetting startedがあれば… ということだったので、今後ドキュメント類がググりやすい形で増えてくれれば普及にはいい感じなのかな
2013-09-12 14:16:19ちなみにscalikejdbcと決めておきながら、僕はscalikejdbc触ったことないので今日から勉強します。
2013-09-12 14:17:18