On Tuesday 07 March 2006 14:49, Russell Keith-Magee wrote: > > > 3) What is to become of the _id fields for ForeignKeys? > > > > They need to stay around for efficiency; I'd like not to have to do > > a db hit just to find the id of something I've already got. Often > > in bulk-data-import situations you have the need to monkey with > > ids, and the few db hits the better. > > Isn't this covered by descriptor caching? One initial DB hit to get > the related object, and then all subsequent requests for the id come > from the cache. Or am I missing something here?
The thing you are missing is that often you only want the id, and you don't want to do that initial hit to get the related object at all. I have a number of use cases where this make a big difference. For example, I have a page list of objects which have related objects. The only thing I want to do with the related objects on that page is display a link to them, and I can construct their URLs using just the primary key. So using the id saves me dozens of queries on those pages. So I would be -1 on removing them, unless there was another way of getting the id without doing an extra db lookup. Luke -- "The only skills I have the patience to learn are those that have no real application in life." (Calvin and Hobbes) Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
