#470: Add Field.db_default for defining database defaults
-------------------------------------+-------------------------------------
Reporter: jws | Owner: John
| Whitlock
Type: New feature | Status: assigned
Component: Database layer | Version:
(models, ORM) |
Severity: normal | Resolution:
Keywords: sql schema | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by John Whitlock):
I hit a dead-end with that approach. The field code can not access the
Model Options or App Config as initialization, so I would have to half-
initialize a field until it gets added to a model. That is awkward, and
would go against the existing code which fully initializes all fields
(with the exception of a primary key) before adding them to the Model.
I was also finding myself wondering what happened if `db_default` was set,
and `default` was not.
I'm attempting a new approach that does not use `db_default`. Instead, I
have a `BaseDefault` class that has more direct control of the default
policy. You can assign an instance of `BaseDefault` or a subclass to
`default`, and the `Field` class behaves differently, and eventually the
`Schema` class will as well.
My first goal is to replicate the `DateField` and `DateTimeField` with
`auto_now` and `auto_now_add`, but through the new class. Then I'll extend
the class and the migrations `Schema` code to tune the the pre-migration
and post-migration column defaults. The behaviors I've identified so far:
* Override `Field.__init__` parameters, such as `editable` and `blank`
(`auto_now`)
* Set the field value on `pre_save` (`auto_now`)
* Test if there is a Python-level default (`has_default`)
* Get a callable version of the Python-level default (`_get_default(),
cached`)
* Pick the `DEFAULT x` value when adding a column
and the new behavior:
* Pick the `DEFAULT x` value after adding a column
I _think_ this will allow a small changes to:
* Persist simple defaults (something like changing `default=0` to
`default=DatabaseDefault(0)`)
* Persist `DateTimeField` and `DateField` (something like changing
`auto_now_add=True` to `DateTimeDatabaseDefault(auto_now_add=True)`)
* Allow for per-database formatting of the `DEFAULT` clause, via
`Expression` or similar
--
Ticket URL: <https://code.djangoproject.com/ticket/470#comment:53>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701832993374b-29404523-a990-436b-83b2-208f01c0a9fd-000000%40eu-central-1.amazonses.com.
