DB Schema migration about webvoteview HOT 9 CLOSED

Search votes is rewired, although it now is showing votes for rollcalls that don't have nominate fields, which used to be hidden. Default should be hide these from the search page because we should at least have conditionally estimated nominates within a few hours of any new votes being added to the db.

The vote pages work (if the nominate data exists). However, the links to member pages are broken.

Please note that I wrote a generic function to waterfall in views/search_list.tpl called waterfall. That might need to go somewhere else if we want to use it for the vote page as well.

from webvoteview.

Okay, I'm updating the original post here with the field names we need to fix.

from webvoteview.

This issue should also not be closed until all of the user-facing documentation is updated.

from webvoteview.

I believe we have two outstanding index issues here:

1. The fulltext index was set up for just description. I corrected this, but the build script should probably be updated to reflect the actual intent.
2. The sparse index for key_flags is not set up at all.

Other than that the schema move was a success.

from webvoteview.

The sparse index thing is still weird--I don't think it can be done in pymongo, so we overrode it with a javascript file that mongo runs directly in build_edits.sh.

@adamboche Where are the main indexes being built now? Probably somewhere in ingestion? We should ensure we all know where so as we update our fulltext indexing strategy it's all set up properly.

from webvoteview.

Post-launch, we need to deal with the fulltext thing.

from webvoteview.

from webvoteview.

from webvoteview.

Isn't this going to index a massive amount of garbage?

from webvoteview.