Finalize and implement data storage plan for project_metrics

after further discussion, it seems we've settled on A) -- given the amount of data we'll be storing, it seems risky to have everything in one giant table, which would make all the queries for individual metrics (which is mostly what we'll be querying for) less performant. C) isn't really a viable option at this time.

just a note that because of the discussion of generalization going on over at #889886: Create a metrics backend framework module, i've decided on an object_type/object_id/timestamp primary key -- this will enable modules to track metrics for more than just nodes.

re: my idea in #2: it's dumb, because we're using one table per metric, and if somebody wants to track a metric across object types, they can just create separate metrics for each type. so, removing this...

regarding #889888-3: Design, document and invoke an info hook for modules to advertise metrics they support -- that's a real can of worms. fortunately mikey_p came up with an idea that i think will work better for our situation:

mikey_p: hunmonk: well with this approach it's basically just a sync up of the data from hook_metrics_times_info, and a schema_status table
mikey_p: and then the schema can check that table and know either what columns or what tables should exist in the DB
mikey_p: and can build it's hook_schema appropriately
mikey_p: then you check if it's a new metric, (i.e. not in our metrics_schema table) - if not, then create the new storage table for that metric, and add a row to the metrics_schema table
mikey_p: then when hook_schema is run it can check metrics_schema for a list of storage tables
hunmonk: mikey_p: and if a metric is deleted, same thing i guess
mikey_p: yeah, although I don't know what the logic should be there...i assume that disabling a module wouldn't delete it's storage table
hunmonk: right, that is a problem
mikey_p: but basically a metrics_times_schema table would just store the state of the schema
hunmonk: i guess it would be a) module has an installed schema version, b) module is disabled = keep the metric
mikey_p: maybe just add a ui to metrics_times at some point for deleting the storage, and whenever you delete a table, delete it's entry from {metrics_times_schema}
hunmonk: mikey_p: yes, i think this can work.  if we report the schema from that table, and edit that table when we call our info hook, i think things can stay clean

so i'll work up that new table and the logic to handle addition/deletion of new tables.

the solution suggested in #4 has now been implemented, and quite elegantly if i do say so myself... ;)

updated code available at http://drupalcode.org/viewvc/drupal/contributions/sandbox/thehunmonkgrou...

i think this issue is done. the storage system is in place, now we just need to populate it with data.

no official project exists for this module yet. moving to redesign queue for now, and retagging

moving this issue to the new module's home...

just a note that because of the rewrite mentioned at #889886-13: Create a metrics backend framework module, this has changed a fair amount. storage is now pluggable per metric -- the default handler will be the one described here, but i'll be extending it to support a variable number of columns.

i'll also probably add another storage handler that will put all metrics in one table, so we can decide which one we'd like to use for each particular metric.