[Django] #34275: Add new Field named FieldAlias

2 views
Skip to first unread message

Django

unread,
Jan 20, 2023, 1:41:56 AM1/20/23
to django-...@googlegroups.com
#34275: Add new Field named FieldAlias
-------------------------------------+-------------------------------------
Reporter: Sharif | Owner: nobody
Mehedi |
Type: New | Status: new
feature |
Component: Database | Version: 4.1
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Let's say I define some abstract model and when some database model
inharits from the abstract model, I would like to have some other name for
a field from the inharited model. This is fairly simple for most of the
field types, with some changes in the query_utils. But This will need some
extra work on GenericForeignKey, where I would like to have some
FieldAlias which should behave like a ForeignKey (some inverse relation to
a GenericRelation (which are not necessarily tied together)) on the
GenericForeignKey.

--
Ticket URL: <https://code.djangoproject.com/ticket/34275>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Jan 20, 2023, 2:01:36 AM1/20/23
to django-...@googlegroups.com
#34275: Add new Field named FieldAlias
-------------------------------------+-------------------------------------
Reporter: Sharif Mehedi | Owner: nobody
Type: New feature | Status: closed
Component: Database layer | Version: 4.1
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):

* status: new => closed
* resolution: => wontfix


Comment:

Thanks for this ticket, it's an interesting idea but it's also quite
niche. Personally, I would create a field subclass for frequently used set
of field arguments.

It sounds like a third-party package is the best way to proceed so that
people can try it out and then approaching the DevelopersMailingList to
reach a wider audience and see what other think. Thanks.

--
Ticket URL: <https://code.djangoproject.com/ticket/34275#comment:1>

Reply all
Reply to author
Forward
0 new messages