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.