Good afternoon, I am currently working on writing a small number of subclasses to `models.Field`. As part of doing this, I wanted to add validation to how those fields are instantiated, and discovered that I think it can't be done. Assuming I'm right, I'd like to fix it.
Here's the use case. Say you want to create a Field subclass, MyField, which requires one or more arguments to be set at initialization. This is equivalent to the requirement of having max_length set on models.CharField. The way models.CharField works is that this validation happens when manage.py syncdb (or sql, or whatnot) is run. It ultimately runs through this file: https://github.com/django/django/blob/master/django/core/management/validation.py ...and if there's an issue, you get an error (e.g. "CharFields require a max_length argument that is a positive integer.") Now, it would seem to me that the appropriate way to write a well-behaved Field subclass would be to have my logic work the same way that the build-in fields do. However, I can't. Sadness. The reason I can't is because that get_validation_errors function is basically a black box. It checks for errors in the field classes included in core through a nested if, e.g. if isinstance(f, models.CharField): [ logic for validating CharField ] if isinstance(f, models.DecimalField): [ logic for validating DecimalField ] ...and so on and so forth. This means that any field subclasses that aren't created by the Django core team can't have their logic validated similarly. It seems like a better way to do this would be to have said logic be part of the field class itself. Why does models.CharField not have the code for how to determine whether a CharField instance has been instantiated properly? Same for DecimalField, FileField, and so on and so forth? This would then allow non-core fields to define that method and get the same validation. I've searched for this on Trac, but don't see a ticket about this. I also combed the documentation, but the issue isn't discussed. It's not clear to me whether or not I should be filing a ticket on Trac or sending a discussion to this list. I'd like to make this improvement if there'd be support for doing so, but I don't want to do the work only to be given an "in principle" no. Would this be something we would be willing to change, to allow non-core Field subclasses to be able to be validated during syncdb? Best Regards, Luke Sneeringer -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
