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

Unify ReEntryInfo #1442

Open
ctm opened this issue Jun 16, 2024 · 0 comments
Open

Unify ReEntryInfo #1442

ctm opened this issue Jun 16, 2024 · 0 comments
Assignees
Labels
chore Maintenance or other non-bug, non-feature

Comments

@ctm
Copy link
Owner

ctm commented Jun 16, 2024

At minimum, use the same type for types::ReEntryInfo as for structure::ReEntryInfo, but probably just unify to a single type.

Currently there are two different ReEntryInfo types, one that's used for structure templates and the other that is used for tournament Events.

The biggest difference is the structure has a last_re_entry_level field which is a LevelNumber and the Event one has a last_re_entry_round which is a BettingRoundOrdinal. That difference is annoying, but is due to the fact that currently, when creating a tournament, the client doesn't have enough information to access the round names, so instead we use "First Level", "Second Level", etc. even though the true name of the level might be "Level 1A", "Level 1B", etc. This GitHub issue is not about that annoyance.

For no good reason, types::ReEntryInfo has a re_entries field that is a NonZeroU8, whereas structure::ReEntryInfo has max_n_re_entries as an Option<NonZeroU8>, with None meaning that there is no limit to the number of re-entries, which sort of makes sense, if 255 isn't enough, make it unlimited, but that also is kind of crazy in that won't 255 be enough?

My plan has always been to have cleaned this up when we put structures into the database, and we've done OK with this goofy difference, but I'm creating this issue now because I had forgotten some of the particulars and had to refresh my memory when I added structure sheet support (#1439) and i figure I might as well document the difference and the need for unification here, while it's still fresh in my mind.

For the structure sheet support, I'm just using a trait to unify the semantics, which is fine.

@ctm ctm added the chore Maintenance or other non-bug, non-feature label Jun 16, 2024
@ctm ctm self-assigned this Jun 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Maintenance or other non-bug, non-feature
Projects
None yet
Development

No branches or pull requests

1 participant