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
We've had a few reports of two seasons on the same show both showing up as "season 1", which goes away once the cache is bopped. Here's my hunch as to what's happening:
when MyRadio_Season::getInstance is called, before allocate() is called, it computes season_num through SQL:
(
SELECTCOUNT(*) FROMschedule.show_seasonWHERE show_id=(SELECT show_id FROMschedule.show_seasonWHERE show_season_id=$1)
AND show_season_id<=$1AND show_season_id IN (SELECT show_season_id FROMschedule.show_season_timeslot)
) AS season_num
At this point, the unallocated season has a season_num of the last allocated one.
2. MyRadio_Season->allocate() is called, which schedules timeslots, but does not update season_num
3. The object is written back to the cache, with the incorrect season_num.
The fix is likely to re-compute season_num in allocate().
We've had a few reports of two seasons on the same show both showing up as "season 1", which goes away once the cache is bopped. Here's my hunch as to what's happening:
MyRadio_Season::getInstance
is called, beforeallocate()
is called, it computesseason_num
through SQL:At this point, the unallocated season has a season_num of the last allocated one.
2.
MyRadio_Season->allocate()
is called, which schedules timeslots, but does not updateseason_num
3. The object is written back to the cache, with the incorrect
season_num
.The fix is likely to re-compute
season_num
inallocate()
.For #1054.
The text was updated successfully, but these errors were encountered: