@@ -7,7 +7,7 @@ This lightweight tool helps you get a sense of your application's schema, as wel
_“I happen to slowly be falling in love with Variety! It is actually one of the most useful tools to get a sense for a messy/unknown data set, and I have put it in a few of our exercises at Zipfian Academy.”_
Jon Dinu
Jon Dinu
_Co-founder of [Zipfian Academy](http://www.zipfianacademy.com/)_
***
...
...
@@ -28,23 +28,23 @@ So, let's see what we've got here:
$ mongo test --eval "var collection = 'users'" variety.js
_("test" is the database containing the collection we are analyzing.)_
Hmm. Looks like everybody has a "name" and "_id". Most, but not all have a "bio".
Interestingly, it looks like "pets" can be either an array or a string. Will this cause any problems in the application, I wonder?
Interestingly, it looks like "pets" can be either an array or a string, but there are more strings than arrays. Will this cause any problems in the application, I wonder?
Seems like the first document created has a weird legacy key—those damn fools who built the prototype didn't clean up after themselves. If there were a thousand such early documents, I might cross-reference the codebase to confirm they are no longer used, and then delete them all. That way they'll not confuse any future developers.
...
...
@@ -148,6 +148,12 @@ Variety can also read that option and mute unnecessary output. This is useful in
Analyzing a large collection on a busy replica set primary could take a lot longer than if you read from a secondary. To do so, we have to tell MongoDB it's okay to perform secondary reads
by setting the ```slaveOk``` property to ```true```:
By default, Variety prints results only to standard output and does not store them in MongoDB itself. If you want to persist them automatically in database for later usage, you can set the parameter ```persistResults```.
Variety then stores result documents in database ```varietyResults``` and the collection name is derived from the source collection's name.