You can always override the save method on the model. If you need to make all
your models override the save method, use inheritance.
class DoNotSaveModel(models.Model):
def save(*args, **kwargs):
pass
From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On
Behalf Of bill.torcaso
Sent: Monday, March 5, 2018 8:48 AM
To: Django users
Subject: Re: Making an object unsaveable ...
On Sunday, March 4, 2018 at 4:43:06 AM UTC-5, Bernd Wechner 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:
1. Load an object from database
2. Flag it as unsaveable, not to be written back to database under any
circumstances
3. Make changes to the object (its fields)
4. 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:
1. Load an object from database
2. Make a copy, that is unsaveable, not to be written back to database under
any circumstances
3. Make changes to the copy (its fields)
4. 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+unsubscr...@googlegroups.com<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to
django-users@googlegroups.com<mailto: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/c25f6674-9d58-408c-8e94-c7f49ca2cd59%40googlegroups.com<https://groups.google.com/d/msgid/django-users/c25f6674-9d58-408c-8e94-c7f49ca2cd59%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscr...@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/28aa8fe8564b4d56acf5e69b23e63502%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.
