On Jun 2, 2009, at 2:07 AM, Karen Tracey wrote: > On Sun, May 31, 2009 at 11:40 PM, Eric Abrahamsen <gir...@gmail.com> > wrote: > > On May 31, 2009, at 11:45 PM, Karen Tracey wrote: > >> On Sun, May 31, 2009 at 10:13 AM, Eric Abrahamsen >> <gir...@gmail.com> wrote: >> >> Hi, >> >> I've got two models, Author and Entry, with a foreignkey from Entry >> to >> Author. There are many Authors with no related entries, and until >> recently I've been able to put this manager on the Author model to >> only select Authors with Entries: >> >> def contributors(): >> return self.exclude(entry__isnull=True) >> >> Recently this started returning a FieldError, saying it could not >> resolve "entry" into a field. >> >> What changed? Did you update Django? Change your code? Something >> must have changed, and if you could identify it, that would be a >> clue. >> [snip] > > I identified the commit in my own code that blew things up (thanks > to my excellent version-tracking habits, it's a pretty large and > tangled commit). This commit touches neither the Author nor the > Entry model, it's got: > > Two new models, one called Sample with a ForeignKey to Author, one > called TranslatorProfile with a OneToOneField to Author (no related > names on either). > > ModelForms for both of these new models. I also moved two existing > modelforms to a different place in the file. > > I'm putting the diff file into dpaste here: http://dpaste.com/ > 49912/, in case anyone's got the patience to look at it. That's a > diff between -r301, which works, and working copy, which doesn't. > The whole models.py file (broken working copy) is here: > http://dpaste.com/49913/ > > The only other possibly relevant thing I can think of is that > Entries also have a ManyToMany to Authors. An Entry is written by an > Author (the ForeignKey), but can also be "about" some unspecified > number of Authors. The ManyToMany has a related name on it, the > ForeignKey doesn't, but changing that doesn't fix the code, and > besides it has been working fine like that up until now. > > > Identifying the commit is a good first step, next would be to > identify which part of the commit caused the break. (Even though it > doesn't seem like any part of that commit should have caused the > break. But it did, so you need to narrow it down to what exact part > of the commit in order to possibly figure out why.) > > Playing around with your models file and reducing it to the > essentials to recreate the problem reveals it's the new SampleForm. > Sample also has a ForeignKey to Author, one with a limit_choices_to > depending on a field in Author. Having that limit_choices_to AND > defining the SampleForm before the Entry model apparently results in > an incomplete Author model. I've opened #11247 to track this. In > the meantime, moving all ModelForm definitions out of the models > file (or at least after all model definitions) avoids the problem.
Holy crow, this is simultaneously genius on your part, and also something I should have been able to figure out (or at least pinpoint) on my own :) Thanks enormously for the solution – moving all model forms to the bottom of the file did the trick, and I'll keep an eye on that ticket. Thanks for getting me past this. Eric > > Karen > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
