id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 24317,"Deprecate field.rel, replace it with real field instances",Anssi Kääriäinen,nobody,"The problem is that when using get_fields(), you'll get either a field.rel instance (for reverse side of user defined fields), or a real field instance (for example ForeignKey). These behave differently, so that the user must always remember which one he is dealing with. This creates lots of non-necessary conditioning in multiple places of Django. For example, the select_related descent has one branch for descending foreign keys and one to one fields, and another branch for descending to reverse one to one fields. Conceptually both one to one and reverse one to one fields are very similar, so this complication is non-necessary. The idea is to deprecate field.rel, and instead add field.remote_field. The remote_field is just a field subclass, just like everything else in Django. The benefits are: - Conceptual simplicity - dealing with fields and rels is non-necessary, and confusing. Everything from get_fields() should be a field. - Code simplicity - no special casing based on if a given relation is described by a rel or not - Code reuse - ReverseManyToManyField is in most regard exactly like ManyToManyField The expected problems are mostly from 3rd party code. Users of _meta that already work on expectation of getting rel instances will likely need updating. Those users who subclass Django's fields (or duck-type Django's fields) will need updating. Examples of such projects include django-rest-framework and django-taggit. Very work-in-progress code available from https://github.com/akaariai/django/tree/virtual_rel_field",Cleanup/optimization,new,"Database layer (models, ORM)",dev,Normal,,,cmawebsite@… mmitar@…,Accepted,0,0,0,0,0,0