On 08/18/2014 02:03 PM, Anssi Kääriäinen wrote: > As for changing ForeignKey to virtual field plus concrete field > representation - I just realized this will be backwards incompatible no > matter what we do regarding categorization. An all-fields including > get_fields() call will return separate author (virtual) and author_id > (concrete) fields after the split. I am not sure what we can do about > this. It would be very unfortunate if we can't refactor the way > ForeignKeys work due to the meta API. Any ideas how we can avoid the > backwards compatibility trap?
Excuse me if I misunderstood the issue being discussed, but is it not viable to (in some situations) filter out the fields that are present in to_field of ForeignKeys? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/53F1E470.8060805%40gmail.com. For more options, visit https://groups.google.com/d/optout.
