Martin Maney wrote:
> On Sat, Aug 15, 2009 at 10:45:44AM -0700, hcarvalhoalves wrote:
>> 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"
>
> +0.9
>
> I found the "association" style both unfamiliar and, frankly, a bit
> precious, but this is brilliant. I especially like the way it gives an
> explicit name to the most important aspect of it: whether FK
> dependencies cause an entity's deletion to propagate recursively or
> not.
> Well, that part is brilliant. I think you're simply wrong about that
> error case:
If this is a response to my comment that "This eliminates the
possibility of RESTRICT... when null=True or default=xxx", then...
> without overriding the defaults, null=False and
> default=None, you have the second case, and should get RESTRICT
> behaviour. And as Russ (I think it was) pointed out, if a default
> value is given the null setting doesn't matter. So in a compressed
> logic table form:
>
> PoD default null default action
> T * * CASCADE
> F <value> * SET DEFAULT
> F none T SET NULL
> F none F RESTRICT
>
...I already understood what you say here. What I meant was, with the
other suggested notations, it is possible to use RESTRICT even with
foreign keys that have null=True and/or default=xxx; with this notation,
it is not. I think that's a bad thing. While I agree that this notation
has a certain elegance to it, it also limits the available options more
than the other suggested notations--too much, in my opinion. I fail to
see how it's an improvement on, say:
ForeignKey(..., on_delete=PROPAGATE)
CASCADE
ForeignKey(..., on_delete=SET_VALUE, null=True)
SET NULL
ForeignKey(..., on_delete=SET_VALUE, default=xxx)
SET VALUE
ForeignKey(..., on_delete=PROTECT)
RESTRICT
This is both at least as explicit as and more flexible than your example
above. (Note that I used on_delete=PROPAGATE instead of
on_delete=CASCADE, which is what I originally suggested, simply to match
your use of the term "propagate" in your example above).
Mike
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
