GoogleChrome / GoogleChrome/webstatus.dev
refactor(lib/gcpspanner): unify entityWriter mappers to use MergeAndCheckChanged to skip redundant mutations
- Dominant language
- Go
- Stars
- 254
- Forks
- 62
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 64
Description
## Feature Request / Refactoring Proposal
Currently, `entityWriter` in `lib/gcpspanner/client.go` uses `mapper.Merge(input, existing)` during `upsert` and `update` operations, and always buffers a `spanner.InsertOrUpdateStruct` mutation even if no fields have changed between `existing` and `input`.
In contrast, `entitySynchronizer` uses `mapper.MergeAndCheckChanged(input, existing)`, which returns `(merged, hasChanged bool)` and skips mutation creation when `hasChanged` is `false`.
### Proposed Changes
1. **Unify Mapper Interfaces:** Update `writeableEntityMapper` interface in `lib/gcpspanner/client.go` to require `MergeAndCheckChanged(ExternalStruct, SpannerStruct) (SpannerStruct, bool)`.
2. **Skip Mutation Buffering in `entityWriter`:** In `entityWriter.createUpdateMutation` (and related helpers like `prepareUpdateMutation`), check `hasChanged`. If `hasChanged == false`, return `nil` mutation to skip `txn.BufferWrite()` while still returning the entity ID if required.
3. **Update Spanner Mappers:** Refactor mappers across `lib/gcpspanner` to implement `MergeAndCheckChanged`.
### Benefits
- **Reduced Spanner Mutation Load:** Prevents buffering and executing redundant write mutations in ReadWriteTransactions when entity data has not changed.
- **API Consistency:** Eliminates the dual pattern between `Merge` and `MergeAndCheckChanged` across `lib/gcpspanner`.
Contributor guide
Research direction
Start in lib/gcpspanner/client.go by reading the writeableEntityMapper interface and the entityWriter upsert/update flow, especially createUpdateMutation and prepareUpdateMutation. Then inspect the Spanner mappers across lib/gcpspanner. Done means all mappers use MergeAndCheckChanged and unchanged entities produce no buffered mutation while required entity IDs remain available.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, databases
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 64/100