Quickest way to delete database from running meteor?

[Sam Hatoum]

I'm writing a set of acceptance tests that require a "clearState" before every run, thus ensuring independence of test idempotency. I'd like to do do this to a running meteor app.

The tests are driven by node from outside the meteor app, so I can either call a method within the running meteor app, or I can access mongo directly from the node app.

The way I've done this in the past with old-school web applications is having an endpoint that does this like this: http://localhost:8080/fixture/clearState - which would call a set of truncate methods. I found htis to be the fastest mechanism.

I'm very open to suggestions here. Speed is the most important factor here as I have a parallel meteor app running that is rsynced on every file save, which then triggers a full suite of acceptance tests so with time this will get slow and milliseconds count!

Anyone have any ideas?

[Dror Matalon]

Two options.
1. Drop all your collections. Nice and easy.
2. Actually remove the database in .meteor/local/db You should restart
Meteor after doing that.

> --
> You received this message because you are subscribed to the Google Groups
> "meteor-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to meteor-talk...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Sam Hatoum]

Thanks

What's the mechanism for dropping collections (I'm new to mongo)? Through a direct mongo connection or from the running meteor app?

Is this the fastest method?

[David Glasser]

If the app is not running, there's "meteor reset", but it sounds like
that isn't what you want.

[Dror Matalon]

My mistake. I thought I was dropping the collection, but I was
actually doing collection.remove({});
which removes all the documents from a collection. I don't see a
command in Meteor to drop a collection. Mongo supports the drop()
command, but I don't see it in the Meteor docs.

On Wed, Apr 3, 2013 at 9:18 PM, Sam Hatoum <s...@hatoum.net> wrote:

[Sam Hatoum]

Not quite. I could use this as a last resort though :)

[Sam Hatoum]

I'll give that a shot and see how that works with collection.remove ({}) — thanks

The other thing to try I guess is to connect from the test harness to mongo directl and call drop. I wonder how meteor will behave when I move the world from under its feet. 

[Ted Neward]

You can either fire up “mongo” (the command-line client) and use that to connect to the running server to drop the collections, or do it from code inside the Meteor app. Is the app running local to your box? Is this something you have to do over and over again, or a one-off?

 

Ted Neward

Leading, Speaking, Consulting, Writing

http://www.tedneward.com

[Sam Hatoum]

The app is running local and this would happen on a one-to-one ratio with the acceptance tests, of which there will be hundreds.

If I connect to the db and drop all tables from my test runner (which is a separate process), will this cause meteor to fire events?

[Ted Neward]

That, I couldn’t say—I’m newer to Meteor than you. I doubt it, though, since I *think* MongoDB doesn’t have any kind of database-originating push notification that Meteor could hook into. (At least, I’ve never seen one, but it’s been a while since I cruised through the Mongo docs.) Going through the Mongo shell completely bypasses the Meteor infrastructure.

 

Meteor folks, correct me where I’m wrong.

[Andrew Wilcox]

If I connect to the db and drop all tables from my test runner (which is a separate process), will this cause meteor to fire events?

Yes, Meteor polls the database to detect changes made to collections from other applications.

I expect you'll need to call collection.remove({}) anyway to clear Meteor's internal cache of the collection's documents, so that's what I'd do.

If tests turn out to be slow I'd try running them in parallel against separate databases.

Also consider using new Meteor.Collection(null) as a database mock.  This allows you to test the collection related logic of your application without the overhead of using the real database.

[Sam Hatoum]

Perfect, just the info I need. Thanks Andrew

I hadn't thought about meteor's caching and if it's to be running, then I'll need to ensure that's taken care of too.

I'll definitely be creating a grid of mirror apps to speed up the tests further down the line, but I'd like that "further" to be as far as possible :)

Thanks for the suggestion on the Meteor.Collection(null), it'd be useful for any integration testing work. For the acceptance testing however, we've got to have the real db as to ensure the full stack is being exercised. Even the hosting infrastructure is included here.

Can collection.remove({}) be called from the client? I'm using selenium which can inject scripts into the client, so I could do this if it's client side.

[Andrew Wilcox]

Can collection.remove({}) be called from the client? I'm using selenium which can inject scripts into the client, so I could do this if it's client side.

Don't know off hand if remove is included in the "client can only modify one document at a time" rule or not, but if not, just make a Meteor method for the client to call.

[Sam Hatoum]

Got it. Thank you

On 4 April 2013 10:32, Andrew Wilcox <andrew...@gmail.com> wrote:

Can collection.remove({}) be called from the client? I'm using selenium which can inject scripts into the client, so I could do this if it's client side.

Don't know off hand if remove is included in the "client can only modify one document at a time" rule or not, but if not, just make a Meteor method for the client to call.