On Oct 21, 4:31 am, David De La Harpe Golden
wrote:
>
> Hmm. Appears to work okay for me (only tested Django-1.1.2), at least
> for instance.delete(). Perhaps you could try the operation directly at
> ./manage.py shell to see if there's anything odd going on:
>
Found the problem - I had overri
On 21/10/10 08:22, shacker wrote:
> Thanks David, but I'm not sure I'm getting this. I've added that line
> to the class, but it doesn't give me cascade delete behavior (I can
> still delete a row and the comments linked to it remain in the db). Is
> there something else I need to do?
Hmm. Appe
On Oct 19, 9:42 am, David De La Harpe Golden
wrote:
>
> So to get deletion behaviour you want, you need to define a reverse
> generic relation back to comment on your model for django's deletion
> cascade to follow the deletion in the generic case. On your own models,
> this is of course straig
On 19/10/10 17:16, shacker wrote:
> If Django comments are attached to a record (like a news item) and
> that item is deleted, the comment remains in the database. In other
> words, comments don't get cascade delete treatment like foreign key
> relationships do.
The django comments contrib uses t
One possibility is to add a post-delete signal which listens for
instances of news items and uses the content type to clean up comments
with that content type and primary key.
I'm pretty sure this isn't considered a bug, but I couldn't address
the issue of whether it was a planned part of the desi
If Django comments are attached to a record (like a news item) and
that item is deleted, the comment remains in the database. In other
words, comments don't get cascade delete treatment like foreign key
relationships do. This leads to A) database clutter and B) breakage
when you do things like loop
6 matches
Mail list logo
