Component
Feature Description
Remove pre-release legacy support for server ingested/wrong row ids...
See instructions below:
Remove legacy observation row-id support (pre–go-live)
Older builds could have Watermelon id ≠ observation_id after pull. The app now aligns them on ingest and keeps dual lookup / merge-by-column for those rows. Before go-live, drop that if you have no production DBs with mixed ids (or after a one-off cleanup).
Preconditions
Code to simplify/remove
-
WatermelonDBRepo.findObservationRecord
Remove the method. updateObservation, deleteObservation, and optionally getObservation / markObservationAsSynced should use observationsCollection.find(stableId) only (or keep getObservation’s existing try/find + query only if you still want lookup-by-column for debugging).
-
markObservationsAsSynced
Revert to a single query: Q.where('id', Q.oneOf(ids)) (ids from sync are domain observationId, which must equal row id).
-
ObservationMapper.observationIdFromDBModel
Either delete and use model.observationId everywhere (assert non-empty in dev), or keep model.observationId || model.id as a tight fallback with a console.warn if !model.observationId.
-
Tests
ObservationMapper.syncIdentity.test.ts can keep asserting observationId column wins when it differs from id only if you still support fat rows in tests; otherwise simplify to id === observationId.
- Remove any test copy that describes “legacy ingested rows.”
-
Comments
Search the repo for legacy, observation_id column, findObservationRecord, and clean up.
Quick verification after removal
npm test
- Manual: create observation → sync → second device pull → edit → push; list/detail show one
observation_id, no duplicate server rows.
Component
Feature Description
Remove pre-release legacy support for server ingested/wrong row ids...
See instructions below:
Remove legacy observation row-id support (pre–go-live)
Older builds could have Watermelon
id≠observation_idafter pull. The app now aligns them on ingest and keeps dual lookup / merge-by-column for those rows. Before go-live, drop that if you have no production DBs with mixed ids (or after a one-off cleanup).Preconditions
observationsrow whereid != observation_id, either delete test data or rewriteidto matchobservation_idper Watermelon rules (see their docs on changing primary keys—often safer to export/re-import or clear pre-release installs).Code to simplify/remove
WatermelonDBRepo.findObservationRecordRemove the method.
updateObservation,deleteObservation, and optionallygetObservation/markObservationAsSyncedshould useobservationsCollection.find(stableId)only (or keepgetObservation’s existing try/find + query only if you still want lookup-by-column for debugging).markObservationsAsSyncedRevert to a single query:
Q.where('id', Q.oneOf(ids))(ids from sync are domainobservationId, which must equal rowid).ObservationMapper.observationIdFromDBModelEither delete and use
model.observationIdeverywhere (assert non-empty in dev), or keepmodel.observationId || model.idas a tight fallback with aconsole.warnif!model.observationId.Tests
ObservationMapper.syncIdentity.test.tscan keep assertingobservationIdcolumn wins when it differs fromidonly if you still support fat rows in tests; otherwise simplify toid === observationId.Comments
Search the repo for legacy, observation_id column, findObservationRecord, and clean up.
Quick verification after removal
npm testobservation_id, no duplicate server rows.