Russell Keith-Magee wrote: > On 3/9/06, Luke Plant <[EMAIL PROTECTED]> wrote: > > > > On Tuesday 07 March 2006 14:49, Russell Keith-Magee wrote: > > > > > > > 3) What is to become of the _id fields for ForeignKeys? > > > > 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. > > Understood. As an added bonus, I now understand what you were getting > at with your lazy object talk earlier in this thread, and now that I > understand, I rather like the idea. Like you said, there are a few > details to work out, but with some creative property handlers it > should be possible, could be quite elegant, and would get rid of the > _id/.id schism (which still bugs me at an aesthetic level).
The problem comes with throwing exceptions (since we agreed there should be an exception for non null foreign keys). If the object returned by article.reporter is lazy, then we can indeed do article.reporter.id without a db lookup, but *not* if we want accessing article.reporter to throw an exception for non-existant objects. Instead, you would have to do 'article.reporter.name' before you get a DoesNotExist error. I don't like the sound of that - the usefulness of the exception goes down since you don't know when it is going to get thrown, or you have to do strange things to force the exception. If you go for lazy objects, I think you have to scrap the DoesNotExist error for these lookups. Instead, I think the lazy object would have to *behave* like 'None'. That is, you can test for existance by doing 'if (article.reporter)', and you get AttributeError if you try to access it's fields when the object doesn't exist in the DB. We can implement the 'if article.reporter' behaviour by overriding __nonzero__. However, having an object that behaves like None, but isn't, is problematic. If people can do 'if article.reporter', they might expect to be able to do 'if article.reporter is not None', which won't work. I think it probably also makes introspection more tricky, and the interactive environment less useful, since you have a proxy and not the real thing. I agree that having both .reporter_id and .reporter.id is ugly. However, at some point you have to draw a line and own up to the (ugly) reality of the database and performance concerns, and I think that this is the most useful and practical place to draw that line. (Of course, I'm still ready to persuaded, but these are my arguments against the lazy object idea). > However, nobody has commented on my revised 'commit ForeignKey changes > immediately' idea (i.e., make SQL calls to modify ForeignKeys as soon > as add/clear is called, in the same way that they are for m2m fields). > Does anyone want to comment on this, or is the idea really _that_ bad? I haven't had time to think this through, but I think I like it. If I'm thinking correctly, the tradeoff is between buginess and performance i.e. if you add an object, your proposed behaviour means you don't have to remember that for *this* type of 'add()', you have to do a save() on the *object you added*. The cost is you could get duplicate saving if you don't know about the behaviour of add(). But I think the consistency and reliability you gain is worth it. Luke --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
