The implementation follows the existing database model: route [table] remains the primary dataset identifier, and fetchViewDatasets(table, "alerts") keys the lookup on (view_type, primary_dataset)
At some point we should revisit this decision. We went along with it because it was the initially written plan, but at this point the real noun has become [view].
For example think of the use case where you want 2 views, both with the same primary dataset, but different secondary datasets.
Originally posted by @IamJeffG in #495 (comment)
The current implementation solved in #193 still treats the route [table] as the primary identifier for a dataset view. Related lookups such as fetchViewDatasets(table, "alerts") are keyed on (view_type, primary_dataset), which means the system effectively assumes there can only be one view of a given type for each primary dataset.
That made sense in the earlier model, where a dataset could have one map, one gallery, and one alerts dashboard. However, the introduction of secondary datasets changes the mental model. A view is no longer only “the map for dataset X.” It may be “a map using dataset X as the primary dataset and dataset Y as context,” or “a map using dataset X as the primary dataset and dataset Z as context.”
For example, we may want:
- A map view of
comapeo_observations by itself
- A map view of
comapeo_observations with territory_boundaries as a secondary dataset
- A map view of
comapeo_observations with satellite_alerts as a secondary dataset
- An alerts dashboard for
satellite_alerts with comapeo_observations as the secondary dataset
- Another alerts dashboard for
satellite_alerts with patrol_routes or community_reports as secondary context
Under the current model, several of these would collide because they share the same view_type and primary_dataset, even though they represent meaningfully different views.
This issue is to revisit that assumption and move toward a model where view is treated as the primary resource. Each view should be identifiable independently from its primary dataset and view type, likely by a stable view ID or slug. The primary dataset should remain an important property of the view, but it should not be the thing that uniquely identifies the view.
This would allow multiple views of the same type to exist for a primary dataset, each with different names, descriptions, secondary datasets, and configuration.
At some point we should revisit this decision. We went along with it because it was the initially written plan, but at this point the real noun has become [view].
For example think of the use case where you want 2 views, both with the same primary dataset, but different secondary datasets.
Originally posted by @IamJeffG in #495 (comment)
The current implementation solved in #193 still treats the route
[table]as the primary identifier for a dataset view. Related lookups such asfetchViewDatasets(table, "alerts")are keyed on(view_type, primary_dataset), which means the system effectively assumes there can only be one view of a given type for each primary dataset.That made sense in the earlier model, where a dataset could have one map, one gallery, and one alerts dashboard. However, the introduction of secondary datasets changes the mental model. A view is no longer only “the map for dataset X.” It may be “a map using dataset X as the primary dataset and dataset Y as context,” or “a map using dataset X as the primary dataset and dataset Z as context.”
For example, we may want:
comapeo_observationsby itselfcomapeo_observationswithterritory_boundariesas a secondary datasetcomapeo_observationswithsatellite_alertsas a secondary datasetsatellite_alertswithcomapeo_observationsas the secondary datasetsatellite_alertswithpatrol_routesorcommunity_reportsas secondary contextUnder the current model, several of these would collide because they share the same
view_typeandprimary_dataset, even though they represent meaningfully different views.This issue is to revisit that assumption and move toward a model where
viewis treated as the primary resource. Each view should be identifiable independently from its primary dataset and view type, likely by a stable view ID or slug. The primary dataset should remain an important property of the view, but it should not be the thing that uniquely identifies the view.This would allow multiple views of the same type to exist for a primary dataset, each with different names, descriptions, secondary datasets, and configuration.