Interview Q and A for MongoDB Part - 1

1. What were you trying to solve when you created MongoDB?

We were and are trying to build the database that we always wanted as developers.

For pure reporting, SQL and relational is nice, but when building data always wanted something different: something that made coding scaled horizontally.

2. What was a major hurdle in the early days of MongoDB?

The big hurdle for the whole nosql space was that moving to anything from

relational is a big step for the user. Relational is a great Everyone who graduates from school already knows it. However, computer architectures are changing, cloud computing is coming if not already here. We need solutions that run in fundamentally different environments. Also are interesting -- thus the dynamic schema nature of the product.

3. What makes Mongodb best? OR Why should use MongoDB ?

Document-oriented

High performance (Index on any attribute, Auto-Sharding, Fast In-Place Updates )

Replication & High availability

Easy scalability

Rich query language

Professional Support By MongoDB

4. If I am using replication, can some members use journaling and others not?

Yes

5. Can I use the journaling feature to perform safe hot backups?

Yes

6. What is a 32 bit nuance?

There is extra memory mapped file activity with journaling. This will further constrain the limited db size of 32 bit builds. Thus, for now journaling by default is disabled on 32 bit systems.

7. Will the journal replay have problems if entries are incomplete (like the failure happened in the middle of one)?

Each journal (group) write is consistent and won't be replayed during recovery unless it is complete.

8. What is role of Profiler/ analyzer in MongoDB?

MongoDB includes a database profiler which shows performance characteristics of each operation against the database. Using the profiler you can find queries (and write operations) which are slower than they should be; use this information, for example, to determine when an index is needed

9. What's a "namespace"?

MongoDB stores BSON objects in collections. The concatenation of the database name and the collection name (with a period in between) is called a namespace.

A “namespace” is the concatenation of the database name and the collection names  with a period character in between. Collections are containers for documents that share one or more indexes. Databases are groups of collections stored

on disk using a single set of data files. For an example acme.users namespace, acme is the database name and users is the collection name. Period

characters can occur in collection names, so that acme.user.history is a valid namespace, with acme as the database name, and user.history as the collection name.

While data models like this appear to support nested collections, the collection namespace is flat, and there is no difference from the perspective of MongoDB between acme, acme.users, and acme.records.

10. If you remove an object attribute is it deleted from the storage layer?

Yes, you remove the attribute and then re-save() the object.

11. Are null values allowed?

For members of an object, yes. You cannot add null to a database collection though as null isn't an object. You can add {}, though.

12. Does an update fsync to disk immediately?

No, writes to disk are lazy by default. A write may hit disk a couple of seconds later. For example, if the database receives a thousand increments to an object within one second, it will only be flushed to disk once. (Note fsync options are available though both at the command line and via getLastError_old.)

13. How do I do transactions/locking? OR How do I do transactions and locking in MongoDB?

MongoDB does not have support for traditional locking or complex transactions with rollback. MongoDB aims to be lightweight, fast, and predictable in its performance. This is similar to the MySQL MyISAM autocommit model. By keeping transaction support extremely simple, MongoDB can provide greater performance especially for partitioned or replicated systems with a number of database server processes.

MongoDB does have support for atomic operations within a single document. Given the possibilities provided by nested documents, this feature provides support for a large number of use-cases.

14. Why are my data files so large? OR Why are MongoDB’s data files so large?

MongoDB aggressively preallocates data files to reserve space and avoid file system fragmentation. You can use the storage.smallFiles setting to modify the file preallocation strategy.

15. How long does replica set failover take?

It varies, but a replica set will select a new primary within a minute.

It may take 10-30 seconds for the members of a replica set to declare a primary inaccessible. This triggers an election. During the election, the cluster is unavailable for writes. The election itself may take another 10-30 seconds.

Note: Eventually consistent reads, like the ones that will return from a replica set are only possible with a write concern that permits reads from secondary members.

16. What's a master or primary? OR What do the terms “primary” and “master” mean?

Primary and master nodes are the nodes that can accept writes. MongoDB’s replication is “single-master:” only one node can accept write operations at a time.

In a replica set, if the current “primary” node fails or becomes inaccessible, the other members can autonomously elect one of the other members of the set to be the new “primary”.

By default, clients send all reads to the primary; however, read preference is configurable at the client level on a per-connection basis, which makes it possible to send reads to secondary nodes instead.

17. What's a secondary or slave? OR What do the terms “secondary” and “slave” mean?

Secondary and slave nodes are read-only nodes that replicate from the primary.

Replication operates by way of an oplog, from which secondary/slave members apply new operations to themselves. This replication process is asynchronous, so secondary/slave nodes may not always reflect the latest writes to the primary. But usually, the gap between the primary and secondary nodes is just few milliseconds on a local network connection.

18. Do I have to call getLastError to make a write durable?

No. If you don't call getLastError (aka "Safe Mode") the server does exactly the same behavior as if you had. The getLastError call simply lets one get confirmation that the write operation was successfully committed. Of course, often you will want that confirmation, but the safety of the write and its durability is independent.

19. Should I start out with sharded or with a non-sharded MongoDB environment?  OR    Is sharding appropriate for a new deployment?

Sometimes. If your data set fits on a single server, you should begin with an unsharded deployment. Converting an unsharded database to a sharded cluster is easy and seamless, so there is little advantage in configuring sharding while your data set is small.Still, all production deployments should use replica sets to provide high availability and disaster recovery.

20. How does sharding work with replication?

To use replication with sharding, deploy each shard as a replica set. Each shard is a logical collection of partitioned data. The shard could consist of a single server or a cluster of replicas.

21. When will data be on more than one shard?

MongoDB sharding is range based. So all the objects in a collection get put into a chunk. Only when there is more than 1 chunk is there an option for multiple shards to get data. Right now, the default chunk size is 64mb, so you need at least 64mb for a migration to occur.

22. What happens if I try to update a document on a chunk that is being migrated?

The update will go through immediately on the old shard, and then the change will be replicated to the new shard before ownership transfers.

23. What happens to queries if a shard is inaccessible or slow?

If a shard is inaccessible or unavailable, queries will return with an error. However, a client may set the partial query bit, which will then return results from all available shards, regardless of whether a given shard is unavailable. If a shard is responding slowly, mongos will merely wait for the shard to return results.

24. Can I remove old files in the moveChunk directory?

Yes, these files are made as backups during normal shard balancing operations. Once these migrations are complete, you may delete these files.The cleanup process is currently manual so please do take care of this to free up space.

25. How can I see the connections used by mongos?  OR

Where does MongoDB report on connections used by mongos?

Connect to the mongos with the mongo shell, and run the following command:

db._adminCommand("connPoolStats");

26. If a moveChunk fails do I need to cleanup the partially moved docs?

No, chunk moves are consistent and deterministic; the move will retry and when completed the data will only be on the new shard.

27. What do you understand by NoSQL databases? Is MongoDB a NoSQL database? explain.

At the present time, the internet is loaded with big data, big users, big complexity etc. and also becoming more complex day by day. NoSQL is answer of all these problems, It is not a traditional database management system, not even a relational database management system (RDBMS). NoSQL stands for "Not Only SQL". NoSQL is a type of database that can handle and sort all type of unstructured, messy and complicated data. It is just a new way to think about the database.

Yes. MongoDB is a NoSQL database.

28. What are the different types of NoSQL databases? Give some example.

NoSQL database can be classified as 4 basic types:

1. Key value store NoSQL database
2. Document store NoSQL database
3. Column store NoSQL database
4. Graph base NoSQL databse

There are many NoSQL databases. MongoDB, Cassandra, CouchBD, Hypertable, Redis, Riak, Neo4j, HBASE, Couchbase, MemcacheDB, Voldemort, RevenDB etc. are the examples of NoSQL databases.

29. What type of DBMS is MongoDB?

MongoDB is a document oriented DBMS.

30. What is the difference between MongoDB and MySQL?

Although MongoDB and MySQL both are free and open source databases, there is a lot of difference between them in the term of data representation, relationship, transaction, querying data, schema design and definition, performance speed, normalization and many more. To compare MySQL with MongoDB is like a comparison between Relational and Non-relational databases.

MySQL Term	Mongo Term
Database	Database
Table	Collection
Row	BSON document (binary encoded serialization of JSON like documents)
Column	BSON field
Primary Key	Element name "_id" is used

31. What is the difference b/w MongoDB and CouchDB?

MongoDB and CouchDB both are the great example of open source NoSQL database.  Both are document oriented databases. Although both stores data but there is a lot of difference between them in terms of implementation of their data models, interfaces, object storage and replication methods etc

32. In which language MongoDB is written?

MongoDB is written and implemented in C++. Drivers and client libraries are typically written in their respective languages, although some drivers use C extensions for better performance.

33. Does MongoDB need a lot space of Random Access Memory (RAM)?

Not necessarily. It’s certainly possible to run MongoDB on a machine with a small amount of free RAM. MongoDB automatically uses all free memory on the machine as its cache. System resource monitors show that MongoDB uses a lot of memory, but its usage is dynamic. If another process suddenly needs half the server’s RAM,

MongoDB will yield cached memory to the other process.

Technically, the operating system’s virtual memory subsystem manages MongoDB’s memory. This means that MongoDB will use as much free memory as it can, swapping to disk as needed. Deployments with enough memory to fit

the application’s working data set in RAM will achieve the best performance.

34. What language you can use with MongoDB?

MongoDB client drivers supports all the popular programming languages so there is no issue of language, you can use any language that you want.

35. Does MongoDB database have tables for storing records?

OR  Do MongoDB databases have tables?

No. Instead of tables, a MongoDB database stores its data in collections, which are the rough equivalent of RDBMS tables. A collection holds one or more documents, which corresponds to a record or a row in a relational database table, and

each document has one or more fields, which corresponds to a column in a relational database table.

Collections have important differences from RDBMS tables. Documents in a single collection may have a unique combination and set of fields. Documents need not have identical fields. You can add a field to some documents in a collection without adding that field to all documents in the collection.

36. Do the MongoDB databases have schema?

Yes.

MongoDB uses dynamic schemas. You can create collections without defining the structure, i.e. the fields or the types of their values, of the documents in the collection. You can change the structure of documents simply by adding new

fields or deleting existing ones. Documents in a collection need not have an identical set of fields.

In practice, it is common for the documents in a collection to have a largely homogeneous structure; however, this is not a requirement. MongoDB’s flexible schemas mean that schema migration and augmentation are very easy in practice, and you will rarely, if ever, need to write scripts that perform “alter table” type operations, which simplifies and facilitates iterative software development with MongoDB.

37. What is the method to configure the cache size in MongoDB?

MongoDB has no configurable cache. MongoDB uses all free memory on the system automatically by way of memory mapped files. Operating systems use the same approach with their file system caches.

38. Why 32 bit version of MongoDB are not preferred ? OR

What are the limitations of 32-bit versions of MongoDB?

MongoDB uses memory-mapped files. When running a 32-bit build of MongoDB, the total storage size for the server, including data and indexes, is 2 gigabytes. For this reason, do not deploy MongoDB to production on 32-bit machines.

If you’re running a 64-bit build of MongoDB, there’s virtually no limit to storage size. For production deployments, 64-bit builds and operating systems are strongly recommended.

Note: 32-bit builds disable journaling by default because journaling further limits the maximum amount of data that the database can store.

39. What kind of database is MongoDB?

MongoDB is a document-oriented DBMS. Think of MySQL but with JSON-like objects comprising the data model, rather than RDBMS tables. Significantly, MongoDB supports neither joins nor transactions. However, it features secondary indexes, an expressive query language, atomic writes on a per-document level, and fully-consistent reads.

Operationally, MongoDB features master-slave replication with automated failover and built-in horizontal scaling via automated range-based partitioning.

Note: MongoDB uses BSON, a binary object format similar to, but more expressive than JSON.

40. Does MongoDB support SQL?

No. However, MongoDB does support a rich, ad-hoc query language of its own.

41. What are typical uses for MongoDB? OR Where should use MongoDB?

MongoDB has a general-purpose design, making it appropriate for a large number of use cases. Examples : Big Data,  content management systems and Delivery, mobile applications, gaming, e-commerce, analytics, archiving, and logging, User Data Management.

Do not use MongoDB for systems that require SQL, joins, and multi-object transactions.

42. Does MongoDB support ACID transactions?

MongoDB does not support multi-document transactions. However, MongoDB does provide atomic operations on a single document. Often these document-level atomic operations are sufficient to solve problems that would require ACID transactions in a relational database.

For example, in MongoDB, you can embed related data in nested arrays or nested documents within a single document and update the entire document in a single atomic operation. Relational databases might represent the same kind of

data with multiple tables and rows, which would require transaction support to update the data atomically.

MongoDB allows clients to read documents inserted or modified before it commits these modifications to disk, regardless of write concern level or journaling configuration. As a result, applications may observe two classes of behaviors:

For systems with multiple concurrent readers and writers, MongoDB will allow clients to read the results of a write operation before the write operation returns.

• If the mongod terminates before the journal commits, even if a write returns successfully, queries may have read data that will not exist after the mongod restarts.

Other database systems refer to these isolation semantics as read uncommitted. For all inserts and updates, MongoDB modifies each document in isolation: clients never see documents in intermediate states. For multi-document operations, MongoDB does not provide any multi-document transactions or isolation.

When mongod returns a successful journaled write concern, the data is fully committed to disk and will be available after mongod restarts.

For replica sets, write operations are durable only after a write replicates and commits to the journal of a majority of the members of the set. MongoDB regularly commits data to the journal regardless of journaled write concern: use the commitIntervalMs to control how often a mongod commits the journal.

43. Does MongoDB require a separate caching layer for application-level

caching?

No. In MongoDB, a document’s representation in the database is similar to its representation in application memory.

This means the database already stores the usable form of data, making the data usable in both the persistent store and in the application cache. This eliminates the need for a separate caching layer in the application.

This differs from relational databases, where caching data is more expensive. Relational databases must transform data into object representations that applications can read and must store the transformed data in a separate cache: if

these transformation from data to application objects require joins, this process increases the overhead related to using the database which increases the importance of the caching layer.

44. Does MongoDB handle caching?

Yes. MongoDB keeps all of the most recently used data in RAM. If you have created indexes for your queries and your working data set fits in RAM, MongoDB serves all queries from memory.

MongoDB does not implement a query cache: MongoDB serves all queries directly from the indexes and/or data files.

45. Are writes written to disk immediately, or lazily?

Writes are physically written to the journal within 100 milliseconds, by default. At that point, the write is “durable” in the sense that after a pull-plug-from-wall event, the data will still be recoverable after a hard restart.

While the journal commit is nearly instant, MongoDB writes to the data files lazily. MongoDB may wait to write data to the data files for as much as one minute by default. This does not affect durability, as the journal has enough information to ensure crash recovery. To change the interval for writing to the data files, see syncPeriodSecs.

46. How do you copy all objects from one collection to another?

In the mongo shell, you can use the following operation to duplicate the entire collection: db.source.copyTo(newCollection)

Warning: When using db.collection.copyTo() check field types to ensure that the operation does not remove type information from documents during the translation from BSON to JSON. Consider using cloneCollection() to maintain type fidelity.

The db.collection.copyTo() method uses the eval command internally. As a result, the db.collection.copyTo() operation takes a global lock that blocks all other read and write operations until the db.collection.copyTo() completes.

Also consider the cloneCollection command that may provide some of this functionality.

47. If you remove a document, does MongoDB remove it from disk?

Yes. When you use remove(), the object will no longer exist in MongoDB’s on-disk data storage.

48. When does MongoDB write updates to disk?

MongoDB flushes writes to disk on a regular interval. In the default configuration, MongoDB writes data to the main data files on disk every 60 seconds and commits the journal roughly every 100 milliseconds. These values are configurable with the commitIntervalMs and syncPeriodSecs.

These values represent the maximum amount of time between the completion of a write operation and the point when the write is durable in the journal, if enabled, and when MongoDB flushes data to the disk. In many cases MongoDB and the operating system flush data to disk more frequently, so that the above values represents a theoretical maximum.

However, by default, MongoDB uses a “lazy” strategy to write to disk. This is advantageous in situations where the database receives a thousand increments to an object within one second, MongoDB only needs to flush this data to disk

once. In addition to the aforementioned configuration options, you can also use fsync and Write Concern to modify this strategy.

49. How do you aggregate data with MongoDB?

In version 2.1 and later, you can use the new aggregation framework, with the aggregate command.

MongoDB also supports map-reduce with the mapReduce command, as well as basic aggregation with the group, count, and distinct. commands.

50. Why does MongoDB log so many “Connection Accepted” events?

If you see a very large number connection and re-connection messages in your MongoDB log, then clients are frequently connecting and disconnecting to the MongoDB server. This is normal behavior for applications that do not use

request pooling, such as CGI. Consider using FastCGI, an Apache Module, or some other kind of persistent application server to decrease the connection overhead.

If these connections do not impact your performance you can use the run-time quiet option or the command-line option --quiet to suppress these messages from the log.

51. Does MongoDB run on Amazon EBS?

Yes. MongoDB users of all sizes have had a great deal of success using MongoDB on the EC2 platform using EBS disks.

52. How do I optimize storage use for small documents?

Each MongoDB document contains a certain amount of overhead. This overhead is normally insignificant but becomes significant if all documents are just a few bytes, as might be the case if the documents in your collection only have one or two fields.

Consider the following suggestions and strategies for optimizing storage utilization for these collections:

• Use the _id field explicitly.

MongoDB clients automatically add an _id field to each document and generate a unique 12-byte ObjectId for the _id field. Furthermore, MongoDB always indexes the _id field. For smaller documents this may account for a significant amount of space.

To optimize storage use, users can specify a value for the _id field explicitly when inserting documents into the collection. This strategy allows applications to store a value in the _id field that would have occupied space in another portion of the document.

You can store any value in the _id field, but because this value serves as a primary key for documents in the collection, it must uniquely identify them. If the field’s value is not unique, then it cannot serve as a primary keyas there would be collisions in the collection.

• Use shorter field names.

MongoDB stores all field names in every document. For most documents, this represents a small fraction of the space used by a document; however, for small documents the field names may represent a proportionally large amount of space. Consider a collection of documents that resemble the following:

{ last_name : "Smith", best_score: 3.9 }

If you shorten the field named last_name to lname and the field named best_score to score, as follows, you could save 9 bytes per document.

{ lname : "Smith", score : 3.9 }

Shortening field names reduces expressiveness and does not provide considerable benefit for larger documents and where document overhead is not of significant concern. Shorter field names do not reduce the size of indexes, because indexes have a predefined structure. In general it is not necessary to use short field names.

• Embed documents.

In some cases you may want to embed documents in other documents and save on the per-document overhead.

53. When should I use GridFS?

For documents in a MongoDB collection, you should always use GridFS for storing files larger than 16 MB.

In some situations, storing large files may be more efficient in a MongoDB database than on a system-level filesystem.

• If your filesystem limits the number of files in a directory, you can use GridFS to store as many files as needed.

• When you want to keep your files and metadata automatically synced and deployed across a number of systems and facilities. When using geographically distributed replica sets MongoDB can distribute files and their metadata automatically to a number of mongod instances and facilities.

• When you want to access information from portions of large files without having to load whole files into memory, you can use GridFS to recall sections of files without reading the entire file into memory.

Do not use GridFS if you need to update the content of the entire file atomically. As an alternative you can store multiple versions of each file and specify the current version of the file in the metadata. You can update the metadata field that indicates “latest” status in an atomic update after uploading the new version of the file, and later remove previous versions if needed.

Furthermore, if your files are all smaller the 16 MB BSON Document Size limit, consider storing the file manually within a single document. You may use the BinData data type to store the binary data.

54. How does MongoDB address SQL or Query injection?

BSON

As a client program assembles a query in MongoDB, it builds a BSON object, not a string. Thus traditional SQL injection attacks are not a problem. More details and some nuances are covered below.

MongoDB represents queries as BSON objects. Typically client libraries provide a convenient, injection free, process to build these objects. Consider the following C++ example:

BSONObj my_query = BSON( "name" << a_name );

auto_ptr<DBClientCursor> cursor = c.query("tutorial.persons", my_query);

Here, my_query then will have a value such as { name : "Joe" }.

 If my_query contained special characters,  for example ,, :, and {, the query simply wouldn’t match any documents. For example, users cannot hijack a

query and convert it to a delete.

JavaScript

Note: You can disable all server-side execution of JavaScript, by passing the --noscripting option on the command line or setting security.javascriptEnabled in a configuration file.

All of the following MongoDB operations permit you to run arbitrary JavaScript expressions directly on the server:

• $where

• db.eval()

• mapReduce

• group

You must exercise care in these cases to prevent users from submitting malicious JavaScript.

Fortunately, you can express most queries in MongoDB without JavaScript and for queries that require JavaScript, you can mix JavaScript and non-JavaScript in a single query. Place all the user-supplied fields directly in a BSON field and

pass JavaScript code to the $where field.

• If you need to pass user-supplied values in a $where clause, you may escape these values with the CodeWScope mechanism. When you set user-submitted values as variables in the scope document, you can avoid evaluating them on the database server.

• If you need to use db.eval() with user supplied values, you can either use a CodeWScope or you can supply extra arguments to your function. For instance:

db.eval(function(userVal){...}, user_value);

This will ensure that your application sends user_value to the database server as data rather than code.

Dollar Sign Operator Escaping

Field names in MongoDB’s query language have semantic meaning. The dollar sign (i.e $) is a reserved character used to represent operators (i.e. $inc.) Thus, you should ensure that your application’s users cannot inject operators into their inputs.

In some cases, you may wish to build a BSON object with a user-provided key. In these situations, keys will need to substitute the reserved $ and . characters. Any character is sufficient, but consider using the Unicode full width

equivalents: U+FF04 (i.e. “$”) and U+FF0E (i.e. “.”).

Consider the following example:

BSONObj my_object = BSON( a_key << a_name );

The user may have supplied a $ value in the a_key value. At the same time, my_object might be { $where : "things" }. Consider the following cases:

• Insert. Inserting this into the database does no harm. The insert process does not evaluate the object as a query.

Note: MongoDB client drivers, if properly implemented, check for reserved characters in keys on inserts.

• Update. The update() operation permits $ operators in the update argument but does not support the $where operator. Still, some users may be able to inject operators that can manipulate a single document only. Therefore your application should escape keys, as mentioned above, if reserved characters are possible.

• Query Generally this is not a problem for queries that resemble { x : user_obj }: dollar signs are not top level and have no effect. Theoretically it may be possible for the user to build a query themselves.

But checking the user-submitted content for $ characters in key names may help protect against this kind of injection.

55. How does MongoDB provide concurrency?

MongoDB implements a readers-writer lock. This means that at any one time, only one client may be writing or any number of clients may be reading, but that reading and writing cannot occur simultaneously.

In standalone and replica sets the lock’s scope applies to a single mongod instance or primary instance. In a sharded cluster, locks apply to each individual shard, not to the whole cluster.

56. What is the compare order for BSON types?

MongoDB permits documents within a single collection to have fields with different BSON types. For instance, the following documents may exist within a single collection.

{ x: "string" }

{ x: 42 }

When comparing values of different BSON types, MongoDB uses the following comparison order, from lowest to highest:

1. MinKey (internal type)

2. Null

3. Numbers (ints, longs, doubles)

4. Symbol, String

5. Object

6. Array

7. BinData

8. ObjectId

9. Boolean

10. Date, Timestamp

11. Regular Expression

12. MaxKey (internal type)

MongoDB treats some types as equivalent for comparison purposes. For instance, numeric types undergo conversion before comparison.

The comparison treats a non-existent field as it would an empty BSON Object. As such, a sort on the a field in documents { } and {a: null} would treat the documents as equivalent in sort order.

With arrays, a less-than comparison or an ascending sort compares the smallest element of arrays, and a greater-than comparison or a descending sort compares the largest element of the arrays. As such, when comparing a field whose

value is a single-element array (e.g. [ 1 ]) with non-array fields (e.g. 2), the comparison is between 1 and 2. A comparison of an empty array (e.g. [ ]) treats the empty array as less than null or a missing field.

MongoDB sorts BinData in the following order:

1. First, the length or size of the data.

2. Then, by the BSON one-byte subtype.

3. Finally, by the data, performing a byte-by-byte comparison.

Consider the following mongo example:

db.test.insert( {x : 3 } );

db.test.insert( {x : 2.9 } );

db.test.insert( {x : new Date() } );

db.test.insert( {x : true } );

db.test.find().sort({x:1});

{ "_id" : ObjectId("4b03155dce8de6586fb002c7"), "x" : 2.9 }

{ "_id" : ObjectId("4b03154cce8de6586fb002c6"), "x" : 3 }

{ "_id" : ObjectId("4b031566ce8de6586fb002c9"), "x" : true }

{ "_id" : ObjectId("4b031563ce8de6586fb002c8"), "x" : "Tue Nov 17 2009 16:28:03 GMT-0500 (EST)" }

The $type operator provides access to BSON type comparison in the MongoDB query syntax.

Warning: Storing values of the different types in the same field in a collection is strongly discouraged.

57. When multiplying values of mixed types, what type conversion rules apply?

The $mul multiplies the numeric value of a field by a number. For multiplication with values of mixed numeric types (32-bit integer, 64-bit integer, float), the following type conversion rules apply:

32-bit Integer 64-bit Integer Float

32-bit Integer 32-bit or 64-bit Integer 64-bit Integer Float

64-bit Integer 64-bit Integer 64-bit Integer Float

Float Float Float Float

Note:

• If the product of two 32-bit integers exceeds the maximum value for a 32-bit integer, the result is a 64-bit integer.

• Integer operations of any type that exceed the maximum value for a 64-bit integer produce an error.

58. How do I query for fields that have null values?

Different query operators treat null values differently:

• The { cancelDate : null } query matches documents that either contains the cancelDate field whose value is null or that do not contain the cancelDate field:

db.test.find( { cancelDate: null } )

The query returns both documents:

{ "_id" : 1, "cancelDate" : null }

{ "_id" : 2 }

• The { cancelDate : { $type: 10 } } query matches documents that contains the cancelDate field whose value is null only; i.e. the value of the cancelDate field is of BSON Type Null (i.e. 10) :

db.test.find( { cancelDate : { $type: 10 } } )

The query returns only the document that contains the null value:

{ "_id" : 1, "cancelDate" : null }

• The { cancelDate : { $exists: false } } query matches documents that do not contain the cancelDate field:

db.test.find( { cancelDate : Fields in a document may store null values, as in a notional collection, test, with the following documents:

{ _id: 1, cancelDate: null }

{ _id: 2 }

{ $exists: false } } )

The query returns only the document that does not contain the cancelDate field:

{ "_id" : 2 }

59. Are there any restrictions on the names of Collections?

Collection names can be any UTF-8 string with the following exceptions:

• A collection name should begin with a letter or an underscore.

• The empty string ("") is not a valid collection name.

• Collection names cannot contain the $ character. (version 2.2 only)

• Collection names cannot contain the null character: \0

• Do not name a collection using the system. prefix. MongoDB reserves system. for system collections, such as the system.indexes collection.

• The maximum size of a collection name is 128 characters, including the name of the database. However, for maximum flexibility, collections should have names less than 80 characters.

If your collection name includes special characters, such as the underscore character, then to access the collection use the db.getCollection() method or a similar method for your driver.

Example

To create a collection _foo and insert the { a : 1 } document, use the following operation:

db.getCollection("_foo").insert( { a : 1 } )

To perform a query, use the find() method, in as the following:

db.getCollection("_foo").find()

60. How do I isolate cursors from intervening write operations?

MongoDB cursors can return the same document more than once in some situations.

You can use the snapshot() method on a cursor to isolate the operation for a very specific case.

snapshot() traverses the index on the _id field and guarantees that the query will return each document (with respect to the value of the _id field) no more than once.

The snapshot() does not guarantee that the data returned by the query will reflect a single moment in time nor does it provide isolation from insert or delete operations.

Warning:

• You cannot use snapshot() with sharded collections.

• You cannot use snapshot() with sort() or hint() cursor methods.

As an alternative, if your collection has a field or fields that are never modified, you can use a unique index on this field or these fields to achieve a similar result as the snapshot(). Query with hint() to explicitly force the query to use that index.