Consistent contribute_to_class's virtual_only

[German M. Bravo]

I needed to create a field like class for my django project and I wanted it to be a virtual field... virtual_only is there for that reason, but my field was inheriting from FileField, and FileField.contribute_to_class() doesn't take virtual_only and so it doesn't passes it to Field.contribute_to_class(). I believe passing virtual_only attribute should be consistent across the source code. I'm attaching a simple patch to fix this. One warning would be for custom fields made by users which have their own contribute_to_class (those will need to be changed to properly receive the virtual_only parameter as optional.)

[Tim Graham]

Would it be better to simply accept and pass on **kwargs? I think that would eliminate the minor backwards compatibility concerns as well.

[ANUBHAV JOSHI]

IMO what is done is better, because

In the contribute_to_class in Field class:

def contribute_to_class(self, cls, name, virtual_only=False)

If from subclass:

super(AutoField, self).contribute_to_class(cls, name, **kwargs)

There is only virtual_only as keyword argument, if we pass **kwargs then it will be possible to pass any other variable to it as well, which is wrong I believe.

[Mitar]

GeoDjango is also missing virtual_only in their fields: ​https://github.com/django/django/blob/master/django/contrib/gis/db/models/fields.py#L213

[Mitar]

Opened pull request: ​https://github.com/django/django/pull/2946

[Tim Graham <timograham@…>]

In 1ed6fbcf44f0eebf29fd9b36be03bc5d73acee0a:

Fixed #21940 -- Added kwargs to contribute_to_class() of model fields..

Thanks Kronuz for the suggestion.

[Gavin Wahl]

Can this be backported to 1.6 and 1.7?

[Carl Meyer]

Definitely not 1.6, it's in security-fixes-only mode. And I don't think this meets the criteria in our ​https://docs.djangoproject.com/en/1.7/internals/release-process/#supported-versions backporting policy for backport to 1.7 either.