Django

Code

Ticket #3369 (closed: duplicate)

Opened 2 years ago

Last modified 1 year ago

reverse caching of foreign keys

Reported by: wbyoung@mcdonogh.org Assigned to: nobody
Milestone: Component: Database layer (models, ORM)
Version: SVN Keywords:
Cc: ferringb@gmail.com Triage Stage: Design decision needed
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

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

patch_1.diff (4.0 kB) - added by wbyoung@mcdonogh.org on 01/26/07 13:14:13.
patch_2.diff (5.5 kB) - added by wbyoung@mcdonogh.org on 01/26/07 14:03:39.

Change History

01/26/07 00:42:56 changed by wbyoung@mcdonogh.org

  • needs_better_patch changed.
  • needs_tests changed.
  • needs_docs changed.

Sorry, that last bit was wrong. It should have been as follows:

c = Company.objects.all()[0]
e = c.employee_set.all()[0]

e.company = c
e.company is c # database accesses for e.company and not equal to the new object

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.

01/26/07 02:00:13 changed by Michael Radziej <mir@noris.de>

  • owner changed from jacob to adrian.
  • component changed from Uncategorized to Database wrapper.
  • stage changed from Unreviewed to Design decision needed.

Ah, a idea like this should be brought up on the developers list. I like it! Can you do, please?

01/26/07 13:14:13 changed by wbyoung@mcdonogh.org

  • attachment patch_1.diff added.

01/26/07 13:14:29 changed by wbyoung@mcdonogh.org

  • needs_better_patch set to 1.
  • has_patch set to 1.
  • needs_docs set to 1.

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.

01/26/07 14:03:39 changed by wbyoung@mcdonogh.org

  • attachment patch_2.diff added.

01/26/07 14:04:53 changed by wbyoung@mcdonogh.org

  • needs_better_patch deleted.
  • needs_docs deleted.

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 ) 06/02/07 23:07:40 changed by Brian Harring <ferringb@gmail.com>

  • cc set to ferringb@gmail.com.

Examples provided in patch2 makes me suspect this is more generally provided by ticket #17... correct assumption?

06/03/07 09:32:28 changed by wbyoung@mcdonogh.org

They're not exactly the same thing, but I think the fixes to #17 would fix this as well.

(in reply to: ↑ 5 ) 09/16/07 11:13:51 changed by ubernostrum

  • status changed from new to closed.
  • resolution set to duplicate.

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.


Add/Change #3369 (reverse caching of foreign keys)




Change Properties
Action