Hey Luke - Yup, this is indeed a problem. It's actually the subject of a Summer of Code proposal [1], so if you can wait there's a good chance that you won't have to do any work yourself :)
Jacob [1] https://groups.google.com/forum/#!msg/django-developers/e0-rOIkrXaQ/w5aiW_R6aFYJ On Sat, May 18, 2013 at 2:26 PM, Luke Sneeringer <[email protected]> wrote: > 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. > > -- 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.
