#35659: Document db_default behaviour before instances are saved
-------------------------------------+-------------------------------------
Reporter: Markus Andresen | Owner: Jerome
Type: | Cagado
Cleanup/optimization | Status: assigned
Component: Documentation | Version: 5.0
Severity: Normal | Resolution:
Keywords: db_default | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Markus Andresen):
Hey, thanks for accepting the ticket!
> It's not safe to randomly cast things without at least checking what the
underlying type of the variable is. Eg bool("false") == True. In this case
my_field is an instance of DatabaseDefault.
I'm aware, the reason this behaviour is problematic (if not properly
documented) is because `my_field` is assumed to be a bool since that is
the case when a BooleanField has a `default` attribute, would people
assume that `db_default` behaves differently? They might have code that
looks something like this:
{{{
my_model = MyModel
if MyModel.my_field:
do_something
# later in code
my_model.save()
}}}
Docs currently looks like this
`If both db_default and Field.default are set, default will take
precedence when creating instances in Python code. db_default will still
be set at the database level and will be used when inserting rows outside
of the ORM or when adding a new field in a migration.`
`default taking precedence in Python code` is somewhat misleading IMO,
adding a proper "disclaimer" here might be good?
--
Ticket URL: <
https://code.djangoproject.com/ticket/35659#comment:4>