Closed lebull closed 3 months ago
If we're going to duplicate the data, we might as well just optimise it and toss an events
array onto the DJ entity. A simple object array that contains the event ref, datetime of the slot, and an optional bool flag of special_play
for the times it doesn't count against the "last played" sorting method we use to schedule peeps.
That's not necessarily optimal: It would mean every time we make a change to the lineup, we're having to keep up with each individual dj that is added or removed. That can easily get out of sync and would be an absolute nightmare to track down if it does happen.
I think this is solution is a good compromise of "useful" to "easy to maintain / less likely to break".
Adding events to the djs may be useful if we aren't able to shotgun events when working with large numbers of djs (Looks like querying off of events in this case is out of the question because firebase's 'array-contains-any' supports up to 30 fields, and we have way more than 30 djs already). My expectation is it will take a few decades at least before there are enough events to start slowing that query down, but if that's not the case, lets consider the option as well.
As far as special plays, I think we can definitely do that assuming we need to track things like afterparty. I think it would also fall under "afterparty support", so out of scope for what I want to stand up for this chunk of work.
Here's how that would pan out. In the feature/prod, I am going to use the 7-7 event only to demo.
https://sunday-service-vr--pr91-add-dj-plays-gt0p9q43.web.app/djs/etzepcAmYpJhvUrtZLph
https://github.com/SundayServiceVR/sunday-service-vr/pull/91
What I had in mind for the DJ-side storage was a single write post-event so we capture any no-shows or other weird issues that would otherwise flag the play as "special". Special plays also come into account for any weird weekend like Groundswell or F'rality Playn'ts; it's not just afterparty (which we never track anyway).
It doesn't matter to me how we do it; but I figured if we only look at this data when we are looking at a DJ, might as well have it attached to the DJ.
Yeah, no shows and maybe some other things there will need to be stored on the dj. I think we can stand those up later, though, this is just the basic "get tracking working"
We need a better way to check what events a dj has played for. Since the references from the slot are 2 arrays deep, it keeps us from easily doing an aggregation query.
We should add a separate array property directly on the Event. We're kind of duplicating data, but DOCUMENT DATABASE SHENANIGANS! We should be fine by massaging this data in the existing
store/events.tsx
.