Season model?
rye opened this issue · 30 comments
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.
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.
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.
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.
What if a team has multiple robots? It's an easy edge case to have happen.
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).
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.
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.
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.
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.
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.
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.
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.
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.
Still. Emptying the database should not be a requirement of using this. We can skip this API-side and do a workaround for WeBCa, but it makes sense to me to include categorizational data.
I can assume that most teams will not have a use for old data and will probably empty the database after each competition even, like we do. But if you're still really insistent on making something that accounts for this, just go with adding year.
On a seasonal basis, I can see people emptying stuff, but I still do see reason to keep data in the database from competition to competition.
Maybe we'll just add year in WeBCa. We can monkey-patch the FReCon::Robot and FReCon::Competition models to add this.
I agree that people shouldn't be forced to empty the database year-to-year. That is forcing our method of usage upon others, which to me is a really mean thing to do.
As I mentioned in #57, we can also use this Season model to reference what format our Records use; this would aid with problems with changing formats from year to year. I will reopen for further discussion.
After all, part of the reason we chose to use dynamic attributes is so that there wouldn't really be a dependency on the year of the record. I think that adding a Year/Season model would actually make it more feasible to keep a running database and not need to change things.
If we do decide that adding a Year/Season model is acceptable, we should consider also how to tie that to Records. We could just determine the Year/Season of the Competition and use that, or we could make Records directly tie to a Season. I'm curious what @frc-frecon/frecon thinks of that.
I do understand that in a typical scouting situation you likely don't care about a team's previous performance, but I'm thinking of the possibility of teams running long-term databases of all of their scouting data and merging their competition databases (see #57) into them. This seems like a pretty significant use case.
Especially if one considers the option of running FReCon in video scouting or scouting with bigger data than we currently do. (A project that I'm currently working on with 2503 does actually involve doing this.) Keeping a running database allows for long-term data science to be done, (including measuring trends in team performance over the course of a competition, which are actually somewhat consistent from year to year) and allows for the review of old data as well.
I will mark this issue for Long-Term development. (Potentially, once FReCon.js is released, this will ease any concerns about implementing the Year/Season model with WeBCa. I would also raise that #57 would make this much more sensible.)
I kind of like the idea of adding a year field to a competition. I do not really see someone greatly complaining about needing to record the year of a competition. A robot could then figure out this field from the competitions it has been in. The year field could even be optional, too.
@Sammidysam, do you favor adding a year field over adding an entire model for the ability to do relations?
Since this is relevant, I'll make the exception of beating a slightly dead horse.
I am still in favor of removing the robot model altogether and establishing a Season model. You said before that the point of having Robots was to establish different Robots that teams have over the years, then having a Season model could also fulfill that purpose.
In FRC, for all intensive purposes, if a team doesn't compete one year then they don't exist for that season. They can't win any awards, they don't qualify for anything, they don't really exist in that particular season. I don't see anything wrong with having to create Teams each year because of this.
I think we've lost sight of the goal, so I just want to reiterate: the proposal to add a Year or Season model is in the spirit of making the database somewhat persistent from season to season. This is not currently the case, as we have no built-in way of distinguishing between entries made during different seasons.
The whole point of having Robots is to have representations of the real, physical objects that the teams bring to a Competition, that they use to participate. Because the Robot model is semantic, and makes logical sense, I am still in favor of keeping it.
The goal of adding a Season model would be two-fold:
- Provide some kind of validation mechanism between Robot and Competition, making sure that they both belong to the same season instead of the alternative, which is relying on two attributes being the same.
- Provide a means to determine which syntax a given Record would use. This would allow a Team to create a web interface like WeBCa which properly displays data no matter which season it comes from.
I could see merit in simply using an attribute to accomplish this task, but using a model is better. I understand that it means marginally more work in terms of implementation, but I still don't think that that's a bad thing, especially given that FReCon.js is soon going to be in progress.
I should add: for our specific use case—that is, within WeBCa—to date, we have always just emptied the database after each season, and even after each competition. I am simply stating that people do like to keep a running record and keep adding to it. Whatever the mechanism we introduce is, we do definitely need to make sure that it works easily for both situations.
I guess I'm just wary of having a model that only really stores one attribute inside of it, and that is why I was leaning towards only having an attribute. If a competition has an attribute, all of the other descendent models of it can effectively inherit that attribute, and it is not too much of an issue. And if you're looking up the competition to determine your year, isn't that similar in performance to looking up this Season model?
That is a valid point, but only really deals with the Competition side of things. I also proposed using this Season model to identify which season a Robot corresponds to, and to validate that a Robot and a Competition are of the same Season before allowing the creation of a Participation.
Yes, we can inherit the attribute very easily, as that simply involves a lookup of a Competition in the database. The two would be practically the same in terms of performance.
I think creating a Season model rather than assigning attributes to multiple other models would make it look a bit cleaner.
Okay. This is what I was thinking of this as well.
To @Sammidysam's comment about worrying about Seasons containing a specific attribute alone, I do agree. However, consider the possibility that a team could elect to put the URL to a game animation in a Season, or a title for the game. We probably won't, but it's still possible.