sonnyvesali
commented
3 months ago also bifurcate user information into priv & pub & make education_metadata the sub json b for all that information to the schema is more resilient to changes & you can minimize the columns
to put it simply there are some things that don't need to be called every time like we've done right now, certain things are one time things such as add-user-metadata, so the way we've solved this is basically through a mix of sql scripts (for existing rows )as well as triggers for new ones) so that can be used to basically take out
the other things I would say is this, so the nokhte-session-join can also be sped up quite a bit, through a breakdown into triggers as well as a simplified sql implementation so imagine that you only had to update the a single row, like collaborator-uids and then you use a trigger to basically update that entire row, I'd bet the query for joining would be substantially quicker.
init session can all be put into a similar architecture, the main thing you could do to preserve rls, is that the only rows you would allow updates on collaborator_uids and maybe some other rows, the question would be how you do updates, there isn't anything wrong with keeping this edge function b/c adding the uid does require some circumvention of rls, but you could also figure out some way of having a queue that the leader executes, but that may be too complex of a setup you just keep an edge function that's like a single query line of inserting, and the rest gets executed as a trigger
nuke session => this one is actually really simple I don't actually thing it would need to be an edge function it's really just about killing idle sessions that only include one person & are really impotent
complete session => same thing here, what you do is that you allow delete, but this time all the side effects get executed as a trigger, all the things about updating authorized viewers, consuming free trials, adding it to finished sessions, all that stuff