After completing a course on MEAN Stack, I'm working on making my own webapp - a recipe page. I've designed my models, but when I try to fill the database with a new Recipe it just won't work. The main issue is the way I want to store ingredients, they'll be stored on one of the tables, then each recipe has its list of ingredients and amounts for each. For example, to make some toast you need, say "50 grs. of Butter and 4 slices of Bread". This is the Schema I'm using:
var RecipeSchema = Schema({
name: String,
desc: String,
author: { type: Schema.ObjectId, ref: 'User' },
category: { type: Schema.ObjectId, ref: 'Category' },
ingredients: [{ amount: String, ingredient: { type: Schema.ObjectId, ref: 'Ingredient' }}],
steps: [String],
image: String,
thumbnail: String,
portions: Number,
difficulty: Number,
cookingTime: Number,
comment: String
});
When I go in Postman and try to fill the "Toast Recipe" entry, I have the following:
name:Toast
desc:Toast is a common breakfast staple.
author:5cad791a7b2e651f7803f5de
category:5cb1ff8f484a172984178a97
ingredients:[{"amount": "4 slices", "ingredient": "5cb1ffdb484a172984178a98"}, {"amount": "35 grs.", "ingredient": "5cb2000d484a172984178a99"}]
steps:['Toast the bread in the oven.','Spread some butter on each toast.']
image:'null'
thumbnail:'null'
portions:1
difficulty:1
cookingTime:15
comment:'null'
But I keep getting a "cast Array" error. What could be the issue? Is it a problem with my model, with Postman, or with the way I'm sending the Array?
EDIT:
Apparently it was a problem whit the way I posted my arrays in Postman. After some more tests I managed to upload a full recipe in JSON format. The structure is correct (but what Juan suggests can be used too, to make the code cleaner).
I'am not completely sure, but when I worked with mongoose, inner objects had a new Schema object inside, in this case it would on ingredients
const IngredientSchema = new Schema({
amount: String,
ingredient: { type: Schema.ObjectId, ref:'Ingredient' }
});
const RecipeSchema = new Schema({
name: String,
desc: String,
author: { type: Schema.ObjectId, ref: 'User' },
category: { type: Schema.ObjectId, ref: 'Category' },
ingredients: [ IngredientSchema ],
steps: [String],
image: String,
thumbnail: String,
portions: Number,
difficulty: Number,
cookingTime: Number,
comment: String
});
Related
I want to do a category table that have a parent category by referencing the ObjectId from the same table.
Is it a normal practice or bad practice to refer ObjectId from the same table? If this is wrong, how do I go about it?
const CategorySchema = new Schema({
title: String,
description: String,
thumbnail: String,
image: String,
parentCategory: {
type: Schema.Types.ObjectId,
ref: 'category',
},
})
module.exports = mongoose.model('category', CategorySchema)
I'm relatively new to MongoDB and I'm wondering what the "best" solution would be for handling the following type of data in my database.
Collections:
Users
Lessons
Overview:
Note: Think of the implementation to be similiar to Duolingo or some other learning site.
Users have all the standard generic user information but they also need to track how many points, words learned, percentage complete, and so on, that they have for each given lesson they've started.
Lessons have data like: words learned, total points, words to review, etc.
Picture
Example of what a user would see in the widget when they view a lesson they've already started...
So what's a good way to handle this? I feel that I will need at a minimum a collection for users and lessons, but where would I store that user specific data relating to lessons they've taken?
What I've thought of so far ...
// user collection
const UserSchema = new mongoose.Schema({
email: { type: String, required: true, unique: true },
username: { type: String, required: true, unique: true },
password: { type: String, required: true },
firstName: { type: String },
lastName: { type: String },
gender: { type: String, enum: ['male', 'female', 'other'] },
admin: Boolean,
address: {
street: String,
city: String,
state: {
type: String,
uppercase: true,
required: true,
enum: statesArray,
},
zip: Number,
},
});
// lesson_results collection
const LessonResultsSchema = new mongoose.Schema({
user_id: Schema.Types.ObjectId,
results: [
{
id: Number,
lesson_id: Schema.Types.ObjectId,
pointsEarned: Number,
wordsLearned: Number,
wordsToPractice: [
{
id: Number,
correct: Number,
incorrect: Number,
bookmarked: Boolean,
},
],
},
],
});
// lesson collection
const LessonSchema = new mongoose.Schema({
title: String,
description: String,
totalPoints: Number,
totalWords: Number,
words: [
{
id: Number,
word: String,
points: Number
}
]
})
// if logged in
// find user in user collection
// find user's results in lessonsResults collection by using user_id
// iterate over each result to find their lesson & lesson's data
// combine data and send to frontend
// calculate percentage complete + other calculations
// render aggregate data on screen
I'm curious how you would resolve this.
Apologies if it's a bit long-winded! (+ hopefully the examples make sense)
You need to have the reference of user in LessonSchema, so that you can track how many lessons are taken by a user.
const LessonSchema = new mongoose.Schema({
user:{type:mongoose.Schema.Types.ObjectId,ref:'UserSchema',required:true},
title: String,
description: String,
totalPoints: Number,
totalWords: Number,
words: [
{
id: Number,
word: String,
points: Number
}
]
})
And you need to maintain a FLAG in LessonResultsSchema to track whether a user has completed that lesson or not. Once the lesson gets completed, you need to update the pointsEarned so that you can have the updated points data.
const LessonResultsSchema = new mongoose.Schema({
user_id: Schema.Types.ObjectId,
completed:{type:Boolean, default:0},
results: [
{
id: Number,
lesson_id: Schema.Types.ObjectId,
pointsEarned: Number,
wordsLearned: Number,
wordsToPractice: [
{
id: Number,
correct: Number,
incorrect: Number,
bookmarked: Boolean,
},
],
},
],
});
I would like to setup a "like" system in my app. User should be able to like either Posts or Comments (Comments of a Post of course). How should I design this?
Users
const userSchema = new Schema({
id: { type: String, required: true },
username: { type: String, required: true },
password: { type: String, required: true },
});
Posts
const postSchema = new Schema({
content: { type: String, required: true },
authorId: { type: mongoose.Schema.Types.ObjectId, ref: "User", required: true }
});
Comments
const commentSchema = new Schema({
content: { type: String, required: true },
authorId: { type: mongoose.Schema.Types.ObjectId, ref: "User", required: true },
postId: { type: mongoose.Schema.Types.ObjectId, ref: "Post", required: true },
});
Likes
const likeSchema = new Schema({
content: { type: String, required: false },
authorId: { type: mongoose.Schema.Types.ObjectId, ref: "User", required: true },
postId: { type: mongoose.Schema.Types.ObjectId, ref: "Post", required: function() { return this.commentId? false : true } },
commentId: { type: mongoose.Schema.Types.ObjectId, ref: "Comment", required: function() { return this.postId? false : true } }
});
I'm coming from relational databases, and maybe my design is completely wrong for nosql. My main interrogation is about Likes, I have no idea how to accept likes on Posts OR Comments.
I would prefer a separate collection:
User:
id:
...
Post:
id:
userId:
...
Comment:
id:
userId:
postId:
Like:
id:
userId:
postId:
commentId:
The second one storing an array will lead you cyclic dependencies in the backend. Especially, when you use NodeJS and strict to flow.
MongoDB is powerful at storing documents. Documents hold the relations.
I would model it in the way your data is being accessed. I do recommend playing around with the powerful aggregation framework and array operators to experience the possibilities. What I would explore is the following
User:
id:
name:
picture:
...
Posts:
id:
authorid:
content:
total_views:
tags: array of String
likes: array of Likes {[
liked_by: user_id
],...}
comments: array of Comments {[
author_id: ...
comment: ...
reactions: array of Comments {[],...}
likes: array of Likes {[
liked_by: user_id
],...}
],...}
Will this model scale? Documents can hold 16MB of data. 16MB in textual format is HUGE.
PS please think again on storing username/password in the database. This is a whole other discussion. Look into the topics of authentication, authorisation, OAuth, hashing/salting etc.
post={
...keys,
likes:[likeSchema],
comments:[CommentSchema]
}
this is i prefer, even if you want to store recursive comments just use
commentschema={
id:unique commet id
text:...
user_id:who wrote this comment
parent_id: to which this comment belongs to!
depth: comment depth as your wish (mostly 2)
}
parent id will be null for a comment posted directly on post
parent id will be comment_id of the comment to which this comment posted for. if its a recursive comment.
hope you get it.
Since, the question is about schema for like a comment or post. I'll focus on likes.
Build a schema like this. Here targetId will be postId or commentId.
const likeSchema = new Schema({
content: { type: String, required: false },
authorId: { type: mongoose.Schema.Types.ObjectId, ref: "User", required: true },
targetId: { type: mongoose.Schema.Types.ObjectId, ref: "Post", required: function() { return this.commentId? false : true } }
});
Some points you need to consider:
Store likes of posts in post collection
Store likes of comments in comments collection
You need to build a mechanism to calculate likes and store in that collection
This is my schema:
var cvSchema = new Schema({
name: {type: String, required: true},
alias: {type: String, required: true, minlength: 6, maxlength: 6},
profitCentre: {type:Number, min:1000, max:9999},
city: String,
company: String,
profession: {
type: Schema.ObjectId,
ref: 'profession',
required: true
},
});
The profession property is a reference. The profession can have one value, but with several languages. Is there any best practice on how to do this?
I came up with two options:
var professionSchema = new Schema({
values: [
{
lang: {type: String, enum: ['sv', 'en']},
name: {type: String, required: true}
}
]
});
Option two: (en = english, sv = swedish):
var professionSchema = new Schema({
en: 'String',
sv: 'String'
});
The first one is more generic, but I find it difficult to run easy queries (populate etc) on it. It's easier to run queries with the second one. Is there a right or wrong way here?
I don't see either of these being right or wrong and think you should use the solution that fits best with what you are trying to accomplish.
You might even consider checking out this npm package to make things simpler.
Is it possible to reference field within same schema? See my example below. Or am I going about this wrong way?
var UserSchema = new mongoose.Schema ({
username: String,
password: String,
email: String,
foods: [{
name: String,
category: String,
ingredients: // how to reference values in the ingredients array?
}],
ingredients: [{
name: String,
category: String
}]
});
Short answer
This is a core MongoDB design decision: MongoDB relationships: embed or reference?
Storing references to objects, rather than independent copies of them, as you would do in a relational database is possible in MongoDB and often done, it just results in more and more complex queries when you need to look them up.
Long answer
If the goal is just to keep the definitions of ingredient schemas consistent, you can define a schema and use it twice. The ingredients will be stored as independent copies, e.g.
[{ username: 'bob',
ingredients: [ { name: 'Carrot', category: 'Vegetable' } , ...],
foods: [ { name: 'Salad', category: 'Lunch', ingredients: [ { name: 'Carrot', category: 'Vegetable'}, ...]}]
}, ...]
var IngredientSchema = new mongoose.Schema({
name: String,
category: String,
});
var UserSchema = new mongoose.Schema ({
username: String,
password: String,
email: String,
foods: [{
name: String,
category: String,
ingredients: [IngredientSchema] // brackets indicates it's an array,
}],
ingredients: [IngredientSchema]
});
Alternatively you can reference ingredients by objectId:
var UserSchema = new mongoose.Schema ({
username: String,
password: String,
email: String,
foods: [{
name: String,
category: String,
ingredients: [mongoose.Schema.Types.ObjectId] // IDs reference individual ingredients,
}],
ingredients: [IngredientSchema]
});
By defining IngredientSchema explicitly, each ingredient object gets its own ObjectId when it is declared. The upside to storing IDs of ingredients (rather than copies of ingredient objects) is more concise and consistent storage. The downside is there will be many more and more complex queries.
[{ username: 'bob',
ingredients: [ { _id: ObjectId('a298d9ef898afc98ddf'), name: 'Carrot', category: 'Vegetable' } , ...],
foods: [ { name: 'Salad', category: 'Lunch', ingredients: [ {$oid: 'a298d9ef898afc98ddf'}, ]}]
}, ...]
A better approach if you want to store references to Ingredients, may be to store Ingredients as its own first class collection. You'll still have many separate queries when you want to look up foods by ingredient, or ingredients by food, but the queries will be simpler.
var UserSchema = new mongoose.Schema ({
username: String,
password: String,
email: String,
foods: [{
name: String,
category: String,
ingredients: [mongoose.Schema.Types.ObjectId] // IDs reference individual ingredients,
}],
ingredients: [mongoose.Schema.Types.ObjectId]
});
if the goal is store normalized references to ingredients and search foods based on them, to quote another [SO post][1], "this is one of those cases where relational databases really shine"
See this SO post for querying subdocuments by Id:
Reading categories and number of articles in a single query
As one respondent notes, "this is one of those cases where relational databases really shine"