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. How would the equivalent of ON UPDATE be handled in this type of scheme, assuming it gets added at some point? 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 -~----------~----~----~----~------~----~------~--~---
