Season model?

[rye]

I'm starting to think that having a Season model would make a lot of sense. With this new Season model, we would have the capacity to collect Robots and Competitions together and to start recording data about relevant years. It could also work to add a year field to both Robot and Competition, since that's effectively the same thing, and then we can validate that those two values for year are identical for the Robot and Competition of a Participation upon creation.

[vmai]

I think this is a bit unnecessary because we are going to empty the database once a year at the absolute minimum anyway. We're never going to care about sorting data between different games so we shouldn't ever run into any issue that this would solve.

[rye]

Think about how we have to do creation of Participations within the current bulk-add system in WeBCa. We create a Team, use that new Team's ID to create a Robot, then use that Robot's ID to create a Participation. What if a Team already exists and has a Robot? Being able to separate out and get rid of all Robots that are from previous seasons would make sense to me. Having a year field would work for this, though, which is why I made that suggestion.

[vmai]

If a team already exists and has a robot, then we just create a participation for that robot. Like I said, we wouldn't ever run into the problem of having robots from previous seasons because there won't be any.

[rye]

What if a team has multiple robots? It's an easy edge case to have happen.

[vmai]

You can't come back home and bag up a different robot and go play in a second competition with a completely different robot. Once you bag up your robot at the end of the competition, it is supposed to stay bagged up until you get to another competition (District Rules are a little different but the same thing applies).

[rye]

Right, but you can create multiple robots for a team. Say a bulk-create gets cut short, but the teams and robots and participations get created. If you try and create them again, what happens? Another robot gets created.

[rye]

By giving a parameter (e.g. year), one can quickly check to see if a team already has a robot for a given year, and can then use that robot rather than creating a duplicate.

[vmai]

Or you can have it fail if you try to create a second robot for a team. A team shouldn't ever have more than 1 robot, in the context of actual FRC and in terms of the db.

[rye]

No, a team should always be able to have more than one robot. We always wanted and will probably always want to continue to be able to have the same database be used for multiple years.

[vmai]

When did we ever want that? Scouting data instantly becomes useless after a new game is announced. There shouldn't be any reason anybody would want to save data from previous years, unless they want to take up more disk space.

[rye]

It doesn't necessarily become useless. What if you want to look at performance curves from multiple previous years? Again, this is thinking about the big picture, for the global audience.

The problem here, relating to the Season model, could easily be solved by adding a year field to both Robot and Competition, which would make things simple enough that I think it'd not be a problem. Participations could fail to be created if the years don't match, and WeBCa-side, we can just query for the Robot that corresponds to the current Competition's year, or create one.

[rye]

If we're fine with adding that year (which is just an Integer representing the current year, which could be autofilled to the year from the current date), I'll close this issue and get on it. Again, I think this'll solve a bunch of the problems with creating Robots and Participations in WeBCa.

[vmai]

I guess I wasn't really thinking big picture. I just know that our team wouldn't have a use of measuring performance over time.

But now that you mention it, you're not going to be able to measure performance curves over time because performance each year completely depends on the game elements. The only simple and objective way to measure performance over time is to look at W/L, and even that has a tremendous amount of flaws (W/L not mattering in 2015, teams getting carried, and more).

I still don't see a use for it, unless somebody wants to look at old and very game-specific data.