On Sun, Aug 16, 2009 at 1:45 AM, hcarvalhoalves<hcarvalhoal...@gmail.com> wrote: > > 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.
Yes. However, I challenge you to point at a single other place in Django where UML notation or syntax is used. I'm sure COBOL has some great turns of phrase too - doesn't mean we'll use them. My issue isn't that Composition and Aggregation aren't good terms by themselves. My problem is that we already have Model.objects.aggregate() in the API, which has nothing to do with UML or cascading deletes. We need to avoid naming collisions like this. 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 -~----------~----~----~----~------~----~------~--~---
