Why Django's model.save() Doesn't Call full_clean() and What You Can Do About It

The Reason Behind the Separation

There are two primary reasons why Django separates save() and full_clean():

1. Backwards Compatibility: In earlier versions of Django, save() didn't perform cleaning. This design decision ensures that existing code that relies on this behavior (without explicit cleaning) doesn't break when upgrading to newer Django versions.

2. Flexibility: Separating these methods allows for more granular control over the validation process. Here are some scenarios where this flexibility is useful:

   • Customizing Validation Logic: You might have specific validation requirements that go beyond what Django's built-in field-level validation can handle. full_clean() provides a place to implement these custom checks.
   • Partial Updates: If you're only updating a subset of a model's fields, you might not need to perform full validation. You can choose to call full_clean() only when necessary.
   • Interaction with Signals: Django signals like pre_save and post_save allow you to modify data or perform actions before or after saving. These signals can be used in conjunction with manual full_clean() calls to fine-tune the validation process.

Manually Calling full_clean()

Since save() doesn't automatically trigger cleaning, you'll need to call full_clean() explicitly if you want to validate your model data before saving:

my_model_instance = MyModel()
my_model_instance.full_clean()  # Perform validation
my_model_instance.save()       # Save the data if validation passes

Alternative Approaches

• ModelForms: When using Django ModelForms, the form automatically performs cleaning and validation before saving the data. This is a convenient approach when handling user input through forms.
• Custom Save Methods: You can override the save() method in your model to include a call to full_clean(). This approach can be useful for more complex validation scenarios.

Key Points to Remember

• model.save() prioritizes backwards compatibility and flexibility by not automatically calling full_clean().
• For explicit validation before saving, manually call full_clean().
• ModelForms and custom save() methods offer alternative ways to handle validation.

Example Codes:

Manual full_clean() before save():

class MyModel(models.Model):
    name = models.CharField(max_length=100)
    email = models.EmailField(unique=True)

    def clean(self):
        # Custom validation logic, e.g., checking for specific name formats
        if len(self.name) < 5:
            raise ValidationError("Name must be at least 5 characters long.")
        return super().clean()

    def save(self, *args, **kwargs):
        self.full_clean()  # Explicit validation call
        super().save(*args, **kwargs)  # Save if validation passes

Using ModelForms:

from django import forms

class MyModelForm(forms.ModelForm):
    class Meta:
        model = MyModel
        fields = '__all__'

def create_model_with_form(data):
    form = MyModelForm(data)
    if form.is_valid():
        form.save()
        # Model is saved after form validation
    else:
        print(form.errors)  # Handle form validation errors

Custom save() Method:

class MyModel(models.Model):
    name = models.CharField(max_length=100)
    email = models.EmailField(unique=True)

    def clean(self):
        # Custom validation logic
        return super().clean()

    def save(self, *args, **kwargs):
        self.full_clean()  # Explicit validation call
        super().save(*args, **kwargs)  # Save if validation passes

These examples illustrate how you can achieve validation in your Django models using different methods:

• Manual full_clean(): Offers granular control but requires explicit calls.
• ModelForms: Convenient for user input validation but might not be suitable for all scenarios.
• Custom save() Method: Provides flexibility but can lead to code duplication if used across multiple models.

Validators on Field Definitions:

Django provides built-in validators that you can directly attach to model fields. These validators perform basic checks like ensuring minimum/maximum length, checking for specific values, or validating email formats.

from django.core.validators import MinLengthValidator, MaxLengthValidator, EmailValidator

class MyModel(models.Model):
    name = models.CharField(max_length=100, validators=[MinLengthValidator(5)])
    email = models.EmailField(validators=[EmailValidator()])

This approach is efficient for simple validations but might not be suitable for complex logic.

Custom Validators:

You can create your own custom validators that take the field value as input and raise a ValidationError if the validation fails. This allows for more intricate validation logic.

from django.core.exceptions import ValidationError

def validate_phone_number(value):
    # Regex or custom logic to validate phone number format
    if not value.isdigit():
        raise ValidationError("Phone number must contain only digits.")

class MyModel(models.Model):
    phone_number = models.CharField(max_length=15, validators=[validate_phone_number])

Signals:

Django provides signals like pre_save and post_save that are triggered before and after saving a model instance. You can connect functions to these signals to perform additional validation or data manipulation.

from django.db.models.signals import pre_save

def validate_unique_combination(sender, instance, **kwargs):
    # Custom logic to check if a combination of fields is unique
    # (e.g., name and email combination)
    if MyModel.objects.filter(name=instance.name, email=instance.email).exists():
        raise ValidationError("This combination of name and email already exists.")

pre_save.connect(validate_unique_combination, sender=MyModel)

Third-Party Libraries:

Several third-party libraries like django-validation and django-crispy-forms offer advanced validation features and functionalities that can extend Django's built-in validation capabilities. Consider exploring these options for specific validation needs.