Scala のモデルクラスでプライマリキーとかをどう扱うかという話

1
Toshiyuki Takahashi @tototoshi

"Scala のモデルクラスでプライマリキーとかをどう扱うかという話" http://t.co/tCvDtoxRoC ご意見募集中

2013-08-04 00:21:19
Kazuhiro Sera (瀬良) @seratch_ja

PK を仮で 0 にするとかはちょっと・・と思ってしまう。私は create を名前付きで呼び出すか NewUser って入れ物つくればいい派なので、特に面白い意見はないんですけど。 http://t.co/X0fLr316wg

2013-08-04 00:31:42
がくぞ @gakuzzzz

http://t.co/b2ehkgZkB9 なるほど。割りと「DaoのAPIを変える」の2番目を使ってます。「適当にデフォルト値を用意する」のバリエーションで、コンパニオンオブジェクトに、def notPersistedUser(...): Userてファクトリ作るのもありかも

2013-08-04 00:47:59
がくぞ @gakuzzzz

@gakuzzzz でもそうすると notPersistedUser の引数は「DaoのAPIを変える」と同じになるので、それなら最初から create を名前つき呼び出しで呼べばいいか

2013-08-04 00:52:54
Kenji Yoshida @xuwei_k

http://t.co/lvo5MKEI2i ファントムタイプについて書いたけど、それやってもある程度定形コード発生するし、結局最終的にはコード生成したくなる

2013-08-04 00:56:21
Kenji Yoshida @xuwei_k

あと、フィールド増やしたらメソッド手動で変更しないといけないのは、つまり "setterがファーストクラスオブジェクトじゃなく合成可能でない" のが悪いから、Lens使って自動生成の方向を考えよう! というScalaz脳

2013-08-04 00:59:56
がくぞ @gakuzzzz

ファントムタイプのアプローチは面白そう。 https://t.co/nRWvgBbkiE macro で自動生成できると良さそうだな

2013-08-04 01:04:38
Toshiyuki Takahashi @tototoshi

@gakuzzzz 余計と思って省きましたが、なぜ名前付き引数じゃなくてUserを渡したいかというと、Play (+Pk)だとリクエストをUserにバインドするのができて、そうするとコード量減るからです。

2013-08-04 01:05:50
がくぞ @gakuzzzz

@tototoshi あーなるほど。あれ、であれば def nonPersistedUser みたいなファクトリメソッド作れば、 Form の構築子に apply の代わりにそれを渡せばよいような気がしました。

2013-08-04 01:08:07
がくぞ @gakuzzzz

createdAt とかも 必要無いしなー。

2013-08-04 01:08:45
Toshiyuki Takahashi @tototoshi

@gakuzzzz そうですね。あ、でもある意味 NonPersistedUser 定義するのと似たようなもんですね。(case class つくる = apply 作ると考えて)。

2013-08-04 01:16:02
Toshiyuki Takahashi @tototoshi

なんでこんな細かいこと考えてたかというとコード自動生成したくて、自動生成されたコードどうするのが一番普通っぽいのかなと思ったから。

2013-08-04 01:17:09
Toshiyuki Takahashi @tototoshi

Phantom Type は一回やってみよう

2013-08-04 01:17:45
もろ @低規模言語モデル ';DROP TABLE 人生-- @jagd5168

DBアクセス回数増えるしFWとの親和性は分からんけど、シーケンスからID取ってきて中身空っぽのUserインスタンスを返すファクトリメソッドをcreate()前に呼ぶとか言う方法も。 RT @tototoshi: http://t.co/9D9WEaS2cb

2013-08-04 01:20:34
Toshiyuki Takahashi @tototoshi

@jagd5168 @tototoshi @gakuzzzz @xuwei_k @seratch ツイートを使わせていただきました。問題ありましたら対応しますのでご連絡ください。 http://t.co/bHuQQOFiMQ

2013-08-04 01:26:31
がくぞ @gakuzzzz

@tototoshi 問題ないです! あと別案として、DB生成のIDやめてUUIDとかsnowflake みたいなインスタンス生成時に決定できるIDを使うって手も。 分散考えるとアリかもしれません

2013-08-04 01:32:52
もろ @低規模言語モデル ';DROP TABLE 人生-- @jagd5168

まぁシーケンスなんてほとんどオンメモリで操作してるから通信コストしかないけど。あとは UUID タイプ 2 や snowflake みたいに各ノードでユニークな値を生成するか。

2013-08-04 01:41:03
もろ @低規模言語モデル ';DROP TABLE 人生-- @jagd5168

業務でJava開発取っ掛かりの前世紀の話。某大手SIerの研究所に全ノード上でユニークなIDの発行を保証できる「ID採番Bean」においくら千万円払ったお客さんがいたなー。中身はノード番号+時刻+シーケンスだったけど。

2013-08-04 01:59:08
kmizu @kmizu

@tototoshi 個人的にはデフォルト値に一票かなと。Squeryl使った場合は、一番それがめんどくさくない感じです(気持ち悪いというのは一理ありますが)。

2013-08-04 02:07:54