Skip to content

Conversation

timgraham
Copy link
Member

@timgraham timgraham force-pushed the 27039 branch 3 times, most recently from 472844f to 3b78010 Compare August 24, 2016 12:46
@timgraham
Copy link
Member Author

@tomchristie, could you review?

@lovelydinosaur
Copy link
Member

Sure thing. Brief look all seems good, but will go through more thoroughly shortly.

@@ -481,6 +481,8 @@ def boolean_check(v):


class CheckboxInput(Widget):
dont_use_model_field_default_for_empty_data = True
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also include similar comment here?

@lovelydinosaur
Copy link
Member

Looks good.

@timgraham timgraham merged commit 4bc6b93 into django:master Aug 24, 2016
@timgraham timgraham deleted the 27039 branch August 24, 2016 23:37
@ryangallen
Copy link

ryangallen commented Sep 14, 2016

@timgraham @claudep @AlexHill

I'm experiencing a strange hiccup in the Django admin since upgrading to v1.10.1 that I think might be related to this issue. If it's not, I'm not sure what else could be causing it but it doesn't happen if I roll Django back to v1.9.9. Either way, I think you are the ones who can help demystify this for me.

I have a field on a model set like so:
verified = models.DateTimeField(null=True, blank=True, default=None)

Any time a different value is entered for this field in the Django admin and saved, the field value on the object does not change. It remains the value it was set to before. If I remove the default value, the field saves normally. Any insight as to why this might be?

@timgraham
Copy link
Member Author

See #7217.

@ryangallen
Copy link

Awesome, thanks much!

@@ -52,6 +52,11 @@ def construct_instance(form, instance, fields=None, exclude=None):
continue
if exclude and f.name in exclude:
continue
# Leave defaults for fields that aren't in POST data, except for
Copy link
Contributor

@RobertAKARobin RobertAKARobin May 31, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@timgraham This caused me a bit of a debugging headache. I expected that if I did something like this:

def clean(self):
    self.cleaned_data['some_field'] = 'some_value'

...that would be sufficient to set what was ultimately saved to the database. But I found that some_field was always being saved with its default value. It took me a while to figure out why, from looking at the Django source. Now I'm doing this, with success:

def __init__(self, *args, **kwargs):
    super(MyForm, self).__init__(*args, **kwargs)
    self.data = self.data.copy()
    self.data['some_field'] = 'some_value'

I'm just curious what the reasoning is behind the rule you implemented here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your expectation seems reasonable. If there's a way to fix that while keeping backwards compatibility, feel free to offer a patch.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do Django's automated tests ensure backward compatibility? If not I probably don't have enough familiarity with Django to do so. Glad I'm not taking crazy pills, though. :)

@timgraham
Copy link
Member Author

If you have the tests passing that's a good start. Someone will review your patch as well.

@RobertAKARobin
Copy link
Contributor

@timgraham Here we go: #11433

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants