Code

Opened 5 years ago

Closed 13 months 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.

Attachments (0)

Change History (5)

comment:1 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

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.

comment:2 Changed 3 years ago by julien

  • Severity set to Normal
  • Type set to Bug

comment:3 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:4 Changed 2 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:5 Changed 13 months ago by aaugustin

  • Resolution set to needsinfo
  • Status changed from new to 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.