Default Values Ignored?

Create issue
Issue #22 new
Randall Degges created an issue

Yo dudes,

I've bumped into a problem using dynamodb-mapper stable (1.8.0) from PyPI. I've got a model defined, which has a 'name' field (unicode).

I noticed that the documentation says that unicode keys get an empty string as their default value, if no default is provided--however, in practice, it seems like my 'name' field is getting NO default value (eg: None).

This is causing problems for me, as I've had to go back to my model and explicitly set a default value for my 'name' field to u'', just so that saving my model works--otherwise, validation will fail since None is not ''.

Comments (3)

  1. Randall Degges reporter

    I should also add some example code, I suppose :)

    from dynamodb_mapper.model import DynamoDBModel
    class Phone(DynamoDBModel):
        __table__ = u'phones_phone'
        __hash_key__ = u'number'
        __schema__ = {
            u'number': unicode,
            u'name': unicode,
            u'created': unicode,
            u'updated': unicode,
        __defaults__ = {
            u'name': u'', # without this, calling save() on a new object will fail, as validation
                                # thinks that name = None, which is invalid since it expects a
                                # unicode value.
            u'created': lambda: unicode(datetime.utcnow().isoformat()),
        def save(self, *args, **kwargs):
            self.updated = unicode(datetime.utcnow().isoformat())
            super(Phone, self).save(*args, **kwargs)
  2. Max Noel

    It's actually a documentation mistake. Old versions of DDBM used to set default values (0, "", {}, [] or set()) but we found that it tended to cause subtle bugs, especially once we started adding extra datatypes (datetime) and validation. So we removed that when we added the option to set explicit defaults.

    What you described is, in fact, intended behavior. Thanks for reporting that issue, I'll fix the docs.

    Also, note that your example would benefit from using the datetime data type instead of strings representing (timezoneless) datetimes. But that's a minor, irrelevant nitpick.

  3. tommaso barbugli

    just came here thinking I was hitting a bug instead of old docs, for future users I suggest you to update the docs :)

  4. Log in to comment