Closed svenbw closed 3 months ago
Thanks for the PR @svenbw 👍
Can you help me understand the use case for this? Is it because you want to monitor usage for a route like GET /posts/{post}
but not count all requests regardless of which post, but instead monitor GET /posts/1
, GET /posts/2
, ... separatly?
I like the idea of having a "properties" array sitting there and you can then basically add whatever you want to it - not just route parameters. For example, you could decide to measure a route's usage for admins $parameters['is_admin'] = true
separately from non-admins.
I indeed want to monitor routes with arguments different arguments seperatly to track which user accessed which post.
The new parameters
column will take all the route parameters and store them as a json array. From the route name and the route parameters it should be possible to reconstruct the original (full) route url if preferred.
I didn't add support to add additional properties: I wanted to keep the spirit of the library and log the information about the routes. Since it's additional content I think that this might require another column.
select
is still in place but I split up fields and column selectionI am planning on releasing a new major version of this package with this PR, but due to holidays this will not be for the next 2 weeks.
Thanks for the reviews and help.
Description
All requests are logged however any parameters which are configured in the route are not, this PR adds the support to log all the parameters to the database as a json string.
Since this might not be the desired behavior there is a new configuration option in the config file
store_parameters
that stores the parameters of the requests if set to true. This option is also available as an environment variableROUTE_STORE_PARAMETERS
.Does this close any currently open issues?
No
Type of change
Please delete options that are not relevant.
...
Any other comments?
...
Checklist