#31300 closed New feature (fixed)
Add function-based virtual fields.
Reported by: | Dulmandakh | Owned by: | Jeremy Nauta |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | field, database, generated |
Cc: | Petr Přikryl, elonzh, Lily Foote, Paolo Melchiorre, julian@pinabausch.org | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
PostgreSQL 12 added support for Generated Columns, see https://www.postgresql.org/docs/12/ddl-generated-columns.html. And I find it very interesting and useful, for example with SearchVectorField.
I imagine it would be called GeneratedField and accept base_field as ArrayField, then expression to generate a value for the field. For example,
class Album(models.Model): ... title = models.CharField(max_length=120) search = GeneratedField( SearchVectorField(), F('title') )
then generate SQL something like below.
CREATE TABLE album ( ... title char(120), search tsvector GENERATED ALWAYS AS title STORED );
I would like to work on this feature, but don't know how to pass expression and generate migration using the expression.
Change History (23)
comment:1 by , 5 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Summary: | Add Generated Columns (PostgreSQL) support → Add function-based virtual fields on PostgreSQL and Oracle. |
comment:2 by , 4 years ago
Cc: | added |
---|
comment:3 by , 23 months ago
Resolution: | wontfix |
---|---|
Status: | closed → new |
Summary: | Add function-based virtual fields on PostgreSQL and Oracle. → Add function-based virtual fields. |
Triage Stage: | Unreviewed → Accepted |
Tentatively accepted, based on the feedback from the mailing list.
comment:4 by , 23 months ago
Has patch: | set |
---|---|
Owner: | changed from | to
Patch needs improvement: | set |
Status: | new → assigned |
comment:5 by , 23 months ago
Cc: | added |
---|
comment:6 by , 20 months ago
Patch needs improvement: | unset |
---|
comment:7 by , 20 months ago
Patch needs improvement: | set |
---|
comment:8 by , 20 months ago
Patch needs improvement: | unset |
---|
comment:9 by , 17 months ago
Cc: | added |
---|
comment:10 by , 17 months ago
Cc: | added |
---|---|
Keywords: | field database generated added |
comment:11 by , 16 months ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:12 by , 16 months ago
Triage Stage: | Ready for checkin → Accepted |
---|
Jeremy, you cannot mark your own patches as RFC, check out docs.
comment:13 by , 16 months ago
Triage Stage: | Accepted → Ready for checkin |
---|
Mariusz if I have interpreted the documentation correctly, having just reviewed it again and not being the author of the PR, I have marked it as an RFC.
comment:14 by , 16 months ago
One thing that might help this land is review of the Oracle support I added in https://github.com/django/django/pull/16860. There's a few open questions that could use thought from more people.
comment:15 by , 16 months ago
I personally can't help with Oracle testing, as I believe many others here, but if there weren't other people able to help, as Adam has already suggested [1] in the PR comments, I wouldn't block the merge of this feature because it lacks the Oracle support given how little it is used.
[1] https://github.com/django/django/pull/16417#issuecomment-1508222534
comment:16 by , 16 months ago
Cc: | added |
---|
comment:17 by , 15 months ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Ready for checkin → Accepted |
comment:18 by , 15 months ago
Patch needs improvement: | unset |
---|---|
Triage Stage: | Accepted → Ready for checkin |
We have an accepted ticket #30511 about identity columns on PostgreSQL, and I think we should stay with this. Generated/Function-based virtual columns are a huge topic that would require many changes and have many caveats, e.g. functions must be deterministic. They are feasible also on Oracle. This kind of features require few weeks (even months) of works, a precise plan, and should be preceded by a discussion on DevelopersMailingList and even DEP.