29-Jan-2026 — Understanding InputSource and EventPopulation #110 #119
This article explains the InputSource and EventPopulation enumerations, how they work together, and how their usage evolved through issues #110 and #119.
Overview
NGX-Ramblers supports two main ways for groups to manage their walk and event data:
- Local management — Walks are created, imported, and maintained in the local database
- Walks Manager sync — Walks are synced from the Ramblers Walks Manager API to the local database
Two key enumerations control this behaviour:
- EventPopulation — A group-level setting that determines how walks are sourced
- InputSource — A per-event field that records how each event entered the system
EventPopulation (Group Configuration)
This setting is configured per-group in System Settings and determines how walks/events are sourced.
Before Issue #110
| Value | Behaviour |
|---|---|
LOCAL |
Walks created/imported locally, stored in local database |
WALKS_MANAGER |
Queried Ramblers API live for every request — slow and lost local enrichments |
HYBRID |
Blended local + live Ramblers data together |
After Issue #110
| Value | Behaviour |
|---|---|
LOCAL |
Unchanged — walks managed locally |
WALKS_MANAGER |
Syncs from Ramblers API to local database, then queries locally — faster and preserves enrichments |
HYBRID |
Removed — no longer needed as WALKS_MANAGER now syncs locally |
After Issue #119
| Value | Behaviour |
|---|---|
LOCAL |
Unchanged |
WALKS_MANAGER |
Queries local database only — all API routing removed. Setting now only controls which sync job runs and UI display logic |
InputSource (Per-Event Metadata)
This field is stored on each event and records how that event entered the system.
Before Issue #110
| Value | Meaning |
|---|---|
FILE_IMPORT |
Imported from a CSV file |
WALKS_MANAGER_IMPORT |
Imported when switching from Walks Manager to Local population |
URL_TO_ID_LOOKUP |
Minimal record linking SEO-friendly slug to Ramblers ID |
MANUALLY_CREATED |
Created manually via the UI |
UNKNOWN |
Legacy or unknown source |
After Issue #110
| Value | Meaning |
|---|---|
FILE_IMPORT |
Unchanged |
WALKS_MANAGER_IMPORT |
Deprecated — redundant with WALKS_MANAGER_CACHE |
WALKS_MANAGER_CACHE |
Added — synced from Ramblers API to local cache |
URL_TO_ID_LOOKUP |
Removed — no longer needed |
MANUALLY_CREATED |
Unchanged |
UNKNOWN |
Unchanged |
After Issue #119 (Current)
| Value | Meaning |
|---|---|
FILE_IMPORT |
Imported from a CSV file |
WALKS_MANAGER_CACHE |
Synced from Ramblers Walks Manager API |
MANUALLY_CREATED |
Created manually via the UI |
UNKNOWN |
Legacy or unknown source |
The Problem Solved by #110 and #119
Before #110
Groups configured with EventPopulation.WALKS_MANAGER had a poor experience:
- Every page view triggered a live API call to Ramblers
- This was slow (network latency on every request)
- Local enrichments were lost (edit history, custom fields, migration tracking)
- The UI showed stale or incomplete data
After #110
All Walks Manager data is now synced to the local database:
- A background sync job pulls data from the Ramblers API
- Data is stored locally with
InputSource.WALKS_MANAGER_CACHE - Queries are faster (local database)
- Local enrichments are preserved
However, some code still routed queries to the live API based on EventPopulation.
After #119
All routing logic was removed:
- Every query goes to the local database regardless of
EventPopulation - The
EventPopulationsetting now only controls:- Which sync job runs (Ramblers API sync vs manual entry)
- UI display logic (e.g., showing "Sync from Walks Manager" button)
Current Valid Combinations
| EventPopulation | InputSource Values | Meaning |
|---|---|---|
LOCAL |
FILE_IMPORT, MANUALLY_CREATED |
Group manages walks locally via CSV import or manual entry |
WALKS_MANAGER |
WALKS_MANAGER_CACHE, MANUALLY_CREATED |
Group syncs from Ramblers, can also create walks locally |
Technical Details
The Problematic Code (Before #119)
// WalksAndEventsService - BEFORE
async queryById(walkId: string): Promise<ExtendedGroupEvent> {
switch (this?.group?.walkPopulation) {
case EventPopulation.WALKS_MANAGER:
// PROBLEM: Fetches from live API, losing local enrichments
return this.ramblersWalksAndEventsService.queryById(walkId);
case EventPopulation.LOCAL:
return this.localWalksAndEventsService.queryById(walkId);
}
}
The Fix (After #119)
// WalksAndEventsService - AFTER
async queryById(walkId: string): Promise<ExtendedGroupEvent> {
// Always use local database
return this.localWalksAndEventsService.queryById(walkId);
}
Why Local Data Matters
The local database contains enriched data that the Ramblers API doesn't provide:
| Field | Local Database | Ramblers API |
|---|---|---|
events |
Edit history with timestamps | Not available |
migratedFromId |
Migration tracking | Not available |
fields.venue |
Local venue details | Not available |
fields.riskAssessment |
Risk assessment data | Not available |
By always querying locally, we preserve all this enriched data.