You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the prod AGAGD, the Chapters table has member_ids that correspond to a chapter-type member in the Members table. For example, https://agagd.usgo.org/chapter/NOVA/ corresponds to https://agagd.usgo.org/player/126/. In other words, the primary key field member_id is unique across both the Members and the Chapters table/model.
make_fake_fixtures.py, however, creates chapters with IDs that correspond to normal players.
Steps to Reproduce the Behaviour
i.e.,
docker-compose down -v (this will delete any test data you currently have)
docker-compose build
docker-compose up
The Expected Behaviour
Chapters should ideally have corresponding Member objects with the same member_id.
Notes
This only affects local dev work, and only in very rare circumstances, so this should be a low priority issue.
The text was updated successfully, but these errors were encountered:
I'm looking into this as a low-fruit contribution. It seems like a Chapter should also have a corresponding Member entry, but the fixture script does not currently make one. I think to fix this a corresponding Member entry should be created, but Member has many fields which I wouldn't know how to fill, e.g., given_names, family_name, occupation, citizen, etc.
If anybody is willing to give any guidance on how to fill those entries for a Chapter, I'd be happy to fix the fixtures, and make other improvements to the script.
Summary of the Bug
In the prod AGAGD, the
Chapters
table hasmember_id
s that correspond to a chapter-type member in theMembers
table. For example, https://agagd.usgo.org/chapter/NOVA/ corresponds to https://agagd.usgo.org/player/126/. In other words, the primary key fieldmember_id
is unique across both theMembers
and theChapters
table/model.make_fake_fixtures.py, however, creates chapters with IDs that correspond to normal players.
Steps to Reproduce the Behaviour
i.e.,
docker-compose down -v
(this will delete any test data you currently have)docker-compose build
docker-compose up
The Expected Behaviour
Chapters should ideally have corresponding
Member
objects with the samemember_id
.Notes
This only affects local dev work, and only in very rare circumstances, so this should be a low priority issue.
The text was updated successfully, but these errors were encountered: