in reply to Efficient log format

The trick, I think, is to not try and make a format that does both efficient for writing and efficient for reading. Instead, create a format that's easy to write to. Then, when you need to read from it, you do so. In most cases, logs are always written to, but rarely read from.

AND ... if you correctly encapsulate the writing of the logfile from the rest of the code, you can change the format later, as needed.


My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^2: Efficient log format
by jeepj (Scribe) on Mar 19, 2008 at 08:48 UTC

    I'm afraid I can't agree with you. Firstly because in our context, I'm speaking about logs, but these are not like servers' logs, this are results from analysis/correction scripts, and results are important, verified, and re-used in some cases to take further actions. But I was propably not clear enough on this point (and the word 'log' is perhaps not the better one in this case, but english is not my mother tongue, sorry ;) )

    Secondly and more generally, I think that putting in place a good and well formatted logging does not require a lot of efforts if done at an early stage. This ease the addition afterwards of new information and the retrieve of this information by other processes.

    I however fully agree that this must be encapsulated in a separated library, to ease the log of information in the scripts. But I'm not sure that changing the format later is easy, as you have to translate all past logs to the new format

      Yeah, that's not a log. That's a "result" or "product". You want to think those through. Confusion sucks. :-)

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?