| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Currently a work in progress. The queries used to display the Pokémon for each species are very inefficient. The text at the top of the page is also very specific to the author.
|
|
|
|
|
|
|
|
| |
This removes the need to use a GROUP or DISTINCT in eager-loading Pokémon on the front page. It duplicates data, but provisions are in place to keep the cache up-to-date. When a Pokémon record is updated, it is required that its cache points to the current revision. When a revision is created, it updates the Pokémon's cache to point to it, because a new revision will always be the most recent one, and it is impossible to reorder revisions.
This does not affect the number of queries used on the front page (see #1).
refs #4
|
|
|
|
| |
Apparently the choice of row to be returned with a GROUP that uses fields outside of ones that are functionally dependent on the GROUP fields is arbitrary, as per https://dev.mysql.com/doc/refman/5.7/en/group-by-handling.html
|
|
|
|
| |
A bug was causing a Vigoroth which had evolved into a Slaking to still show up as a Vigoroth on the front page of the engine, even though it showed up properly on its show page. This was deemed to be caused by eager loading.
|
|
|
|
|
|
|
|
| |
The migration will set all of the revisions of each Pokémon to have the species that that Pokémon was set to. If reversed, the migration sets the Pokémon's species to the first revision's species, which mimics the behavior of the engine from before this change, but do note that running the migration backwards like this can lose data.
This change slightly affects the loading time of the front page. See #2.
refs #3
|
| |
|
| |
|
|
|
|
|
|
|
| |
Pokeviewer now expects the main app's ApplicationController to contain a
method called "authenticate_pokeviewer" which will return true iff the
username and token passed to it are valid. An example stub is present in
the test dummy ApplicationController.
|
|
|
|
|
|
|
|
|
|
|
| |
Reduced the number of queries that the front page runs to 2 queries
total: one to get trainer data, and one to get the Pokémon. The latter
query selects only the necessary columns, notably ignoring basically
everything from the revisions join other than the nickname of the most
recent revision. The controller then does the work of chunking the
Pokémon into party/boxes, and then into trainers/unaccounted.
refs #2
|
| |
|
|
|
|
|
| |
Note that the met location for Pokémon from Orre is completely
incorrect.
|
| |
|
|
|
|
|
| |
This commit imports a lot of assets from veekun, as well as a font from
http://www.victoryroad.net/showthread.php?t=1507
|
| |
|
|
|