I disagree with this system check and I would like to see it reverted before 1.9 final.
I admit that my opinions here are skewed by the fact that I think model level validation is fundamentally not well implemented by Django at all. I work to a philosophy that there are two places where validation happens - once at the entry point to the system (form or serialiser) and once at the database level to ensure integrity of the data. I view model level validators, custom clean methods, and the editable and blank flags as merely hints to automatic ModelForm creation and other similar objects. I can't think of a single time I have explicitly called model.clean(). Now, I can see the merits of a good model level validation system, Django's model level validation is trivial to bypass and I consider relying on it to be bad practice. This check implies that you must use model level validation. I don't agree it should be that unavoidable a feature. The docs for `blank` in fact only reference form validation https://docs.djangoproject.com/en/1.8/ref/models/fields/#blank. The system check framework is supposed to be there to stop easy mistakes. However: - The original error reported by the OP of the ticket was in fact not able to accidentally deploy the code in question because it did not run. - It is common practice to not be use or at least be perfect about your model level validation. I certainly have created many fields which are system level but do not have `editable=False` on them because I explicitly make sure all of my forms do not include this field. They are likely hidden away in the admin as well because they are only used by some internal code. Best practices such as the requirement for model forms to have fields specified make sure that I am being explicit. - If we are going to make it required that your model level validation is correct, then we need to do so in a much more complete way than just checking default values. In particular, code such as Manager.create() should check validation rules. This would be a hugely breaking change for Django. I can of course easily bypass this change, add it to ignored checks or similar. However as a beginner developer I would see this check, think model level validation is important and reliable. Marc On 23 October 2015 at 21:51, James Addison <add...@gmail.com> wrote: > I have a model like so: > > class Provider(models.Model): > description = models.TextField(default='') > > > In recent Django 1.9 changes (this did not occur with 1.8.x), this causes > the following traceback: > > Performing system checks... > > > Traceback (most recent call last): > File > "/home/vagrant/.virtualenvs/myproject/lib/python3.4/site-packages/gevent/greenlet.py" > , line 523, in run > result = self._run(*self.args, **self.kwargs) > File > "/home/vagrant/.virtualenvs/myproject/src/django/django/utils/autoreload.py" > , line 226, in wrapper > fn(*args, **kwargs) > File > "/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/commands/runserver.py" > , line 116, in inner_run > self.check(display_num_errors=True) > File > "/home/vagrant/.virtualenvs/myproject/src/django/django/core/management/base.py" > , line 472, in check > raise SystemCheckError(msg) > django.core.management.base.SystemCheckError: SystemCheckError: System > check identified some issues: > > > ERRORS: > businesses.Provider.description: (fields.E008) Invalid 'default' value: > This field cannot be blank. > images.ImageSet.hash: (fields.E008) Invalid 'default' value: This field > cannot be blank. > users.User.gender: (fields.E008) Invalid 'default' value: This field > cannot be blank. > > > System check identified 3 issues (0 silenced). > > Why is it that this was perfectly allowable before but not now? I have a > data processing script that's pulling in data from an external source and > creating instances with blank 'descriptions', it now doesn't work. I have > to set `blank=True` on fields having this error, which I don't want to do > (for form validation reasons). > > I believe the following links are pertinent: > > https://code.djangoproject.com/ticket/25417 > https://github.com/django/django/pull/5303 > > James > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/c6ffdd4b-6147-43ff-be73-daef2e8149fe%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c6ffdd4b-6147-43ff-be73-daef2e8149fe%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1Ep3HZLhx_0dCJZ5pZ5nro%2BkJ5jAjb6j4R7bsWA1iQDeA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
