#35269: GeneratedFields can't be defined on RelatedFields
-------------------------------------+-------------------------------------
     Reporter:  Perrine L.           |                    Owner:  nobody
         Type:  New feature          |                   Status:  closed
    Component:  Database layer       |                  Version:  5.0
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:  invalid
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Comment (by fero):

 Hello Sarah,
 thanks for the answer

 Replying to [comment:4 Sarah Boyce]:
 > Hi Perrine,

 Perrine?!? Sorry...I think you are answering me, and not Perrine. I hope
 to be right.

 > this ticket should only be re-opened if you do as Mariusz requested and
 provide a valid column DDL definition that you believe is not currently
 supported.

 I have opened the issue without a DDL because the matter is just a way on
 how Django give an accessor to ForeignKey attributes, mainly very useful
 lookup. And this can be done (at least in PostgreSQL) even without
 constraints. So no DDL really required for this feature.

 > I believe this will not be possible as
 [https://www.postgresql.org/docs/current/ddl-generated-columns.html the
 linked documentation states] and Mariusz mentioned, `GeneratedFields`
 cannot reference anything other than the current row in **any way** and
 being a `ForeignKey` is a reference to an external model.

 Yes, the GeneratedField can reference only info of its own row. I have had
 the problem when I wanted to created a generated field with a CASE WHEN
 and apply a Now(), aka CURRENT_TIMESTAMP as a default value. This cannot
 be done.

 But in this case the ForeignKey is just and ID and it is computed from
 data of its own row. It is really the same as a BigIntegerField (or a
 CharField if you use id like ssn), but it gives you a quicker way to
 access to the related model.

 So, I really appreciate your answer, but my humble opinion disagrees with
 the position that implementing this feature would imply that
 GeneratedField relies in external data.


 > Thank you for the sample project and I can see what you're trying to do.
 As what you're suggesting would be a new feature to Django, the
 recommended path forward is to first propose and discuss the idea with the
 community and gain consensus that this would be a desirable addition to
 Django. To do that, please consider starting a new conversation on the
 [https://forum.djangoproject.com/c/internals/5 Django Forum], where you'll
 reach a wider audience and likely get extra feedback.
 >
 > I'll close this ticket, but if there is a community agreement for the
 feature request, you are welcome to create a ticket for the new feature
 and point to the forum topic. For more details, please see
 [https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
 features/#requesting-features the documented guidelines for requesting
 features].
 >

 I leave the ticket closed, but I have answered here to return you with a
 feedback, and to link the ticket in the forum where I will go.

 Thank you very much!
-- 
Ticket URL: <https://code.djangoproject.com/ticket/35269#comment:6>
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/0107018ea33dabe1-9ce8e73c-2d2a-45a7-a837-2b8832e671aa-000000%40eu-central-1.amazonses.com.

Reply via email to