I see two separate concerns here:

1) Should Django present to users the option to do validate-on-save by
default? That is, should that option be visible -- in the form of a
documented setting or an optional argument to save()?

I tend to accept James'  (and others) views and reasoning against that.

2) Can a user activate validation-on-save-by-default without resorting
to monkeypatching? Should it be possible?

I think applying such validation should be possible -- because, in many
places, you see less-than-disciplined teams creating large projects
containing heaps of code that is not of the finest quality. And I think
we should help these projects improve incrementally -- that is,
introduce means to improve their situation; promoting notions like

        data mutation should occur only in well-defined, controlled ways

without making them prerequisite.

This notion is a nice ideal, but installing it on a project
after-the-fact is hard; in many places it is not realistically
attainable -- at least in the boundaries of the team's resources,
delivery requirements, and a reasonable timeframe.

Note that for such general validation, a project-wide-base-model as
suggested e.g. by Uri is, in general, not sufficient, because it may
not apply to models from 3rd-party apps, or even from django.contrib
apps. Most models in such apps are not swappable.

But there is a way, I think, using a pre_save signal. One can write a
small app to install pre-save validation on all models in the project,
merely by including it in INSTALLED_APPS.

Basically, 

    from django.db.models import signals
    ...
    class WhateverConfig(AppConfig):
    ...

        def ready()

            def validate(sender, instance, raw, **kwargs):
                if not raw:
                    instance.full_clean()

            signals.pre_save.connect(validate, weak=False)

This, of course, is just a POC -- it doesn't include things like
allowing a model to opt out, for example. Or one might want to apply it
only where settings.DEBUG is set. Or only log warnings. Or a few other
variations that don't jump to my mind immediately.

But it is a way for those of us involved with large teams and projects
to add this feature, without affecting the experience of newcomers or
the layer-separation sensibilities of the framework.

HTH,
        Shai.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20221010163935.4ba0fcb6.shai%40platonix.com.
          • ... Aaron Smith
          • ... Mariusz Felisiak
          • ... Aaron Smith
          • ... James Bennett
          • ... Aaron Smith
          • ... James Bennett
          • ... Aaron Smith
          • ... James Bennett
          • ... Jure Erznožnik
          • ... Aaron Smith
          • ... Shai Berger
    • ... 'Barry Johnson' via Django developers (Contributions to Django itself)
  • Re... Aaron Smith

Reply via email to