回答編集履歴
4
修正
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
いったん消す
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
修正中
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
追記
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)
|