Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow backfill of parsed player_caches info after visibility setting change #2687

Open
howardchung opened this issue Dec 15, 2023 · 0 comments

Comments

@howardchung
Copy link
Member

howardchung commented Dec 15, 2023

Currently we do not store rows in player_caches for anonymous players at api or parse data insertion time because we don't have an ID for them.

However, this means that if the user later turns it on and refreshes their profile, that parsed data is not available for aggregation purposes. We request api data for the matches, which fills in the basic info, but reparse is required to get parsed info to show up under that player (e.g. for wordcloud and totals)

Solution:
We can store anonymous player_caches rows under the anonymous account id. When a user requests a full history update and we find match IDs missing, update those rows to the appropriate account id. The downside of this approach is that it may double the size of player_caches since we'll be storing a lot more rows.

This approach could also work for gcdata, where we update the player_caches rows when we get the account IDs from the GC

EDIT: This will not work because Cassandra does not allow updating the partition key (which kind of makes sense since this would require the data to move to another node. We'd have to copy the existing row and write a new entry under the player's account ID. . . which could be done

@howardchung howardchung changed the title Allow backfill of parsed player_caches info Allow backfill of parsed player_caches info after visibility setting change Dec 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant