The first version of the YUMPS logging system is now implemented.
I posted
here about my struggles with deciding the best way to structure a log table.
Lacking a perfect answer, I tried to finesse the approach -- basically I wrote a fairly generic logging system where any code can make a call to log an event and pass any array of variables to log.
The log router uses configurable rules to decide which of multiple database Log Tables the event gets stored into. Most events might be routed to a generic main log file, but special events can be routed to specialist tables (or in fact saved to a file or emailed to an admin).
You could also if you wanted use different tables for storing errors vs warnings, or for routing specific kinds of events, etc.
The log system will automatically use table columns for the event fields if they exist, or else store them in a serialized text field if they do not. In this way I think I can combine the best of both worlds -- using very small efficient log tables for special kinds of events, and a generic table for most others -- and provide good searchability for most fields (which is the main driving force for supporting specialized columns in the log tables), even when using non-specialized log tables.
In addition to the generic administration grid for the log entries that i have shown before (which allows flexible browsing and searching), log items can also easily be moved between log tables -- allowing one to keep a large ARCHIVE table and a small main table, or use certain tables for longer term storage of questionable entries while clearing the rest.
It's extremely easy to add new log tables to the system and configure YUMPS so that it knows about them and makes them available to the admin. So adding custom logging features should be very easy for custom projects. In the screenshot below you can see I simply configured 3 log tables and told the system that entries can be moved from the main one to the other two.
At some later point I will add some options to configure periodic automatic moving of items from one table to another based on date or other fields.
The logging system also makes use of my Throttling component, which can watch for degenerate cases where something goes wrong and huge numbers of log entries start being created -- at which point it can temporary disable logging and alert the administrator about the problem (you learn to implement such things after a few experiences on donationcoder where 500 fatal error emails are sent in the course of 60 seconds).
Recent Posts
