govtrack/govtrack.us-web

…ded database back to 1789 today

We've been using the old pure-Python memcached library in production. The new one might be faster but also errors when values exceed the max value size, which is helpful for diagnosing cache problems.

…hed limits

So every request for a prognosis, especially in bill search results, was hitting the hard disk
for each bill.

To stay within the 1 MB value limit, we only cache the prognosis number for each bill,
not the explanatory text. The explanatory text is only used on bill pages, so we keep
going to disk for those pages.

One was missing an index. Bulk load search results.

…ache was cleared

…lated bills

…and add more things they should do to get started on govtrack

* show vote details for cloture votes
* hide 'Considered by House Committee on Rules'
* merge entries for 'Text Published' for 'Reported in House/Senate' status with 'Reported by ...' enties with committee report links in cases where there isn't a REPORTED status change, e.g. if the report comes after the ordered reported date or when there's a report in the second chamber

…in case of incorrect titles

…when there's a vote summary (I previously did the case of a bill summary)

… and into the only view where it is displayed

It was cached, but the times where there's a cache miss -- expecially on site startup -- might be expensive.

It was in template_context_processors so it was executing on every page load, and even though it was cached (assuming the cache was working), it probably slowed down site startup times as every process made the query before the first one successfully cached the result.

…d gop.com and matching perceptual lightness

Also it's nice to have a less wide text run.

…rson's bills

…ion since she was appointed