Closed pastly closed 7 years ago
How should we actually record position years? 2015-2016 makes sense for a school year, but those people should not be shown in the officers page (as that term is already over).
GOOD point. I suggest we break it up by semester and store an addition 's' for sprint or 'f' for fall. Should it be its own column or tacked onto the year (ex: '2016f')? Good question.
If we do it this way, then the front end can determine if we are in the first half of the year or second half and search for an 's' or 'f' based on the answer.
Open to suggestions. Right now it just sees if current_year
is in the year column, which I know will return half wrong results.
That means we have to create potentially a dozen records for someone like Eugene. Why not make end_year exclusive if it's June or later?
2015-2016, currently feb 2016: Valid officer 2015-2016, currently October 2016: Not officer
EDIT: Also need to consider partial-year officers. Just fall 2016 for example.
EDIT2: Should we just break this down into a start_date/end_date? Seems a little unnecessary, but handles all the weird cases.
See https://github.com/pastly/db-final-project/issues/10 for storage of position year questions/development.
While the tangent is resolved, the original 'issue' remains, but is now mute imo. If we display the entire person merged with position record (name/title/start/end) I think it will be fine.
I'm not 100% on what @Deedasmi is saying, but I think/agree this is no longer an issue. The /people/index.html page will have up to 4 lists of people, and I think it's fine that Richard Petrie shows up in both the students list and the officer list.
This makes sense because of how the query is written, but we want something like
array_agg
onpos.c.title
Couldn't figure it out quickly, so here is the issue.