Custom role creation in MongoDB - Time & Space Complexity

Time Complexity: Custom role creation

O(n)

Understanding Time Complexity

When creating custom roles in MongoDB, it's important to understand how the time to create or update roles changes as the number of privileges grows.

We want to know how the work increases when we add more actions or resources to a role.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

db.createRole({
  role: "customRole",
  privileges: [
    { resource: { db: "test", collection: "users" }, actions: ["find", "update"] },
    { resource: { db: "test", collection: "orders" }, actions: ["insert"] }
  ],
  roles: []
})

This code creates a custom role with a list of privileges, each specifying resources and allowed actions.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Iterating over the privileges array to process each privilege.
• How many times: Once for each privilege in the list.

How Execution Grows With Input

Explain the growth pattern intuitively.

Input Size (n privileges)	Approx. Operations
10	10 operations (one per privilege)
100	100 operations
1000	1000 operations

Pattern observation: The work grows directly with the number of privileges; doubling privileges doubles the work.

Final Time Complexity

Time Complexity: O(n)

This means the time to create a custom role grows linearly with the number of privileges you add.

Common Mistake

[X] Wrong: "Adding more privileges won't affect the creation time much because it's just one command."

[OK] Correct: Each privilege must be processed, so more privileges mean more work and longer creation time.

Interview Connect

Understanding how the number of privileges affects role creation time shows you can think about how database commands scale with input size, a useful skill in real projects.

Self-Check

"What if we added nested roles inside the custom role? How would that change the time complexity?"

Practice

1. What is the main purpose of creating a custom role in MongoDB?

easy

A. To speed up database queries

B. To assign specific permissions tailored to user needs

C. To backup the database automatically

D. To create new collections in the database

Solution

1. Step 1: Understand role purpose

   Custom roles are designed to control what actions a user can perform.

2. Step 2: Match purpose to options

   Only To assign specific permissions tailored to user needs describes assigning specific permissions tailored to user needs.

3. Final Answer:

   To assign specific permissions tailored to user needs -> Option B

4. Quick Check:

   Custom role purpose = Assign specific permissions [OK]

Hint: Custom roles control user permissions precisely [OK]

Common Mistakes:

• Confusing roles with database backups
• Thinking roles speed up queries
• Assuming roles create collections

2. Which of the following is the correct syntax to create a custom role named readWriteReports with read and write privileges on the reports database?

easy

A. db.createRole({role: "readWriteReports", privileges: [{resource: {db: "reports"}, actions: ["readWrite"]}], roles: []})

B. db.createRole({role: "readWriteReports", privileges: [{resource: {db: "reports", collection: ""}, actions: ["find", "insert", "update"]}], roles: []})

C. db.createRole({name: "readWriteReports", privileges: [{resource: {db: "reports", collection: ""}, actions: ["find", "insert", "update"]}], roles: []})

D. db.createRole({name: "readWriteReports", privileges: [{resource: {db: "reports"}, actions: ["readWrite"]}], roles: []})

Solution

1. Step 1: Check correct field names

   The field for role name is name, not role.

2. Step 2: Verify privileges structure

   Privileges must specify resource with db and collection, and actions as an array of strings.

3. Final Answer:

   db.createRole({name: "readWriteReports", privileges: [{resource: {db: "reports", collection: ""}, actions: ["find", "insert", "update"]}], roles: []}) -> Option C

4. Quick Check:

   Use 'name' for role name and specify privileges correctly [OK]

Hint: Use 'name' key for role name in createRole [OK]

Common Mistakes:

• Using 'role' instead of 'name' for role name
• Omitting collection field in resource
• Using 'readWrite' as action instead of specific actions

3. Given the following command, what will be the effect of the custom role limitedUser?

db.createRole({
  name: "limitedUser",
  privileges: [
    { resource: { db: "sales", collection: "orders" }, actions: ["find"] }
  ],
  roles: []
})

medium

A. User has no permissions on sales.orders collection

B. User can read and write on sales.orders collection

C. User can perform any action on sales database

D. User can only read documents from sales.orders collection

Solution

1. Step 1: Analyze privileges actions

   The action specified is only "find", which means read access.

2. Step 2: Understand resource scope

   The resource is the "orders" collection in the "sales" database, so permissions apply only there.

3. Final Answer:

   User can only read documents from sales.orders collection -> Option D

4. Quick Check:

   Action 'find' = read only on specified collection [OK]

Hint: Action 'find' means read-only permission [OK]

Common Mistakes:

• Assuming 'find' allows write operations
• Thinking permissions apply to whole database
• Confusing empty roles array as full access

4. Identify the error in this custom role creation command:

db.createRole({
  name: "dataEditor",
  privileges: [
    { resource: { db: "analytics", collection: "reports" }, actions: "update" }
  ],
  roles: []
})

medium

A. The 'actions' field should be an array, not a string

B. The 'resource' field is missing the database name

C. The 'name' field should be 'role'

D. The 'roles' array cannot be empty

Solution

1. Step 1: Check 'actions' field type

   The 'actions' field must be an array of strings, but here it is a single string "update".

2. Step 2: Verify other fields

   The 'resource' includes both db and collection correctly; 'name' is correct; 'roles' can be empty.

3. Final Answer:

   The 'actions' field should be an array, not a string -> Option A

4. Quick Check:

   'actions' must be an array [OK]

Hint: Always use array for 'actions' even if one action [OK]

Common Mistakes:

• Using string instead of array for 'actions'
• Confusing 'name' with 'role' field
• Thinking 'roles' array cannot be empty

5. You want to create a custom role reportManager that allows users to read all collections in the reports database and also run the aggregate action on the summary collection only. Which of the following commands correctly implements this?

hard

A. db.createRole({name: "reportManager", privileges: [{resource: {db: "reports", collection: ""}, actions: ["find"]}, {resource: {db: "reports", collection: "summary"}, actions: ["aggregate"]}], roles: []})

B. db.createRole({name: "reportManager", privileges: [{resource: {db: "reports"}, actions: ["find"]}, {resource: {db: "reports", collection: "summary"}, actions: ["aggregate"]}], roles: []})

C. db.createRole({name: "reportManager", privileges: [{resource: {db: "reports", collection: "summary"}, actions: ["find", "aggregate"]}], roles: []})

D. db.createRole({name: "reportManager", privileges: [{resource: {db: "reports", collection: ""}, actions: ["find", "aggregate"]}], roles: []})

Solution

1. Step 1: Understand the requirements

   Users must have read (find) access on all collections in 'reports' and aggregate only on 'summary' collection.

2. Step 2: Check privileges for all collections

   Using collection: "" means all collections in the database, so first privilege grants find on all collections.

3. Step 3: Check aggregate privilege on summary

   Second privilege grants aggregate only on 'summary' collection.

4. Final Answer:

   db.createRole({name: "reportManager", privileges: [{resource: {db: "reports", collection: ""}, actions: ["find"]}, {resource: {db: "reports", collection: "summary"}, actions: ["aggregate"]}], roles: []}) -> Option A

5. Quick Check:

   Separate privileges for all collections and specific collection actions [OK]

Hint: Use empty string for all collections, specify collection for specific actions [OK]

Common Mistakes:

• Using db only without collection for find
• Combining find and aggregate on all collections
• Missing separate privilege for aggregate on summary