refer to HackGT/timber#266 for the UI side changes
currently we have
const updatedCategoryGroup = await prisma.categoryGroup.update({
//...
data: {
//...
users: {
set: req.body.users?.map((id: number) => ({ id })) ?? undefined,
},
},
});(code ptr: services/expo/src/routes/categorygroups.ts, in categoryGroupRoutes.route("/:id").patch)
which takes the entire body.users (list of users) and sets it into storage which could cause a race condition if multiple people are adding judges.
Change this to accept the diff from the UI and instead perform a merge on the current set of users.
Talk to whoevers working on the ui side (or yourself) to confirm data shape, probably do something like {add: [...], removed: [...]} and then we just have to fetch the current list of judges and merge it in
^ There maybe could be a race condition between endpoint handles too (another call pulls users list before a previous one is done writing back in to db), so might have to deal with that too (lower prio). Maybe theres a postgres thing for that.
refer to HackGT/timber#266 for the UI side changes
currently we have
(code ptr:
services/expo/src/routes/categorygroups.ts, incategoryGroupRoutes.route("/:id").patch)which takes the entire
body.users(list of users) and sets it into storage which could cause a race condition if multiple people are adding judges.Change this to accept the diff from the UI and instead perform a merge on the current set of users.
Talk to whoevers working on the ui side (or yourself) to confirm data shape, probably do something like
{add: [...], removed: [...]}and then we just have to fetch the current list of judges and merge it in^ There maybe could be a race condition between endpoint handles too (another call pulls users list before a previous one is done writing back in to db), so might have to deal with that too (lower prio). Maybe theres a postgres thing for that.