I was actually thinking also last night of:
3. Override the save() method on the model.
Not tested, not sure how robust, but as it happens there's a hook there already as all the models I'm work with have it overridden with tiny method that updates some admin fields like last_updated and last_updated_by. This could be a nice place for a small hook.
Signals are an idea too, and want to explore them as much for the heck of it and learning as anything. But I wonder what you mean by "This is easily circumvented." - I'm guessing that even if you catch a signal prior to save and do something, there's no guarantee some downstream code won't do a save. I wonder if overriding save() is more secure, or if there's any possibility other code could go around such an override.
Regards,
Bernd.
On Sunday, 4 March 2018 22:24:38 UTC+11, Dan Tagg wrote:
Two possibilities spring to mind1. Don't grant django's database user the right to update the relevant table. If you take this approach you'll need to catch any errors if anyone writes code to attempt to do this2. Use signals to catch any save attempts. This is easily circumvented.On 4 March 2018 at 09:41, Bernd Wechner <bernd....@gmail.com> wrote:--An interesting question I've not been able to solve reading docs or Googling. As every posting here only after some serious research efforts including class inspections ;-). But am stumped and wonder if anyone else has any ideas.
Here is the use case:
- Load an object from database
- Flag it as unsaveable, not to be written back to database under any circumstances
- Make changes to the object (its fields)
- Present a detail view of the object.
Basically, would like the freedom to change an object knowing the database is secure.
As ever, am more interested in how to do this, than questioning why to do it. It may not be possible in which case fear not, I'm on top of the why's and can look at alternative strategies. But this use case provides an easy way of injecting some filters in one place of a code body I have without changing any of the views or other code. Simply one small hook I place into extant code, which will play around with the object (making translations for example). But in order to do so would want to know this cannot be written back to the database, that from here on in, it's for display purposes only.
Have a suspicion after some research that this can't be done. In which case there's a second and almost as useful use case:
- Load an object from database
- Make a copy, that is unsaveable, not to be written back to database under any circumstances
- Make changes to the copy (its fields)
- Present a detail view of the copy.
This has some slightly better chance of being possible. If not as well, yes indeed, I have to dive into the view itself and put hooks into each field as it renders I guess. Which is life. But would seem useful to do it with one of these use cases (again no need to discuss the merits of one approach over the other at all, am more interested in possibility - projects have huge amounts of context not readily shareable that influence the relative merits of one approach over another of course.
Regards,
Bernd.
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com .
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users .
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/9162bad4- .935a-ed39-d2d8-a001103ec705% 40gmail.com
For more options, visit https://groups.google.com/d/optout .
--Wildman and Herring Limited, Registered Office: 28 Brock Street, Bath, United Kingdom, BA1 2LN, Company no: 05766374
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5e292463-504b-41db-984f-86a25d8c36b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment