Hey guys I was hoping for a little help on narrowing down an issue I’ve noticed with parse for a while now. 3 years ago I noticed that removing rows via Parse Dashboard didn’t clean up file data. In MongoDB both fs. files and fs. chunks stayed the same. It wasnt that big of a deal then because we werent doing a bunch of file storage.
For the last few weeks I’ve been working on migrating a clients huge project from Firebase to Parse for an image intensive application. Being primarily an iOS developer now I decided to use Parse Dashboard because its easier to see how my migration went between objects. Its also a little faster to just click a few buttons and clear the entire database and make an adjustment and run it again.Several times now I’ve hit my database size limit even after deleting every object from every table and found that fs. file and fs chunk is not empty and fs. chunk size is massive. Deleting those tables entirely temporarily resolves my issue and I am able to move forward till I hit the size limit again.
Now, I see that the issue was fixed for fs. file via issue #506 for Parse Server back in 2016. I see no issue for fs chunk at all on either Parse Server or Parse Dashboard.
So here’s my questions. I’m trying to figure out possibly what the issue is and who might be responsible for it so I can add it to the correct channel. So, I have a few questions.
What is fs chunk? Should it be cleaned up immediately or is it temporary file data that would have eventually been cleaned up but I am running scripts too quickly for that to happen. In other words am I the issue?
Is there a workaround? I figured anyone who’s an expert with parse server and its internal workings could figure this out faster than I could. Would nullifying the column prior to deletion remove the file data?
On a unrelated note while looking around in mLabs I noticed that all Parse Relation tables never got cleared either after deleting all data from a class. Think its worth opening a issue for that? I would assume whoevers responsible for question 3 is also responsible for this.