Relation query stops working when moving to Linux (from Mac)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Relation query stops working when moving to Linux (from Mac)

mrstone

I'm getting a strange error that I have not been able to sort out.

When moving my project to the production server the below query stops
working. (It works fine on Mac)

I noticed that using CamelCase in fieldnames is an issue when moving
code, but that doesn't seem to be the problem here.

Any other hints that could point me in any direction?


Thanks
Sten
....

qs = InfoProxy.objects.filter(info_locations__country_code =
where.country_code)

the related model:

class InfoLocation(models.Model):
    info_proxy = models.ForeignKey(InfoProxy,
db_column="info_proxy_id", related_name='info_locations')
    country_code = models.CharField(maxlength=2, db_index=True)


.....
The trace:

  File
"/usr/local/lib/python2.4/site-packages/django/db/models/query.py",
line 171, in iterator
    select, sql, params = self._get_sql_clause()

  File
"/usr/local/lib/python2.4/site-packages/django/db/models/query.py",
line 444, in _get_sql_clause
    joins2, where2, params2 = self._filters.get_sql(opts)

  File
"/usr/local/lib/python2.4/site-packages/django/db/models/query.py",
line 574, in get_sql
    joins2, where2, params2 = val.get_sql(opts)

  File
"/usr/local/lib/python2.4/site-packages/django/db/models/query.py",
line 622, in get_sql
    return parse_lookup(self.kwargs.items(), opts)

  File
"/usr/local/lib/python2.4/site-packages/django/db/models/query.py",
line 730, in parse_lookup
    joins2, where2, params2 = lookup_inner(path, lookup_type, value,
opts, opts.db_table, None)

  File
"/usr/local/lib/python2.4/site-packages/django/db/models/query.py",
line 831, in lookup_inner
    raise TypeError, "Cannot resolve keyword '%s' into field" % name

TypeError: Cannot resolve keyword 'info_locations' into field


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Relation query stops working when moving to Linux (from Mac)

Malcolm Tredinnick

On Fri, 2006-10-13 at 03:16 -0700, mrstone wrote:
> I'm getting a strange error that I have not been able to sort out.
>
> When moving my project to the production server the below query stops
> working. (It works fine on Mac)
>
> I noticed that using CamelCase in fieldnames is an issue when moving
> code, but that doesn't seem to be the problem here.
>
> Any other hints that could point me in any direction?

Are you using the same versions of Django on both machines? We fixed a
couple of bugs with related name lookups a couple of months ago, so if
you have some old source on the production server, this might be
tripping over it.

Another thing to look at is whether you are running that query before
you have finished importing the files containing InfoProxy and/or
InfoLocation. If so and you have suddenly switched to using, say,
mod_python, rather than the development server, you might find this
problem popping up. Basically, running queries against the models in the
global scope of a model file (so things that are going to be executed at
import time) will not work reliably (related to ticket #2438. It's
almost impossible to fix that problem, too, although I keep going back
to think about it from time to time). So don't run queries at the
file-level in model files.

If neither of those suggestions help and nobody else has better ideas,
maybe you could work out in more detail what the differences are between
the two systems. What Django versions are you using? What database
versions? What webserver and webserver interface on each system.
Basically, work out each difference. That might help identify where the
problem is. Failing that, start trimming the code down to the smallest
possible example that fails. Then we can examine it as a complete
example and working out what is going on.

Regards,
Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---