mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-18 21:16:47 +00:00
michael-bohr
84b51a8af5
Two consumers decide whether a candidate place is one the trip already has, and they spelled the rule out separately: the bulk importers ask an in-memory set (isPlaceDuplicate), while findDuplicatePlace asks the database because its caller needs the matched row's id. The two had drifted — the SQL copy falls back to a coordinate match for a NAMED candidate, which the in-memory copy deliberately never does, since that would merge the restaurant and the bar at the same address. The order now lives once in @trek/shared as placeMatchStrategies(), and each consumer is a mechanical interpreter of it: provider id (the only part that survives a rename, #1550), then name, then coordinates and only when there is no name. Adds PlacesService.findMatchingPlaceId as the public door for an importer that has to link to the existing place rather than merely skip the candidate. findDuplicatePlace stays private behind it — it also returns google_ftid for the bulk importer's backfill, which is that caller's business and not part of "which place is this?". No behaviour change for either existing caller. The coordinate branch is currently unreachable from the one call site, which sits inside an isPlaceDuplicate() guard that has already matched on name and returned; the drift only bites once something calls it standalone. COORD_DEDUP_TOLERANCE and externalIdsOf move to shared and are re-exported from places.helpers, so collections.service and places.service keep their imports.