You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes I need to log to different files based on some log metadata. Imagine for instance of having a variable number of entities handled by your application, it can be useful to log actions regarding each entity in a separate file.
This can already be done with metadata_filter if you know in advance which are the entities you manage. But, if entities can change at application runtime you can't.
My proposal is to allow specifying the path of the log file as a {module, function} tuple, the function will be called giving log metadata as argument (maybe also log_level?) and it should return the log file path where the log entry should be written.
What do you think about? I can submit a PR if you think is worth.
PS: this is somehow related to the first part of #18 but it allows a more fine customization of the path. I'm perfectly ok also with the solution proposed in #18 if you think is safer.
The text was updated successfully, but these errors were encountered:
Sometimes I need to log to different files based on some log metadata. Imagine for instance of having a variable number of entities handled by your application, it can be useful to log actions regarding each entity in a separate file.
This can already be done with
metadata_filter
if you know in advance which are the entities you manage. But, if entities can change at application runtime you can't.My proposal is to allow specifying the path of the log file as a
{module, function}
tuple, the function will be called giving log metadata as argument (maybe also log_level?) and it should return the log file path where the log entry should be written.What do you think about? I can submit a PR if you think is worth.
PS: this is somehow related to the first part of #18 but it allows a more fine customization of the path. I'm perfectly ok also with the solution proposed in #18 if you think is safer.
The text was updated successfully, but these errors were encountered: