The database model create is in a different place (see _should_intercept)
It's intended for conditions (should x request be profiled or not)
We would have to mutate the request object itself
Why not view_name?
view_name could be used as the custom ID field instead of adding a new one
but it's not used in the request view (rows or cards) as of 5.0.1 the path is
The user has their own specific logic in which they'd separate out a request of the same path. GraphQL being a perfect example.
But you can do it with profiling
Profiling is different feature in django-silk (as of 5.0.1). Yes, you can use a silk_profile(name='name') decorator, but that's not a delineating a different request.
Assume #606, GraphQL requests aren't possible to distinguish at this point.
Sometimes a path has nuance to it, e.g. business logic inside the
HttpRequestcan be used to label the request so its not randomRequest model
1. New field: Custom label field
If there was a
label/titleto give requests for what to show in /silk/requests/ instead ofrequest.path2. New callback: In
RequestModelFactory.construct_request_model()This is to customize the contents of
models.Request.It will have accessed to to the django
HttpRequestviaself.requestto fetch any necessary metadata and write a labelWhy not
SILKY_INTERCEPT_FUNC?_should_intercept)Why not
view_name?The user has their own specific logic in which they'd separate out a request of the same path. GraphQL being a perfect example.
But you can do it with profiling
Profiling is different feature in django-silk (as of 5.0.1). Yes, you can use a
silk_profile(name='name')decorator, but that's not a delineating a different request.