Closed robmonie closed 11 years ago
I pushed a commit for this on thursday evening and reverted it this morning. It turned out that it didn't really help because we need some of the interim computed info about incorrect predictions in the UI. This was just adding duplicated complexity.
If you pulled this commit it's no big deal. It added a column to the game_memberships table but it won't impact anything if it hangs around until you next do a full db reset.
@stuliston obviously no need to review this anymore if you haven't already.
Thanks for the update, dude.
On Saturday, August 17, 2013, Rob Monie wrote:
I pushed a commit for this on thursday evening and reverted it this morning. It turned out that it didn't really help because we need some of the interim computed info about incorrect predictions in the UI. This was just adding duplicated complexity.
If you pulled this commit it's no big deal. It added a column to the game_memberships table but it won't impact anything if it hangs around until you next do a full db reset.
@stuliston https://github.com/stuliston obviously no need to review this anymore if you haven't already.
— Reply to this email directly or view it on GitHubhttps://github.com/stuliston/lastmanstand.in/issues/27#issuecomment-22801621 .
Doing this after all as it'll mean we drag less data down on the initial page load and can still show the lists of games categories by past and current games.
Done. THIS WILL REQUIRE A RESEED.
At the moment there's a bit of logic going on in the UI that calculates a user's lives based on their predictions and fixture results. This seems like it should be simple to store in the db and manage via active record observers.
If lives are stored on the game_membership, a lot of things can be simplified in the UI and it will improved performance.