same code runs on two machines and barfs on the third

[kenneth gonsalves]

hi,

this is the relevant part of my model:

class Team(models.Model):
name = models.CharField(_("Team Name"),max_length=150,unique=True)
members =
tournament = models.ForeignKey(Tournament)

in my view I have the following line of code:
cr = Team.objects.filter(tournament_id=tournid)

I have three installations of this app. All have the latest trunk (all
the same version). The only difference between the three is that one is
on Fedora 14, one on Fedora 15 and one on Fedora 16. Deployment is the
same. All are on python 2.7 with slightly differing versions of
postgresql. On Fedora 14 and 16 the code runs ok. On Fedora 15, django
barfs saying:
'cannot resolve tournament_id into a field, fields available are: name,
tournament ...'

any clues?
--
regards
Kenneth Gonsalves

[Babatunde Akinyanmi]

Perhaps you made a change to a model and forgot to syncdb on your
Fedora 15 machine.....

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

--
Sent from my mobile device

[kenneth gonsalves]

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.....

no
--
regards
Kenneth Gonsalves

[Mike Dewhirst]

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. Ask me how I know.

Good luck

Mike

[kenneth gonsalves]

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
Altitude: two of the machines are at 7200 feet above sea level, but the
offending machine is at 3400 feet.

> Ask me how I know.

how?
--
regards
Kenneth Gonsalves

[akaariai]

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.

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...

- Anssi

[kenneth gonsalves]

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 ;-)
--
regards
Kenneth Gonsalves

[akaariai]

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

[kenneth gonsalves]

I finally deleted the whole django-trunk and made a fresh svn checkout.
Then it works. Must have been some stale .pyc file or some file got
corrupted.
--
regards
Kenneth Gonsalves