3 ms·
Why don't you think sqlite is a good fit for logging? Given the extensive testing including crash testing, it's plausibly more robust than plain text - because
by emn13 10y ago
Why don't you think sqlite is a good fit for logging?
Given the extensive testing including crash testing, it's plausibly more robust than plain text - because you're almost surely not using any kind of fsync's in your plain-text logger, so that text file isn't as incorruptible as you may think. And you may write a buggy logger, or use a buggy json implementation, or write incorrect error-recovery code when reading the file.
I'm skeptical that robustness is an argument in favor of plain text logging over sqlite.
- majewsky 10y ago> you're almost surely not using any kind of fsync's in your plain-text logger, so that text file isn't as incorruptible as you may think Agreed. But if the log file is corrupted, then a plain-text one will be easier to decipher for a human than any binary blob.
- mschwaig 10y agoWriting to files in general is a fairly difficult thing if you care about not losing any data under any circumstances, because you have to use the right syscalls for the semantics of your filesystem, which may somtimes be why you're looking at corrupted files in the first place. Correctly implemented transactions can prevent you from dealing with that. Maybe that's worth giving up easily readable, searchabe and processable textfiles, maybe not.
- JdeBP 10y ago> you're almost surely not using any kind of fsync's in your plain-text logger I am, though, and have been for many years. * http://untroubled.org/daemontools-encore/multilog.8.html http://untroubled.org/daemontools-encore/multilog.8.html * http://b0llix.net/perp/site.cgi?page=tinylog.8 http://b0llix.net/perp/site.cgi?page=tinylog.8 * http://smarden.org/runit/svlogd.8.html http://smarden.org/runit/svlogd.8.html * http://jdebp.eu./Softwares/nosh/guide/cyclog.html http://jdebp.eu./Softwares/nosh/guide/cyclog.html