All ideas are welcome. Just because the Idea doesn't make it into the product immediately does not make it a bad idea.
In 6.6.2 logging introduced and stored in a flat file with webapp id and pageid exposed. To make this data useful for a client a minimum of one report with all records showing the WebAppName and Page Description should be available from admin reports or similar. This would require the log data to be stored in a table. This can be accomplished at the client site by a Consultant or a cient power user but should really be part of the platform itself. We should not be requiring client personnel to have to manually import the records and inner join them to Webapp and Page to make it useful. This is a key set of data for clients using client facing tools like dspMonitor where they could become independent of a full time consultant.
Paul Garner
Thanks for registering the idea. Please see the response from engineering below. With the concerns they highlight we won't be writing the logs to a database table due to space and performance implications.
There was concern from both support and development about performance and disk space when looking to write the logs to a database table. With a site under heavy load, there could be potentially be millions of entries created daily by all of the event executions/page loads.
We needed a way to ensure that ensure that performance of the site wasn't negatively impacted as the number of entries grew. Writing to the file system allowed us to create new log files daily. It also gives the dsp administrators the option to write the logs to a remote network path to avoid disk space issues on the web/database server machines that could negatively affect the dsp site.
