Subject: Re: [boost] [boost.log] set_open_handler() and set_close_handler() for text_multifile_backend?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-11-10 12:12:27
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.