回答編集履歴
4
修正
answer
CHANGED
|
@@ -1,18 +1,20 @@
|
|
|
1
|
-
|
|
1
|
+
[https://github.com/illuminate/validation/blob/74e13a98299bbc3c48c5131a9239b9ad499a4efe/DatabasePresenceVerifier.php#L108](https://github.com/illuminate/validation/blob/74e13a98299bbc3c48c5131a9239b9ad499a4efe/DatabasePresenceVerifier.php#L108)
|
|
2
2
|
|
|
3
|
+
を確認しました。 `NOT NULL` じゃなくて **`NOT_NULL`** のようです。
|
|
4
|
+
|
|
3
5
|
----
|
|
4
6
|
|
|
5
|
-
|
|
7
|
+
個人的な意見ですが，そもそもリクエストバリデーションでユニークをチェックするのはあまりおすすめしません。データベースアクセスが不要なフォーマット的なチェックだけを行うほうが，バリデーションルールが散らからないと思います。
|
|
6
8
|
|
|
7
9
|
- [5年間 Laravel を使って辿り着いた，全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころ](https://zenn.dev/mpyw/articles/ce7d09eb6d8117)
|
|
8
10
|
|
|
9
|
-
上記
|
|
11
|
+
上記の理論に基づいて今回のバリデーションを書くなら
|
|
10
12
|
|
|
11
13
|
```php
|
|
12
14
|
// email が文字列であることはバリデーション済みであると想定
|
|
13
15
|
|
|
14
16
|
if (User::query()->where('email', $email)->exists()) {
|
|
15
|
-
throw new DuplicateEmailException($email);
|
|
17
|
+
throw new DuplicateEmailException($email); // 独自に設けた例外
|
|
16
18
|
}
|
|
17
19
|
```
|
|
18
20
|
|
|
@@ -20,6 +22,6 @@
|
|
|
20
22
|
|
|
21
23
|
---
|
|
22
24
|
|
|
23
|
-
|
|
25
|
+
更に蛇足ですが，論理削除とユニーク制約は両立可能なので，こちらも参照してみてください。整合性に対する信頼性が大きく向上します。
|
|
24
26
|
|
|
25
27
|
- [MySQLでLaravel標準のSoftDeletesを使った論理削除とユニーク制約を両立させる方法 - Qiita](https://qiita.com/mpyw/items/d3e25860ecaaeb8340ab)
|
3
いったん消す
answer
CHANGED
|
@@ -1,35 +1,5 @@
|
|
|
1
1
|
**【回答が間違っていそうなので修正中】**
|
|
2
2
|
|
|
3
|
-
-----
|
|
4
|
-
|
|
5
|
-
[https://github.com/illuminate/validation/blob/9cb3e3a6871925cd7344eb28078784c6de0ba2e2/Rules/Unique.php#L67-L73](https://github.com/illuminate/validation/blob/9cb3e3a6871925cd7344eb28078784c6de0ba2e2/Rules/Unique.php#L67-L73)
|
|
6
|
-
|
|
7
|
-
を見た感じ， `unique:` は引数を 5 個しか取りませんね。つまり
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
```php
|
|
11
|
-
'email' => [
|
|
12
|
-
'unique:users,email,null,id,deleted_at,NULL',
|
|
13
|
-
]
|
|
14
|
-
```
|
|
15
|
-
|
|
16
|
-
は
|
|
17
|
-
|
|
18
|
-
```php
|
|
19
|
-
'email' => [
|
|
20
|
-
'unique:users,email,null,id,deleted_at',
|
|
21
|
-
]
|
|
22
|
-
```
|
|
23
|
-
|
|
24
|
-
とみなされている可能性が高いです。使われていない引数なので， `NULL` を `NOT NULL` にしても動作が何も変わらないのは期待された動きです。そもそもそういう使い方が想定されていないので。
|
|
25
|
-
|
|
26
|
-
そして
|
|
27
|
-
|
|
28
|
-
- [https://github.com/illuminate/validation/blob/9cb3e3a6871925cd7344eb28078784c6de0ba2e2/Concerns/ValidatesAttributes.php#L716-L760](https://github.com/illuminate/validation/blob/9cb3e3a6871925cd7344eb28078784c6de0ba2e2/Concerns/ValidatesAttributes.php#L716-L760)
|
|
29
|
-
- [https://github.com/laravel/framework/blob/c7824d4e163947331d2676dc35213126499736a1/src/Illuminate/Validation/DatabasePresenceVerifier.php#L36-L55](https://github.com/laravel/framework/blob/c7824d4e163947331d2676dc35213126499736a1/src/Illuminate/Validation/DatabasePresenceVerifier.php#L36-L55)
|
|
30
|
-
|
|
31
|
-
このへんを読んだ感じだと， `NOT NULL` をつけるのは，既存のバリデーションルールでは厳しそうです。 `PresenceVerifier` をカスタムして注入して動きを変えるなど，高度なやり方が必要になってきます。
|
|
32
|
-
|
|
33
3
|
----
|
|
34
4
|
|
|
35
5
|
ここからは個人的な意見ですが，そもそも **リクエストバリデーションでユニークをチェックするのはおすすめしません。データベースアクセスが不要なフォーマット的なチェックだけを行いましょう**。
|
2
修正中
answer
CHANGED
|
@@ -1,3 +1,7 @@
|
|
|
1
|
+
**【回答が間違っていそうなので修正中】**
|
|
2
|
+
|
|
3
|
+
-----
|
|
4
|
+
|
|
1
5
|
[https://github.com/illuminate/validation/blob/9cb3e3a6871925cd7344eb28078784c6de0ba2e2/Rules/Unique.php#L67-L73](https://github.com/illuminate/validation/blob/9cb3e3a6871925cd7344eb28078784c6de0ba2e2/Rules/Unique.php#L67-L73)
|
|
2
6
|
|
|
3
7
|
を見た感じ， `unique:` は引数を 5 個しか取りませんね。つまり
|
1
追記
answer
CHANGED
|
@@ -32,4 +32,20 @@
|
|
|
32
32
|
|
|
33
33
|
- [5年間 Laravel を使って辿り着いた，全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころ](https://zenn.dev/mpyw/articles/ce7d09eb6d8117)
|
|
34
34
|
|
|
35
|
-
上記におおまかな方針を示してあるので，参考に読んでみてください。
|
|
35
|
+
上記におおまかな方針を示してあるので，参考に読んでみてください。上記の理論に基づいて今回のバリデーションを書くなら
|
|
36
|
+
|
|
37
|
+
```php
|
|
38
|
+
// email が文字列であることはバリデーション済みであると想定
|
|
39
|
+
|
|
40
|
+
if (User::query()->where('email', $email)->exists()) {
|
|
41
|
+
throw new DuplicateEmailException($email);
|
|
42
|
+
}
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
のようなイメージになります。
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
また蛇足ですが，論理削除とユニーク制約は両立可能なので，こちらも参照してみてください。整合性に対する信頼性が大きく向上します。
|
|
50
|
+
|
|
51
|
+
- [MySQLでLaravel標準のSoftDeletesを使った論理削除とユニーク制約を両立させる方法 - Qiita](https://qiita.com/mpyw/items/d3e25860ecaaeb8340ab)
|