Opened 11 years ago
Closed 11 years ago
#21434 closed Bug (fixed)
IN clause not supporting the to_field
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.5 |
Severity: | Normal | Keywords: | |
Cc: | Baptiste Mispelon | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I think this is similar to bug 17972.
If I have a model defined:
class VolumeTemplate(models.Model): parent = models.ForeignKey( 'Volume', null=True, blank=True, to_field='uuid', related_name='parent_templates') class BracketVolume(models.Model): uuid = UUIDField(version=4, auto=True, db_index=True, unique=True)
The following query returns an empty result set, even if the parent is non None:
queryset = Volume.objects.all() VolumeTemplate.objects.filter(parent__in=queryset)
However the following will return the corresponding VolumeTemplates:
VolumeTemplate.objects.filter(parent__pk__in=queryset)
This is because the subquery generated by the IN clause does not take the to_field into consideration and instead returns a list of Volume.id values instead of Volume.uuid values. The SQL is comparing the parent_id which is a UUID field due to the to_field.
Change History (1)
comment:1 by , 11 years ago
Cc: | added |
---|---|
Component: | Uncategorized → Database layer (models, ORM) |
Resolution: | → fixed |
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
Hi,
I can indeed reproduce the issue on the 1.5 branch, using the two following models:
With these models, the following code shows the issue:
assert Bar.objects.filter(foo__in=Foo.objects.all()).count()
(this requires having created one model of each kind in the database).Having this code, I was able to track down the commit that fixed this issue in the master branch (also present in 1.6, as it turns out): 97774429aeb54df4c09895c07cd1b09e70201f7d.
Seeing as this issue is not a regression (and therefore its fix is unlikely to get backported), I'm going to mark this ticket as
fixed
.Feel free to reopen the ticket if you think otherwise of course.
Thanks for your report.