On Aug 15, 8:53 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > 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.
The point is, using terms that are agreed upon. My idea was using UML terms, which is a standard in OO modeling, the same way as ForeignKey is used, which is a term from ER modeling. I don't know what you tried by comparing UML to COBOL, but I'm not even going further on this because... > 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. ... you're right, I forgot that the term is used in other context for the ORM already. Anyway, I insist on using known, widespread terms for this as possible. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
