Optional and automated Unique Key identifier of the fields of the models

[MoonspicAI]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Apps of Django have models that have classes that have fields.
If Django has a a feature that builds a map of the projects. Hence to provide a unque universal key identifier of the fields (like f'{App}{ModelName}{FieldName}') then it can allow having automated queries that can be comparable to graphene and graphql .. by which the server can create views on the fly either by searching field name of the fields or by providing their unique ID by the requests.

Allowing the user to enter key ID of choice in the fields will prevent exposing the internal server architecture to the clients and users.

All it takes is only to generate the fields ID either automatically or by the user. to reference them in the requests. the permission can be assessed class based

it is possible to write such feature without amending the source code of Django but it will be more complex. Because it require tracking the fields in django and provide them with ID's.

Problem

This will save time in development .. allow using rest frame work in comparable way to graven.

Request or proposal

request

Additional Details

Actually I have got too deep into the implementation of Django to confirm whether I will be a part of creating this feature or not. But I think it is not a complicated feature. Django team does not need to build the automation of the queries. Just adding a mechanism of creating (1) fields unique identifiers as automated attribute or an attribute that is specified by the developer (2) adding manage.py instruction to resolve conflicts or to add the unique ID of the fields directly or identify their clashes.

I do not think it can take a long time. It is possible to set a DB of the fields architecture (or through a special app for that) but the security issues will be on the developer's own risk

Implementation Suggestions

#in the field class
def get_field_uid(app_label, model_name, field_name):
return f'{app_label}{model_name}_{field_name}

class Field(RegisterLookupMixin):
non_db_attrs = (
'field_uid'
)

def init(
self, field_uid =None):
if field_uid ==None:
self.fiedl_uid = self._get_field_uid()

#I think that might be pretty much it

[github-actions]

Thank you MoonspicAI for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[timgraham]

The usefulness of this seems questionable, although I don't completely understand the use case very well based on what you wrote.

I don't think 80% of Django projects would make use of it, and since it can be done as a third-party I think that would be the way to go for now. If you did have a third-party library that implemented the idea, that would help to make your proposal more concrete. And if the library became very popular that would strengthen the proposal for including it in Django.

p.s. I closed the duplicate Trac ticket.