I've a model like this with Django 1.1:
class Booking(models.Model):
name = models.CharField(max_length=100)
By default, I'm reading that both 'null' and 'blank' are False.
So with a test like this...
class SimpleTest(TestCase):
def test_booking_save(self):
b = Booking()
b.save()
... I expected the save to throw an exception. But it doesn't. It seems quite happy to create a new record with a blank name (Postgres and SQLite3).
I note that via the admin interface a save does indeed fail with a "this field is required".
Questions are:
Is the 'blank' attribute only applied by forms?
Is the fix to override the save() method and explicitly check that len(name) != 0?
Have I misunderstood something which once understood resolves my misunderstanding?
UPDATE: See the model validation documentation in recent Django versions.
Original answer: blank=True/False only applies to forms. Data validation currently only happens at the form level; this will change when the model-validation Google Summer of Code work gets merged in to trunk.
The only kind of validation that currently happens at the model layer is whatever errors your database backend will throw if it can't handle what it gets. In the case of an empty CharField you'll generally never get errors from the database, as Django sets the field to an empty string by default.
For now, you should use the save() method for any model-level validation you want. Soon (if you're on trunk) or when 1.2 comes out, use the model validation stuff.
From the Django Docs:
"Note that empty string values will always get stored as empty strings, not as NULL. Only use null=True for non-string fields such as integers, booleans and dates."
Your code is storing an empty string.
To illustrate this, try:
class SimpleTest(TestCase):
def test_booking_save(self):
b = Booking()
b.name = None
b.save()
Related
I have a model
class SomeModel(models.Model):
emails = ArrayField(models.EmailField(), default=list)
And let's say I have the following Serializer of the model:
class SomeModelSerializer(serializers.ModelSerializer):
class Meta:
model = SomeModel
fields = ['emails']
The email field is not blank-able, i.e: It's required to set a value for it when submitting a Form of the model, or when making changes to its Admin page.
My understanding is that DRF relies as well on Django's internal machinery to validate whether emails is missing on the Serializer data or not. But the thing is that I can't find where (and when) this happens.
I've found that DRF is not calling the Model's clean() method anymore (link). But what baffles me is that changing the blank value on the field seems to have a direct impact on the Serializer. I have switched to blank=True, and then the Serializer would allow it to be saved without that field... Then I switched back to blank=False, and the Serializer would fail if emails is not present.
So do you have any idea of when and where DRF checks for a field's blank value?
Thanks!
As far as I know, it simply doesn't. Those are only used across forms and the django admin interface.
I always specify those things on the serializer level, by setting the appropiate arguments for my fields (doc), in this case it would be allow_blank.
I am building REST APIs with django, and the only case where the blank property on the model field catches me, is when fiddling around on the admin page.
However, there appears to be a package that could be of interest to you:
django-seriously.
I haven't used it, but it appears to call full_clean() on every save().
Of course, this has the disadvantage that you will probably loose DRFs nice error messages.
I have the following problems for a nested model like this:
def Post(models.Model)
name = models.CharField(unique=True)
content = models.TextField()
def Comment(models.Model)
post = models.ForeignKey(Post)
content = models.CharField()
I created default model serializers with all fields.
Problems:
The default model serializer does not work for nested models. I have to explicitly write create/update. This has been explained in the documentation, so nothing against it. Although I think choosing sane default can cater to 99% of use cases (and for the rest, behaviour can be customisable). I will try to take a shot at this.
When I try to use json from existing post object, serializer is_valid() fails saying "unique constraint on name fails". But I wanted it to update and not create. Should is_valid not be create/update aware based on id being passed in json.
When creating a new nested json with many comments, is_valid() fails saying that "post is empty". Of course I will not have post id in the json, as post creation is yet to happen. So is_valid becomes useless. Should is_valid not depend on if id is passed in json? Also, I can not use data/validated_data without having is_valid pass.
Setting validators = [] also does not remove field validations. I have not yet found a way to suppress field validations.
I have gone through source code and documentation and spent more than a day to set up something so simple.
I must be missing something simple, so any help is appreciated.
I have a postgres Database and a model with a field as blank=False and null=True.
Let's say:
class MyModel(models.Model):
param1 = models.CharField(max_length=1024)
param2 = models.CharField(max_length=1024)
info = models.CharField(max_length=1024, blank=False, null=False)
Now, when I am creating a model like this:
m = MyModel(param1=val1, param2=val2)
it basically won't raise any exception for info field on saving. Even more, it will keep an empty value for info in the database after using save method.
UPDATED
When instantiating the model like this:
m = MyModel(param1=val1, param2=val2, info=None)
saving will raise an exception in that case
Any suggestions why does it happen? In my opinion if I miss to add a value in the model initialization, it should be at least assumed as None, but it's not. I googled that and couldn't find an specific answer for that. But, found that only full_clean() model method performs checking and raises exceptions like these:
ValidationError: {'info': ['This field cannot be blank.'], 'owner': ['This field cannot be blank.']}
Any help is welcome!
So after researching I came up with this answer:
First of all, blank stands only for form validation, and null for DB validation (docs). As well, Django always assume the empty value for a missing parameter, but with a little bit different behavior for those field types.
The key difference is that for:
Char fields - it uses an empty string (which is ''), the default Django implementation. So if Django sees that there is a missing parameter, it won't pass None for that type of field, since NULL are not being recommended to be stored in DB for char fields. ( details here )
Other fields - it uses an empty value (which is None). So Django sees that there is a missing parameter, it will assume it's None. But since the database restriction null=False, it will raise the exception.
So the conclusion is that only non-charfields that are being supposed to use database constraint null=False - are being checked on save method for missing params by raising exceptions.
Now if you wanna raise exceptions for Charfields as well, you need to use full_clean (used by forms) that will tell you what type of field can't be blank (or missing). So in the end, the right way is to use blank=False and then full_clean to detect missing Charfields. Or/And, you can override the model`s clean() method if have some additional logic to those fields.
info = models.CharField('Facts and features', max_length=1024)
I am very new to django and python in general, and I was trying to learn rest_framework to create RESTful APIs.
So i have a model like this:
class Listing(models.Model):
listingid = models.BigIntegerField(primary_key=True)
sellerid = models.IntegerField()
createdon = models.DateTimeField(auto_now_add=True, editable=False)
expirydate = models.DateTimeField(null=True)
validationstatus = models.SmallIntegerField(default=0)
listingstatus = models.SmallIntegerField(
choices=((0, 'Active'),
(1, 'Hidden'),
(2, 'Suspended'),
(4, 'Expired'),
(5, 'Deleted'),
),
default=0)
Now i need to validate that the expirydate is always greater than the createdon date.
I know i can do this in the views, I guess that would not be a good idea, since now the validation only exists in the views.
So that leaves me with the serializers and the model.
I know I can override the save method to do check this like so:
class MasterListing(models.Model):
# fields here..
def save(self, *args, **kwargs):
if self.expirydate > self.createdon:
super().save(*args, **kwargs)
return ValidationError("Expiry date cannot be greater than created date ("++")")
but I dont know if this would be a good idea, since now I am raising an error which the programmer may forget to catch. I am also not sure if the fields would be populated when this method would run.
Another way I read about in the docs is the clean method which i couldn't really understand so well.
Can anyone guide me on how to handle situations like this when you are working with the rest_framework?
Some of the things I have read about validation till now:
Serializer Validation
Field level validation
Validators
Model Validation
override clean method
override save method
Just do it manually in the views
There seem to be so many options, and I might have even left a few, I could not clearly get an idea of when to use where.
I am sorry if this is a little on the beginner level, but i am new to frameworks and django seems to be very different from what i was doing in PHP. Any advice is welcome!
Edit: I will be using django for the rest_framework only and nothing else, since we only want to build RESTful APIs.
Django REST framework used to call Model.clean, which was previously the recommended place for putting validation logic that needed to be used in Django forms and DRF serializers. As of DRF 3.0, this is no longer the case and Model.clean will no longer be called during the validation cycle. With that change, there are now two possible places to put in custom validation logic that works on multiple fields.
If you are only using Django REST framework for validation, and you don't have any other areas where data needs to be manually validated (like a ModelForm, or in the Django admin), then you should look into Django REST framework's validation framework.
class MySerializer(serializers.ModelSerializer):
# ...
def validate(self, data):
# The keys can be missing in partial updates
if "expirydate" in data and "createdon" in data:
if data["expirydate"] < data["createdon"]:
raise serializers.ValidationError({
"expirydata": "Expiry date cannot be greater than created date",
})
return super(MySerializer, self).validate(data)
If you need to use Django REST framework in combination with a Django component that uses model-level validation (like the Django admin), you have two options.
Duplicate your logic in both Model.clean and Serializer.validate, violating the DRY principle and opening yourself up to future issues.
Do your validation in Model.save and hope that nothing strange happens later.
but I dont know if this would be a good idea, since now I am raising an error which the programmer may forget to catch.
I would venture to say that it would be better for the error to be raised than for the saved data to possibly become invalid on purpose. Once you start allowing invalid data, you have to put in checks anywhere the data is used to fix it. If you don't allow it to go into an invalid state, you don't run into that issue.
I am also not sure if the fields would be populated when this method would run.
You should be able to assume that if an object is going to be saved, the fields have already been populated with their values.
If you would like to both Model Validation and Serializer validation using Django REST Framework 3.0, you can force your serializer to use the Model validation like this (so you don't repeat yourself):
import rest_framework, django
from rest_framework import serializers
class MySerializer(serializers.ModelSerializer):
def validate(self, data):
for key, val in data.iteritems():
setattr(self.instance, key, val)
try:
self.instance.clean()
except django.core.exceptions.ValidationError as e:
raise rest_framework.exceptions.ValidationError(e.message_dict)
return data
I thought about generating a new function from my model's clean() function's code, and have it either spit out django.core.exceptions.ValidationError or rest_framework.exceptions.ValidationError, based on a parameter source (or something) to the function. Then I would call it from the model, and from the serializer. But that hardly seemed better to me.
If you want to make sure that your data is valid on the lowest level, use Model Validation (it should be run by the serializer class as well as by (model)form classes (eg. admin)).
If you want the validation to happen only in your API/forms put it in a serializer/form class. So the best place to put your validation should be Model.clean().
Validation should never actually happen in views, as they shouldn't get too bloated and the real business logic should be encapsulated in either models or forms.
I have the following model in Django 1.5:
class Person(models.Model):
name = models.CharField(max_length=50)
Note that according to https://docs.djangoproject.com/en/dev/ref/models/fields/
name.blank is by default False which means it must be specified.
However, I could successfully create a Person object as follows:
Person.objects.create()
Notice the name is not specified. What is going on?
Ok, the answer from the docs is :
Note that this is different than null. null is purely database-related, whereas blank is validation-related. If a field has blank=True, form validation will allow entry of an empty value. If a field has blank=False, the field will be required.
Another catch:
Note that validators will not be run automatically when you save a model, but if you are using a ModelForm, it will run your validators on any fields that are included in your form.
It's your responsibility to call the clean methods before saving if you're not using a form.
blank only applies to form field validation as in the admin, django forms, etc.
null on the other hand is a database level nullable column.
As for why blank results in a default '', I had really just accepted it as "that's the way it works" but here's where it appears to be in django.db.models.Field
def get_default(self):
"""
Returns the default value for this field.
"""
if self.has_default():
if callable(self.default):
return self.default()
return force_unicode(self.default, strings_only=True)
if (not self.empty_strings_allowed or (self.null and
not connection.features.interprets_empty_strings_as_nulls)):
return None
return ""
# ^ this
Django creates your user with an empty string. You can actually run Person.objects.all() and it will give you a list, if you save that to a variable called user_list and do something like user_list[0], it will return a user object with an empty string. I do not know how or why it does this.