On Thu, Jul 8, 2010 at 11:19 PM, Ric <riccardodivirgi...@gmail.com> wrote:
> Hi Russ, nice to talk with u,
>
> i think that we can focus only on substitute feature,
> to archive it we have 2 options:
>
> simply upgrade the current delete_view or make a new view, something
> like
> url(r'^(.+)/substitute/$',
> wrap(self.substitute_view),
> name='%s_%s_substitute' % info),
>
>
> to make it work for every model we need to build form with one
> ModelChoiceField.
> this field will be initialized with a queryset of the model_admin
> (queryset method), and then call the queryset exclude method to remove
> from the field the instance/s that will be deleted.
>
> field = forms.ModelChoiceField(queryset =
> self.queryset(request).exclude(**{"%s__in" %
> self.model._meta.pk.attname: objects_to_delete})
>
> so imagine that we have 10 object
>
> 1 Banana
> 2 Apple
> 3 Tree
> 4 ...
> 10 Stick
>
> we mark for deletion object 1 and 2, in the view the form will make us
> choose objects from 3 to 10, the use choose to substitute with object
> 3 and all Banana and Apple in the database will be replaced with a
> Tree, using the queryset update method.
>
> is it clear?
This much was already clear. My concern is about the edge cases.
Lets say we have an Author model that we are deleting. You're giving
the use case of deleting an author, and modifying all the Blog posts
that reference that author so that they point somewhere else. I have
no problems with the concept or implementation of this as you describe
it.
But:
* What if you have multiple models referring to Author? Do you assume
that every related model will be updated the same way?
* What if you have multiple foreign keys from Blog to Author? Do you
assume that every foreign key on a single model will be updated in the
same way?
* What if there is a model with a m2m relation to Author? Do you
delete the m2m relation, or do you replace it with the substituted
object?
* What if you use admin actions to delete N authors? Do we assume
that every one of the authors will be replaced with the same single
substitute?
These sorts of decisions are all business logic decisions. You may
have a good answer for your site, but I'm not convinced that there is
a universal answer that will always be correct for all users, and I'm
not convinced that it would be possible to define an easily
configurable interface to expose all possible interpretations of this
feature.
This is why I'm suggesting that the best approach here is to make it
*possible*, but not to bake this capability into Django itself. If we
provide the appropriate hooks, you (as an end user) should be able to
add whatever implementation of this feature you want.
If there are hooks on Django's admin that need to be added or
modified, then I'm happy to entertain those changes.
Yours,
Russ Magee %-)
--
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.
