frc-frecon / frecon

An API for building scouting apps for FRC competitions
MIT License
3 stars 0 forks source link

Participations and Robots are redundant #56

Closed rye closed 9 years ago

rye commented 9 years ago

The Robot model is effectively a duplicate of the Participation model. Given that Participations and Robots are not the same thing (physically), it makes sense to change them.

@Sammidysam and I mentioned this recently in our group Hangout with @vmai on the sidelines. We'd need to make Participation belongs_to :robot and Robot has_one :participation.

The rationale behind this is this: they're the same thing, and it makes sense to have one object with the Team-to-Competition connection (and another that connects to that one object) as opposed to two separate objects that aren't related at all.

Why it's not "Robot has_many :participation (plural instead of singular)", you may ask? Well, we think that Robots probably change quite a bit from Participation to Participation (i.e. from Competition to Competition). So rather than tracking the history of (or just changing) robots, it's better to create a robot for each individual competition, since we don't know what happens between.

Implementing this would involve changing the db schema in general, and would probably result in a whole new minor version.

rye commented 9 years ago

Of course, it might simplify things if we remove the Robot model, or replace the Participation model with the Robot model.

rye commented 9 years ago

14284176529471093021488

This might work, actually. Unless we have robots having the ability to have many participations, I think this works better.

rye commented 9 years ago

@Sammidysam, do you like how this sounds? It seems like it makes more sense. I will go ahead and branch for this.

Sammidysam commented 9 years ago

That works, we will just definitely need to document it. I personally would prefer the model being Participation and Robot being axed, but you can go either way.

rye commented 9 years ago

Okay, just to disambiguate: I will delete the Participation model, and make it so that a Team has_many :robots, and that a Competition has_many :robots as well. Then, I will update the respective models; basically, Participations get eliminated and re-routed through Robots.

rye commented 9 years ago

Pending your approval, I will delete close this Issue and create a new branch.

EDITed

Sammidysam commented 9 years ago

Yep, that is what I understood you as doing. Since my language was a bit bad, I was saying that I would rather Robot be eliminated rather than Participation (I seem to remember not wanting to create it in the first place), but you can remove what you want since you're the one going through and doing it.

rye commented 9 years ago

Okay. I think the name Robot makes more sense, so I'll go with that. Closing this issue.

rye commented 9 years ago

Actually, no, Participation makes more sense. I suppose a team could participate without using a Robot (in the situation where this API is applied to something other than FRC, I'd rather not impose overhead). The same stuff will apply, however.

rye commented 9 years ago

Well, it's looking like this might actually need to result in a major schema change. We'll see. Further discussion should be had on the new pull request that I create.

Sammidysam commented 9 years ago

I approve of using Participation instead of Robot. I'll try to check out the pull request later today.

-Sam

Sent using CloudMagic [https://cloudmagic.com/k/d/mailapp?ct=pa&cv=6.3.40&pv=5.0.2]

On Mon, Jun 29, 2015 at 4:51 PM, Kristofer Rye < notifications@github.com [notifications@github.com] > wrote: Well, it's looking like this might actually need to result in a major schema change. We'll see. Further discussion should be had on the new pull request that I create.

— Reply to this email directly or view it on GitHub [https://github.com/frc-frecon/frecon/issues/56#issuecomment-116843198] .[https://github.com/notifications/beacon/AC7z1kCLklQVyz_EnrJcSdiyHoGzo0yaks5oYac_gaJpZM4D6mfK.gif]