Re: Inappropriate behavior [was: Re: default delete() clear() behavior and you.]

[Kevin Howerton]

sorry.  my intention wasn't to make light of violence of any nature.
the image i posted was an actual ad for las vegas.  i just returned
from there (for the millionth time, i have family that live there..
not the biggest fan of vegas) ... and thus it was on my mind.  i will
contain my sardonic wit henceforth, as it clearly doesn't translate
well on the internet.

sorry again.

-k

On Tue, Apr 6, 2010 at 12:14 AM, Jacob Kaplan-Moss  wrote:
> On Mon, Apr 5, 2010 at 1:06 PM, Kevin howerton  
> wrote:
>> ps.  I didn't really murder a hooker in vegas
>
> This sort of "joke" is highly offensive, and isn't appropriate here.
> Frankly, I don't think it's appropriate *anywhere*, but I actually
> have some power to stop this sort of crap here, and I'm using it.
>
> Violence against women and sex workers is very real, and joking about
> it trivializes the very real pain of survivors. The image you posted
> could have been highly hurtful to those who've experienced violence;
> images and jokes about sexualized violence trigger painful memories.
>
> I recognize that you probably didn't intend to offend. Nevertheless,
> you did: I found your "joke" offensive and tasteless, and the image
> you posted more so. Discriminatory and exclusionary humor causes real
> pain and is not appropriate here.
>
> Jacob
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: default delete() clear() behavior and you.

[Florian Apolloner]

Hi,

On Apr 6, 12:19 am, Kevin Howerton  wrote:
> I only killed one hooker, but it was really small so I don't know if it 
> counts.
Hmmm…

> The problem with those patches though are that they don't appear
> (correct me if i'm wrong) to account for handling different deletes
> per reverse relation.  You really need to have a more granular
> approach.  If an object has two parents pointing at it; one with NULL,
> and one with a DEFAULT set... how would you be able to have it handle
> the different behavior on both?
I won't; the database takes care of it, if I delete the object the
foreignkey from parent1->object will get set to null and the
foreignkey from parent2->object will get set to the default. (see
http://www.postgresql.org/docs/8.4/static/ddl-constraints.html#DDL-CONSTRAINTS-FK
for more info, I guess it becomes clearer when you see it in a non orm
context)

> Also, regardless of whether an elegant solution that relies on the
> database exists for the delete method, I feel like the clear method
> should be patched to match the behavior of the code I posted.
Yes, I hope this will land together with ON_UPDATE/ON_DELETE support.

I hope I didn't confuse you more than necessary ;)

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: default delete() clear() behavior and you.

[Kevin Howerton]

I only killed one hooker, but it was really small so I don't know if it counts.

The problem with those patches though are that they don't appear
(correct me if i'm wrong) to account for handling different deletes
per reverse relation.  You really need to have a more granular
approach.  If an object has two parents pointing at it; one with NULL,
and one with a DEFAULT set... how would you be able to have it handle
the different behavior on both?  It seems like the patches mentioned
in that ticket would only allow you to either delete(cascade=defaults)
or delete(cascade=nulls)... when you really need it to vary based on
the parent field.  Not sure what whether all of the databases can
handle that behavior?

Also, regardless of whether an elegant solution that relies on the
database exists for the delete method, I feel like the clear method
should be patched to match the behavior of the code I posted.

-k
On Mon, Apr 5, 2010 at 5:20 PM, Florian Apolloner  wrote:
> Uhm, your fix fixes the problem at the wrong end. This can and should
> be supported by the database's native capabilities. This would be the
> ticket for it: http://code.djangoproject.com/ticket/7539
>
> But I like your imagination, or is there more truth behind your story
> than you'd admit?
>
> Cheers,
> Florian Apolloner
>
> On Apr 5, 8:06 pm, Kevin howerton  wrote:
>> Hi.
>>
>> So I came across a use-case for wanting to delete content (which
>> django doesn't really handle exactly to my liking).  I just got back
>> from a vacation in vegas and noticed in a drunken stupor I had posted
>> some pictures on my blog that should I really shouldn't have 
>> (http://i.imgur.com/5oj15.jpgSFW).
>>
>> Anyhow, currently django's only delete behavior (to my knowledge) is
>> to delete all objects related from a reverse relation.  I think it
>> would be preferable to actually delete only objects that have NOT NULL
>> **and** no default set.
>>
>> Right now clear() sort of fills some of the void for what you need to
>> do prior to deleting an object, but it fails to handle DEFAULT
>> conditions.
>>
>> I realize changing the default behavior of the delete() method is
>> probably out of the question... and there are a bunch of tickets open
>> asking for cascades and what-not, that will hopefully one day fill the
>> void.  clear(), however, *should* handle DEFAULTS in the same way it
>> handles null=True.
>>
>> Also, I wrote a mix-in class that fixes the delete method to work as I
>> believe it should... for those of you with similar use-cases.  Anyone
>> have any feedback on it?
>>
>> ps.  I didn't really murder a hooker in vegas (I don't even have a
>> blog), just felt that I should provide a relevant use-case ;)
>>
>> from django.db.models.fields import NOT_PROVIDED
>> from django.contrib import admin
>>
>> class ClearOnDelete(models.Model):
>>     def delete(self):
>>         related_objects = self._meta.get_all_related_objects()
>>         for object in related_objects:
>>             accessor_name = object.get_accessor_name()
>>             related_accessor = getattr(self.__class__, accessor_name)
>>             related_accessor_instance = getattr(self, accessor_name)
>>
>>             if related_accessor.related.field.default is not
>> NOT_PROVIDED:
>>                 for relation in related_accessor_instance.all():
>>                     setattr(relation,
>> related_accessor.related.field.name,
>> related_accessor.related.field.default)
>>                     relation.save()
>>             elif related_accessor.related.field.null:
>>                 for relation in related_accessor_instance.all():
>>                     setattr(relation,
>> related_accessor.related.field.name, None)
>>                     relation.save()
>>         super(ClearOnDelete, self).delete()
>>
>>     class Meta:
>>         abstract = True
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: default delete() clear() behavior and you.

[Florian Apolloner]

Uhm, your fix fixes the problem at the wrong end. This can and should
be supported by the database's native capabilities. This would be the
ticket for it: http://code.djangoproject.com/ticket/7539

But I like your imagination, or is there more truth behind your story
than you'd admit?

Cheers,
Florian Apolloner

On Apr 5, 8:06 pm, Kevin howerton  wrote:
> Hi.
>
> So I came across a use-case for wanting to delete content (which
> django doesn't really handle exactly to my liking).  I just got back
> from a vacation in vegas and noticed in a drunken stupor I had posted
> some pictures on my blog that should I really shouldn't have 
> (http://i.imgur.com/5oj15.jpgSFW).
>
> Anyhow, currently django's only delete behavior (to my knowledge) is
> to delete all objects related from a reverse relation.  I think it
> would be preferable to actually delete only objects that have NOT NULL
> **and** no default set.
>
> Right now clear() sort of fills some of the void for what you need to
> do prior to deleting an object, but it fails to handle DEFAULT
> conditions.
>
> I realize changing the default behavior of the delete() method is
> probably out of the question... and there are a bunch of tickets open
> asking for cascades and what-not, that will hopefully one day fill the
> void.  clear(), however, *should* handle DEFAULTS in the same way it
> handles null=True.
>
> Also, I wrote a mix-in class that fixes the delete method to work as I
> believe it should... for those of you with similar use-cases.  Anyone
> have any feedback on it?
>
> ps.  I didn't really murder a hooker in vegas (I don't even have a
> blog), just felt that I should provide a relevant use-case ;)
>
> from django.db.models.fields import NOT_PROVIDED
> from django.contrib import admin
>
> class ClearOnDelete(models.Model):
>     def delete(self):
>         related_objects = self._meta.get_all_related_objects()
>         for object in related_objects:
>             accessor_name = object.get_accessor_name()
>             related_accessor = getattr(self.__class__, accessor_name)
>             related_accessor_instance = getattr(self, accessor_name)
>
>             if related_accessor.related.field.default is not
> NOT_PROVIDED:
>                 for relation in related_accessor_instance.all():
>                     setattr(relation,
> related_accessor.related.field.name,
> related_accessor.related.field.default)
>                     relation.save()
>             elif related_accessor.related.field.null:
>                 for relation in related_accessor_instance.all():
>                     setattr(relation,
> related_accessor.related.field.name, None)
>                     relation.save()
>         super(ClearOnDelete, self).delete()
>
>     class Meta:
>         abstract = True

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.