2017-07-19 4 views
0

J'essaie de créer un schéma où body peut avoir des clés différentes en fonction de l'événement entrant. Donc, quand j'essaie de rendre les données, il suffit d'envoyer _id au client event ne fait pas partie des résultats. Ai-je mis en place un mauvais schéma avec cette approche?Comment utiliser le schéma mongoose lorsque vous avez des valeurs dynamiques?

event.model.js

var mongoose = require('bluebird').promisifyAll(require('mongoose')); 


var bmpEventSchema = new mongoose.Schema({ 
    event: { 
    type: String, 
    body : {} 
    } 
}); 

export default mongoose.model('BmpEvent', bmpEventSchema); 

JsonDocument

{ 
    "_id" : ObjectId("596f672f4c387baa25db5ec6"), 
    "event" : { 
     "type" : "json", 
     "body" : { 
      "evntType" : "Smtduki", 
      "tkt" : "75522655", 
      "cat" : "RNT", 
      "esc_lvl" : "4", 
      "asset" : "DNEC843027 ATI", 
      "esc_tm" : "2017-05-26 09:18:00", 
      "tos" : "T3APLS", 
      "mcn" : "SL6516", 
      "cusTkt" : "", 
      "tktSrc" : "BMP", 
      "tier1" : "STLMOETS" 
     } 
    } 
} 
+0

Ce n'est vraiment pas clair pour moi ce que vous demandez ici. –

+0

pas besoin de promettre des méthodes mongoose. – Lazyexpert

Répondre

0

schéma est erroné. Devrait être:

var bmpEventSchema = new mongoose.Schema({ 
    event: { 
    type: String, 
    body : Mixed 
    } 
}); 
+0

ReferenceError: Mixed n'est pas défini à Object. développer/bpm_modeler/server/api/bmpEvents/bmpEvent.model.js: 9: 12) – hussain

+0

Alors corps 'Schema.Types.Mixed' –

+0

pas de chance': Schema.Types.Mixed ReferenceError: schéma n'est pas defined' – hussain

0

Il existe deux approches que je peux suggérer:

  • vous simplement ne pas la liste de vos clés comme dans votre exemple
  • vous listez toutes les clés possibles et marquer certains d'entre eux selon les besoins (en fonction de votre logique)

Exemple:

"key": { 
    type: "string", 
    required: true 
} 
0

Ceci est un cas d'utilisation pour les discriminateurs. Vous pouvez faire un corps de type Mixte mais cela va à l'encontre du but de Mongoose pour fournir une validation. Supposons que vous avez modélisé une base de données de livres. Vous faites une clé nommée Professeur pour un livre académique. Mais alors vous devez faire un romancier clé pour un roman. Vous devez stocker le genre pour le roman mais pas pour les livres éducatifs. Vous pouvez maintenant créer une clé de type comme dans votre cas d'utilisation et jouer avec les résultats. Mais alors vous devrez peut-être appliquer des valeurs par défaut pour romancier dans les romans. Ou vous devrez peut-être définir un champ requis dans l'un des types et pas l'autre. Un autre problème avec cette approche serait d'utiliser des middlewares (hooks) pour les différents types. Vous pouvez effectuer une fonction différente sur la création de roman et une fonction différente sur la création d'un livre éducatif. C'est juste un scénario et vous pouvez avoir comme 10 ou 15 types qui seront encore plus encombrants à gérer. Maintenant, afin d'éviter ces problèmes, vous pouvez créer un modèle différent pour chaque type. Mais si vous faites cela, lorsque vous voulez interroger tous les livres, vous devrez effectuer une requête sur chacun des modèles qui seront inefficaces. Vous avez besoin de quelque chose sur la couche ODM. C'est là que les discriminateurs entrent en jeu. Vous créez un modèle de base avec toutes les clés que vous voulez dans tous les types de livres et vous y ajoutez une clé de discrimination (reportez-vous à docs). Ensuite, vous créez un roman à partir de la fonction discriminateur de ce modèle et ajoutez des clés supplémentaires qui ne seront que dans le roman. Vous pouvez créer autant de modèles enfants que vous le souhaitez de cette façon et ensuite vous pouvez les utiliser simplement de manière polymorphe. En interne, cela va créer une collection unique nommée livres mais pour les romans il ne conservera que les clés des romans. La validation, les middlewares, etc. des différents types de modèles seront gérés par la couche ODM. http://mongoosejs.com/docs/discriminators.html