pokemon vs pokemon-form vs pokemon-variety
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 重构
- 描述清晰度
- 需要澄清
- 活跃度
- 活跃
- 领域
- api
调研方向
首先比较 issue 中描述的 pokemon/10091、pokemon-form/10193、rattata-alola 和 evolution-chain/7 资源。追踪当前哪些字段是某个种类和形态的权威字段，然后记录移除重复数据所需的模型变更。完成的标准是关系明确无歧义，且受影响的 API 资源保持一致。
由索引模型根据 Issue 内容生成。
描述
Hi all, something has been on my mind a bit and now has drawn to a head with some updates to the evolution-requirements, where we now have required_pokemon_form pointing to a pokemon-form rather than a specific pokemon. I think there is now a bit of a disconnect between pokemon-varieties and pokemon-forms.
For example, take an evolution with a pokemon variety e.g., rattata-alola, evolution-chain/7. This used to point to the Pokémon at pokemon/10091, but now instead to pokemon-form/10193/. A Pokémon form "belongs" to at most 1 Pokémon (i.e., a 1-to-many relationship), and the only difference being that a form might have some minor field differences (just like a variety might).
I understand that maybe pokemon-form differs from pokemon-variety as it is purely cosmetic rather than a new Pokémon (moves, types etc), but I think it is creating unnecessary complexity when we could just add a new pokemon (which would still be different e.g., sprites).
We have a bunch of duplicated data, e.g., pokemon-form/10193/ copies most of the fields from pokemon/10091. This creates a multitude of problems e.g.,:
Let's assume we want to grab the types (normal/fire/water) of rattata-alola, where exactly should we look now?
It is pretty obfuscated as to which form/variety fields should be taken as ground truth.
I can't think of a case where a pokemon-form would not have any fields changed that could not be represented in a Pokémon. The monotonous part is then copying across these fields to pokemon (e.g., is_mega).
I really think that there is justification in merging pokemon-form with pokemon (just as varieties already does).
Please correct me if I'm overlooking something, but I really think each pokemon-form should be a pokemon, just as pokemon-variety already does (i.e., a pokemon-form/... just points to a new entry in pokemon/....). And, we dont need pokemon-form relation AT ALL.
- 主要语言
- Python
- 星标
- 5.4k
- 派生
- 1.2k
- 平均合并
- 2 天 4 小时
- 30 天内合并 PR
- 15
环境准备
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
PokeAPI/pokeapi 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
PokeAPI/pokeapi#1685 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
PokeAPI/pokeapi#1684 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-2 天 新手友好度 76/100
PokeAPI/pokeapi#1631 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 58/100
PokeAPI/pokeapi#1687 · 4 条评论 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 55/100
PokeAPI/pokeapi#1623 · 3 条评论 ·
维护者通常 1 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 90/100
维护者通常 1 天内回复
-
instance instance add
难度 2/5 1-3 小时 新手友好度 68/100
searxng/searx-instances#941 · 1 条评论 ·
-
难度 1/5 1 小时以内 新手友好度 92/100
FluidNumerics/fluid-walk-blocker#89 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复