[boost.log] set_open_handler() and set_close_handler() for text_multifile_backend?
I think it makes a lot of sense for these methods to be available for the text_multifile_backend as they are for the text_file_backend. My use case is that I am logging data out in html format and being able to log data out as individual html files for browsing through later on. Being able to have an html header and footer added as files are opened and closed makes a lot of sense for this backend. Jamie
Jamie Allsop wrote:
I think it makes a lot of sense for these methods to be available for the text_multifile_backend as they are for the text_file_backend. My use case is that I am logging data out in html format and being able to log data out as individual html files for browsing through later on. Being able to have an html header and footer added as files are opened and closed makes a lot of sense for this backend.
Actually I spent some time looking at the implmentation of this and there doesn't seem to be a sensible way to implement this. I think what I really want is some sort of 'id' based file rotation. In that light I suppose I could use the time_based_rotation and supply my own function that rotates based on a changing 'id'. Perhaps this could be generalised in the library to be a 'triggered_rotation' where some of the current implementations happen to be time based? Jamie
On 11/09/2010 04:57 AM, Jamie Allsop wrote:
Jamie Allsop wrote:
I think what I really want is some sort of 'id' based file rotation. In that light I suppose I could use the time_based_rotation and supply my own function that rotates based on a changing 'id'. Perhaps this could be generalised in the library to be a 'triggered_rotation' where some of the current implementations happen to be time based?
I'm not sure I understand. Do you need a way to customize the logic of detection when to rotate the log file? What is the 'id' then?
Andrey Semashev wrote:
On 11/09/2010 04:57 AM, Jamie Allsop wrote:
Jamie Allsop wrote:
I think what I really want is some sort of 'id' based file rotation. In that light I suppose I could use the time_based_rotation and supply my own function that rotates based on a changing 'id'. Perhaps this could be generalised in the library to be a 'triggered_rotation' where some of the current implementations happen to be time based?
I'm not sure I understand. Do you need a way to customize the logic of detection when to rotate the log file? What is the 'id' then?
I'm saying that you allow a predicate to be specified that determines when a file rotation occurs for the text_file_backend. You can specify this predicate on construction (keywords::time_based_rotation) or by calling set_time_based_rotation(). I'm saying that you obfuscate this somewhat by calling it 'time_based_rotation' since, from what I can see it is a simple predicate based rotation. In other words I could supply any 'trigger' function that would cause a rotation. The name hid the general capability from me. I'm suggesting you rename this to something more general like, 'predicate_based_rotation' or 'rotation_trigger' or 'rotation_predicate'. Of course you can go on to show how you provide some out-of-the-box time based predicates. In my use case I have a number of test cases (conceptually at least) and as I move to a new test case (a new test case 'id') I want the results to be logged to a separate file. I'd therefore want to provide a predicate that knew when the 'id' changes and cause the file to rotate. From what I understand this is pretty easy for me to do using a time_based_rotation predicate? The name however really should be more general to reflect more accurately how it can be used.
On 11/10/2010 04:35 AM, Jamie Allsop wrote:
Andrey Semashev wrote:
On 11/09/2010 04:57 AM, Jamie Allsop wrote:
Jamie Allsop wrote:
I'm not sure I understand. Do you need a way to customize the logic of detection when to rotate the log file? What is the 'id' then?
I'm saying that you allow a predicate to be specified that determines when a file rotation occurs for the text_file_backend. You can specify this predicate on construction (keywords::time_based_rotation) or by calling set_time_based_rotation(). I'm saying that you obfuscate this somewhat by calling it 'time_based_rotation' since, from what I can see it is a simple predicate based rotation. In other words I could supply any 'trigger' function that would cause a rotation. The name hid the general capability from me. I'm suggesting you rename this to something more general like, 'predicate_based_rotation' or 'rotation_trigger' or 'rotation_predicate'. Of course you can go on to show how you provide some out-of-the-box time based predicates.
I see. Yes, the suggestion seems reasonable. I guess, it was naive of me to assume that the predicate could only implement some time-based rotation criteria.
In my use case I have a number of test cases (conceptually at least) and as I move to a new test case (a new test case 'id') I want the results to be logged to a separate file. I'd therefore want to provide a predicate that knew when the 'id' changes and cause the file to rotate. From what I understand this is pretty easy for me to do using a time_based_rotation predicate? The name however really should be more general to reflect more accurately how it can be used.
Yes, that should be possible, given that the predicate should have its means to discover the current test case id.
participants (2)
-
Andrey Semashev -
Jamie Allsop