These are chat archives for scalikejdbc/ja

16th
Mar 2015
KAWACHI Takashi
@tkawachi
Mar 16 2015 00:39
↑のPR入ったリリースがすぐにでる機運はあったりしますか?
Kazuhiro Sera
@seratch
Mar 16 2015 03:57
scalate のリリース待ちで次のリリースを考えていたのでそこに入れることはありえますが、ビルドに失敗しているな(ちゃんと見てない)。
KAWACHI Takashi
@tkawachi
Mar 16 2015 03:59
hasManyFixed などというメソッドをコピペで定義してしばらく過ごします。
KAWACHI Takashi
@tkawachi
Mar 16 2015 04:21
うーん、なぜか many 側テーブルの id column を見に行ってしまうな...
Kazuhiro Sera
@seratch
Mar 16 2015 04:45
時間が取れたら見るつもりで大丈夫げとか書いたけどたぶん大丈夫じゃないなと思っているところ。extract のところで id となる PK は認識していないとダメだから今の形になってる気が。やりようはあると思いますが。
Manabu Nakamura
@gakuzzzz
Mar 16 2015 05:20
あー Option版の extract で null かどうか判定するカラムが必要なのか。
KAWACHI Takashi
@tkawachi
Mar 16 2015 05:23
hasMany().byDefault 相当を NoId なテーブルを対象に書きたいのですが、hasMany を使わない他の方法はありますか?
Kazuhiro Sera
@seratch
Mar 16 2015 12:50

うーん、なぜか many 側テーブルの id column を見に行ってしまうな...

一つの column でユニーク性を判定できるデータ構造ですかね?もしそうであれば override def primaryKeyFieldName = "fullName" でそのカラムにマッピングされるフィールド名を指定すれば動作すると思われます。

KAWACHI Takashi
@tkawachi
Mar 16 2015 12:52
many 側、ユニーク性を判定するカラム無かった..
うそ、複合 column で判定する構造でした
Manabu Nakamura
@gakuzzzz
Mar 16 2015 12:52
あれ、hasManyの同値性検証ってEntityEqualityじゃなかったんですね……
Kazuhiro Sera
@seratch
Mar 16 2015 12:53
This message was deleted
This message was deleted
many がいるかは ResultSet の何らかの項目の存在確認をしているのでそこで想定外となってしまうのが今回のケース。
Manabu Nakamura
@gakuzzzz
Mar 16 2015 12:56
あ、ですよね。同値性検証というか存在チェックのカラムが必要ってことですよね。よかった
Kazuhiro Sera
@seratch
Mar 16 2015 12:57
でも、このパターンを hasMany で
Manabu Nakamura
@gakuzzzz
Mar 16 2015 12:57
なので ユニーク制約じゃなくて non-null 制約のカラムであればよさそうな
Kazuhiro Sera
@seratch
Mar 16 2015 12:57
サポートしようというのは正直ちょっとキツイ気がしてるのですけど、諦めるのはまだ早いだろうか。
Manabu Nakamura
@gakuzzzz
Mar 16 2015 13:01
work around としては override def primaryKeyFieldName = "fullName" で NOT NULL なカラム指定すればいけそうですかね?
Kazuhiro Sera
@seratch
Mar 16 2015 13:02
いや、まだ確認中です。
Manabu Nakamura
@gakuzzzz
Mar 16 2015 13:02
ya-
Kazuhiro Sera
@seratch
Mar 16 2015 13:05
ダメそう。scalikejdbc で one.toManies 書いていただきたい。
それか pull request。
KAWACHI Takashi
@tkawachi
Mar 16 2015 13:08
えーと hasMany は Id ついてるときのみってことでしょうか?
Kazuhiro Sera
@seratch
Mar 16 2015 13:09
少なくとも今はその想定です。
KAWACHI Takashi
@tkawachi
Mar 16 2015 13:09
わかりました。ありがとうございます
Kazuhiro Sera
@seratch
Mar 16 2015 13:11
WithId 以外を受け付けるとそれはそれで今まで型チェックがあった普通のパターンでそれがなくなるというデメリットはある。
あと hasMany でやるなら belongsTo でもやらないと一貫性がない。
ちなみにダメそうというのはまったく動かないわけではなく、そのパターンだとこの issue が再発してしまうなど問題を見つけたというステータスです。 skinny-framework/skinny-framework#243
Manabu Nakamura
@gakuzzzz
Mar 16 2015 13:24
あー pagination が絡むと確かに難易度高そう。 unique 保証が必要ですね。
Kazuhiro Sera
@seratch
Mar 16 2015 13:24
がくぞさんのこれ、残念ながら期待には答えていないです>同値性検証というか存在チェックのカラムが必要ってことですよね。よかった
Manabu Nakamura
@gakuzzzz
Mar 16 2015 13:25
ですね
Kazuhiro Sera
@seratch
Mar 16 2015 13:25
primary key の値で unique 担保しているので。で、この実装パターンとしては私は現状は妥当だと思っています。
Manabu Nakamura
@gakuzzzz
Mar 16 2015 13:26
なるほど
Kazuhiro Sera
@seratch
Mar 16 2015 13:27
あ、違うな。
撤回。
Option[Entity] を返していて、確かに存在確認のカラムはなんでもいいはずか。
すみません、自分で少し混乱していました。
ところで対応したとして NoIdMapper で override def primaryKeyFieldName = "fullName" とか work around で書くのが本当に良いのだろうかという。
Kazuhiro Sera
@seratch
Mar 16 2015 13:33
このパターンに対してわかりやすい DSL を提供できるのだろうかという疑問。
Manabu Nakamura
@gakuzzzz
Mar 16 2015 13:35

ところで対応したとして NoIdMapper で override def primaryKeyFieldName = "fullName" とか work around で書くのが本当に良いのだろうかという。

これはちょっとイケてない感ですね

rs => Option[ManyEntity] となるような extructor を同時に指定できればいいのかな?