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
Create Shift CRUD Methods and GraphQL Resolvers #55
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great progress so far! 😄 This is a big set of changes so I'll be doing another round of review after these comments are addressed
@sherryhli updated changes! Feel free to review again. Thanks! 💯 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there! I noticed an edge case when creating shifts with no recurrence interval, otherwise just some minor things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more minor comment!
37e1d33
to
9553342
Compare
@sherryhli fixed! Let me know if there's anything else 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay reviewing! A few very minor things left, which I can take of
77d3475
to
08b3564
Compare
08b3564
to
77d3475
Compare
return shiftTimes; | ||
} | ||
|
||
async checkConflictingShifts( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LenaNguyen some context on why we check for conflicts :)
We want to avoid creating duplicate shifts (i.e. 2 shifts associated with the same posting that have the exact same start time and end time. This validation is pretty costly but unless there are significant performance issues, I think it's worthwhile to keep. We wouldn't want the database to be spammed with lots of duplicate entries (either accidentally or maliciously), it'd hurt performance and waste our row count quota in Heroku.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what is more efficient but we can also add an index to the database so that postingId, startTime, and endTime are unique.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, overlapping shift times are okay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked product peops last month and they were OK with overlapping shift times 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what is more efficient but we can also add an index to the database so that postingId, startTime, and endTime are unique.
I like this idea. My feeling is that even with the write overhead of indexing, it might be more performant as it wouldn't require querying all shifts of a posting and then comparing start/end times for every shift write.
Would suggest merging this current implementation first though and doing some experiments before committing to the index approach.
} | ||
|
||
buildTimeBlocks(shifts: ShiftBulkRequestDTO): TimeBlock[] { | ||
const endDate: Moment = moment(shifts.endDate, dateFormat, STRICT_MODE).add( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we add a day to the endDate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This offset is made so that when we compare startTime
to endDate
, any time block that starts and ends on the original endDate will be added to shiftTimes
. For example, if our end date is 2022-01-01, a time block that starts on that same day (2022-01-01) will be added as it passes the start < endDate
check.
return shiftTimes; | ||
} | ||
|
||
async checkConflictingShifts( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what is more efficient but we can also add an index to the database so that postingId, startTime, and endTime are unique.
return shiftTimes; | ||
} | ||
|
||
async checkConflictingShifts( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, overlapping shift times are okay?
const recurringShifts = []; | ||
if (duration) { | ||
for ( | ||
let start = startTime.clone(), end = endTime; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we copy startTime but not endTime?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's safe to not clone startTime
but I wasn't 100% sure, @lambo-liu can you confirm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Create a dummy posting using SQL. Here are the following SQL queries to run:
insert into branches (id, name) values (1, 'test branch');
insert into postings (id, branch_id, type, title, purpose, responsibilitie, tasks, desired_qualities, mandatory_activities, benefits, working_conditions, num_volunteers) values (1, 1, 'GROUP', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 0);
Go to localhost:5000/graphql, and test the individual queries & resolvers.
The insert for postings in this PR description is out of date right? I tried running it and the table no longer has some of these colums.
Sorry Lena! Forgot to update these after Brian & Albert changed the schema for postings. Will update this now. |
@LenaNguyen this is the updated insert: INSERT INTO postings (branch_id, type, title, description, num_volunteers, auto_closing_date, start_date, end_date) VALUES (1, 'GROUP', 'Title', 'Description', 5, '2021-01-01', '2021-01-11', '2021-01-15'); Could you take a final pass at this PR, I think it's good to go :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but let's hold off on merging until Lena approves
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good :))
Ticket link
Closes #51
Implementation description
Steps to test
insert into branches (id, name) values (1, 'test branch');
insert into postings (id, branch_id, type, title, description, auto_closing_date, start_date, end_date) values (1, 1, 'GROUP', 'a', 'a', '2022-01-09T21:33:51.302Z', '2022-01-09T21:33:51.302Z', '2022-01-09T21:33:51.302Z');
localhost:5000/graphql
, and test the individual queries & resolvers.Examples:
Create shifts by bulk, using a biweekly recurrence interval
mutation { createShifts(shifts: { postingId: "1", times: [ { date: "2021-12-16" startTime: "01:30" endTime: "04:30" }, { date: "2021-12-18" startTime: "12:00" endTime: "16:00" } ], endDate: "2022-01-15", recurrenceInterval: BIWEEKLY }) { id postingId startTime endTime } }
Update a single shift
mutation { updateShift(id: "1", shift: { startTime: "2021-12-16 04:30", endTime: "2021-12-16 06:30" }) { postingId startTime endTime } }
What should reviewers focus on?
HH:mm
format, and DateTimes should be inputted in theYYYY-MM-DD HH:mm
format. Any other format should throw an error.Checklist