Unit 4 - Practice Quiz

MongoDB is a document-oriented database, which means it stores data in flexible, JSON-like documents called BSON.

A collection in MongoDB is a grouping of MongoDB documents, which is conceptually similar to a table in a relational database system.

A document is the basic unit of data in MongoDB. It is a data structure composed of field and value pairs, similar to a JSON object.

mongosh (the MongoDB Shell) is the modern, feature-rich command-line tool used to interact with MongoDB deployments.

The use command selects the specified database. If the database does not exist, MongoDB creates it when you first store data in that database.

The insertOne() method is the standard command for inserting a single document into a specified collection.

The find() method is used to query a collection for documents. Passing an empty document {} as the query filter matches all documents in the collection.

Mongoose provides a straightforward, schema-based solution to model your application data, manage relationships, and provide type casting and validation for MongoDB.

A Mongoose schema defines the shape of the documents, default values, validators, and other properties for a specific collection.

Models are constructors compiled from Schema definitions. An instance of a model represents a MongoDB document and can be saved, updated, or deleted.

CRUD stands for Create, Read, Update, and Delete, which are the four basic functions of persistent storage.

BSON stands for Binary JSON. It is a binary-encoded serialization of JSON-like documents that MongoDB uses for storing data.

The db.collectionName.drop() method is used to remove a collection completely from the database, including any indexes associated with it.

The db.dropDatabase() command drops the entire current database, deleting all its collections and indexes.

updateOne() is the specific method for updating a single document that matches the specified filter criteria.

The deleteOne() method takes a filter document as its first argument and deletes the first document it finds that matches the filter.

The mongoose.model('ModelName', mySchema) function is the correct way to create a Mongoose model from a previously defined schema.

The .limit(number) method is chained to a find() query to restrict the number of documents returned, which is essential for setting a page size in pagination.

The .skip(number) method controls the starting point of the results set, allowing you to bypass a certain number of documents, which is a core component of pagination logic.

MongoDB's dynamic and flexible schema means that you do not need to define the structure of documents beforehand, and documents within the same collection can vary, which is great for evolving applications.

MongoDB practices 'lazy creation' for databases. The use <dbname> command switches the current database context in the shell. The database itself is only created on the file system when you first store data in it, for example, by inserting a document into a collection.

Without an update operator like set operator correctly modifies existing fields and adds new ones without affecting other fields in the document.

The correct syntax uses a query document where conditions are implicitly joined by AND. The second argument, called a projection, specifies which fields to include (1 for include, 0 for exclude). _id is included by default, so it must be explicitly excluded with _id: 0 if not desired.

In Mongoose, schema fields are defined with a type. To add constraints like required and unique, you must use an object for the field definition where the type and constraints are specified as properties. unique: true creates a unique index on that field in the MongoDB collection.

By default, findByIdAndUpdate and findOneAndUpdate return the document as it was before the update was applied. Setting the { new: true } option configures the method to return the modified document instead.

To get the Nth page, you need to skip (N-1) * itemsPerPage documents. In this case, for the 5th page with 20 items per page, the number of documents to skip is (5 - 1) * 20 = 80. The .limit(20) method then retrieves the next 20 documents.

The push would add the tag regardless of whether it's already present.

Mongoose follows a convention of taking the singular model name you provide (e.g., 'User'), making it lowercase, and pluralizing it to determine the collection name. Therefore, the 'User' model will map to the 'users' collection.

The { ordered: false } option tells MongoDB to continue trying to insert the remaining documents in the batch even if one fails. The default behavior (ordered: true) is to stop the entire operation upon the first error.

In Mongoose, Model.findById(id) is essentially a convenient shorthand for Model.findOne({ _id: id }). They both perform the same underlying query and return the same result. The choice between them is a matter of code readability and convenience.

The core terminology mapping from relational databases to MongoDB is: Database -> Database, Table -> Collection, and Row/Record -> Document. Each document is a BSON (Binary JSON) object that holds the data for a single entity.

As its name implies, deleteOne is designed to delete only a single document. Even if the query filter matches multiple documents, it will only delete the first one it encounters. To delete all matching documents, you would use deleteMany.

Mongoose's enum validator is used for this purpose. It is defined as a property within the field's definition object and takes an array of allowed string values. Any attempt to save a document with a value for this field that is not in the array will result in a validation error.

The upsert option (a blend of 'update' and 'insert') instructs MongoDB to perform an update if a document matching the query filter is found, or to insert a new document if no matching document is found. The new document will be a combination of the query filter and the update operation.

The native driver provides a direct, low-level connection to MongoDB. Mongoose is a layer on top of the driver that provides a powerful schema-based modeling environment. This helps enforce data structure, validate data before it's saved, and provides middleware (hooks) for business logic, significantly improving development workflow and data integrity.

The drop() command on a collection is a destructive operation that completely removes the collection, all documents within it, and any associated indexes. The db.getCollection() syntax is a safe way to reference collection names that might be invalid as JavaScript properties (e.g., names with hyphens).

Comment.countDocuments() is the modern and recommended Mongoose method for counting documents that match a query. While find().length works, it is inefficient because it retrieves all matching documents from the database into memory just to count them. countDocuments performs the count on the database server itself, which is much more efficient. count() is deprecated.

While running two separate queries is a common and valid approach, using the $facet aggregation stage is often more efficient. It allows you to process multiple aggregation pipelines within a single stage on the same set of input documents. This lets you get the total count and the paginated subset of data with a single round trip to the database, which can be more performant.

A core feature of MongoDB is its flexible schema model. Unlike relational databases, collections do not enforce a rigid document structure by default. This allows for evolving application requirements without complex database migrations. While you can enforce a schema at the application level (using Mongoose) or at the database level (using JSON Schema validation), the default behavior is schema-less.

To query a date range, you should use the comparison operators lt (less than). This query correctly selects all documents where eventDate is on or after the first moment of 2023-01-01 and strictly before the first moment of 2024-01-01, effectively capturing all events within the year 2023.

The updateMany command targets all documents where profile.tags contains 'B', which includes Alice's document. The update operator has two parts:

1. $inc: { 'profile.score': 5 } increments the score from 10 to 15.
2. $addToSet: { 'profile.tags': 'D' } adds 'D' to the tags array only if it doesn't already exist. Since 'D' is not present, the array becomes ["A", "B", "D"].
   Both operations are applied atomically to the document.

This query demonstrates the interaction between the positional projection operator.

1. The gt: 0 }).
2. The variants.$ in the projection operator then returns only the first element of the variants array that matched the query condition. In this case, it's the { color: 'red', stock: 10 } element.

The ordered: false option tells MongoDB to attempt to insert all documents in the array, even if one or more of them fail. The server will not stop processing the batch on the first error. In this case, it will successfully insert { _id: 1, val: 'A' } and { _id: 2, val: 'B' }. When it attempts to insert { _id: 1, val: 'C' }, it will fail with a duplicate key error. The operation result will contain information about the successful inserts and the write error.

The execution flow is as follows:

1. A new User is created with level: 5 and xp: 550.
2. user.save() is called, which triggers the pre('save') middleware.
3. Inside the middleware, this.xp >= this.level * 100 (550 >= 500) is true.
4. this.level is incremented to 6.
5. this.xp is recalculated: 550 - (6 - 1) * 100 which is 550 - 500 = 50.
6. The middleware calls next(), and the document { name: 'Zelda', level: 6, xp: 50 } is saved to the database.
7. The rank virtual is accessed. It checks the current level, which is 6. Since 6 < 10, it returns 'Rookie'.

This question tests the interaction of several findOneAndUpdate options:

1. upsert: true: Since no document matches { name: 'Gadget' }, MongoDB will create a new one.
2. Document Creation: During an upsert, the new document is created by applying the update operation ($inc: { stock: 1 }) to a document based on the query filter ({ name: 'Gadget' }). This results in a new document { name: 'Gadget', stock: 1 } being inserted.
3. new: false: This option specifies that the function should return the document as it was before the update. Since the document did not exist before, the return value (result) is null.

Using a simple $lt on both fields is incorrect. The correct logic requires handling two cases:

1. Documents with a createdAt timestamp that is strictly less (older) than the last one seen.
2. Documents that have the exact same createdAt timestamp as the last one, in which case we use the unique _id field as a tie-breaker to find the next ones in the sequence.
   The $or operator correctly combines these two conditions, ensuring no documents are skipped or repeated, thus providing stable and correct pagination even with duplicate sort key values.

Capped collections are a special type of collection with a fixed maximum size and, optionally, a maximum number of documents. Once a collection is full, the oldest documents are overwritten by new ones, behaving like a circular buffer. They preserve insertion order, which makes them highly performant for writes and for reading the most recently inserted items (e.g., tailable cursors). This makes them perfect for high-throughput logging, caching, or storing real-time event data where only the most recent information is relevant.

This question tests the fundamental difference between static and instance methods in Mongoose.

• Static methods (defined on schema.statics) are called on the Model itself (e.g., User). User.findByName('Alice') is the correct way to use it.
• Instance methods (defined on schema.methods) are called on a document instance (e.g., alice). alice.hasName('Alice') is the correct way to use it, where this inside the method refers to the alice document.
  Therefore, both of the specified calls are syntactically correct and follow the intended design pattern.

A critical concept in Mongoose is that query middleware for operations like updateOne, updateMany, and findOneAndUpdate does not run schema validators by default. These commands are passed directly to the MongoDB driver. To enable validation, you must explicitly add the runValidators: true option to the query. Since it is absent here, the operation succeeds, and the data that violates the schema rule (maxlength: 8) is inserted into the database.

The ESR (Equality, Sort, Range) rule is a guideline for ordering fields in a compound index. The optimal order is:

1. Equality: Fields on which you perform an exact match (status: "active").
2. Sort: Fields on which you sort the results (lastLogin: -1).
3. Range: Fields on which you perform range queries (lt).
   Following this rule, the index { "status": 1, "lastLogin": -1 } is optimal because MongoDB can first quickly filter the documents by the status field and then traverse the index in the pre-sorted order of lastLogin to get the results, avoiding an expensive in-memory sort.

MongoDB creates databases lazily. The use newDB command only switches the shell's internal db context pointer. The database itself, along with its physical files, is not created until the first write operation occurs. A createCollection command is considered a write operation. Therefore, the files are created at that point. The subsequent db.dropDatabase() command, which operates on the current db context (newDB), then successfully removes the newly created database and its files.

MongoDB guarantees atomicity for all write operations that affect a single document. Even if the operation includes multiple update operators modifying different fields (like push here), MongoDB ensures that either all modifications are applied to the document, or none are. This single-document atomicity is a core feature and does not require an explicit multi-document transaction.

One of the key features of Mongoose is its built-in type casting. When you provide data to create or update a document, Mongoose attempts to cast the values to match the types defined in the schema. In this case, the string '19.99' can be successfully parsed and converted into a Number. This cast happens before validation and saving, so the document is stored in the database with price as a numeric type.

Mongoose's populate method is powerful enough to handle this scenario. To populate a path that is nested inside an array of subdocuments, you use dot notation for the path string. The path 'items.productId' tells Mongoose to go into the items array and, for each object in the array, populate the productId field. You can chain multiple populate calls or pass an array of population options to populate multiple paths like user and items.productId in the same query.

A "majority" in a replica set refers to a majority of the voting members. In a standard 3-node replica set, all nodes are voting members, so a majority is ceil(3 / 2) = 2. Since the Primary and one Secondary are still up and can communicate, a majority of 2 is available. The write operation will be sent to the Primary, replicated to the available Secondary, and once both have acknowledged the write to their respective oplogs, the w: "majority" condition is met, and a success response is returned to the client.

The main downside of automatic population is its indiscriminate nature. While convenient, it means that every single find, findOne, etc., query on the Post model will trigger a second query to the User collection to perform the population. In many cases (e.g., fetching a list of post titles for a sitemap), the populated user data is unnecessary. This leads to redundant database load and increased latency, a classic performance pitfall of implicit, 'magic' behavior.

When a query in a sharded environment does not include the shard key, the mongos router cannot determine which shard(s) hold the relevant data. As a result, it must broadcast the query to all shards. This is known as a scatter-gather query. For a deleteMany operation, this means every shard must execute the query, which can lead to high CPU, I/O, and network load across the entire cluster, significantly impacting overall performance, especially if the operation is frequent or targets many documents.

GridFS is the official, built-in solution for this exact problem. It provides a driver-level API that abstracts the process of splitting a large file into smaller chunks (typically 255KB each) and storing them as individual documents in a chunks collection. A separate metadata document is stored in a files collection, containing information like the filename, content type, and the sequence of chunk IDs. This approach overcomes the 16MB document limit and is well-integrated into the MongoDB ecosystem for managing large files.

The majority read concern provides a crucial consistency guarantee. It ensures that the data being read has been written to the oplogs of a majority of the replica set's voting nodes. This means the data is durable and will not be rolled back in the event of a primary failover. Reading with local or available can be faster but risks reading data that might be rolled back if the primary fails before the data is replicated to a majority.

This distinction is critical for database management. deleteMany({}) is a data manipulation (DML) operation that iterates through and removes every document, which can be slow and resource-intensive for large collections. It leaves the collection's structure, including all its indexes, in place. In contrast, db.collection.drop() is a metadata (DDL) operation. It is extremely fast because it removes the entire collection namespace and all associated index files at a low level, rather than deleting documents one by one.