Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Requirements

  • Each league/tournament/etc allocates sequences of game numbers to each schedule

  • Game numbers are only unique within each schedule and may be reused in other schedules

  • Game numbers often have a prefix and suffix to identify which league and category

  • A schedule with groups/flights will have a sequences per group (flight 1 will have 1000-1999, flight 2 will have 2000-2999, etc within the same U13 schedule)

  • Draft games can be have their numbers resorted based on the date/time prior to publishing, but published games cannot be resorted

Current behaviour

Currently we have a (published) games table and a drafts table, where drafts essentially act as isolated containers of a schedule.

When creating a (published) game directly, if you do not specify a game number, it defaults to the system ID (which is a standard incrementing postgres sequence). Otherwise the game number specified is used as is.

When creating drafts, you can specify a starting game number, which will automatically increment within the draft, with an option to resort the numbers. When publishing the draft, if a draft game matches the game number of a published game, the published game will be updated instead of creating a new game. This starting game number option only exists within the draft, and ceases to exist once the draft is published.

Proposed behaviour

Following the implementation of SPR-453 Draft Redesign, there will be two game tables: Game (published) and DraftGame (unpublished), and the Draft table that creates an isolated container effect will no longer continue to exist. Sequences (this proposal) are necessary to introduce to maintain the original start number draft option functionality.

A sequence will be composed of a starting number (which may have a prefix/suffix matching the regex format /^(.*?)(\d+)(\D*)$/) and a maximum range.

This is modelled after Postgres sequences, which also have a optional increment property which could allow you to increment the next number in the sequence by more than 1 at a time (so a sequence of 1, 3, 5 if you wanted or 10, 20, 30, etc) but this has not been identified as a requirement. So this would allow you to create a sequence with a starting number of U13L1000 which increments up to U13L1999.

Creating a game, regardless of whether it’s published directly or a draft game, will pull the next sequence number available. Drafts will require sequences to be configured in the schedule as draft games cannot rely on the game ID sequence.

If the next sequenced number already exists for whatever reason (e.g., that number was manually provided when creating a game or in case of an error updating the sequence), another sequence number will be produced until a non-conflicting number is available.

It is possible to reset a sequence back to a given starting number, which may be necessary in case a batch of games are deleted. Resets will never be done automatically as we cannot predict if the user wants to reuse the sequence or not.

It will also be possible to produce multiple sequences, so that you can have multiple sets of sequences as necessary. The sequence with the lowest next number that has not been exhausted will be used to produce the next sequence.

If all sequences are exhausted, published games will fall back to using game IDs if there are no viable sequences available, and draft games will fail to produce.

Potential concerns

Assuming a sequence of U13L1000-1999 for simplicity of explanation:

  • It will be possible for someone to create a published game, which would use U13L1000, then generate 100 draft games which would be numbered U13L1001 through U13L1100. Before publishing these draft games, someone could create a new published game, which would use U13L1101 as the next number in the sequence.

    • At this point there are only 2 published games, 1000 and 1101, while 1001-1100 are unpublished.

    • Likewise, if you were to create another draft game at this point, the next draft game number would be U13L1102.

  • Deleting a game would create a gap in the sequence. Should this gap be automatically identified and reused or ignored?

    • You could publish games 12000 through 1299 and then delete 1250. If you generate 3 additional games, should the next games be numbered as:

      • 1250, 1300, 1301, or

      • 1300, 1301, 1302?

  • No labels