回答編集履歴

4

修正

2021/07/20 10:06

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -1,4 +1,8 @@
1
- **【回答が間違っていそうなので修正中】**
1
+ [https://github.com/illuminate/validation/blob/74e13a98299bbc3c48c5131a9239b9ad499a4efe/DatabasePresenceVerifier.php#L108](https://github.com/illuminate/validation/blob/74e13a98299bbc3c48c5131a9239b9ad499a4efe/DatabasePresenceVerifier.php#L108)
2
+
3
+
4
+
5
+ を確認しました。 `NOT NULL` じゃなくて **`NOT_NULL`** のようです。
2
6
 
3
7
 
4
8
 
@@ -6,7 +10,7 @@
6
10
 
7
11
 
8
12
 
9
- ここからは個人的な意見ですが,そもそも **リクエストバリデーションでユニークをチェックするのはおすすめしません。データベースアクセスが不要なフォーマット的なチェックだけを行いましょう**
13
+ 個人的な意見ですが,そもそもリクエストバリデーションでユニークをチェックするのはあまりおすすめしません。データベースアクセスが不要なフォーマット的なチェックだけを行うほうが,バリデーションルールが散らからなと思い
10
14
 
11
15
 
12
16
 
@@ -14,7 +18,7 @@
14
18
 
15
19
 
16
20
 
17
- 上記におおまかな方針を示してあるで,参考に読んでみてください。上記の理論に基づいて今回のバリデーションを書くなら
21
+ 上記の理論に基づいて今回のバリデーションを書くなら
18
22
 
19
23
 
20
24
 
@@ -26,7 +30,7 @@
26
30
 
27
31
  if (User::query()->where('email', $email)->exists()) {
28
32
 
29
- throw new DuplicateEmailException($email);
33
+ throw new DuplicateEmailException($email); // 独自に設けた例外
30
34
 
31
35
  }
32
36
 
@@ -42,7 +46,7 @@
42
46
 
43
47
 
44
48
 
45
- また蛇足ですが,論理削除とユニーク制約は両立可能なので,こちらも参照してみてください。整合性に対する信頼性が大きく向上します。
49
+ 更に蛇足ですが,論理削除とユニーク制約は両立可能なので,こちらも参照してみてください。整合性に対する信頼性が大きく向上します。
46
50
 
47
51
 
48
52
 

3

いったん消す

2021/07/20 10:06

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -1,64 +1,4 @@
1
1
  **【回答が間違っていそうなので修正中】**
2
-
3
-
4
-
5
- -----
6
-
7
-
8
-
9
- [https://github.com/illuminate/validation/blob/9cb3e3a6871925cd7344eb28078784c6de0ba2e2/Rules/Unique.php#L67-L73](https://github.com/illuminate/validation/blob/9cb3e3a6871925cd7344eb28078784c6de0ba2e2/Rules/Unique.php#L67-L73)
10
-
11
-
12
-
13
- を見た感じ, `unique:` は引数を 5 個しか取りませんね。つまり
14
-
15
-
16
-
17
-
18
-
19
- ```php
20
-
21
- 'email' => [
22
-
23
- 'unique:users,email,null,id,deleted_at,NULL',
24
-
25
- ]
26
-
27
- ```
28
-
29
-
30
-
31
-
32
-
33
-
34
-
35
- ```php
36
-
37
- 'email' => [
38
-
39
- 'unique:users,email,null,id,deleted_at',
40
-
41
- ]
42
-
43
- ```
44
-
45
-
46
-
47
- とみなされている可能性が高いです。使われていない引数なので, `NULL` を `NOT NULL` にしても動作が何も変わらないのは期待された動きです。そもそもそういう使い方が想定されていないので。
48
-
49
-
50
-
51
- そして
52
-
53
-
54
-
55
- - [https://github.com/illuminate/validation/blob/9cb3e3a6871925cd7344eb28078784c6de0ba2e2/Concerns/ValidatesAttributes.php#L716-L760](https://github.com/illuminate/validation/blob/9cb3e3a6871925cd7344eb28078784c6de0ba2e2/Concerns/ValidatesAttributes.php#L716-L760)
56
-
57
- - [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)
58
-
59
-
60
-
61
- このへんを読んだ感じだと, `NOT NULL` をつけるのは,既存のバリデーションルールでは厳しそうです。 `PresenceVerifier` をカスタムして注入して動きを変えるなど,高度なやり方が必要になってきます。
62
2
 
63
3
 
64
4
 

2

修正中

2021/07/20 10:03

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -1,3 +1,11 @@
1
+ **【回答が間違っていそうなので修正中】**
2
+
3
+
4
+
5
+ -----
6
+
7
+
8
+
1
9
  [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
10
 
3
11
 

1

追記

2021/07/20 10:00

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -66,4 +66,36 @@
66
66
 
67
67
 
68
68
 
69
- 上記におおまかな方針を示してあるので,参考に読んでみてください。
69
+ 上記におおまかな方針を示してあるので,参考に読んでみてください。上記の理論に基づいて今回のバリデーションを書くなら
70
+
71
+
72
+
73
+ ```php
74
+
75
+ // email が文字列であることはバリデーション済みであると想定
76
+
77
+
78
+
79
+ if (User::query()->where('email', $email)->exists()) {
80
+
81
+ throw new DuplicateEmailException($email);
82
+
83
+ }
84
+
85
+ ```
86
+
87
+
88
+
89
+ のようなイメージになります。
90
+
91
+
92
+
93
+ ---
94
+
95
+
96
+
97
+ また蛇足ですが,論理削除とユニーク制約は両立可能なので,こちらも参照してみてください。整合性に対する信頼性が大きく向上します。
98
+
99
+
100
+
101
+ - [MySQLでLaravel標準のSoftDeletesを使った論理削除とユニーク制約を両立させる方法 - Qiita](https://qiita.com/mpyw/items/d3e25860ecaaeb8340ab)