Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#27992 closed Bug (invalid)

Cleaned form values does not save to model

Reported by: Pavel Patrin Owned by: nobody
Component: Forms Version: 1.10
Severity: Normal Keywords: model, form
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Example

class MyModel(Model):
    my_field = TextField(default='')


class MyModelForm(ModelForm):
    class Meta:
        model = MyModel
        fields = ('my_field',)

    def clean_my_field(self):
        return 'cleaned_value'  # Or complex logic


form = MyModelForm({})
form.save()

result = MyModelForm.objects.get()

# This is true
result.my_field != 'cleaned_value'

This happens, because Django applies model attributes like this:

def construct_instance(form, instance, fields=None, exclude=None):
    # ... code
    for f in opts.fields:
        # ... code
        # Leave defaults for fields that aren't in POST data, except for
        # checkbox inputs because they don't appear in POST data if not checked.
        if (f.has_default() and form[f.name].field.widget.value_omitted_from_data(form.data, form.files, form.add_prefix(f.name))):
            continue
        # ... code
    # ... code
    return instance

So Django skips fields that has default value, but not present in raw data. Why?

Change History (4)

comment:1 Changed 3 years ago by Tim Graham

Resolution: invalid
Status: newclosed

Hi, this isn't the place to ask about Django's design decisions. You can try asking using the resources linked at TicketClosingReasons/UseSupportChannels. You can also investigate design decisions by using git blame to find commits and tickets related to those lines of code.

comment:2 in reply to:  1 Changed 3 years ago by Pavel Patrin

Replying to Tim Graham:

Hi, this isn't the place to ask about Django's design decisions. You can try asking using the resources linked at TicketClosingReasons/UseSupportChannels. You can also investigate design decisions by using git blame to find commits and tickets related to those lines of code.

Hello, Tim. Ok, i'll see git-blame. If description of a problem look like a question - i am sorry, this is not a question, i think this is a bug.
So, could anybody say me that this is a feature, not a bug?

comment:3 Changed 3 years ago by Tim Graham

No, "Django skips fields that has default value, but not present in raw data." isn't a bug -- you can look at this history of that code to understand its purpose. If you find the relevant commit, you'll probably also find some documentation about the behavior.

comment:4 in reply to:  3 Changed 3 years ago by Pavel Patrin

Replying to Tim Graham:

No, "Django skips fields that has default value, but not present in raw data." isn't a bug -- you can look at this history of that code to understand its purpose. If you find the relevant commit, you'll probably also find some documentation about the behavior.

Ok. Thank you.

Note: See TracTickets for help on using tickets.
Back to Top