On 3/7/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > Russ, I can't thank you enough for your work on this stuff. Half > these edge cases I wouldn't have even thought of 'til they bit me in > the ass -- I really appreciate it :)
More than welcome. Being on the other side of the world makes keeping up with IRC discussions on big API changes a little difficult, so nutting out annoying details and fixing bugs is often the most productive thing I can do :-) > > I propose that: 'Article.reporter_set = X' be allowed, where X is any > > Which "feels right" to me. Looks like this is the way most people are falling. > My reasoning is that if I do:: > > article.reporter_id = some_non_existant_id > print article.reporter > > I should get an exception, but if I construct a Article with an empty > (i.e. None) reporter_id, I should get None. Ok - this introduces an additional use case that I hadn't considered; I was thinking that if _id was going away, then article.reporter = r1 would be the only way to assign a related object., in which case the only occasion for DoesNotExist would be retrieving a null=False field before it was assigned. However, if _id is sticking around, then obviously you can provide a broken ID. But how do you determine if an ID is invalid? Trunk/existing MR doesn't bork until save() if you provide a non-existent ID, and short of a DB lookup, I can't see any way to easily establish whether an ID is invalid. > > 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 other thing that concerns me about retaining _id is DRY. What takes precedence during commit to the database? Alternatively, which of the two is canonical - the value of article.reporter.id, or the value of article.reporter_id? > > 4) Reverse descriptors and save() have an interesting relationship. > [snip] > > a) make add()/remove()/clear()/__set__ implicit save points. This > > Like hugo, I like this approach, and for all the same reasons he > gave. However, I'd say I'm +0.9 -- if there's a better solution I'd > like to have it, but damned if I can think what it might be. What about the 'immediate commit' option I mentioned in response to Malcolm? i.e., take the SQL table update for ForeignKey and OneToOneField out of object.save(), and made part of the descriptor, so a1.reporter = r1 is immediately applied to the database, with regular numeric, text fields etc applied at the save(). This makes ForeignKey and OneToOneField behaviour exactly analogous to ManyToMany fields, and removes the need to cascade/implicit save the entire object. The only potential problem I can see with this approach is that objects would need to be saved before being added as related objects, which could lead to some interesting bootstrapping problems on circular references that might require transactions to resolve. Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
