What exactly is a "cursor" in MongoDB?

[fuzzybabybunny]

The MongoDB docs don't say what exactly a cursor *is*.

If I do the following:

db.users.find({age: 20})

I get a "cursor", which I'm then expected to "iterate" over. When I hear "iterate" I think "do something over and over" or "loop."

But if I do:

db.users.find({age: 20}).fetch()

I get an actual object containing all the keys and values matching my query.

So what exactly is a cursor? Is it like an address that points to the results of the query? How do you "iterate" over an address?

Cursors in Mongo deactivate themselves after 10 minutes. So I'm thinking that maybe cursors are, like, a set of instructions to find what I'm querying? It doesn't perform the actual query and it doesn't return the actual objects?

 

[mv2devnull]

http://en.wikipedia.org/wiki/Cursor_(databases)

 

[Markbnj]

I think what you read was "curses," which is what people do when they realize how Mongo works.

j/k. obviously.

 

[Jaydip]

Here is how,

var fuzzybabybunnycursor=db.users.find({age: 20});
fuzzybabybunnycursor.forEach(printjson);

Cursor behaves like a pointer to an Array, you can iterate as long as it points to something.

 

[beginner99]

The important part is that it's a pointer and no data has been loaded from the disk so far. This avoids reading data you don't really want maybe you you stop reading after 100 records also if done properly prevents memory issues. If you just read a huge dataset at once, maybe it's too big.

 

[mv2devnull]

But if I do:

db.users.find({age: 20}).fetch()

I get an actual object containing all ...

The fetch() obviously does iteration in order to construct a result object.
Is the cursor still valid after the fetch()?

 

[BoberFett]

The important part is that it's a pointer and no data has been loaded from the disk so far. This avoids reading data you don't really want maybe you you stop reading after 100 records also if done properly prevents memory issues. If you just read a huge dataset at once, maybe it's too big.

Of course cursors can also be far MORE resource intensive than simply spitting out the results. Depends entirely on the purpose, what kind of cursor you're using, and how you're using it.

If I just wanted 100 read only records, I'd do a TOP 100.

If you need to move forward and backward in a set, execute complex logic in a store proc on each row, sure.

Don't even start on the potential for causing performance problems through not understanding locking and the effect cursors can have there...

I've often found that if I look at my logic where I thought I might need a cursor, I can break things down into a couple simpler set based queries that I can do the same thing faster and more logically. Cursors can be useful, but very case specific.

 

[fuzzybabybunny]

Ohhhhhhhhh... wow, that's a very important distinction - it's actually not bring back the data.

I guess when you're starting out with this database stuff, you're working with really small datasets and really simple data.

Say you've got a database of 5 users and you want to get the first names of each user. You run the query and get back a cursor but of course the cursor isn't an object containing the actual first names and then you have to go through an extra step to fetch the data and bring it back as an actual object that you can use.

That's where I got confused. I actually want the data values and I was wondering why is there even this cursor nonsense since (in my head) the purpose of a database is to output actual data values.

I hadn't considered that if the database had a million users I wouldn't want my query to then immediately fetch ALL of that data and bring it back on the wire.

So yeah, cursors can be useful in certain situations, haha.