Ticket #12760 is no dublicate
kanu
My Ticket http://code.djangoproject.com/ticket/12760 Titled : "related
models with Foreignkey.null=True must not get deleted on delete of
their relation" was marked as dublicate today.
I don't aggree that this is a dublicate. i filed this as a bug not a
feature request.
I am also relating to the django version 1.1 and not the svn.
I really think that it was intendet to not delete those relations.
e.g. the comments in CollectedObjects.add say :
# Nullable relationships can be ignored -- they are nulled out before
# deleting, and therefore do not affect the order in which objects
# have to be deleted.
Even if it is not a bug the code appears a little confusing.
Why is a relation updated and afterwards deleted ?
Please have a 2nd look into this.
best regards
-kanu
Karen Tracey
Hi,
My Ticket http://code.djangoproject.com/ticket/12760 Titled : "related
models with Foreignkey.null=True must not get deleted on delete of
their relation" was marked as dublicate today.
I don't aggree that this is a dublicate. i filed this as a bug not a
feature request.
The fact that you do not like the existing behavior does not make it a bug. There have been fairly extensive discussions on this list and in tickets on this subject; I'm reasonably certain from those that the existing behavior is in fact intentional. Many people don't like it. Supporting other behaviors is a feature request, already tracked by another ticket.
I really think that it was intendet to not delete those relations.
e.g. the comments in CollectedObjects.add say :
# Nullable relationships can be ignored -- they are nulled out before
# deleting, and therefore do not affect the order in which objects
# have to be deleted.
Even if it is not a bug the code appears a little confusing.
Why is a relation updated and afterwards deleted ?
From my reading of that comment, it doesn't imply the objects won't be deleted. The code here appears to be concerned with generating the list of objects to be deleted in the appropriate order, and these don't affect the order. That's why they can be ignored here. I'd guess the nulling and then deleting in the "right" order is to enable deletions that would otherwise trigger integrity errors on some DBs, but I don't know enough about this code to say for sure.
If you read through the related tickets I think you'll find suggestions for how to accomplish what you are looking for without actually requiring that it be implemented in the base.
Karen
Luke Plant
> My Ticket http://code.djangoproject.com/ticket/12760 Titled :
> "related models with Foreignkey.null=True must not get deleted on
> delete of their relation" was marked as dublicate today.
>
> I don't aggree that this is a dublicate. i filed this as a bug not
> a feature request.
This 'bug' has been reported various times, and it depends on your
point of view whether it is a bug or not. There are certainly cases
where the opposite would be a bug. Consider, for instance, this
model:
class Employee(Model):
boss = ForeignKey('self', null=True)
The semantics of this model might include the idea that employees with
boss == NULL are directors. Now, if we delete employee e1 who happens
to be the boss of employee e2, and just null out e2.boss, we have
promoted e2 to being a director, which is not intended.
So this is a feature request, and on your bug, I linked to the most
recent, open bug covering it.
> I really think that it was intendet to not delete those relations.
> e.g. the comments in CollectedObjects.add say :
> # Nullable relationships can be ignored -- they are nulled out
> before # deleting, and therefore do not affect the order in which
> objects # have to be deleted.
>
> Even if it is not a bug the code appears a little confusing.
> Why is a relation updated and afterwards deleted ?
Karen is right, it allows mutually related data to be deleted without
causing an integrity error in the absence of transactions:
class A(Model):
b = ForeignKey(B)
class B(Model):
a = ForeignKey(A, null=True)
By noticing the null=True, we can null out B.a, then delete the A
object, then the B object, all without requiring a transaction.
CollectedObjects uses this logic to decide that the correct order of
deletion is A,B. Another part of the code actually does the nulling
out and deleting.
Hope that explains it, sorry if the message was rather brief, but this
has come up several times before and we can't explain it every time.
Cheers,
Luke
--
"Where a person wishes to attract, they should always be ignorant."
(Jane Austen)
Luke Plant || http://lukeplant.me.uk/
kanu
I didn't recognize the "first update and then delete" thing as a
safety method.
Hopefully future versions of django will have mechanics to handle the
on delete behaviour.
Still it is hard to belief, that you have less problems with auto-
deleting of relations than you
would have with auto-nulling. Predelete-Signals would be a sufficient
mechanic to
accomplish a on delete cascade. On the other hand its quite
complicated to overwrite the delete of
django.contrib models e.g. if you have a foreignkey to the user model.
> class Employee(Model):
> boss = ForeignKey('self', null=True)
>
> The semantics of this model might include the idea that employees with
> boss == NULL are directors. Now, if we delete employee e1 who happens
> to be the boss of employee e2, and just null out e2.boss, we have
> promoted e2 to being a director, which is not intended.
>
I favor a wrong assinged employee over a flushed table. I think thats
what happens if you
delete the (single) director.
> Hope that explains it, sorry if the message was rather brief, but this
> has come up several times before and we can't explain it every time.
I can only imagine how often you need to repeat your selfs. And I
appreciate your patience
very much.
best regards
-kanu