Bug 1093948

This is a placeholder for an upcoming patch, once the lawyers look it over. Here are the notes so far:

---

Support for metric traits and call times in Cassandra storage

Traits are stored into one table, call times one table.

There is a secondary index on call name in Cassandra. (Unclear if this is
really needed, but required when doing filtered queries. Unfortunately
the UI does partial search only.)

TTL is used for expiry. No more need to purge this data hourly.

Migration tooling added but not really tested.

Things yet to do:

Paging and custom sorting doesn't work at all. There is lots of work to
support sorting, less for paging.

The UI shows the latest trait value and timestamp when data was last
reported, not when it changed. To display properly, need to access (the entire)
history of a schedule, but this might be too many round trips for this piece of
data. The UI can probably change to remove this, or the UI can simply retrieve
all history.

Possible issues:

Hard to do data paging in Cassandra. Since custom sorting isn't supported,
the entire result set needs to be retrieved and sorted in memory. (This is what
a 'real database' does in memory.)

Cassandra does have some support for ranges on hashed fields but would need to build
infrastructure around this. PageControl could hold this token, possibly.

Purging of duplicate history items happens weekly. The reason is that traits
are updated usually every hour to 24 hours. With a small window, there are
few duplicates. The window to look back is about 8 days. Even if a trait
doesn't change, the history table will have duplicates.

How to support runtime change of TTL? Currently the server must be restarted
to change the TTL. Older data not changed. (Same issue exists for metrics, though.)

TODOs:
* The UI requires extra data pulled from Oracle. Can fields (display name) be duplicated in traits table?
* Documentation (of course)