#23624: Regression in ManyToManyField with through, runtime-generated models
-------------------------------------+-------------------------------------
     Reporter:  ludoo                |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  1.7
  (models, ORM)                      |               Resolution:
     Severity:  Normal               |             Triage Stage:
     Keywords:                       |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Description changed by ludoo:

Old description:

> I admit my situation is a corner case: an app interfacing with a legacy
> db, where I need to extend an abstract model to contextualize it to
> identical tables, named differently (eg obj_1 table, obj_2 table, etc.),
> and to make things worse the number of tables is only known at runtime.
>
> I am then dynamically generating a module for each set of models, and
> while things work great in Django 1.6, in 1.7 ManyToManyField using a
> through model breaks.
>
> I am attaching a sample models.py file that illustrates the issue. I have
> not yet found the time to delve into what's happening, I hope someone
> with a better understanding of all the related stuff steps in as it's
> something I have never looked into.

New description:

 I admit my situation is a corner case: an app interfacing with a legacy
 db, where I need to extend an abstract model to contextualize it to
 identical tables, named differently (eg obj_1 table, obj_2 table, etc.),
 and to make things worse the number of tables is only known at runtime.

 I am then dynamically generating a module for each set of models, and
 while things work great in Django 1.6, in 1.7 ManyToManyField using a
 through model breaks.

 I am attaching a sample models.py file that illustrates the issue. I have
 not yet found the time to delve into what's happening, I hope someone with
 a better understanding of all the related stuff steps in as it's something
 I have never looked into.

 What happens is that the manager seems to ignore the through model, here
 is the traceback (actual call and models in the attached file):


 {{{
 Traceback (most recent call last):
   File "<console>", line 1, in <module>
   File "/home/ludo/Desktop/dev/venv/spritz/local/lib/python2.7/site-
 packages/django/db/models/manager.py", line 191, in all
     return self.get_queryset()
   File "/home/ludo/Desktop/dev/venv/spritz/local/lib/python2.7/site-
 packages/django/db/models/fields/related.py", line 887, in get_queryset
     return qs._next_is_sticky().filter(**self.core_filters)
   File "/home/ludo/Desktop/dev/venv/spritz/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 691, in filter
     return self._filter_or_exclude(False, *args, **kwargs)
   File "/home/ludo/Desktop/dev/venv/spritz/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 709, in _filter_or_exclude
     clone.query.add_q(Q(*args, **kwargs))
   File "/home/ludo/Desktop/dev/venv/spritz/local/lib/python2.7/site-
 packages/django/db/models/sql/query.py", line 1287, in add_q
     clause, require_inner = self._add_q(where_part, self.used_aliases)
   File "/home/ludo/Desktop/dev/venv/spritz/local/lib/python2.7/site-
 packages/django/db/models/sql/query.py", line 1314, in _add_q
     current_negated=current_negated, connector=connector)
   File "/home/ludo/Desktop/dev/venv/spritz/local/lib/python2.7/site-
 packages/django/db/models/sql/query.py", line 1138, in build_filter
     lookups, parts, reffed_aggregate = self.solve_lookup_type(arg)
   File "/home/ludo/Desktop/dev/venv/spritz/local/lib/python2.7/site-
 packages/django/db/models/sql/query.py", line 1076, in solve_lookup_type
     _, field, _, lookup_parts = self.names_to_path(lookup_splitted,
 self.get_meta())
   File "/home/ludo/Desktop/dev/venv/spritz/local/lib/python2.7/site-
 packages/django/db/models/sql/query.py", line 1383, in names_to_path
     self.raise_field_error(opts, name)
   File "/home/ludo/Desktop/dev/venv/spritz/local/lib/python2.7/site-
 packages/django/db/models/sql/query.py", line 1389, in raise_field_error
     "Choices are: %s" % (name, ", ".join(available)))
 FieldError: Cannot resolve keyword u'a' into field. Choices are: a_s, id,
 name

 }}}

--

--
Ticket URL: <https://code.djangoproject.com/ticket/23624#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.ea74ddf97e7746c4945f3d2db096b422%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to