Opened 18 years ago
Closed 17 years ago
#3369 closed (duplicate)
reverse caching of foreign keys
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Keywords: | ||
Cc: | ferringb@… | Triage Stage: | Design decision needed |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
It would be nice if Django were to cache the reverse value of foreign keys when they're looked up. That might not be entirely clear, so let me give an example:
class Company(Model): name = models.CharField(maxlength=100) class Employee(Model): company = models.ForeignKey(Company) c = Company.objects.all()[0] e = c.employee_set.all()[0] # e now really must have a company of c... there's no reason it wouldn't be c e.company # accesses the database
I tried implementing this, but got lost in some of the model code. My approach was to use an auto_cache 'filter' for QuerySets. The above code would look like this:
c = Company.objects.all()[0] e = c.employee_set.auto_cache(company=c).all()[0] e.company # no database accesses
Which eventually I would have made automatic for all sets. I got far enough to realize that each foreign key will potentially query the database even after an attribute has explicitly been assigned. For example:
c = Company.objects.all()[0] e = c.employee_set.all()[0] new_company = Company() e.company = new_company e.company == new_company # database accesses for e.company and not equal to the new object
I'd love to see a feature like this, so if it's not something that you all want to implement, point me in the right direction.
Attachments (2)
Change History (9)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
Component: | Uncategorized → Database wrapper |
---|---|
Owner: | changed from | to
Triage Stage: | Unreviewed → Design decision needed |
Ah, a idea like this should be brought up on the developers list. I like it! Can you do, please?
by , 18 years ago
Attachment: | patch_1.diff added |
---|
comment:3 by , 18 years ago
Has patch: | set |
---|---|
Needs documentation: | set |
Patch needs improvement: | set |
I've implemented it. I'm going to work on making it automatic now, but the auto_cache part works. I'm attaching a patch.
by , 18 years ago
Attachment: | patch_2.diff added |
---|
comment:4 by , 18 years ago
Needs documentation: | unset |
---|---|
Patch needs improvement: | unset |
Patch 2 makes it automatic. With review this should be ready to add into the trunk. It seems to work very nicely.
follow-up: 7 comment:5 by , 18 years ago
Cc: | added |
---|
Examples provided in patch2 makes me suspect this is more generally provided by ticket #17... correct assumption?
comment:6 by , 18 years ago
They're not exactly the same thing, but I think the fixes to #17 would fix this as well.
comment:7 by , 17 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Replying to Brian Harring <ferringb@gmail.com>:
Examples provided in patch2 makes me suspect this is more generally provided by ticket #17... correct assumption?
Yes. Closing this in favor of #17.
Sorry, that last bit was wrong. It should have been as follows:
So I guess that the reason that e.company isn't being updated is because the foreign key is equal to c's primary key. It appears to work fine in other cases, though.
It seems that this aspect of it could either be considered a 'feature' or a 'bug'. Either functionality seems to be right in some sense, but for the auto_cache to work it would have to be a bug.