Subject: Re: [boost] [boost.log] set_open_handler() and set_close_handler() for text_multifile_backend?
From: Jamie Allsop (ja11sop_at_[hidden])
Date: 2010-11-09 20:35:51
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk