Skip to content

Fix returning None when allow_none is True in CharField #1834

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Sep 5, 2014

Conversation

piotrjakimiak
Copy link
Contributor

When We have model with nullable char field allow_none is set to True.
Setting None in this field leads to serializing this field to "None" instead of null.

serializer = CharFieldSerializer(data={'char': None})
self.assertTrue(serializer.fields['char'].allow_none)
self.assertTrue(serializer.is_valid())
self.assertIsNone(serializer.data['char'])
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't see what this assert does. You probably meant serializer.object['char'] ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok I've changed it to serializer.object.char

if not self.allow_none:
return ''
else:
# return None implicity because smart_text(None) == 'None'
Copy link
Collaborator

Choose a reason for hiding this comment

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

Actually, it's explicitly. BTW, could you add a reference to #1834 in the comment ?

@tomchristie
Copy link
Member

Setting None in this field leads to serializing this field to "None" instead of null.

Sorry, do me me that the literal string "None" is used as the serialized representation?

@piotrjakimiak
Copy link
Contributor Author

Yes. Serialized value of None is string "None".

In [2]: smart_text(None) == "None"
Out[2]: True

During serialization of CharField when value is None and allow_none == True smart_text is called.

@xordoquy
Copy link
Collaborator

xordoquy commented Sep 5, 2014

@tomchristie PR looks fine to me, was about to merge it but got interrupted. Anything against this ?

class NullableCharFieldModel(models.Model):
char = models.CharField(null=True, blank=True, max_length=4)


Copy link
Member

Choose a reason for hiding this comment

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

Let's not use a model for this test - cleaner if we can narrow it down to a regular serializer.

@tomchristie tomchristie added this to the 2.4.3 Release milestone Sep 5, 2014
@tomchristie tomchristie added the Bug label Sep 5, 2014
@tomchristie
Copy link
Member

One inline comment. Also I'm unclear if this is a regression or not.

@piotrjakimiak
Copy link
Contributor Author

In version 2.3.14 None was returned, as in my commit.

I've deleted model and used Serializer

class CharFieldSerializer(serializers.Serializer):
char = serializers.CharField(allow_none=True, required=False)
serializer = CharFieldSerializer(data={'char': None})
self.assertTrue(serializer.fields['char'].allow_none)
Copy link
Member

Choose a reason for hiding this comment

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

We don't need this assert any more.

@tomchristie
Copy link
Member

One minor inline comment left, otherwise looking great.

@piotrjakimiak
Copy link
Contributor Author

Should I delete that inline comment?

@tomchristie
Copy link
Member

That assert line that checks the field attribute should be deleted - it's not really useful.

@piotrjakimiak
Copy link
Contributor Author

Should i squash all commits into one?

@tomchristie
Copy link
Member

Your call - I don't mind too much either way.

@piotrjakimiak
Copy link
Contributor Author

I hope everything is ok now.

tomchristie added a commit that referenced this pull request Sep 5, 2014
Fix returning None when allow_none is True in CharField
@tomchristie tomchristie merged commit 2b47c6b into encode:master Sep 5, 2014
@tomchristie
Copy link
Member

Nice work: thanks!

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

Successfully merging this pull request may close these issues.

3 participants