chris.giteaandClaude Sonnet 5
082beec1b9
geocoding.providers-json and recognition.providers-json were each a
single STRING preference holding a JSON-encoded array, rewritten whole
on every edit through GeocodingProviderEditView/
MaintenanceRecognitionPane.addProvider() -- structured, repeated data
forced into a scalar because PreferenceType had nowhere else to put
it. Replaces both with real tables (geocoding_provider,
recognition_provider) in the settings database, via plain-JDBC
repositories -- not Spring Data JDBC, for the same reason
SettingsDatabase itself avoids publishing a JdbcOperations bean.
*.active-provider stays a plain preference: it only ever names one of
these rows, so there's no "at most one active" invariant worth
enforcing in the repository.
Each repository migrates its own legacy JSON blob out of
preference_value on construction, guarded by its own sentinel,
independent of PreferenceService's own YAML-import sentinel so each
piece could in principle ship on its own schedule.
@DependsOn("preferenceService") is load-bearing here: without it nothing
guarantees that YAML-to-database migration has already populated
preference_value before a provider repository goes looking for its
row there.
PlaceSearchService/RecognitionService/GeocodingProviderEditView/
MaintenanceRecognitionPane/MaintenanceGeoView keep their exact public
method signatures (providers()/saveProviders()/activeProvider()/
saveActiveProvider()) -- only PlaceSearchService and RecognitionService
needed a new constructor dependency.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
