Opened 15 years ago
Closed 12 years ago
#11403 closed Bug (needsinfo)
Django Models - Default and Choices made to Table Schema
Reported by: | seanmccully | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.0 |
Severity: | Normal | Keywords: | Models Default Choices |
Cc: | Triage Stage: | Design decision needed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I am pretty new to Django/python. While working on a project for Work, Ive run into a few seperations the Database layer from Table Schemas. We are using Postgres database(s), and when applying the column attribute Default or Choices to Fields Ive noticed that this is not applied to the table schema as an enumerated type and default keyword.
As such, I would like to see when choices are applied to a field the database schema uses an enumerated type to describe this. This enforces several data constinencies, and I think is a better way to describe the data and I believe saves space by values being stored as an index not a string value of descriptions (makes sense?).
The same goes for default, and adding a DEFAULT behavior for the column/field.
Change History (5)
comment:1 by , 15 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:2 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:5 by , 12 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
This ticket is really about two different features:
1) storing default in the database
2) using enum fields for fields with a limited number of choices
The main drawback both ideas is that changes to the default value or choices will have to be propagated to the database. This requires schema alteration.
These are large problems, I suggest sending concrete proposals to django-developers. The proposal should address backwards-compatibility and if possible include a proof of concept.
There is a larger issue here that needs to be addressed - to what extent should the ORM hide the discrepancies between databases? This is part of a family of issues that we need to look at - e.g., support for ON DELETE CASCADE/RESTRICT has similar issues.