hcarvalhoalves wrote:
> On Aug 14, 11:48 pm, Russell Keith-Magee
> <freakboy3...-re5jqeeqqe8avxtiumw...@public.gmane.org>
> wrote:
>> On Sat, Aug 15, 2009 at 8:09 AM,
>> hcarvalhoalves<hcarvalhoal...-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote:
>>
>>> On Aug 13, 9:30 am, Russell Keith-Magee
>>> <freakboy3...-re5jqeeqqe8avxtiumw...@public.gmane.org>
>>> 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"
This eliminates the possibility of CASCADE when null=True or default=xxx
are specified, which I think goes to far. I prefer either
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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
