i just wanted to spark some discussion of #3369. i implemented it and
would like to see it get included.
here's an example of what reverse caching of foreign keys would mean:
b = Blog.objects.get(id=1)
for entry in b.entry_set.all():
entry.blog # No database access required.
currently each item in the list would require a database access (which
isn't needed).
the one controversial change that i made is this. when you assign a
value for a foreign key association, django sets the value, and clears
it's cache. so this:
entry = Entry.objects.get(id=1)
blog = Blog.objects.get(id=1)
entry.blog = blog
entry.blog is blog # false
entry.blog == blog # maybe true, maybe false
is how things work currently. to some extent this makes sense. the
entry hasn't been saved, so the value in the database is still
potentially some other value. to me it makes more sense to update the
cache rather than clearing the cache. my changes do just that, so the
way it works is:
entry = Entry.objects.get(id=1)
blog = Blog.objects.get(id=1)
entry.blog = blog
entry.blog is blog # true
entry.blog == blog # true
doing this made implementing the reverse caching easier. all tests
still pass, and i doubt it is something that anyone using django would
notice. updating the cache is the way that i (and i imagine others)
would expect things to work.
so i hope that people like the reverse caching idea (the main point of
this post) and don't mind the small implication that it has on other
parts of django.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
