Making an object unsaveable ...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Making an object unsaveable ...

Bernd Wechner

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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Making an object unsaveable ...

Dan Tagg
Two possibilities spring to mind

1. 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 this

2. Use signals to catch any save attempts. This is easily circumvented. 

On 4 March 2018 at 09:41, Bernd Wechner <[hidden email]> 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 [hidden email].
To post to this group, send email to [hidden email].
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAPZHCY7BciY%2B5JRQ2o%2B8eiLMVfCfg6boR0g_Fc8ymqO_E1EU_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Making an object unsaveable ...

Bernd Wechner
Thanks Dan,

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 mind

1. 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 this

2. Use signals to catch any save attempts. This is easily circumvented. 

On 4 March 2018 at 09:41, Bernd Wechner <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="429VrBhJAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">bernd....@...> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="429VrBhJAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-users...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="429VrBhJAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django...@....
Visit this group at <a href="https://groups.google.com/group/django-users" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-users&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-users&#39;;return true;">https://groups.google.com/group/django-users.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-users/9162bad4-935a-ed39-d2d8-a001103ec705%40gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-users/9162bad4-935a-ed39-d2d8-a001103ec705%40gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-users/9162bad4-935a-ed39-d2d8-a001103ec705%40gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-users/9162bad4-935a-ed39-d2d8-a001103ec705%40gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Making an object unsaveable ...

gamesbook
In reply to this post by Bernd Wechner

I think the second case is more manageable; I'd actually have a second table that has an exact duplicate structure of the first. Then you can save your newly changed copy into that -- and delete the record just afterward, or even  much later,  if you need to.

I cannot imagine a scenario in which somone would do a lot of work and then not save it (even temporarily).

On Sunday, 4 March 2018 11:43:06 UTC+2, 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 [hidden email].
To post to this group, send email to [hidden email].
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/42be8668-a288-410c-a2c0-5f933e5d4d41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Making an object unsaveable ...

bill.torcaso
In reply to this post by Bernd Wechner


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 [hidden email].
To post to this group, send email to [hidden email].
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.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

RE: Making an object unsaveable ...

Matthew Pava

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: [hidden email] [mailto:[hidden email]] 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 [hidden email].
To post to this group, send email to [hidden email].
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.
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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Making an object unsaveable ...

Melvyn Sopacua
In reply to this post by Bernd Wechner
Hi Bernd,

On zondag 4 maart 2018 10:41:52 CET Bernd Wechner wrote:

> 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.

Since this is for display purposes, why does it have to remain a model?
--
Melvyn Sopacua

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/2367426.DusgZ0bLcz%40fritzbook.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Making an object unsaveable ...

James Bennett
The only way to guarantee a model is unsaveable is to do it at the database permission level.

You can override methods on the model in your Python code to make it *harder* to save, but you can't make it impossible, because of how Python works.

Consider the following simplified pair of classes:


class Base:
    def __init__(self, name):
        self.name = name

    def save(self):
        print("Saving {}".format(self.name))


class Child(Base):
    def save(self):
        raise Exception("Can't save me!")


You'd think you can't save() an instance of Child. Except:


c = Child(name="Unsaveable instance")
Base.save(c)


Which will succeed and print that it's saving the "unsaveable" instance of Child. Now imagine that you override save() and everything else you can think of on your model class, and then someone goes and grabs the base Model class and calls its save() method passing in an instance of your "unsaveable" class. It's going to succeed in saving your "unsaveable" model.

No matter how much you do to your model class in Python, someone who's sufficiently determined will always be able to find a way to save it. Only by cutting off the ability to run INSERT/UPDATE queries at the database-permission level can you completely stop this. 



On Tue, Mar 6, 2018 at 12:12 AM, Melvyn Sopacua <[hidden email]> wrote:
Hi Bernd,

On zondag 4 maart 2018 10:41:52 CET Bernd Wechner wrote:

> 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.

Since this is for display purposes, why does it have to remain a model?
--
Melvyn Sopacua

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/2367426.DusgZ0bLcz%40fritzbook.
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAL13Cg9GrypCNg97rE2PKUHWdHVqcKWYHjo1YcJTfpPfsq1v1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Making an object unsaveable ...

Bernd Wechner
In reply to this post by Melvyn Sopacua
Melvyn,

Just preference. Nothing more. Fix the issue at its source so all views that exist or might exist honor the demand basically. One model, many views.

Regards,

Bernd.

On Tuesday, 6 March 2018 19:13:42 UTC+11, Melvyn Sopacua wrote:
Hi Bernd,

On zondag 4 maart 2018 10:41:52 CET Bernd Wechner wrote:

> 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.

Since this is for display purposes, why does it have to remain a model?
--
Melvyn Sopacua

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/a5fc94e3-a2ae-4433-9880-9309843d6145%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Making an object unsaveable ...

Bernd Wechner
In reply to this post by James Bennett
James,

Thanks, that's really well put.

I've implemented an override, and better still I love that with a model mix in I can override the save method on the object. Sort of like:

class MyMixIn:
   
def check_stuff(self)
         
...
         
if ...:
             
self.save = self.disabled_save

   
def disabled_save(self):
       
raise Exception("Can't save me!")

class MyModel(MyMixIn, models.Model):
   
...

Now yes, your insight that this can be circumvented is interesting, and it might (though I wonder how in this version, perhaps by calling models.Model.save(obj)?) but am content with a solution for now that prevents inadvertent saving not malicious saving efforts. What this allows is that the extant body of code can tested and run and even put into production in a sense, trusting that any overlooked save avenues will throw this exception. Which is awesome. 

Bot 100% secure perhaps, but pretty danged good. I've tested this sort of thing now and walked the code in a debugger and am pretty happy with it. As long as there are not other ways the django core code might go and save an object (i.e. not using a models save() method. I sort of imagine and hope not that one of the deign paradigms was in fact to make something like this possible, to override base model methods with confidence (typically invoking super() to extend on existing functions but perhaps not as in here).

Anyhow, rather pleased this works. Opens up a pile of interesting options (the main interest I have is in loading an object, modifying an object for display purposes and sandbox purposes, but securing against an inadvertent save of the object).

Regards,

Bernd.

On Tuesday, 6 March 2018 19:28:58 UTC+11, James Bennett wrote:
The only way to guarantee a model is unsaveable is to do it at the database permission level.

You can override methods on the model in your Python code to make it *harder* to save, but you can't make it impossible, because of how Python works.

Consider the following simplified pair of classes:


class Base:
    def __init__(self, name):
        <a href="http://self.name" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fself.name\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3JOkg7Vn23FjpPTI8mfGhfDqO3A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fself.name\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3JOkg7Vn23FjpPTI8mfGhfDqO3A&#39;;return true;">self.name = name

    def save(self):
        print("Saving {}".format(<a href="http://self.name" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fself.name\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3JOkg7Vn23FjpPTI8mfGhfDqO3A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fself.name\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3JOkg7Vn23FjpPTI8mfGhfDqO3A&#39;;return true;">self.name))


class Child(Base):
    def save(self):
        raise Exception("Can't save me!")


You'd think you can't save() an instance of Child. Except:


c = Child(name="Unsaveable instance")
Base.save(c)


Which will succeed and print that it's saving the "unsaveable" instance of Child. Now imagine that you override save() and everything else you can think of on your model class, and then someone goes and grabs the base Model class and calls its save() method passing in an instance of your "unsaveable" class. It's going to succeed in saving your "unsaveable" model.

No matter how much you do to your model class in Python, someone who's sufficiently determined will always be able to find a way to save it. Only by cutting off the ability to run INSERT/UPDATE queries at the database-permission level can you completely stop this. 



On Tue, Mar 6, 2018 at 12:12 AM, Melvyn Sopacua <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="DZVgeniDAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">m.r.s...@...> wrote:
Hi Bernd,

On zondag 4 maart 2018 10:41:52 CET Bernd Wechner wrote:

> 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.

Since this is for display purposes, why does it have to remain a model?
--
Melvyn Sopacua

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="DZVgeniDAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-users...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="DZVgeniDAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django...@....
Visit this group at <a href="https://groups.google.com/group/django-users" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-users&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-users&#39;;return true;">https://groups.google.com/group/django-users.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-users/2367426.DusgZ0bLcz%40fritzbook" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-users/2367426.DusgZ0bLcz%40fritzbook&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-users/2367426.DusgZ0bLcz%40fritzbook&#39;;return true;">https://groups.google.com/d/msgid/django-users/2367426.DusgZ0bLcz%40fritzbook.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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/06fd9834-aafc-4167-901f-5112cb3ca566%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.