Michael Glassford wrote:
>
>
> hcarvalhoalves wrote:
>> On Aug 14, 11:48 pm, Russell Keith-Magee
>> <freakboy3...-re5jqeeqqe8avxtiumwx3w-xmd5yjdbdmrexy1tmh2...@public.gmane.org>
>> wrote:
>>> On Sat, Aug 15, 2009 at 8:09 AM,
>>> hcarvalhoalves<hcarvalhoal...-re5jqeeqqe8avxtiumwx3w-xmd5yjdbdmrexy1tmh2...@public.gmane.org>
>>> wrote:
>>>
>>>> On Aug 13, 9:30 am, Russell Keith-Magee
>>>> <freakboy3...-re5jqeeqqe8avxtiumwx3w-xmd5yjdbdmrexy1tmh2...@public.gmane.org>
>>>> wrote:
>>>>> On Thu, Aug 13, 2009 at 12:04 AM, Michael
>>>>> Glassford<glassfo...-re5jqeeqqe8avxtiumw...@public.gmane.org> 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"
Drat, my email client sent this before I was finished with it. I was
going to say:
This eliminates the possibility of RESTRICT (not CASCADE) when null=True
or default=xxx
are specified, which I think goes to far. I prefer either Russell
Keith-Magee's original suggestion:
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.
Or my original suggestion (using on_delete=CASCADE, SET_NULL,
SET_DEFAULT, PREVENT) or a modified version of my original suggestion to
make it more like the above by combining SET_NULL and SET_DEFAULT into a
single SET_VALUE (which would use default if available, otherwise would
set to None if null=True).
Drat
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
