Skip to content

Captain / Alternate indicator on statscards #87

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
vreelb opened this issue Nov 13, 2014 · 6 comments
Open

Captain / Alternate indicator on statscards #87

vreelb opened this issue Nov 13, 2014 · 6 comments

Comments

@vreelb
Copy link
Member

vreelb commented Nov 13, 2014

This could go where the NHL 'flavor' logos are if the player is not a draft pick (which is most cases).

Collision details will have to be figured out. Also this will result in using s8/s8, so if we plan on tracking anything else we should look into expanding those (or switching to MongoDB).

@hamilr2
Copy link
Member

hamilr2 commented Nov 13, 2014

Re: S8 / MongoDB --

I'd like to switch to an "arbitrary attribute" sort of nosql / key/value model for teams, players, and stats at some mid-term point. Titles/geos/attributes already follow this model, which gives them huge amounts of flexibility.

The issue is that the editing interface becomes significantly more complex than our current EditableTable, and it's not necessarily clear which attributes are required for the concept of a 'player' or 'team' to exist.

@peteritism
Copy link
Member

I've gotten the sudden urge to take this head on after swearing at the editing UI over the last few days (love you Reilly :P). My real motivation is to completely overhaul the editing UI, but I see no point in doing that only to have to redo it once this is done.

I completely agree that everything needs to move to k:v. We need flexibility at every level of a game/event and we just don't have it now.

At a basic level -- rewriting this to the status quo -- I don't think the layout needs to change much. Currently you have the stattype (stype) which gives a name to a stat field on a player-by-player basis. You can similarly make the construct of a sport under which you can arbitrarily decided who gets what stat (a postition of 'G' gives you WLT Saves GAA and shows xyz information in the editing interface; a set of keys could be defined as a bio so it can be segregated, hidden, etc). So really your only difference from the editable table is that you get one editable table for players and one for goalies, which is already a better logical grouping.

At that point, you're back to where we are currently, which means this could enter production without entirely fleshing out how to deal with additional data from an editing and a display perspective, and add as we figure things out. I need more time to think about handling an extended set of data, but I don't think that means we need to hold off, and I'm sure you've had some ideas in the past months. Let's talk this week if you have some time.

@hamilr2
Copy link
Member

hamilr2 commented Jan 19, 2015

Cool, are you free to meet Wednesday? Can you meet at like 9pm ET? I could maybe do 8pm if 9 is too late.

I know we talked about doing this last year, and then decided to do it over the summer. Well, that didn't happen, so lets knock it out now. I don't think it'll be too hard to replicate functionality, especially if we can do it alongside the existing implementation to not impact production.

I like the idea of grouping things for display. Could get a bit complex to set up different rules, but the result should be quite nice.

@peteritism
Copy link
Member

9 works for me. Perhaps @vreelb and @asquared will join as well.

Since we are moving to a new DB scheme, we can basically start from scratch with the db alongside the current version. The only thing that might be useful to keep and convert is team info, but all the player info is expendable.

@peteritism peteritism assigned peteritism and vreelb and unassigned vreelb and peteritism Jan 19, 2015
@hamilr2
Copy link
Member

hamilr2 commented Jan 19, 2015

Spitballing schema/editing:
http://i.imgur.com/Aq0lSBT.png

EDIT: http://www.gliffy.com/go/publish/7000241

@vreelb
Copy link
Member Author

vreelb commented Apr 8, 2015

RE: Questions

Do players have to belong to a team?
I lean towards yes, but there are events where individuals compete without affiliation. Should they then just be "their own team" as far as the database is concerned or should we make team associations optional?

How are players linked to a team?
Team has player ids, multiple teams can have player on them (Hockey + Golf for example). Stats for a player are associated with sport/team.

Should "teams" correspond to a single season?
Yes, though I feel it should be a subset... like RPI -> 14-15. They were chosen for the team "4 times".

What attributes do players have to have? Any? Name?
Name, but we can't require First AND Last (see: Ichero [Suzuki], etc).

How do coaches fit in?
Player with no number and "Coach/Asst. Coach" position, they are on the team X seasons, etc. just like the players. Special positions can be ignored when looking for player count.

Do we care about +/- being present? Should title just decide?
It should be optional, that way we can do without if need be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants