v3: Redesign `Entity.fields`

[edan-bainglass]

Background

The QbFields system (introduced in #6245 and integrated with the Pydantic system of #6990) allows one to access the projectable (schema) fields of an Entity via Entity.fields.###, yielding type-aware flavors of QbField, which support QueryBuilder operations yielding QueryBuilder filters and projections.

Use cases

User-friendly QueryBuilder interface

QueryBuilder().append(
    Computer,
    filters=(Computer.fields.pk < 3) & (Computer.fields.label.like('%local%'),
    project=(Computer.fields.uuid),
)

representing the identical

QueryBuilder().append(
    Computer,
    filters={
        'and': [
            {'pk': {'<': 3},
            {'label': {'like': '%local%'}},
        ],
    },
    project='uuid'
)

Projectable fields discovery (from e.g., REST API)

@app.get('/projections')
async def get_computer_projections():
    return service.get_projections()

where

    def get_projections(self):
        return self.entity_class.fields.keys()

Construction

Presently (as of v2.8.0), Entity.fields are dynamically constructed in Entity._patch_qb_fields() called from Entity.__init_subclass__() (per Entity subclass). The method does the following:

1. Scans through the entity's ReadModel
2. Generates a type-aware QbField per model field
3. Assigns it to fields[field-name]
4. Assigns QbFields(fields) to self.fields

Present issue

The system triggers on import of the ORM class, regardless if the importer intends to make use of fields. Not ideal!

Proposed system

We currently define on each Entity class (and for subclasses) each field as a property. I propose here that we replace the property decorator with a queryable decorator.

More on how this would be implemented will be detailed shortly.