Background:
Currently, code uses .save() to persist new UserRole documents. However, UserRoleModel.create(...) both creates and saves in one step, returning a promise that resolves to the saved document. Using create() is more concise and avoids redundancy (creating document + explicit save).
Goal:
Refactor code to use UserRoleModel.create() instead of:
const ur = new UserRoleModel({...});
await ur.save();Directly return the result of UserRoleModel.create() instead.
Tasks
-
Find all .save() usages:
- Search across the
user-service repo for .save() invocations related to UserRoleModel.
- Identify cases where
.save() is used after new UserRoleModel(...) or otherwise where create() could replace the pattern.
-
Replace with .create():
-
For simple one-liner document creation, refactor to:
const userRole = await UserRoleModel.create({ /* fields */ });
return userRole;
-
Remove redundant new UserRoleModel(...) + .save() patterns.
-
⚠️ Considerations (when not to replace):
-
If extra logic is applied to the document before saving:
const userRole = new UserRoleModel(data);
userRole.token = generateToken();
await userRole.save();
→ keep .save() in such cases.
-
If you rely on special middleware or hooks that behave differently between .create() and .save(), verify carefully before replacing.
-
Test and ensure behavior is unchanged:
- Run unit/integration tests covering
UserRole creation to make sure no regressions.
- Validate that required hooks/middleware still trigger as expected.
-
Code review & consistency:
- Ensure style is consistent (error handling,
await usage, promise returns).
- Update comments/documentation if any reference
.save().
Acceptance Criteria
- All safe instances of
.save() (where only saving a new UserRoleModel document) are replaced with UserRoleModel.create(...).
.save() remains in cases where additional field manipulation or middleware dependency requires it.- All tests pass with no regressions.
- Code review feedback incorporated.
Background:
Currently, code uses
.save()to persist newUserRoledocuments. However,UserRoleModel.create(...)both creates and saves in one step, returning a promise that resolves to the saved document. Usingcreate()is more concise and avoids redundancy (creating document + explicit save).Goal:
Refactor code to use
UserRoleModel.create()instead of:Directly return the result of
UserRoleModel.create()instead.Tasks
Find all
.save()usages:user-servicerepo for.save()invocations related toUserRoleModel..save()is used afternew UserRoleModel(...)or otherwise wherecreate()could replace the pattern.Replace with
.create():For simple one-liner document creation, refactor to:
Remove redundant
new UserRoleModel(...)+.save()patterns.If extra logic is applied to the document before saving:
→ keep
.save()in such cases.If you rely on special middleware or hooks that behave differently between
.create()and.save(), verify carefully before replacing.Test and ensure behavior is unchanged:
UserRolecreation to make sure no regressions.Code review & consistency:
awaitusage, promise returns)..save().Acceptance Criteria
.save()(where only saving a newUserRoleModeldocument) are replaced withUserRoleModel.create(...)..save()remains in cases where additional field manipulation or middleware dependency requires it.