Differences

This shows you the differences between two versions of the page.

--- mantisbt:performance_counters_requirements [2006/09/28 02:45] – Out of box counters and new calculation functions. vboctor
+++ mantisbt:performance_counters_requirements [2011/11/16 07:38] (current) – The page rendering was broken (maybe since new PHP version on mantisbt.org). Added new line to fix it at end of file. atrol
@@ Line 12: / Line 12: @@
    * mantis_perf_counters_def_table
-     * perf_counter_def_id
+     * id
      * name = string (64)
+     * description = string (255)
      * function = Name of function to call to calculate the value (this is prefixed by perf_counter_calc_*).
      * params = string (255) - format is typically as follows: project_id=2,user_id=0,field3=value3
      * frequency = frequency in hours (e.g. 24 for performance counters that should be calculated daily).
      * enabled = boolean
+     * next_calc_due - datetime - the timestamp when the next calculation is due.
+     * date_created - datetime
+     * last_updated - datetime
    * mantis_perf_counters_val_table
-     * perf_counter_val_id
+     * id
      * perf_counter_def_id
-     * timestamp
+     * timestamp - timestamp where the counter was calculated
-     * value (int) or double?
+     * value (int)
 ===== Cronjob Script =====
@@ Line 30: / Line 34: @@
 <code>
-for each enabled counter
+for each enabled counter that is due for calculation
-   if no previous recorded values or last recorded greater than "frequency" hours then
       calculate the performance counter and record the value.
+      update the next_calc_due on the counter definition.
 </code>
@@ Line 44: / Line 48: @@
      * Modify counters: We shouldn't really be able to change the parameters sent to the counter calculator.  If done then we need to delete all historical values.  Hence, delete/add will be used.
      * Delete counters: Deletes the counter definition as well as all historical values.
+     * Enable/Disable Counters
 ===== Out-of-the-box-counters =====
@@ Line 81: / Line 86: @@
        * we should add a view access level to the definition table.
      * The other option is to store this information in the database and have the access control implemented in the reports that access the performance counters.
+     * Ability to use saved filters to calculate values for counters.  For example, number of issues matching a filter would be the value of the counter.
+     * Template Counters - it would be very useful to have a counter that counts the number of open issues for a developer or a category, then be able to run this counter for every developer or every category, rather than having to define a counter record per developer or per category.
 ===== Feedback =====
-Put your feedback in this section.
+I don't understand the original premise, that Mantis only has a snapshot of information as at the current time. It already contain hsitorical data with fields storing when a task was submitted, etc. So the example above "number of issues that has priority 1 and have been open for more than 3 days" is already trivial. ''SELECT * from  bug WHERE date_submitted > now() - 3 AND priority = 1''
+In projects I've worked on, de-normalising the database in this way has often created a lot more work in the long term than just building more advanced queries. If there is historical information which is lost over time, then perhaps an extra table to keep that information in a revisioned format would be a better option. But from what I've seen so far of Mantis, this appears to not be a problem. --- //aristedes 2007/04/14 04:04//