You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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"
},
The text was updated successfully, but these errors were encountered:
warpfactorfive
changed the title
Include previous year's UID in camp data structure
Support identifying camps year-to-year
Feb 27, 2019
This was discussed with Placement this year. We won't be implemented this year, but we confirmed that it is possible through the linking of Questionnaire records with the parent Camp records. So there would be an additional ID added to the record that identifies the Camp. We can also retroactively push that record to previous years.
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"
},
The text was updated successfully, but these errors were encountered: