Mongoose: Inconsistency in .find() and default values

Created on 28 Nov 2018  路  2Comments  路  Source: Automattic/mongoose

Do you want to request a feature or report a bug?

Possible bug or unexpected behaviour

What is the current behavior?

.find() overwrites fields that are undefined but have a default value with that exact value, making it inconsistent and not possible to see if such that value is set in the database or not.
See #7269 for reference.

If the current behavior is a bug, please provide the steps to reproduce.

const mongoose = require("mongoose")
const { Schema } = mongoose;
const PersonSchema = new Schema({
  name: String,
  age: { type: Number, default: 0 }
})
const Person = mongoose.model("Person", PersonSchema)
mongoose.connect('mongodb://localhost:27017/test');

async function runTest() {
  // creating document with manual set value for "age"
  await Person.create({ name: "martin", age: 30 });

  // get document
  let entry = await Person.findOne();
  console.log(entry); // entry.age == 30

  // deleting the key "age"
  await Person.collection.update({ _id: entry._id }, { $unset: { age: 1 }});
  // attribute "age" is now not existing on that document in the database-storage

  let newResult = await Person.findOne();
  console.log(newResult); // attribute "age" is now existing again on the runtime object and has the default value of 0
}
runTest();

What is the expected behavior?
The default value of an attribute should be used on creation or maybe even on update
(https://mongoosejs.com/docs/defaults.html#the-setdefaultsoninsert-option) but NOT on pure reading a document from the database.

Please mention your node.js, mongoose and MongoDB version.
node v8.11.3, mongoose 5.3.13, mongoDB latest version

discussion

Most helpful comment

@vkarpov15 i kinda agree that it's more writing when you need to null-check attributes and can't rely on it beeing an empty string or so.
But the thing that made me create this issue is the pure fact, that "reading" a mongoose-document should, if no custom hooks are modifying it, return the object "as it is" from the database. The intent on pulling some document from the database is to know the values that are stored in the database. If there is an attribute that is undefined there will always be a reason why that value is saved as undefined into the database. In my opinion one should start rethinking there and not letting the database set "some value the nest time the data is pulled from the db".
Scenario:

  • A field "user" gets a default of the user who is logged into the GUI and creating the document.
  • at some point old data need to be imported manualle into the DB directoy to mongoDB, skipping mongoose. All fields are valid in mongoose but the "user" field is undefined because at the time these entried were created first, there was no username as default.
  • You now cann tell, that if the value of username is undefined then it was imported and not created the normal way.
    But if you now find a document and the correct undefined gets replaced by the currently logged in user, then the document incorrectly states, that user xyz has created that document, which is simply not true.
    I am not saying that this behaviour MUST not be used, but i too would like to discuss this and maybe we can work out some option/setting for that behaviour like setting forceDefault: true/false or forceDefaultOnEmpty: true/false in the schema :)

All 2 comments

This is something worth discussing more. Currently, this is by design. The spirit of this behavior is to apply defaults where possible, because setDefaultsOnInsert isn't always on. This way, you can use defaults to avoid an extra != null check if you want to use String#startsWith() or similar.

You can always use Document#$isDefault() to check whether age is set to the default value or not.

@vkarpov15 i kinda agree that it's more writing when you need to null-check attributes and can't rely on it beeing an empty string or so.
But the thing that made me create this issue is the pure fact, that "reading" a mongoose-document should, if no custom hooks are modifying it, return the object "as it is" from the database. The intent on pulling some document from the database is to know the values that are stored in the database. If there is an attribute that is undefined there will always be a reason why that value is saved as undefined into the database. In my opinion one should start rethinking there and not letting the database set "some value the nest time the data is pulled from the db".
Scenario:

  • A field "user" gets a default of the user who is logged into the GUI and creating the document.
  • at some point old data need to be imported manualle into the DB directoy to mongoDB, skipping mongoose. All fields are valid in mongoose but the "user" field is undefined because at the time these entried were created first, there was no username as default.
  • You now cann tell, that if the value of username is undefined then it was imported and not created the normal way.
    But if you now find a document and the correct undefined gets replaced by the currently logged in user, then the document incorrectly states, that user xyz has created that document, which is simply not true.
    I am not saying that this behaviour MUST not be used, but i too would like to discuss this and maybe we can work out some option/setting for that behaviour like setting forceDefault: true/false or forceDefaultOnEmpty: true/false in the schema :)
Was this page helpful?
0 / 5 - 0 ratings