Re: Using _pre_delete() to stop execution
Thanks for the quick reply, Arthur. I've gone over the MR version of doing this, by overwriting delete(), which seems to be like a good approach. I have not tried to add it to my code, because due to some bad management, I'm currently not working on that particular code. In a way, the problem fixed itself. ;-) I will probably come back to it soon, and I intend on using it. I also agree with Glenn. As a relative python newb, my first thought was "Oh, so I shouldn't raise an exception if the delete fails? Hmmm, probably because it would make the admin app do wierd things." I was actually curious if it would be appropriate to take this a step further. Have a "can_delete()" which would check if the logged in user can do some action. After all, you don't want to give a user false hope by showing them a widget which will just return an error. I realize that this may be done with group permissions, but it's just not the same amount of control. Imagine if I allowed logged in users to delete their own stuff, but not someone elses. Then, you have managers who can delete stuff that belongs to them or to one of their team members. And then you have admins who can do whatever they want. Since Django currently doesn't have "can delete self only" permissions, could I fake it with a psuedo-delete inside the Model? This would require accessing current user in the model function. Maybe this patch? http://code.djangoproject.com/attachment/ticket/1132/current_user_field_patch.2.diff These are just some random thoughts, feel free to ignore them. Thanks for the great software, I'm hoping to devote more time to it as soon as I get a chance. ;-) Norbert. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
I totally agree with Glenn. Every day I suffer of the lack of example in the Python doc. It would be great that Django does it better. Olivier. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
On Tue, Apr 11, 2006 at 04:16:09PM -0400, Max Battcher wrote: > "pass" is the Python "do nothing" command, which is often used as an > indicator to "fill in the blanks" with your own specific code (because > Python doesn't allow empty functions it is often seen in psuedo-code). yes... yes... I know that... > I don't think it implies that you shouldn't raise an exception, after > all raising an exception is valid Python code. But that's not the point for documentation and examples of how to use something like Django... the docs and examples should show how to do it right -- or at least the expected way to do something or a "good" way to do it. I maintain that just not saving and doing nothing is not an example of how one should handle such a case. Unless an example shows raising an exception in this case, one might, not unreasonably, think that perhaps one should never raise an exception at that point in the process (e.g. "gee, it's too late to raise an exception, Django must expect me to let the user know in my view instead of in the model"). -- Glenn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
On 4/11/06, Glenn Tenney <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 11, 2006 at 02:24:04PM -0400, Max Battcher wrote: > > You are free to raise your own exception in the path that fails to > > call super().delete() in M-R. > > Then perhaps the docs etc. should instead show "raise " > instead of "pass"... When one shows as an example to use "pass", > it misleads some to think that one shouldn't raise an exception. "pass" is the Python "do nothing" command, which is often used as an indicator to "fill in the blanks" with your own specific code (because Python doesn't allow empty functions it is often seen in psuedo-code). I don't think it implies that you shouldn't raise an exception, after all raising an exception is valid Python code. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
On Tue, Apr 11, 2006 at 06:19:49PM -, arthur debert wrote:
> the thing is, if there's anything in django's knowledge to avoid the
> save / delete it DOES raise an error. (such as trying to delete an non
> existant object or trying to save a model that does not pass
> validation). my guess here is if you need anything else in you logic
> that django doesn't know about (from validators and the db) you must
> implement it yourself.
Thanks.
I was my understanding that validators were a "view" thing... even
though you define the validator_list in the model. I thought that
because the data passed to a validator is NOT the actual data that
will be stored into the field(s) in question.
i.e. from http://www.djangoproject.com/documentation/forms/#validators
"Note that at the point validators are called all data will still be
strings (as do_html2python hasn't been called yet)."
So... are validators called automatically before any data is stored
into a model's "field"? Or, are the validators actually called only
as part of the form / view
> try:
> amodel.delete()
> except:
> return HttpResponseRedirect("bad_detele_action")
>
> or something to that effect.
Right... I can write all of my save/delete/etc. code around a "try".
But shouldn't this be a part of the "official" api -- either all such
destructive methods might raise an exception (so you should be
prepared for it), or all such destructive methods must return a
boolean indicating success/failure (and you should check for it)...
Plus, if I do code it that way, then how will the admin work against
my models that raise exceptions Will the admin try for exceptions
in save etc.? (sorry, but because I had one bad __repr that didn't
return a string and it did NOT get caught by a "try", I'm not making
any assumptions...)
> maybe the so called validation aware models in m-r will do it?
> http://groups.google.com/group/django-developers/browse_frm/thread/4bc65cf676c93846/5d7db0f7a5f85006?q=validation+aware=2#5d7db0f7a5f85006
I like the idea that the model should use a validator... but... is
that the way it DOES work in M-R? Do all "fields" of a model actually
invoke their validators?
--
Glenn
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
On Tue, Apr 11, 2006 at 02:24:04PM -0400, Max Battcher wrote: > You are free to raise your own exception in the path that fails to > call super().delete() in M-R. Then perhaps the docs etc. should instead show "raise " instead of "pass"... When one shows as an example to use "pass", it misleads some to think that one shouldn't raise an exception. Are there any other problems that might crop up if any of save / delete / etc. do raise some exception? e.g. will admin still work, just telling the user that it didn't work instead of some cryptic back-trace debug output due to an unexpected exception? -- Glenn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
On 4/11/06, Glenn Tenney <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 11, 2006 at 05:01:39PM -, arthur debert wrote: > > more on this here: > > http://code.djangoproject.com/wiki/RemovingTheMagic#Addedamorepowerfulwayofoverridingmodelmethodsremovedhardcoded_pre_save_post_saveetc. > > > Everything that I read there shows that you can choose to save or > not-save, delete or not-delete, etc... which is fine, but I don't > think goes far enough. I wouldn't want attempts to > save/delete/insert/whatever to just not happen with everything else > seeming to be fine, and with no ability to get an error message of > some sort to the user. > > Shouldn't there be a way to signal that the save/delete/etc. did or > did not work ok? Either by raising an exception or by returning a > success / failure result... You are free to raise your own exception in the path that fails to call super().delete() in M-R. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
Hi Glenn.
the thing is, if there's anything in django's knowledge to avoid the
save / delete it DOES raise an error. (such as trying to delete an non
existant object or trying to save a model that does not pass
validation). my guess here is if you need anything else in you logic
that django doesn't know about (from validators and the db) you must
implement it yourself.
#
try:
amodel.delete()
except:
return HttpResponseRedirect("bad_detele_action")
or something to that effect.
maybe the so called validation aware models in m-r will do it?
http://groups.google.com/group/django-developers/browse_frm/thread/4bc65cf676c93846/5d7db0f7a5f85006?q=validation+aware=2#5d7db0f7a5f85006
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
Hi Norbert, this is not possible on trunk , if you are using magic-removal, you can do it like this: def delete(self): if conditionIsMet == True: super(ModelName, self).delete() # Call the "real" delete() method. else: # Don't delete. pass more on this here: http://code.djangoproject.com/wiki/RemovingTheMagic#Addedamorepowerfulwayofoverridingmodelmethodsremovedhardcoded_pre_save_post_saveetc. cheers arthur --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Using _pre_delete() to stop execution
Can I use _pre_delete() in a model to stop the deletion from occurring? I've checked the documentation, but couldn't find anything relevant. Someone also raised this question on the save_delete_hooks documentation, with no response. Maybe throw some exception? Has someone done this before or have any ideas? Thanks, Norbert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
