Pourquoi ne Mangouste ont à la fois des schémas et des modèles?

Souvent le moyen le plus facile de répondre à ce type de question est un exemple. Dans ce cas, quelqu'un l'a déjà fait pour moi 🙂

Prendre un coup d'oeil ici:

http://rawberg.com/blog/nodejs/mongoose-orm-nested-models/

EDIT: Le post original (comme mentionné dans les commentaires) semble ne plus exister, je suis donc de le reproduire ci-dessous. Faut-il jamais de retour, ou si elle vient d'emménager, s'il vous plaît laissez-moi savoir.

Il donne une description décent de l'aide de schémas à l'intérieur des modèles dans la mangouste et pourquoi vous voulez le faire, et vous montre également comment pousser les tâches par l'intermédiaire du modèle, tandis que le schéma est tout au sujet de la structure, etc.

Original Post:

Commençons par un exemple simple de l'incorporation d'un schéma à l'intérieur d'un modèle.

var TaskSchema = new Schema({
    name: String,
    priority: Number
});

TaskSchema.virtual('nameandpriority')
    .get( function () {
        return this.name + '(' + this.priority + ')';
    });

TaskSchema.method('isHighPriority', function() {
    if(this.priority === 1) {
        return true;
    } else {
        return false;
    }
}); 

var ListSchema = new Schema({
    name: String,
    tasks: [TaskSchema]
});

mongoose.model('List', ListSchema);

var List = mongoose.model('List');

var sampleList = new List({name:'Sample List'});

J'ai créé un nouveau TaskSchema objet avec des informations de base à une tâche peut avoir. Une Mangouste un attribut virtuel est le programme d'installation de facilement combiner le nom et la priorité de la Tâche. J'ai seulement précisé un getter ici, mais virtuel setters sont pris en charge ainsi.

J'ai également défini une tâche simple méthode appelée isHighPriority pour montrer comment les méthodes de travail avec cette configuration.

Dans le ListSchema définition, vous remarquerez comment les tâches clé est configuré pour contenir un tableau de TaskSchema objets. La tâche clé sera une instance de DocumentArray qui fournit des méthodes spéciales pour traiter intégré Mongo documents.

Pour l'instant je n'ai passé le ListSchema objet dans la mangouste.modèle et à gauche de la TaskSchema out. Techniquement, il n'est pas nécessaire de tourner le TaskSchema dans un modèle formel puisque nous ne serons pas en l'enregistrant dans sa propre collection. Plus tard, je vais vous montrer comment il n'a pas de mal à rien si vous ne et il peut aider à organiser tous vos modèles de la même manière, surtout lorsqu'ils commencent à s'étendant sur plusieurs fichiers.

Avec le List modèle de configuration, nous allons ajouter un couple de missions et de les enregistrer à Mongo.

var List = mongoose.model('List');
var sampleList = new List({name:'Sample List'});

sampleList.tasks.push(
    {name:'task one', priority:1}, 
    {name:'task two', priority:5}
);

sampleList.save(function(err) {
    if (err) {
        console.log('error adding new list');
        console.log(err);
    } else {
        console.log('new list successfully saved'); 
    }
});

Les tâches de l'attribut de l'instance de notre List modèle (simpleList) fonctionne comme un tableau JavaScript, et nous pouvons ajouter de nouvelles tâches à l'aide de push. La chose importante à noter est que les tâches sont ajoutés régulièrement des objets JavaScript. C'est une distinction subtile qui peut ne pas être immédiatement intuitive.

Vous pouvez vérifier dans le shell Mongo que la nouvelle liste et les tâches ont été enregistrés à mongo.

db.lists.find()
{ "tasks" : [
    {
        "_id" : ObjectId("4dd1cbeed77909f507000002"),
        "priority" : 1,
        "name" : "task one"
    },
    {
        "_id" : ObjectId("4dd1cbeed77909f507000003"),
        "priority" : 5,
        "name" : "task two"
    }
], "_id" : ObjectId("4dd1cbeed77909f507000001"), "name" : "Sample List" }

Maintenant, nous pouvons utiliser la ObjectId à tirer la Sample List et parcourir ses tâches.

List.findById('4dd1cbeed77909f507000001', function(err, list) {
    console.log(list.name + ' retrieved');
    list.tasks.forEach(function(task, index, array) {
        console.log(task.name);
        console.log(task.nameandpriority);
        console.log(task.isHighPriority());
    });
});

Si vous exécutez ce dernier code, vous obtiendrez un message d'erreur indiquant que le document incorporé ne dispose pas d'une méthode isHighPriority. Dans la version actuelle de la Mangouste, vous ne pouvez pas les méthodes d'accès sur les schémas directement. Il y a un ticket ouvert pour le fixer et après en posant la question de la Mangouste Groupe Google, manimal45 posté un utile de travailler autour de l'utiliser pour l'instant.

List.findById('4dd1cbeed77909f507000001', function(err, list) {
    console.log(list.name + ' retrieved');
    list.tasks.forEach(function(task, index, array) {
        console.log(task.name);
        console.log(task.nameandpriority);
        console.log(task._schema.methods.isHighPriority.apply(task));
    });
});

Si vous exécutez ce code, vous devriez voir la sortie suivante sur la ligne de commande.

Sample List retrieved
task one
task one (1)
true
task two
task two (5)
false

Avec qui travailler autour de en tête passons TaskSchema dans une Mangouste modèle.

mongoose.model('Task', TaskSchema);

var Task = mongoose.model('Task');

var ListSchema = new Schema({
    name: String,
    tasks: [Task.schema]
});

mongoose.model('List', ListSchema);

var List = mongoose.model('List');

La TaskSchema définition est la même qu'avant, donc je l'ai laissée. Une fois transformé en un modèle, on peut toujours y accéder du Schéma sous-jacent de l'objet à l'aide de la notation point.

Nous allons créer une nouvelle liste et incorporer les deux instances de modèle à l'intérieur.

var demoList = new List({name:'Demo List'});

var taskThree = new Task({name:'task three', priority:10});
var taskFour = new Task({name:'task four', priority:11});

demoList.tasks.push(taskThree.toObject(), taskFour.toObject());

demoList.save(function(err) {
    if (err) {
        console.log('error adding new list');
        console.log(err);
    } else {
        console.log('new list successfully saved'); 
    }
});

Que nous sommes à l'intégration de la Tâche d'instances de modèle dans la Liste que nous appelons toObject à convertir leurs données sous forme d'objets JavaScript que l' List.tasks DocumentArray attend. Lorsque vous enregistrez le modèle des instances de cette façon, votre incorporé documents contiennent ObjectIds.

Le code complet de l'exemple est disponible comme un résumé. Espérons que ces solutions de rechange aider à arranger les choses comme la Mangouste continue à se développer. Je suis encore assez nouveau pour la Mangouste et MongoDB, donc n'hésitez pas à partager les meilleures solutions et conseils dans les commentaires. Heureux de modélisation de données!

Je ne pense pas que l'on a accepté de répondre en fait la réponse à la question qui a été posée. La réponse n'explique pas pourquoi Mangouste a décidé d'exiger un développeur de fournir à la fois un Schéma et une variable de Modèle. Un exemple d'un cadre où ils ont éliminé la nécessité pour les développeur pour définir le schéma de données est django--un développeur écrit leurs modèles dans le models.py fichier, et laisse le cadre pour gérer le schéma. La première raison qui vient à l'esprit pour expliquer pourquoi ils font cela, compte tenu de mon expérience avec django, est la facilité d'utilisation. Peut-être plus important encore est le DRY (don't repeat yourself) principe--vous n'avez pas à vous rappeler de mettre à jour le schéma lorsque vous modifiez le modèle django va le faire pour vous! Rails gère également le schéma de données pour vous-un développeur de ne pas modifier le schéma directement, mais la transforme en définissant des migrations qui manipulent le schéma.

L'une des raisons que je pourrais comprendre que la Mangouste séparées pour le schéma et le modèle est des cas où vous voulez construire un modèle à partir de deux schémas. Un tel scénario pourrait introduire plus de complexité que vaut la gestion de--si vous avez deux schémas qui sont gérés par un seul modèle, pourquoi ne sont-ils pas un schéma?

Peut-être la question d'origine est plus qu'une relique de la traditionnelle relationnel de la base de données du système. Dans le monde NoSQL/Mongo monde, peut-être le schéma est un peu plus souple que MySQL/PostgreSQL, et donc de changer le schéma est une pratique plus courante.