C'est trivial sur un document pour un utilisateur, ça l'est moins sur plusieurs documents, dans un environnement concurrent sans passer par des locks et toutes les joyeusetés qui vont avec.
A priori isolated peut/va faire le job. Mais pour le coup, je n'utiliserais pas Mongo dans un environnement nécessitant des transactions multi-documents. L'idée c'est de stocker des données plutôt disjointes, sans side-effect et le faire rapidement dans un environnement à accès concurrents.
je suis passée à la version 3.2 qui est sortie récemment et qui change pas mal de choses ;
j'ai finalement utilisé un exemple qui se rapproche du blog mais change quand même un peu et va me permettre des trucs plus évolués par la suite.
Le plan pour les prochaines semaines :
adapter les 3 derniers chapitres de la 1e partie
repasser sur toutes vos remarques
J'espère passer la partie 1 en validation d'ici la fin du mois.
J'ai été convaincu par Mongo et je veux l'utiliser pour de vrai. Comment je fais dans mon application en Java, PHP, python, C++, <insérez ici un autre langage de votre choix> ?
La réponse se trouve sûrement sur Google en 5 minutes et tu n'as peut-être pas envie de t'étaler sur la question, mais ça pourrait néanmoins sans doute être utile de mettre des liens vers des bibliothèques, connecteurs, API… Vu que c'est totalement différent des bases SQL dont on a l'habitude, je pense qu'il faudrait en toucher quelques mots, au moins rapidement.
Typiquement si on compare avec un cours sur MySQL rédigé de façon classique, on ne reste pas en console très longtemps et on attaque vite fait l'utilisation à travers JDBC ou PDO… certes on n'a pas un langage de requêtage complet et pratique comme JavaScript à disposition, mais… tout de même…
Je ne sais pas encore dans quelle mesure j'aborderai ça. A priori ce n'est pas prévu mais j'en toucherai peut-être un mot.
Les jointures n'existent pas, tu l'expliques très clairement. Est-ce que ça veut dire que, pour avoir une base performante, dans le cadre d'un blog par exemple, j'ai intérêt à stocker un array de tags dans chaque document de la collection billets et un array d'ID de billets dans chaque document représentant un tag ? Avec les risques de données obsolètes associées ? Avoir deux collections liées est une mauvaise idée du coup ?
Ayant comme beaucoup été depuis toujours lobotomisé aux bases SQL et à peu près exclusivement SQL, ce genre de question me trouble. J'espère bien que tu as l'intention d'y venir dans un prochaîn chapitre.
J'ai toute une partie prévue sur le design d'une base de données mongo, dans quel cas utiliser des objets complexes, dans quels cas séparer en deux collections. C'est un sujet super intéressant et franchement mind-blowing quand on vient du SQL (enfin moi j'ai trouvé ça trop cool en tout cas ) parce que la manière de penser est vraiment complètement inversée par rapport aux BDD relationnelles.
En effet. Vu que j'ai profité des changements pour passer aussi à la version 3.2, je le mentionne. Mais on est très loin des jointures SQL, tant au niveau fonctionnalité qu'au niveau finalité.
J'ai pas lu tout le topic ni tout le tuto, j'ai juste ouvert une page au hasard et suis tombé là-dessus :
la norme JSON exige que les clés soient entourés de guillemets. On peut cependant les omettre si elle ne contiennent pas de caractère spéciaux, d'espace et qu'elles commencent par une lettre (ou "_").
Trois remarques :
La norme JSON exige que les clés soient entourées de guillemets.
Sans aucune exception.
S'il y avait eu des exceptions, j'aurais indiqué _ et non "_".
Pour rappel, la syntaxe JSON pour le clés est la suivante : (citation de json.org, page d'accueil)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
object
{}
{ members }
members
pair
pair , members
pair
string : value
[...]
string
""
" chars "
Du coup, je vais reprendre ma lecture du début. Je ne relève pas les fautes formelles. J'espère ne pas répéter de remarques sur lesquelles tu m'aurais déjà cloué le bec.
NoSQL
Ainsi naquit NoSQL
Les différents modèles et technologies ayant émergés sont aujourd'hui regroupés sous la bannière « NoSQL », qui signifie « Not Only SQL » (« Pas seulement SQL »).
Pourquoi « Not Only SQL » ?
Les requêtes sur la BDD ne peuvent se faire que via les clés, ce qui en fait un système extrêmement performant, mais très peu souple quant à la récupération des données.
Tu pourrais expliciter la partie en gras.
Ce modèle étend en quelque sorte le modèle clé-valeur. Chaque valeur est un document
Qu'est-ce qu'un document ? Comme tu dis après qu'on le stocke au format JSON, on comprend assez vite, mais il me semble intéressant d'en donner une définition.
et il est possible de faire des requêtes soit en utilisant la clé du document
Dans l'exemple que tu donnes en-dessous, je ne vois pas ce que serait la clé du document (ni dans Mongo d'ailleurs).
et peuvent contenir des attributs qui sont eux-mêmes des documents, ou des listes de documents.
Tu pourrais donner juste en-dessous un exemple de liste de documents. Mais c'est un détail, on se l'imagine assez facilement.
Les performances sont moins bonnes qu'avec le modèle clé-valeur, mais ce modèle très souple permet des fonctionnalités avancées.
Là encore, pourquoi ce modèle est-il très souple ?
parce que le but est que les application n'utilise pas que le SQL
parce que pas mal de DB NoSQL reprennent des concepts voire la syntaxe de SQL.
Tu pourrais expliciter la partie en gras.
Dans mes souvenirs ça vient plus tard. Je pense donc qu'il vaut mieux ne pas trop s'apesentir au début.
Qu'est-ce qu'un document ? Comme tu dis après qu'on le stocke au format JSON, on comprend assez vite, mais il me semble intéressant d'en donner une définition.
ça par contre c'est primordial. (et document mérite du gras)
Je poursuis. Il y a pas mal de remarques, mais beaucoup sont des questions d'approfondissement. Il n'y a que très peu de passages obscurs.
Présentation de MongoDB
Fonctionnalités principales
Une collection est simplement une liste de documents.
Plutôt un ensemble, non ?
On aura par exemple une collection client, une collection arbres, etc.
Tu as un coup un "s" à la fin du nom de la collection, un coup non. Tu m'avais indiqué la convention utilisée mais j'ai oublié.
Or ces index seront plus performant (à utiliser et à tenir à jour) si tous les documents sont du même type dans la collections.
J'ignore un peu comment prendre ce passage puisque d'un côté Mongo nous offre de la souplesse en nous permettant d'avoir des documents de natures différentes, et de l'autre il est conseillé d'avoir des documents identiques (dans leur structure) dans une même collection.
Fonctionnalités absentes ou restreintes
Gérer les éléments qui nécessitent une transaction avec un SGBD relationnel, et éventuellement le combiner avec MongoDB pour les éléments moins critiques.
Mongo permet-il (d'une manière dont je n'ai aucune idée) de se coupler facilement avec une base relationnelle, ou faut-il gérer ça au niveau de l'application ?
On a donc bien une garantie d'atomicité avec MongoDB, mais elle est plus restreinte que dans les bases de données relationnelles, et n'est pas faite au même niveau.
J'ai un peu buté là-dessus. Tu pourrais peut-être l'expliciter en reprenant l'exemple de Mjolnir et en expliquant pourquoi le comportement décrit ne peut être obtenu avec Mongo.
il faut qu'un changement dans celle-ci fasse passer les données d'un état valide à un autre état valide, sans étape intermédiaire dans laquelle les données sont invalides
Un exemple de données invalides aiderait à comprendre, même si on arrive à se faire une petite idée.
Cependant, dans certaines configurations, MongoDB peut être cohérente au final.
Tu pourrais rajouter "seulement". Après, la question est un peu : au final de quoi ?
Peut-être serait-il préférable de formuler de la sorte : "Cependant, dans certaines configurations, MongoDB peut être momentannément incohérent".
C'est le cas notamment lorsque l'on utilise des réplicats
Si on n'utilise pas de réplicats, qu'on ne peut accéder à la base depuis un seul serveur, est-on assuré de la cohérence des données ?
Si pendant que cette opération se déroule, on tente de modifier un certain document, il est possible que cette modification soit perdue : le document enregistré par l'opération d'ajout de champ écrasant les modifications qui été faite entre le lancement de celle-ci et la modification du document.
Ca me semble un peu étrange, puisque ça voudrait dire qu'au moment de la requête "modifier tous les documents", Mongo enregistre leur état, puis repasse sur chacun d'eux pour effectuer la modification. Pourquoi ne pas simplement les parcourir un à un et les modifier au fur et à mesure, peu importe qu'un document ait été modifié depuis le début du parcours ?
Pour les modifications qui affectent plusieurs documents, MongoDB dispose d'une option qu'on peut utiliser pour garantir l'isolation.
Ca rejoint la question précédente, mais pourquoi ne pas considérer une opération sur plusieurs documents comme une opération sur le premier (alors isolée), puis sur le deuxième (également isolée), etc. ?
Chaque modification des données est d'abord enregistrée en mémoire. Toutes les 100 millisecondes, elles sont ajoutées au journal
Je me souviens que j'avais bloqué là-dessus la première fois, parce que je croyais qu'on faisait la même chose dans le journal que sur le disque (on modifiait les données). En fait, si j'ai bien compris, ce sont les requêtes qu'on stocke dans le journal. Le cas échéant, peut-être pourrais-tu reformuler.
Modèle client - serveur
MongoDB est un SGBD basé sur le modèle "client - serveur".
Tu pourrais fournir un lien explicitant cette notion.
Il est possible (et même courant) d'avoir plusieurs clients différents communiquant avec le même serveur.
Peut-être pourrais-tu glisser un mot sur les API disponibles dans plusieurs langage. Autrement dit, indiquer qu'on peut effectivement démarrer plusieurs instances de mongo, mais aussi communiquer avec la base depuis une application Python ou que sais-je.
Présentation du shell Mongo
Mais le shell mongo, c'est aussi un interpréteur JavaScript. Vous pouvez donc écrire des instructions en JS, elles s'exécuteront sans problème.
Même si on le devine très facilement, je ne crois pas que tu aies dit explicitement que c'était là où, en plus d'écrire des commandes JS, on allait effectuer nos requêtes à la base. Tu pourrais par exemple formuler ce passage de la sorte : "C'est dans ce shell mongo que nous allons effectuer nos requêtes au serveur. Sachez à ce propos que le shell est également un interpréteur JavaScript. Vous pouvez donc utiliser les fonctionnalités de ce langage pour effectuer vos requêtes (par exemple, faire une requête en boucle) et en manipuler les résultats.".
J'ai pas mal bloqué (et je bute toujours) sur la partie concernant l'isolation. Peut-être est-ce parce que je n'ai pas très bien compris ce que c'était.
la norme JSON exige que les clés soient entourés de guillemets. On peut cependant les omettre si elle ne contiennent pas de caractère spéciaux, d'espace et qu'elles commencent par une lettre (ou "_").
Trois remarques :
La norme JSON exige que les clés soient entourées de guillemets.
Sans aucune exception.
S'il y avait eu des exceptions, j'aurais indiqué _ et non "_".
C'est sans doute la formulation qui t'ennuie. C'est bien MongoDB qui autorise de se passer des guillemets dans les conditions citées. Je vais reformuler parce qu'effectivement c'est pas clair.
Les différents modèles et technologies ayant émergés sont aujourd'hui regroupés sous la bannière « NoSQL », qui signifie « Not Only SQL » (« Pas seulement SQL »).
Pourquoi « Not Only SQL » ?
Je vais corriger pour ajouter une explication.
Les requêtes sur la BDD ne peuvent se faire que via les clés, ce qui en fait un système extrêmement performant, mais très peu souple quant à la récupération des données.
Tu pourrais expliciter la partie en gras.
J'ai rajouté une mini-explication. Ca suffit ?
Ce modèle étend en quelque sorte le modèle clé-valeur. Chaque valeur est un document
Qu'est-ce qu'un document ? Comme tu dis après qu'on le stocke au format JSON, on comprend assez vite, mais il me semble intéressant d'en donner une définition.
et il est possible de faire des requêtes soit en utilisant la clé du document
Dans l'exemple que tu donnes en-dessous, je ne vois pas ce que serait la clé du document (ni dans Mongo d'ailleurs).
et peuvent contenir des attributs qui sont eux-mêmes des documents, ou des listes de documents.
Tu pourrais donner juste en-dessous un exemple de liste de documents. Mais c'est un détail, on se l'imagine assez facilement.
Les performances sont moins bonnes qu'avec le modèle clé-valeur, mais ce modèle très souple permet des fonctionnalités avancées.
Là encore, pourquoi ce modèle est-il très souple ?
Je viens de reformuler la partie sur les DB orientées objet pour inclure —la plupart de— vos remarques à toi, artragis et victor. Est-ce mieux ?
Présentation de MongoDB
Fonctionnalités principales
Une collection est simplement une liste de documents.
Plutôt un ensemble, non ?
Pas sûre de voir la différence.
On aura par exemple une collection client, une collection arbres, etc.
Tu as un coup un "s" à la fin du nom de la collection, un coup non. Tu m'avais indiqué la convention utilisée mais j'ai oublié.
J'ai un peu cherché sur Google et dans la doc si je trouvais une convention, mais en fait, même dans les exemples de la doc, des fois c'est pluriel, des fois c'est singulier. Mais il faudra quand même que je décide de ce que moi je vais faire, et rester cohérente tout au long du cours. Donc singulier !
Or ces index seront plus performant (à utiliser et à tenir à jour) si tous les documents sont du même type dans la collections.
J'ignore un peu comment prendre ce passage puisque d'un côté Mongo nous offre de la souplesse en nous permettant d'avoir des documents de natures différentes, et de l'autre il est conseillé d'avoir des documents identiques (dans leur structure) dans une même collection.
Je viens de pas mal reformuler toute cette partie, notamment l'explication avec les stylos et les crayons et la raison pour laquelle il vaut mieux avoir plusieurs collections qu'une seule. Au lieu de poser la question et d'y répondre d'un bloc, j'en parle au niveau de l'explication sur les index, ainsi qu'au niveau de la répartition des données. A mon avis, les explications sont moins boiteuses et plus claires. Par contre, est-ce que ce n'est pas trop d'explications du coup ?
Fonctionnalités absentes ou restreintes
Gérer les éléments qui nécessitent une transaction avec un SGBD relationnel, et éventuellement le combiner avec MongoDB pour les éléments moins critiques.
Mongo permet-il (d'une manière dont je n'ai aucune idée) de se coupler facilement avec une base relationnelle, ou faut-il gérer ça au niveau de l'application ?
A ma connaissance, il faut gérer ça côté appli
On a donc bien une garantie d'atomicité avec MongoDB, mais elle est plus restreinte que dans les bases de données relationnelles, et n'est pas faite au même niveau.
J'ai un peu buté là-dessus. Tu pourrais peut-être l'expliciter en reprenant l'exemple de Mjolnir et en expliquant pourquoi le comportement décrit ne peut être obtenu avec Mongo.
Bon, j'ai un peu étoffé l'explication, mais je me demande si j'en fais pas trop du coup.
il faut qu'un changement dans celle-ci fasse passer les données d'un état valide à un autre état valide, sans étape intermédiaire dans laquelle les données sont invalides
Un exemple de données invalides aiderait à comprendre, même si on arrive à se faire une petite idée.
L'exemple du paragraphe suivant, avec les données lues sur un serveur secondaire (donc pas nécessairement à jour au moment où une modification est faite) n'est pas suffisant ?
Cependant, dans certaines configurations, MongoDB peut être cohérente au final.
Tu pourrais rajouter "seulement". Après, la question est un peu : au final de quoi ?
Peut-être serait-il préférable de formuler de la sorte : "Cependant, dans certaines configurations, MongoDB peut être momentannément incohérent".
C'est le cas notamment lorsque l'on utilise des réplicats
Si on n'utilise pas de réplicats, qu'on ne peut accéder à la base depuis un seul serveur, est-on assuré de la cohérence des données ?
Oui
Si pendant que cette opération se déroule, on tente de modifier un certain document, il est possible que cette modification soit perdue : le document enregistré par l'opération d'ajout de champ écrasant les modifications qui été faite entre le lancement de celle-ci et la modification du document.
Ca me semble un peu étrange, puisque ça voudrait dire qu'au moment de la requête "modifier tous les documents", Mongo enregistre leur état, puis repasse sur chacun d'eux pour effectuer la modification. Pourquoi ne pas simplement les parcourir un à un et les modifier au fur et à mesure, peu importe qu'un document ait été modifié depuis le début du parcours ?
Un update sur plusieurs documents va effectivement récupérer un curseur (donc un pointeur vers les documents trouvés) puis parcourir ce curseur pour faire les modifications demandées. Si deux opérations update se déroulent en même temps et concernent en partie les mêmes documents, il est possible d'avoir un problème.
Par exemple, je lance l'opération A au temps $t_{1}$ et l'opération B au temps $t_{2}$. Si les deux opérations sont isolées, il est possible que B écrase des changements fait par A (puisque B arriverait après), mais l'inverse ne devrait pas être possible. Dans le cas où les opérations ne sont pas isolées, imaginons que A concerne les objets x, y et z, et l'opération B concerne uniquement y. A récupère le curseur [x, y, z] et commence par modifier x, puis B récupère le curseur [z], modifie z et se termine. A continue son bonhomme de chemin et modifie y, puis z. Il est possible que la modification de z par A écrase la modification de z par B. Parce que les opérations A et B ne sont pas isolées.
Pour les modifications qui affectent plusieurs documents, MongoDB dispose d'une option qu'on peut utiliser pour garantir l'isolation.
Ca rejoint la question précédente, mais pourquoi ne pas considérer une opération sur plusieurs documents comme une opération sur le premier (alors isolée), puis sur le deuxième (également isolée), etc. ?
Mais c'est le cas, l'isolation, et l'atomicité, sont garanties au niveau du document.
Chaque modification des données est d'abord enregistrée en mémoire. Toutes les 100 millisecondes, elles sont ajoutées au journal
Je me souviens que j'avais bloqué là-dessus la première fois, parce que je croyais qu'on faisait la même chose dans le journal que sur le disque (on modifiait les données). En fait, si j'ai bien compris, ce sont les requêtes qu'on stocke dans le journal. Le cas échéant, peut-être pourrais-tu reformuler.
Ou c'est bien les requêtes même qui sont enregistrées, pas les documents modifiés. Mais quand je relis le passage, ça me parait clair, ou du moins je vois pas comment reformuler… Une suggestion ?
Modèle client - serveur
MongoDB est un SGBD basé sur le modèle "client - serveur".
Tu pourrais fournir un lien explicitant cette notion.
Même si j'explique juste après ?
Il est possible (et même courant) d'avoir plusieurs clients différents communiquant avec le même serveur.
Peut-être pourrais-tu glisser un mot sur les API disponibles dans plusieurs langage. Autrement dit, indiquer qu'on peut effectivement démarrer plusieurs instances de mongo, mais aussi communiquer avec la base depuis une application Python ou que sais-je.
C'est peut-être la fatigue mais je vois pas trop non plus comment amener ça sans avoir une explication un peu lourde pour pas grand chose…
Présentation du shell Mongo
Mais le shell mongo, c'est aussi un interpréteur JavaScript. Vous pouvez donc écrire des instructions en JS, elles s'exécuteront sans problème.
Même si on le devine très facilement, je ne crois pas que tu aies dit explicitement que c'était là où, en plus d'écrire des commandes JS, on allait effectuer nos requêtes à la base. Tu pourrais par exemple formuler ce passage de la sorte : "C'est dans ce shell mongo que nous allons effectuer nos requêtes au serveur. Sachez à ce propos que le shell est également un interpréteur JavaScript. Vous pouvez donc utiliser les fonctionnalités de ce langage pour effectuer vos requêtes (par exemple, faire une requête en boucle) et en manipuler les résultats.".
De ce fait, la norme JSON exige que les clés soient entourés de guillemets. MongoDBD est cependant plus souple et permet l'omission des guillemets autour des clés qui ne contiennent ni caractères spéciaux, ni espaces et qui commencent par une lettre (ou _).
Mise à part la petite coquille, je pense qu'il vaudrait la peine de grouper cette petite explication avec celle qui dit que le shell Mongo est en réalité un interpréteur JS connecté à un serveur Mongo exposant l'API de Mongo. Quand on le dit comme ça, on réalise que c'est la syntaxe JS (objets littéraux) qui est acceptée par l'API JavaScript de Mongo. La syntaxe JSON n'étant quant à elle qu'un sous-ensemble ou une spécification de la syntaxe littérale des objets JS.
Merci pour tes retours et la prise en compte des remarques.
Plutôt un ensemble, non ?
Pas sûre de voir la différence.
Dans une liste, les éléments sont ordonnés. On s'attend donc à pouvoir sélectionner le premier document, le second, etc.
j'en parle au niveau de l'explication sur les index […]. Par contre, est-ce que ce n'est pas trop d'explications du coup ?
La partie sur les index est en effet un peu longue, mais j'ai peur qu'elle ne soit pas assez claire si tu enlèves l'exemple.
D'ailleurs, je viens de me rendre compte que j'avais, je crois, mal interprété ce passage :
Pour permettre une exécution rapide des requêtes, MongoDB permet de créer des index, c'est-à-dire des structures de données spéciales qui stockent une petite portion des documents d'une collection de manière ordonnée.
J'avais compris qu'on ne gardait que certains documents de la collection, alors qu'en fait on les garde tous, mais ne conserve que certains attributs.
Du coup, concernant le bloc informatif sur les performances des index, tu pourrais procéder de la manière suivante :
Même lorsque l'attribut désigné n'existe pas dans le document, ce dernier est stocké dans l'index ;
Ainsi, si les documents d'une même collection ont une structure très différente, beaucoup risquent de ne pas renseigner l'attribut désigné par l'index, lequel contiendra donc des documents inutiles ;
Les performances ne seront donc pas optimales, puisqu'on parcourera des documents pour rien et risque de ne pas avoir assez de place pour stocker l'index en RAM.
Ce n'est bien sûr qu'une suggestion, et je ne suis pas énormément satisfait de cette proposition.
Présentation de MongoDB
Fonctionnalités principales
Cette manière de conserver les données permet de simplifier notamment les allées-venues entre la base de données et l'application qui utilise celle-ci.
Tu pourrais un peu expliciter cela. Il me semble que tu le fais(sais ?) quelque part, en disant que du point de vue de l'application, ce qui a du sens ce sont les objets (un article, un commentaire, etc.) et pas tellement les attributs (le titre, la note, etc.), et donc qu'on souhaite tout récupérer d'un coup en base, ce que permet Mongo avec ses documents.
Ca peut se déduire de l'analogie que tu fais juste après avec la POO, mais il me semble intéressant de le préciser.
On a donc bien une garantie d'atomicité avec MongoDB, mais elle est plus restreinte que dans les bases de données relationnelles, et n'est pas faite au même niveau.
Bon, j'ai un peu étoffé l'explication, mais je me demande si j'en fais pas trop du coup.
Le premier élément de la liste répète en effet ce qui précède. Tu pourrais dire un truc du genre : "Alors que dans une base de données relationnelle l'atomicité peut être garantie pour un ensemble d'opérations, faisant intervenir possiblement plusieurs lignes ou tables, Mongo ne la garantit que pour des opérations concernant un seul et même document.".
Et du coup, reprendre l'exemple avec Mjolnir est effectivement un peu redondant, désolé.
L'exemple du paragraphe suivant, avec les données lues sur un serveur secondaire (donc pas nécessairement à jour au moment où une modification est faite) n'est pas suffisant ?
Si.
Ou c'est bien les requêtes même qui sont enregistrées, pas les documents modifiés. Mais quand je relis le passage, ça me parait clair, ou du moins je vois pas comment reformuler… Une suggestion ?
En fait, je crois que c'est la partie en gras qui m'a perturbé : "Chaque modification des données est d'abord enregistrée en mémoire. Toutes les 100 millisecondes, elles sont ajoutées au journal". Le terme "opération" que tu utilises plus bas ("En cas de crash du serveur, lors du redémarrage, MongoDB va vérifier dans le journal s'il reste des opérations") est plus clair je trouve. Tu peux aussi parler de requête : "Chaque requête modifiant les données est d'abord enregistrée en mémoire.".
Tu pourrais fournir un lien explicitant cette notion.
Même si j'explique juste après ?
Il me semble intéressant pour la culture de connaître ce modèle de communication, et pas uniquement dans le cas de Mongo (par exemple, en Web). Mais c'est un détail.
C'est peut-être la fatigue mais je vois pas trop non plus comment amener ça sans avoir une explication un peu lourde pour pas grand chose…
Tu pourrais le placer après la liste, sous la forme de : "mongo n'est pas le seul moyen de communiquer avec le serveur. Il existe notamment des bibliothèques dans divers langages pour interroger une base Mongo depuis sa propre application (par exemple, son site Web).".
Mise à jour du chapitre 5 avec les nouvelles données.
Cool !
De ce fait, la norme JSON exige que les clés soient entourés de guillemets. MongoDBD est cependant plus souple et permet l'omission des guillemets autour des clés qui ne contiennent ni caractères spéciaux, ni espaces et qui commencent par une lettre (ou _).
Mise à part la petite coquille, je pense qu'il vaudrait la peine de grouper cette petite explication avec celle qui dit que le shell Mongo est en réalité un interpréteur JS connecté à un serveur Mongo exposant l'API de Mongo. Quand on le dit comme ça, on réalise que c'est la syntaxe JS (objets littéraux) qui est acceptée par l'API JavaScript de Mongo. La syntaxe JSON n'étant quant à elle qu'un sous-ensemble ou une spécification de la syntaxe littérale des objets JS.
victor
J'ai modifié cette partie pour correspondre plus à ta proposition, qui me semble effectivement pertinente (et je viens de voir que j'ai oublié de corriger la coquille >__< ).
=> Vayel, je n'oublie pas tes retours, mais là, je vais dormir
Je me suis mal exprimé. Mes retours sur ces deux chapitres datent d'il y a une ou deux semaines, pas de cette nuit. Relire c'est bien, mais dormir c'est mieux.
Le but étant d'avoir des données qui soient complètement factorisées et agnostiques de l'application (ou des applications) dans lesquelles elles seront utilisées.
Or :
Aussi, tu es certains que le terme « agnostique » s'utilise bien dans un tel contexte ? Parce que, pour ma part, je ne l'ai jamais vu employé qu'en relation avec les questions religieuses. Ce ne serait une importation de l'anglais par hasard ?
Je confirme, c’est un calque de l’anglais agnostic. Il faudrait reformuler « nous allons donc devoir être agnostique du type d’adresse manipulé » en « nous ne devrons donc faire aucune présomption quant au type d’adresses manipulé ».
Je suis pour garder le terme agnostique. Il s'agit simplement d'un nouvel usage bien pratique et suffisamment répandu de ce mot. En anglais comme en français.
Du coup si je dis que le bytecode Java est agnostique de la plateforme sur laquelle il tourne, tu dis ça comment ?
Dans ce contexte, ce qu'un informaticien comprend, c'est que le bytecode ne sait pas, n'a pas besoin de savoir et n'est pas spécifique à la plateforme sur laquelle il tourne.
Si on dit "le bytecode Java ne fait aucune présomption quant à la plateforme sur laquelle il tourne", cela ne veut pas dire qu'il ne tient pas compte de la plateforme, ça veut dire qu'il ne va pas supposer à l'avance que cette plateforme sera X ou Y.
Si on dit "le bytecode Java est ignorant de la plateforme sur laquelle il tourne", ça ne veut pas dire qu'il ne lui est pas spécifique.
L'utilisation "informatique" d'"agnostique" répond à un usage et se trouve désormais dans les dictionnaires d'usage en anglais. Je ne vois pas pourquoi on devrait refuser de lui faire subir le même sort en français.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
) parce que la manière de penser est vraiment complètement inversée par rapport aux BDD relationnelles.
