On Aug 14, 11:48 pm, Russell Keith-Magee <freakboy3...@gmail.com> 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". >
This is UML, so anyone familiar with it understands Composition vs Aggregation. It doesn't help if the person doesn't know UML, of course, but I'm not just coming up with names of my own - it's an industry standard. OTH, WEAK and STRONG are terms used neither by SQL or UML, so I would be less in favor of using something like this. I only see two options: either use standard terms that appear in literature (hence my idea for UML terms), or phrase it in a way that makes very clear what happens. E.g.: ForeignKey(..., propagate_on_delete=True) CASCADE ForeignKey(..., propagate_on_delete=False, null=False) RESTRICT ForeignKey(..., propagate_on_delete=False, null=True) SET NULL ForeignKey(..., propagate_on_delete=False, default=XXX) SET DEFAULT ForeignKey(..., propagate_on_delete=False) Raises Exception, need to define either "null" or "default" I think it's a good middle-ground between the SQL-specific terms, Russ ideas, and making sense on the documentation from the ORM point of view. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
