db v070

[smnorris]

• use bcfishpass.observations and observation_key (vs observations_vw and unstable fish_observation_point_id)
• reduce use of nested views
• reduce use of fwa functions in view/materialized view queries

[smnorris]

Output column observation_key_upstr is not actually used anywhere when generating outputs.
It could be dropped but is useful for QA.

[smnorris]

A simple fix would be to only include upstream observation keys within the same watershed group. Retaining trans-wsg boundary species observed is required to correctly code 'observed' habitat on trans-wsg rivers

[smnorris]

@andrewp-CWF I've tweaked the workflow to take the list of plans from bcfishpass.wcrp_watersheds - but auto_rank.py has a hard coded list of choices and current PR fails https://github.com/smnorris/bcfishpass/actions/runs/17867255026/job/50820187043

Is it ok to modify auto_rank.py to also pull the choices from bcfishpass.wcrp_watersheds?

[smnorris]

Ok, looking closer they are actually quite different lists. I'll revert to running auto_rank.py on the list that is present in that script and the existing workflow in the CWF repo.

[smnorris]

Latest failure appears unrelated to anything in the PR - the only change to the query that is timing out is a move from view streams_habitat_known_vw to table streams_habitat_known. New table is indexed the same as the view was. It seems something odd is going on with the connections to the db, these queries do not take that long (relatively speaking), and the point of failure is not consistent.

I'll call the script locally and QA results. If all looks fine I'll migrate the prod dbs and merge the PR. We'll see if db connection issues remain with the prod dbs.