How do I describe a collection in Mongo?

Question

So this is Day 3 of learning Mongo Db. I\'m coming from the MySql universe...

A lot of times when I need to write a query for a MySql table I\'m unfamiliar with, I woul

Answer 1

If you're OK with running a Map / Reduce, you can gather all of the possible document fields.

Start with this post.

The only problem here is that you're running a Map / Reduce on which can be resource intensive. Instead, as others have suggested, you'll want to look at the code that writes the actual data.

Just because the database doesn't have a schema doesn't mean that there is no schema. Generally speaking the schema information will be in the code.

Answer 2

I wrote a small mongo shell script that may help you. https://gist.github.com/hkasera/9386709

Let me know if it helps.

Answer 3

This is an incomplete solution because it doesn't give you the exact types, but useful for a quick view.

const doc = db.collectionName.findOne();
for (x in doc) {
  print(`${x}: ${typeof doc[x]}`)
};

Answer 4

AFAIK, there isn't a way and it is logical for it to be so.

MongoDB being schema-less allows a single collection to have a documents with different fields. So there can't really be a description of a collection, like the description of a table in the relational databases.

Though this is the case, most applications do maintain a schema for their collections and as said by Chris this is enforced by your application.

As such you wouldn't have to worry about first fetching the available keys to make a query. You can just ask MongoDB for any set of keys (i.e the projection part of the query) or query on any set of keys. In both cases if the keys specified exist on a document they are used, otherwise they aren't. You will not get any error.

For instance (On the mongo shell) :

If this is a sample document in your people collection and all documents follow the same schema:

{
  name : "My Name"
  place : "My Place"
  city : "My City"
}

The following are perfectly valid queries :

These two will return the above document :

db.people.find({name : "My Name"})
db.people.find({name : "My Name"}, {name : 1, place :1})

This will not return anything, but will not raise an error either :

db.people.find({first_name : "My Name"})

This will match the above document, but you will have only the default "_id" property on the returned document.

db.people.find({name : "My Name"}, {first_name : 1, location :1})

Answer 5

I had this need too, Cavachon. So I created an open source tool called Variety which does exactly this: link

Hopefully you'll find it to be useful. Let me know if you have questions, or any issues using it.

Good luck!

Answer 6

This is my day 30 or something like that of playing around with MongoDB. Unfortunately, we have switched back to MySQL after working with MongoDB because of my company's current infrastructure issues. But having implemented the same model on both MongoDB and MySQL, I can clearly see the difference now.

Of course, there is a schema involved when dealing with schema-less databases like MongoDB, but the schema is dictated by the application, not the database. The database will shove in whatever it is given. As long as you know that admins are not secretly logging into Mongo and making changes, and all access to the database is controller through some wrapper, the only place you should look at for the schema is your model classes. For instance, in our Rails application, these are two of the models we have in Mongo,

class Consumer
    include MongoMapper::Document

    key :name, String
    key :phone_number, String
    one :address
end

class Address
    include MongoMapper::EmbeddedDocument

    key :street, String
    key :city, String
    key :state, String
    key :zip, String
    key :state, String
    key :country, String
end

Now after switching to MySQL, our classes look like this,

class Consumer < ActiveRecord::Base
    has_one :address
end

class Address < ActiveRecord::Base
    belongs_to :consumer
end

Don't get fooled by the brevity of the classes. In the latter version with MySQL, the fields are being pulled from the database directly. In the former example, the fields are right there in front of our eyes.

With MongoDB, if we had to change a particular model, we simply add, remove, or modify the fields in the class itself and it works right off the bat. We don't have to worry about keeping the database tables/columns in-sync with the class structure. So if you're looking for the schema in MongoDB, look towards your application for answers and not the database.

Essentially I am saying the exactly same thing as @Chris Shain :)