How to delete a Collection?

[elgusto]

I have an app where I create collections dynamicaly based on documents in an other collection.

I am looking for a way to remove the dynamicaly created collections when the document from the base collection is removed.

I currently empty the created collection via a cursor observe but I cannot find a way to succesfully remove the collection from mongo.

How would you proceed ?

[fvilers]

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.

[elgusto]

Thanks for the reply.

I have a cusor oberve callback instead of using collection hooks package to achieve this.

It is indeed this drop() function that I would like to use inside of the Meteor app.

[artpolikarpov]

Is it a server collection or a client-only collection with collection:null?

[elgusto]

“Unfortunately” it is a server/client collection.

[nlammertyn]

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?

[elgusto]

The use-case is the following:

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.

[kookoskar]

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?

[elgusto]

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.

[kookoskar]

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.

[elgusto]

I think this is the way to go!

I will post here later when I am done with the package.

Thanks for your valuable input!

[trusktr]

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.