0

I have a question, wondering if there is any way to persist the returned document when using the Mongoose .populate() function by saving it back to the model. Also some questions on how to structure things. Here are my schemas: 

var clientSchema = new Schema({
    phone: String,
    email: String
    },
);

var menuSchema = new Schema({
    itemName: String,
    itemPrice: Number,
});


var transactionSchema = new Schema ({
    createdBy: { type: Schema.ObjectId, ref: 'Client'},
    items: [{ type: Schema.ObjectId, ref: 'Menu' }],
});

var Menu = mongoose.model('Menu', menuSchema);
var Client = mongoose.model('Client', clientSchema);
var Transaction = mongoose.model('Transaction', transactionSchema);

When I create a new Transaction with a POST request, I populate it and return the populated Transaction as a response:

{
    "_id": "5a0bde94f4434c0a604341d2",
    "createdBy": {
        "_id": "5a0a8a3f9c348f0998ba8c2c",
        "phone": "1234567890",
        "email": "some@thing.com"
    },
    "__v": 0,
    "items": [{ Many Menu objects }]
}

However, when I query the DB again with GET, I get this:

{
    "_id": "5a0bde94f4434c0a604341d2",
    "createdBy": "5a0a8a3f9c348f0998ba8c2c",
    "__v": 0,
    "items": [Array of ObjectIds]
}

I can't use .save() because the original schema only accepts ObjectId, not an entire Object.

I noticed that when I made my schema include SubDocuments, I did not really need to use the .populate() function. I simply pushed an object into the array, and it would be there when queried. 

var transactionSchema = new Schema ({
    createdBy: { type: Schema.ObjectId, ref: 'Client'},
    items: [menuSchema], // Sub Doc
});

MongoDB Docs say creating large mutable arrays is a bad design. I could see some transactions having 50 or 100 objects. I can see this being more of a problem if I use subDocuments because file size , but I could also imagine that doing a .populate() on an array of 100 object IDs may be expensive.

I need to update the items array in the transaction schema every time the client registers an onclick function. I need to re-render that to the client, which involves a single PUT request per click. But I have to parse that array with each click, one by one. If I'm doing a .populate() on every single item in the array...that's not great. But using subDocuments would increase the filesize of the database.

I previously had a simpler schema, but thought that passing by reference would increase the integrity of the prices being rendered. Is it better to just have an array of Objects and push into that?

var transactionSchema = new Schema ({
    createdBy: { type: Schema.ObjectId, ref: 'Client'},
    items: [{
      name: {type: String},
      price: {type: Number}
    }]
});
Mikhail
  • 870
  • 1
  • 10
  • 23
  • Long question. What are you asking? Is the eventual point that you are trying to change your data back to "embedded" but don't know how? Or are you simply asking us "which one is best?" – Neil Lunn Nov 15 '17 at 07:16
  • @NeilLunn Which one is best? Ref or Subdocs? Is it going to make things slow to have to `.populate()` large arrays? Is it going to make the file size too large to have arrays of hundreds of subdocuments? Including a reference to the item being pushed seems to be more secure than a completely unrelated array of Price and item name fields. Originally was unsure of why I have to repopulate with every query. Want to store item _ids, populate them once, have them persist as embedded item objects if I want to query transactions for a price of an item – Mikhail Nov 15 '17 at 07:21
  • There is no such thing as "which is best", which is what the existing answers tell you. It's only about what your application actually needs to do and how you use the data. The cases for that are already discussed in those answers. So I just wanted to clear up what you were really asking so you could be pointed at the existing wisdom on the topic. If you want "all the data together" which is "most of the time", then the strong lean here is towards embedding. But read what the existing pros and cons discuss. – Neil Lunn Nov 15 '17 at 07:31
  • The "duplicate" links do not anser the question. This is about SAVING which is not covered in the "embed or reference" questions. – Emmanuel Apr 23 '19 at 01:23

0 Answers0