On Sat, Aug 15, 2009 at 10:46 PM, Michael Glassford<glassfo...@gmail.com> wrote: > > Russell Keith-Magee wrote: >> On Sat, Aug 15, 2009 at 10:57 AM, Michael Glassford<glassfo...@gmail.com> >> wrote: >>> Russell Keith-Magee wrote: >>>> On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves<hcarvalhoal...@gmail.com> >>>> wrote: >>>>> On Aug 13, 9:30 am, Russell Keith-Magee <freakboy3...@gmail.com> >>>>> wrote: >>>>>> On Thu, Aug 13, 2009 at 12:04 AM, Michael >>>>>> Glassford<glassfo...@gmail.com> wrote: >>>>>> >>>>>> Secondly: I'm sensitive to the extent that 'on delete cascade' et al >>>>>> are phrased in SQL specific terms. I fully acknowledge the use case - >>>>>> what happens to a FK when the object it points to is deleted - but I >>>>>> want to make sure that we phrase it in a way that makes sense with >>>>>> non-SQL backends. Have you had any thoughts about this? >>>>> Maybe using the UML terms to declare these associations, as it makes >>>>> sense in an ORM environment, and is not SQL specific. >>>>> >>>>> ForeignKey(composition=True) >>>>> Strong association -> relates to SQL's CASCADE or similar behavior on >>>>> custom backends >>>>> >>>>> ForeignKey(aggregation=True) >>>>> Weak association -> relates to SQL's SET_NULL or similar behavior on >>>>> custom backends >>>>> >>>>> ForeignKey(restrict=True) >>>>> Optional restrict to raise Exception on delete -> relates to SQL's >>>>> RESTRICT >>>> This is an interesting idea - it's nicely object-based, and it gets >>>> around the SQL-specific terminology. However, it does introduce some >>>> nasty term-overloading with the phrase "aggregation". >>>> >>>> However, the 'strong/weak' distinction is an interesting starting >>>> point for some language. A proposal: >>>> >>>> ForeignKey(XXX, association=STRONG) >>>> - The current arrangement, equivalent to SQL ON DELETE CASCADE >>>> >>>> ForeignKey(XXX, association=WEAK, null=True) >>>> - The equivalent of SQL ON DELETE SET NULL >>>> >>>> ForeignKey(XXX, association=WEAK, default=xxx) >>>> - The equivalent of SQL ON DELETE SET DEFAULT >>>> >>>> ForeignKey(XXX, association=PROTECTED) >>>> - The equivalent of SQL ON DELETE RESTRICT. Deletion is prevented. >>>> >>>> For completeness: >>>> >>>> ForeignKey(XXX, association=WEAK) >>>> >>>> would be an error, since the field doesn't allow NULLs, but an >>>> alternate default value hasn't been specified. >>>> >>>> Opinions? >>> I think more people would understand the on_delete= than the >>> association= terminology without having to look it up; but I'd have no >>> problem implementing it this way if it's what gets decided on. >> >> Are you saying that a user who discovers on_delete=PREVENT in a model >> won't need to do exactly the same thing? What does PREVENT mean? It >> doesn't have an SQL equivalent - what is going to be prevented? > > True, they would have to look up PREVENT, but probably not CASCADE, > SET_NULL, or SET_DEFAULT. > >> If you want to argue that association=STRONG et al is a bad conceptual >> abstraction, thats fine. However, I won't accept the argument that >> on_delete=CASCADE is better because it is somehow renders the user >> immune from a need to read documentation. We _want_ users to read the >> documentation on a feature before they use it. We _want_ to break the >> assumptions they might bring with regard to SQL implementations. > > I'm not really arguing in favor of it, just mentioning that more people > will be familiar with the on_delete concept. At this point I don't have > a strong preference for either method over the other. I do think I would > prefer either method to nothing at all. > > One more question that occurred to me this morning is, what would this do: > > ForeignKey(XXX, association=WEAK, null=True, default=xxx) > - Is this the equivalent of SET NULL or SET DEFAULT?
SET DEFAULT. The SET-equivalent options are based entirely on the value of `default`. The `null` argument doesn't affect this feature. SET NULL is just the special case when you (implicitly or explicitly) have default=None. Keep in mind that: ForeignKey(XXX) is actually an implicit version of: ForeignKey(XXX, default=None) but if you have default=None, you'd better have null=True as well, or else you're going to get validation errors (since null=False is the implicit setting). Yes, this does mean you can't specify a default but have FK's reset to NULL. However, to my mind, that's what a default means. Again - we're not trying to reproduce SQL here, we're trying to come up with an object model that makes sense. Yours, 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
