On Feb 8, 11:27 am, kenneth gonsalves <law...@thenilgiris.com> wrote:
> On Wed, 2012-02-08 at 00:15 -0800, akaariai wrote:
> > On Feb 8, 9:15 am, kenneth gonsalves <law...@thenilgiris.com> wrote:
> > > On Tue, 2012-02-07 at 19:29 +1100, Mike Dewhirst wrote:
> > > > On 7/02/2012 6:14pm, kenneth gonsalves wrote:
> > > > > On Tue, 2012-02-07 at 08:06 +0100, Babatunde Akinyanmi wrote:
> > > > >> Perhaps you made a change to a model and forgot to syncdb on
> > your
> > > > >> Fedora 15 machine.....
>
> > > > When you have eliminated all the possibilities what remains must
> > be
> > > > the
> > > > problem :)
>
> > > > The trick is to confirm your assumptions one by one.
>
> > > code: all three machines are running code pulled from the same repo.
> > > django version: all three are on r 17461
> > > database: the table structure on all three is identical. (in fact
> > two
> > > machines have the same data also). Postgresql versions differ, but
> > this
> > > is a django error - not a database error.
> > > The offending line of code worked fine on the F15 machine when it
> > was
> > > running F14
>
> > Most likely, for some reason, the offending machine's definition is
> > missing the tournament field in the models.py file.
>
> field is there. instead of:
>
> cr = Team.objects.filter(tournament_id=tournid)
>
> I do:
> tourn = Tournament.objects.get(pk=tournid)
> cr = Team.objects.filter(tournament=tourn)
>
> it works on the offending machine.
>
>
>
> > Anyways double-check that the offending machine is really using the
> > same version of the project's code than the other machines. Check
> > especially carefully the models.py file containing the Team model
> > definition. To see that you are really using the file you think you
> > are, put an assert(False) just before the Team model definition on
> > your offending machine. This should make the project totally non-
> > functional on that machine (easy way to see that yes, the change had
> > an effect => this file is really in use). Of course, if this is a
> > production machine, don't do the assert trich. Use logging instead.
>
> > If the model is double-checked correct, and the assert is raised, then
> > we have a more complex problem...
>
> model is correct. Database is correct - we have a more complex
> problem ;-)
Can you run
print Task._meta.get_fields_with_model()
print Task._meta.get_field_by_name('tournament')
print Task._meta.get_field_by_name('tournament').attname
on the offending server and provide the output?
- Anssi
--
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.
