Override instance attribute

Question

In views.py I have:

my_computer = Computer.objects.get(pk=some_value)

The computer object has a field called projects that's a ManyRelatedManager.

Calling

my_projects = my_computer.projects.all()

will set the value of my_projects to a list of three project objects.

What I'm trying to achive is to set the value of my_computer.projects to the above list of projects instead of the ManyRelatedManager.

I have tried:

my_computer.projects = my_projects

but that doesn't work, although it doesn't raise an error either. The value of my_computer.projects is still the ManyRelatedManager.

This is not clear. You already get the attribute from `my_computer.projects`, why do you want to set it back to that attribute? — Daniel Roseman, Jul 28 '14 at 13:07
Now I am very confused. You want to set `my_computer.projects` to the value of `my_computer.projects.all()`? You mean you just want to remove the necessity to add the `.all()`? Why? — Daniel Roseman, Jul 28 '14 at 14:01
@DanielRoseman Yes, that's what I want. I want to do that because afterwards I want to edit the projects list in order to add some extra attributes to the projects before passing them to the template. — Ionut Hulub, Jul 28 '14 at 14:03

score 1 · Answer 1 · answered Jul 28 '14 at 16:00

1

You can't do that. Your best bet is to simply use another attribute name.

my_computer.related_projects = list(my_computer.projects.all())

answered Jul 28 '14 at 16:00

Daniel Roseman

588,541
66
880
895

Luis Masuelli · Accepted Answer · 2014-07-28T21:16:51.733

Manager objects implement __set__ - they behave as descriptors.

This means you cannot change the object by assigning it (as long as its attribute of another object - __set__ is only called in the context of __setattr__ on the parent object - parent regarding composition relationships, and not inheritance relationships).

You can assign any list-like (actually: iterable) value to a manager if such iterable value yields models of the expected type. However this means:

When you query my_computer.projects, you will get again a manager object, with the objects you assigned.
When you save the object my_computer, only the specified objects will belong to the relationship - previous object in the relationship will not be related anymore to the current object.

There are three scenarios you could have which led you to this issue:

You need to hold a volatile list - this data is not stored, in any way, but used temporarily. You have to create a normal attribute in the class:

class Computer(models.Model):
    #normal database fields here

    def __init__(self, *args, **kwargs):
        super(Computer, self).__init__(*args, **kwargs)
        #ENSURE this attribute name does not collide with any field
        #I'm assuming the Many manager name is projects.
        self.my_projects = []

You need another representation of the exact same relationship - in this way, you want a comfortable way to access the object, instead of calling a strange .all(), e.g. to do a [k.foo for k in mycomputer.my_projects]. You have to create a property like this:

class Computer(models.Model):
    #Normal database fields here
    #I'm assuming the Many manager name is projects.

    @property
    def my_projects(self):
        #remember: my_projects is another name.
        #it CANNOT collide, so I have another
        #name - cannot use projects as name.
        return list(self.projects.all())

    @my_projects.setter
    def my_projects(self, value):
        #this only abstracts the name, to match
        #the getter.
        self.projects = value

You need another relationship (so it's not volatile data): Create ANOTHER relationship in your model, pointing to the same mode, using the same through if applicable, but using a different related_name= (you must explicitly set related_name for at least one of the multiple relationships to the same model, from the same model)

Nice answer, but it would be nice if you world add a workaround to it like Daniel Roseman suggested for future references. — Ionut Hulub, Jul 28 '14 at 20:05
It was modified, adding 3 possible cases I thought about. For the comment I saw, you need the second one. — Luis Masuelli, Jul 28 '14 at 21:17

Override instance attribute

2 Answers2