Implementing file attachments in a specific section

41 views Asked by At

I am currently writing an LMS, similar to google classroom for a school project. Everything went find until the part where i need to implement file uploads and attachments for class assignments/announcements/submissions.

So firstly, i've implemented the file upload, where files have an auto generated file id, file name, file path, file url, and file type. Then attachments, where they have an auto generated id, a foreign key to file id, nullable foreign keys to assignment, submission, and announcement id, and uploader

This is the problem: The auto generated ids for assignment/submissions/announcement are generated in the backend. So, when a user uploads an attachment for one of them, the foreign key field to assignment/submission/announcement id would be left out empty, and there's probably no way to keep them stored in the frontend when the user is refreshing the page after uploading the attachments, because i wouldn't be able to filter the attachment based on its foreign key. So, here are my questions:

  1. Should the id for assignment/submission/announcement be generated in the frontend?

If it is generated in the frontend, by the time the user uploads an attachment, i could just put the id into the attachment's foreign key fields. The id would be long, so it's kinda impossible for them to have a duplicate.

  1. Should i make all fields of assignment/submission/announcement be nullable + draft/published option?

So, when the user clicks "create assignment/submission/announcement", the frontend would send a post request to the server, and the server would give the assignment id back to the frontend, and having a "draft" status. When the user clicks "send to class", it would send a PATCH request with the rest of data needed for the assignment/submission/announcement, and update the status to published

  1. How does google classroom handle this?

The heading says it all

1

There are 1 answers

0
Mochida On

The second option works for me. Turns out that I don't need it to be stored after refresh. The frontend should just send a DELETE request on refresh, or on cancel. The ID is also generated in the backend, and stored temporarily in the frontend as long as it's not refreshed