This change can only live if we provide a way to fill metadata.

A trait object? A callback function?

For example, for Onyx Docs, we'd like to map an API key to an user, following the api key field of the Users table, but we could imagine a case where:

• OAuth authentication is used
• several keys are generated, maintained in a separate table

The first case would be covered by an attribute like [#TableMap("Users", User, "api_key"], to allow a generic behavior mapping a SQL query SELECT * FROM <table> WHERE <field> = <value> to a struct <type> (with here #TableMap providing <table>, <type> and <field>).

The other cases are less easy to map.

Sometimes, the API key will be managed by a service mesh and not by the application, and mapping between an user and the key would become the selection of the user from an user id provided by an header added by the service mesh (we could for example imagine a service mesh with a guard adding X-API-AUTHENTICATED: true and X-API-USER: 121000211 to the requests).

That makes me reluctant to offer a lot of automation.

To provide the type without an implementation won't be useful as to use it as a guard in Rocket, the application should impl FromRequest for APIKey, but can't: that behavior is reserved to the crates defining FromRequest (rocket) and APIKey (limiting-factor). A callback function would solve that issue nicely.