Je travaillais avec mangouste pour remplir le champ d'identifiants avec leurs documents respectifs dans un nouveau champ. Ma question suppose que mon modèle de panier est -
let CartSchema = new mongoose.Schema({
userId: {
type: mongoose.Schema.Types.ObjectId,
ref: 'User'
},
productIds: [
{
type: String
}
]
}, { toJSON: { virtuals: true } });
CartSchema.virtual('products', {
ref: 'Product',
localField: 'productIds',
foreignField: '_id',
});
Cart.find({}).populate("products").exec(function (err, cart) {
console.log(cart)
}
Je veux remplir les produits donc je utilisé
Cart.find({}).populate("products").exec(function (err, cart) {
console.log(cart)
}
mais cela remplit les documents dans le même nom de champ productIds et je veux remplir ces champs dans un nouveau nom de champ appelé "produits" alors j'ai essayé ceci p >
let CartSchema = new mongoose.Schema({
userId: {
type: mongoose.Schema.Types.ObjectId,
ref: 'User'
},
productIds: [
{
type: mongoose.Schema.Types.ObjectId,
ref: 'Product'
}
]
});
mais a renvoyé un tableau vide nommé products.so comment puis-je remplir le tableau productIds avec un nouveau nom de champ products avec leur tableau de documents respectif.
Merci. p>
3 Réponses :
Faire ce que vous voulez faire techniquement va à l'encontre de la convention en ce qui concerne l'utilisation de Mongoose. Vous pouvez simplifier les choses en renommant simplement le champ "productIds" en "products":
Si vous y réfléchissez bien, un tableau de produits peut être un tableau des valeurs d'identifiant de produit, ou il peut s'agir des documents réels. Le nom de propriété "produits" s'applique correctement à tous les scénarios, pas "productIds".
Étant donné que les documents remplis ont également la propriété "_id" sur chacun d'eux, il n'est pas nécessaire de gonfler le JSON avec de nouvelles propriétés virtuelles uniquement pour les valeurs d'id - vous les avez déjà!
Il est hautement improbable que vous obteniez des identifiants lorsque vous attendez des documents ou que vous obteniez des documents lorsque vous attendez des identifiants, car vous êtes toujours au courant des heures auxquelles vous choisissez de remplir la propriété et quand pas. Exemple: si vous parlez à un point de terminaison d'API, ce point de terminaison d'API renverra toujours les produits remplis ou non, pas les deux au hasard. Votre front-end est alors codé contre cela!
oui vous avez raison mais si je veux ajouter des produits à mon panier, je mettrais les identifiants du produit dans l'identifiant et quand je reçois mon panier, je voudrais que les identifiants soient renseignés en tant que produit et lors de la programmation de mon modèle dans ios, je suis va avoir besoin de créer 2 modèles différents pour envoyer et recevoir des informations sur le panier si j'utilise ce champ pour les deux
@NatnaelGetachew J'ai supposé que vous aviez entièrement une pile technique mal typée (par exemple NodeJS). Si vous ne le faites pas, vous ne pouvez pas toujours réutiliser complètement vos modèles mal typés dans votre front-end fortement typé. Je vous suggère de trouver une solution sur le front-end fortement typé plutôt que de bâtarder vos modèles Mongoose sur le backend faiblement typé.
l'approche est correcte, vous devriez voir vos données renseignées dans le champ produits. assurez-vous d'avoir les bonnes données et le modèle n
Il existe un moyen de le faire - cela s'appelle Virtuals (voir docs ). L'idée est de créer une "propriété virtuelle" qui n'est pas réellement enregistrée dans la base de données et agit comme une propriété calculée. Selon l'exemple fourni par qinshenxue sur le problème github associé: < pré> XXX
Je suppose que cela résout le problème, mais cela bastarise les modèles Mongoose. Si OP avait entièrement utilisé une pile technologique faiblement typée (par exemple NodeJS), cela n'aurait jamais été un problème. Si vous avez un front-end fortement typé, alors la solution appropriée ici est de trouver une solution sur le front-end fortement typé plutôt que de bâtarder les modèles Mongoose sur le backend faiblement typé.
@skyzaDev veuillez définir "bâtardises". À mon avis, peu importe si vous utilisez des typages ou non, avoir un objet avec une propriété de surprise (une propriété dont vous ne savez jamais ce qu'il contient) est une solution extrêmement sujette aux erreurs qui ne devrait jamais être utilisée.
La population de mangoustes serait appelée intentionnellement, et non au hasard. Par exemple. si vous avez un point de terminaison d'API, ce point de terminaison renverra toujours des données de base de données soit remplies soit non remplies, pas les deux de manière aléatoire. Le frontal est ensuite codé par rapport à cela.
@skyzaDev donc si j'ai, disons, 3 propriétés remplissables, je devrais avoir 9 types pour un tel objet? Pour chaque combinaison de propriétés peuplées / non peuplées? Cela ressemble en effet à une bâtardise.