Is your feature request related to a problem? Please describe.
There is at least one search (LGBTQ Camps) that requires identifying a specific subset of camps, each year. This is most efficiently done by identifying the UIDs of the relevant camps, but since they change from year to year, it requires us to identify the camps in the dataset, typically by camp name string comparison. This approach is prone to errors.
Describe the solution you'd like
If the camp data structure included the previous year's UID, it means we could leverage each year's dataset off of the previous year's, thus propogating all the error checking and robustness, instead of starting from scratch each year.
Describe alternatives you've considered
Alternative #1: keep the UIDs over multiple years, for returning camps, ie, re-using the 2017 UIDs for 2018. However, I'm guessing that this operation would not be easily supported by the backing system.
Alternative #2: Add another key field, which does not change year-to-year, but which would support identifying returning camps.
Additional context
Proposed dataset change shown below in bold:
{
"uid": "a1X0V000003WsSdUAK",
"year": 2018,
"name": "Comfort & Joy",
"url": "http://www.playajoy.org",
"contact_email": null,
"hometown": "San Francisco",
"previous_uid":"a1X0V000003HFFIUA4"
"description": "Restore your body and lift your spirits at Comfort & Joy, a gay\r\ncommunity oasis offering a fully functioning Gym, colorful art\r\ninstallations and daily events including yoga classes, inspiring performances, & quite queer nightlife.",
"location": {
"string": "7:00 & D",
"frontage": "7:00",
"intersection": "D",
"intersection_type": "&",
"dimensions": "200 x 500"
},
"location_string": "7:00 & D"
},
Is your feature request related to a problem? Please describe.
There is at least one search (LGBTQ Camps) that requires identifying a specific subset of camps, each year. This is most efficiently done by identifying the UIDs of the relevant camps, but since they change from year to year, it requires us to identify the camps in the dataset, typically by camp name string comparison. This approach is prone to errors.
Describe the solution you'd like
If the camp data structure included the previous year's UID, it means we could leverage each year's dataset off of the previous year's, thus propogating all the error checking and robustness, instead of starting from scratch each year.
Describe alternatives you've considered
Alternative #1: keep the UIDs over multiple years, for returning camps, ie, re-using the 2017 UIDs for 2018. However, I'm guessing that this operation would not be easily supported by the backing system.
Alternative #2: Add another key field, which does not change year-to-year, but which would support identifying returning camps.
Additional context
Proposed dataset change shown below in bold:
{
"uid": "a1X0V000003WsSdUAK",
"year": 2018,
"name": "Comfort & Joy",
"url": "http://www.playajoy.org",
"contact_email": null,
"hometown": "San Francisco",
"previous_uid":"a1X0V000003HFFIUA4"
"description": "Restore your body and lift your spirits at Comfort & Joy, a gay\r\ncommunity oasis offering a fully functioning Gym, colorful art\r\ninstallations and daily events including yoga classes, inspiring performances, & quite queer nightlife.",
"location": {
"string": "7:00 & D",
"frontage": "7:00",
"intersection": "D",
"intersection_type": "&",
"dimensions": "200 x 500"
},
"location_string": "7:00 & D"
},