Skip to content

Sports dataclass #78

Description

@Levi-Lesches

Go over the SportsGame class and think about any structural changes that need to be made. Also think of new types of data we can store related to sports games.

Here is a bit of info about how games are currently stored:

  • there are documents in the Firestore "sports" collection. Each document has the school year as its title, and a list called "games" with all the JSON of every game.
  • We could have one game per document, and get rid of the year since it's included in the timestamp, but then we'd need to download many documents per user, per load. This way, it's guaranteed that you'll only ever need one document
  • The local (IDB) database is less complicated since it doesn't matter how many rows (documents) we collect. It's just one big table called "sports" with each game in its own row.
  • SportsGame.sport is an enum (Sports). That means we can easily map from a sport to a custom icon (like \images\icons\volleyball.png), but that means it's hard-coded and that's not good for maintenance. It's a trade-off -- if you want to have icons for each sport that means you need to manually handle each sport. Strings would be nice, but then it's harder to have a drop-down menu to pick the sport.

Think of new ways to structure this data. These structural changes also apply to how the games are stored in the database. Currently is handled by the HybridSports database.

Metadata

Metadata

Assignees

Labels

Code healthDoesn't change functionality, but keeps the code clean

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions