set attribute to None does not work (at least for fields with default values)

[DavidBord]

    class User(Document):
        name = StringField()
        height = IntField(default=184)
    User.objects.delete()
    u = User(name='user')
    u.save()
    u_from_db = User.objects.get(name='user')
    u_from_db.height = None
    u_from_db.save()
    self.assertEquals(u_from_db.height, None)

[rozza]

This has long been a bone of contention - I think you need to delete the value to remove it but that may have changed.

Essentially, default means the value if its missing and not the value when first set - which is the issue.

[thedrow]

This is definately a bug.

[rozza]

Copying comment from #735

Default should be used on the creation of totally new objects only and not from the database. This would be a breaking change and might get some people relying on the current behaviour (eg to mimic last_updated with a default callable of now).

[DavidBord]

When I set the value to None, I don't want to remove it - I want to set it to None but it does not happen

[rozza]

Here's the crux None is not a valid String, Number, EmbeddedDocument etc..

>>> type(None) == type('string')

False

If you set a StringField to None its string representation is "None" which is not correct.
None is a valid BSON type and can be stored in MongoDB - but is that the type you want to store or would it be better not to store a value at all? What happens if its required?

[thedrow]

If it's required it should be null.

[DavidBord]

1. I wouldn't expect that set to an attr to None would unset it. I think it is even better for it to fail on validation
2. Why not make None explicitly a valid value just like in Django?

[rozza]

In response:

1. Ok so validation would fail as the types wouldn't match - we could stop people setting the value to None
2. We could be we still have to clarify what happens in various scenarios

So a couple more questions to help spec this out:

1. If we set a value to None - should we store it as null in the database or not store it at all?
2. Does required=True v required=False change behaviour?
3. What should we do with new models who by definition have default values as null set them to None or simply not set them?

[DavidBord]

1. Store it as null
2. No
3. Set them to None

[mitar]

It seems this could address #381 as well.

[mitar]

Great! When will this be in a released version?

[jimmyshen]

Hi,

I was playing with the new 'null' behavior, which I would like to use in a project I'm working on. While messing with it on master, I noticed some inconsistency in the behavior with regard to DateTimeField and ComplexDateTimeField.

Here's a demonstration:

def test_null_datetime_fields():
    class TestDoc(Document):
        dt_field = DateTimeField(null=True)
        cdt_field = ComplexDateTimeField(null=True)

    doc = TestDoc()
    doc.save()

    assert doc.dt_field is None
    assert doc.cdt_field is None

The cause seems to be related to some logic specific to ComplexDateTimeField that falls back to datetime.now on retrieval from db. I'm not sure what the motivation was for the different behavior between DateTimeField and ComplexDateTimeField -- it was introduced a long time ago and there's even a test to ensure it doesn't regress:

0187a0e1

I made a PR with a teeny patch that (I think) remedies the behavior:

#864

[RussellLuo]

@DavidBord, has this issue been fixed? I use MongoEngine v0.10.0, but the nullable field will still be deleted if I set its value to None:

class User(Document):
    name = StringField(null=True)

user = User(name='user')
# the name field is stored in MongoDB
user.save()

user.name = None
# the name field is deleted from MongoDB
user.save()