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

Adding previous generations' damage relation data (+ data changelog discussion) #572

Open
phrasmotica opened this issue Feb 13, 2021 · 5 comments

Comments

@phrasmotica
Copy link
Contributor

Hey all. Was wondering if there would be some interest in supporting data that has changed over time, e.g. between generations. For example, Poison was supereffective on Bug in Generation I but did normal damage thereafter, so we should be able to see that reflected in the Type model.

I have some prospective changes for this in a branch: master...phrasmotica:feature/past-type-efficacy

These changes create a new field past_damage_relations in the Type model. The field is a list of objects containing damage relations data alongside the generation in which the damage relations data was last valid for the given Type. While this works, I think it might be best to have such a new field instead be a generation-by-generation changelog of the type's damage relations, which would include the damage relations for the current generation if applicable. Furthermore the past_ prefix hints at some attachment to the current generation, so the field's name could be changed to something like damage_relations_changelog instead.

Assuming the damage relations data was kept current in its CSV file, this would result in the existing damage_relations field containing the same data as the last element in the damage_relations_changelog field. At which point might it be sensible to store all damage relations data in a single CSV file, where all entries contain the ID of the generation in which they were first used (not last used, since we do not know the last generation that the current data will be used in). Then the damage_relations field could be deprecated, although I think it would be nice to keep it for easy access to the current data.

I think this pattern could be applied to any data that changed over the course of version groups/generations/etc. I made a PR recently (#457) that involved creating a past_types field in the Pokemon model for a similar purpose, which could benefit from this new pattern also. Would love to hear people's thoughts on the idea 😃

@phrasmotica
Copy link
Contributor Author

I had some brief discussion about this with the folks over at veekun/pokedex a while back: veekun/pokedex#288

@briancorbin
Copy link

IMO we should probably get rid of change-log tables all-together and just have discrete entries for each generation/version-group. The total data increase would be minimal and would definitely increase the accuracy of finding exact info about any specific generation.

@briancorbin
Copy link

Currently working on a restructuring of the database as we speak, actually. Will be releasing it as a RealmIO db, and will also address the issue of not being able to handle different evolution triggers for various regional forms (alolan, galarian) as well as a few other little issues I've found whilst doing this.

@Naramsim
Copy link
Member

Naramsim commented Mar 1, 2021

@phrasmotica Hi there :)

Thanks for opening the issue, so I think we've already merged one similar PR. The one for Pokemon types.

Feel free to open a new one for the type effectiveness. Normally types don't change much and a changelog table would be kinda good in this case. And anyway, we aren't going to change our model structures.

Thanks again for your time 😸

@phrasmotica
Copy link
Contributor Author

@Naramsim hey, sorry for the super-delayed follow-up! I've tidied up my changes for this and created a PR: #634

It's very similar to the one I created for the past Pokemon types. Have a look when you've got the time 😃

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

3 participants