Conversation
|
This is a good idea, but it's a bit scary. The reason it's a bit scary is that it denormalizes the database: these fields can be wrong according to other tables in the database. In theory, we could instead create a has_routes() function, for example, that goes looking in the Routes table to see if the game has routes or not. This would be safer but slower. (In theory, there exist constructs in databases such as materialized views to split the difference here, but I looked into this and it seems like it would be a pain in the ass without much native Django support, so I don't think it's worth doing.) I think it is fine to do things this way, on one condition: We need a test that validates that for each game, these fields are correct. In other words, it should create the constant table and then double check that, for example, there are routes if has_routes is set, and no routes if it isn't set. Since these are all constants anyway, a test suffices to check their correctness. As a side note, I would consider computing these fields in setup_constant_table rather than treating them as fixed constants. But you don't have to do that. |
Adds 3 new fields to each game:
has_routeshas_multiple_shotshas_subshotsAlso simplify some logic using the new fields.