BDMS-787 site_name script

[jeremyzilar]

What is changing

• The site_name field on well detail pages was always returning null because the legacy AMP Location table has a SiteNames column that was never included in the data transfer.
• site_name is derived from the alternate_ids array by finding the entry where alternate_organization == "NMBGMR" and returning its alternate_id value. No such entries existed in the database.
• This PR adds a one-time migration script (transfers/migrate_nmbgmr_site_names.py) that reads SiteNames from the legacy Location.csv and inserts the missing ThingIdLink rows with alternate_organization = "NMBGMR".

What the script does

• Reads PointID and SiteNames from transfers/data/nma_csv_cache/Location.csv
• Filters to rows with a non-null, non-empty SiteNames value (31,775 rows in the source)
• Matches each PointID to a Thing in the database (8,487 matched locally)
• Inserts a ThingIdLink row per match with alternate_organization = "NMBGMR" and alternate_id = SiteNames
• Skips rows that already exist, so it is safe to re-run after future well transfers

Test plan

• Confirm site_name returns the correct value for WL-0029 (Zwager domestic), RA-077 (Swingle Domestic), and AR-0056 (McDaniel Irrigation) after running the script on staging
• Run the script on staging: python -m transfers.migrate_nmbgmr_site_names
• Verify the script is idempotent by running it a second time and confirming it inserts 0 new rows
• Run on production after staging is confirmed

[jacob-a-brown]

Overall this looks good to me, though see comment below about using LocationId/nma_pk_location instead of PointID. I read through transfers/link_ids_transfer.py and the SiteNames column is never addressed.

[jacob-a-brown]

Consider using LocationId from the Locations table and match it to nma_pk_location in the Thing table to get the correct id since that is the primary key from NM_Aquifer and should therefore have more fidelity than PointID (there are some non-unique PointIDs in Locations)

something like

with session_ctx() as session:
    # Build a LocationId -> thing_id map for all matching wells in one query.
    location_ids = df["LocationId"].tolist()
    thing_id_by_location_id: dict[str, int] = {
        location_id: thing_id
        for location_id, thing_id in session.execute(
            select(Thing.nma_pk_location, Thing.id).where(Thing.nma_pk_location.in_(location_ids))
        ).all()
    }

then use LocationId subsequently instead of PointID. Something like

# Build candidate rows.
candidates: list[dict] = []
for row in df.itertuples(index=False):
    thing_id = thing_id_by_location_id.get(row.LocationId)
    if thing_id is None:
        continue
    candidates.append(
        {
            "thing_id": thing_id,
            "relation": RELATION,
            "alternate_id": row.SiteNames,
            "alternate_organization": ALTERNATE_ORGANIZATION,
            "release_status": RELEASE_STATUS,
        }
    )

[jeremyzilar]

Thank you @jacob-a-brown 🎉
I fixed it and then ran it again locally, and it looks like only one record out of the 8,487 records had a different location when using the old PointID approach (MB-1005 was the duplicate).

[ksmuczynski]

Looks good! Thanks @jacob-a-brown for the comment re: the Locations table and the nma_pk field, I was thinking this, too.