2 | | |
3 | | Replying to [comment:3 Carlton Gibson]: |
4 | | > Hi Gaurav, |
5 | | > |
6 | | > Thanks for the follow-up. (I wasn't sure about the attachment: it's seemed like the whole project was saved as binary in the `manage.py` file — how did you create that? How would one run it? — Not something I've seen before, but I was able to look at it.) |
7 | | > |
8 | | > I'm going to move this to `needsinfo` — assuming a storage that didn't create unique names, I can see how this might come up. |
9 | | > |
10 | | > The storage issue is a bit of a distraction. The correct validation should be at the form layer: |
11 | | > |
12 | | > * Calling `form.is_valid()`, on a `ModelForm` using the image (or file field). |
13 | | > * In [https://github.com/django/django/blob/156a2138db20abc89933121e4ff2ee2ce56a173a/django/forms/models.py#L383 `_post_clean()`] we WOULD validate the uniqueness of the field. |
14 | | > * In a test case [https://github.com/django/django/blob/156a2138db20abc89933121e4ff2ee2ce56a173a/django/forms/models.py#L310 `_get_validation_exclusions()`] **included** the `logo` field — that's because of the `blank=True` on the model definition. That means `_post_clean()` will be skipped for it. |
15 | | > |
16 | | > Removing the `blank=True` allows `logo` not be excluded but I didn't have enough time to verify whether the image/file field would then trigger the expected error in `validate_unique()`. I may be able to get back to it (it's interesting) but if you could dig down deeper that would help. |
17 | | > |
18 | | > * I'd subclass `Storage` and override `.get_alternative_name()` to not do that properly. |
19 | | > * Then create a `ModelForm` with just the `logo` field to verify that `_post_clean()` triggers the uniqueness error. |
20 | | > |
21 | | > If not then we can see why not, and whether it can be adjusted. |