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? >> How would the equivalent of ON UPDATE be handled in this type of scheme, >> assuming it gets added at some point? > > What aspect of ON UPDATE are you looking to implement? It isn't > immediately obvious to me that ON UPDATE is a good idea, or one that > has a natural object-based interpretation. I agree that it's less important and less obviously useful than ON DELETE. I'll see if I can come up with a more compelling example, but the way we've mainly used it is to set a lot of our foreign keys to on_update=CASCADE. This is because the default SQL behavior when no ON UPDATE clause is specified is to RESTRICT. Mike --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
