You should start by having a look at Collection Hooks to execute a callback when the document is removed. Then, you could remove all documents from the created collection in the callback.
But I canât find any way to remove the collection inside Meteor like you would on the command line with the drop() function.
Creating collections dynamically seems like a strange method, perhaps quickly outline your use-case as Iâm quite sure you could more easily solve it with a single collection?
In my app, I made a survey builder using autoform and simple schema. The output of this form builder is a document of my âsurveysâ collection having fields like âtitleâ, âcreatedAtâ, etc and a blackbox field: schema.
This schema is then used to create a dynamic collection to collect the survey results, again using autoform.
I know this seems weird but I didnât want to store the results in the survey document as I read in the mongo documention that document arrays that grow a lot are not really recommended. I understand I will NOT have millions of survey results but I thought this to be the best practice for this use case (mongo noob talking).
I was also thinking to change my form builder to give it a broader use: some kind of entity creation for a CMS. (I plan to release the package on atmosphere as soon as I am satisfied with my code, it is a little bit messy right now as I was experimenting with object heritage)
If you could recommend a better pattern for this, I would be ever so grateful.
Why not just use a âdedicatedâ separate Collection for results and store surveyId with each result? Then you can just run
SurveyResults.remove({surveyId: surveyId});
This way, you always have one âaccess pointâ to all results and can always very easily operate with them. Unless thereâs some trickery involved for why you need a new Collection every time?
I have to think about this. The issue I see straight away is the validation of the survey results because doing as you say would mean that I would need to change the schema for the survey result collection for each survey. I have to see how autoform does validation in details but I think it runs in both the client and the server.
I havenât used autoform myself, but as far as I can see, you can specify a schema instead of a collection for a form (by passing schema=something instead of collection=something). Which means you donât have to âattachâ a schema to the collection, but can just use the schema directly with autoform.
The documentation itself specifically states:
This schema will be used to generate and validate the form prior to submission, so you can specify this along with a collection if you want to use a schema that is slightly different from the one your collection uses.
The way I see it: thereâs no schema on the collection, but you just pipe the schema directly to autoform, which does the validation etc. If result is validated by autoform, it is inserted into the collection with surveyId, at which point you can operate with it however you want.
Correct me if Iâm wrong and this doesnât work, of course.
A database migration might involve renaming a collection, and itâd be convenient to be able to delete the old collection right in the same server code that is running the migration.