gmaps: emit both 'longitude' and 'longtitude' JSON keys#275
Open
boredland wants to merge 1 commit into
Open
Conversation
The Entry.Longtitude field has shipped with the misspelled JSON key "longtitude" since the project started. The CSV exporter already uses the correct spelling (CsvHeaders[14] = "longitude"), but the JSON output and the Go struct field are still misspelled. Downstream consumers that read .json results either copy the typo or work around it (we hit this in trinkhallen-data while parsing results to confirm OSM enrichment matches). Renaming the JSON tag outright would break every existing parser, so: - MarshalJSON emits both "longtitude" (preserved verbatim) and "longitude" so downstream consumers can migrate without a flag day. - UnmarshalJSON accepts either key; "longtitude" wins when both are present so existing data files round-trip byte-identical. The Go struct field is intentionally left as Longtitude — renaming it would break every importer of the package, and the field is documented as deprecated in the comment so new code can prefer reading via JSON unmarshal into Longitude-tagged structs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
Entry.Longtitudefield has shipped with the misspelled JSON key"longtitude"since the project started. The CSV exporter already uses the correct spelling (CsvHeaders[14] = "longitude"ingmaps/entry.go), but the JSON output and the Go struct field still use the typo.Downstream consumers reading the JSON output either copy the typo into their schemas or have to work around it. I ran into this while wiring gosom into trinkhallen-data — naively reading
longitudefrom the result silently dropped every record because the actual key islongtitude.Fix
Renaming the JSON tag outright would break every existing parser, so this PR keeps the legacy key and adds the correctly spelled one as an alias:
MarshalJSONemits both"longtitude"(preserved verbatim) and"longitude"so new consumers can read the correct key and old consumers keep working.UnmarshalJSONaccepts either key;"longtitude"wins when both are present so existing data files round-trip byte-identical.The Go struct field is intentionally left as
Longtitude— renaming it would break every importer of the package. The field's doc comment now points new code at the correct JSON key.Tests
Two new tests in
gmaps/entry_test.go:Test_EntryMarshalEmitsBothLongitudeKeys— verifies the output contains both keys with the same value.Test_EntryUnmarshalAcceptsEitherLongitudeKey— verifies legacy, modern, and both-present inputs all populateLongtitudecorrectly.Full test suite (
go test ./gmaps/) andgo vet ./gmaps/both pass. ExistingTest_EntryFromJSON*tests untouched.Compatibility
"longitude"key appears alongside."longtitude"parsed. Now: either key parses.Entry.Longtituderemains exported with the same type.