Dans deux articles précédents, nous avons vu une introduction à CouchDB et l’utilisation de CouchDB avec Ruby.
Nous sommes donc maintenant capable d’ajouter des données dans notre base et de récupérer une liste de ceux-ci. Mais il peut parfois arriver d’avoir besoin de faire des requêtes plus complexes.
Prenons par exemple une table CouchDB générée par CouchREST. Vous y verrez, pour chacun de vos modèles, un document nommé « _design/Model ». Par exemple, « _design/File ».
Il ne s’agit en réalité par d’un document. Mais d’une vue.
Regardons l’une des vues générées par CouchREST.
{
"all": {
"map": "function(doc) {
if (doc['couchrest-type'] == 'Image') {
emit(doc['_id'],1);
}
}"
}
}
Vous lisez bien, les vues CouchDB sont du javascript ! 
Après avoir chargé cette vue, tentez de visiter la page votre_base/_design/votre_vue/_view/all.
Vous constaterez que seuls les éléments de type « Image » sont retournés.
Notre fonction javascript est exécutée sur chacun des éléments. Et seuls ceux que vous désirez (en les insérant avec « emit ») sont retournés.
Prenons le cas d’une plateforme de blog (oui cas bidon).
Supposons que nous désirions visualiser uniquement les documents ayant l’attribut « published » à true.
{
"all": {
"map": "function(doc) {
if (doc['published'] == true) {
emit(doc['_id'], doc);
}
}"
}
}
De la même manière que tout à l’heure, nous ne retournons que les billets publiés dans notre blog.
Voici ainsi le contenu qui m’est retourné pour la vue précédente
{
"total_rows":2,
"offset":0,
"rows":[
{
"id":"7c46156162a59d145cf9cf7850e6b677",
"key":"7c46156162a59d145cf9cf7850e6b677",
"value":{
"_id":"7c46156162a59d145cf9cf7850e6b677",
"_rev":"5-f726b6d7f469b686079fbe4c5f50726b",
"title":"My First Blog Post",
"content":"My Post Content",
"published":true,
"comments":[
{"author":"John","content":"First Comment"},
{"author":"James","content":"Second Comment"}
]
}
},
{
"id":"f14fde843b20e18561ea5e8055dbc3b3",
"key":"f14fde843b20e18561ea5e8055dbc3b3",
"value":{
"_id":"f14fde843b20e18561ea5e8055dbc3b3",
"_rev":"1-5eef22da217f5858542d175c41d2ef3d",
"title":"My Second Post",
"content":"Second Content",
"published":true
}
}
]
}
Vous constatez que j’ai inséré plusieurs commentaires sur l’un de mes billets. Il ne s’agit pas de documents différents mais bien du même document.
L’attribut « comments » est un tableau de commentaires, chacun pouvant contenir les éléments que je désire.
Et la, la problématique à laquelle on pense rapidement, c’est : « Mais comment je fais pour récupérer la liste de tous mes documents ? »
Comme précédemment, avec une vue bien évidemment !
{
"all": {
"map": "function(doc) {
for (var i in doc.comments) {
emit(doc, doc.comments[i]);
}
}"
}
}
Nous parcourons chacun de nos documents. Puis dans chacun de ceux-ci, nous parcourons tous les commentaires.
Et insérons au resultat tous les commentaires.
Le résultat obtenu est le suivant.
{
"total_rows":2,
"offset":0,
"rows":[
{
"id":"7c46156162a59d145cf9cf7850e6b677",
"key":"My First Blog Post",
"value":{
"author":"James",
"content":"Second Comment"
}
},
{
"id":"7c46156162a59d145cf9cf7850e6b677",
"key":"My First Blog Post",
"value":{
"author":"John",
"content":"First Comment"
}
}
]
}
Nous avons bien la liste de tous nos commentaires. Et (vu que nous l’avons ajoutés au résultat), nous avons même le titre billet qui va avec !
Et les performances dans tout ça ?
Comme c’est de l’HTTP, il y a du cache natif, que CouchDB gère parfaitement bien. Si vous chargez plusieurs fois votre vue, vous verrez donc que la page retournée est bien un 304 not modified.
Je n’ai pas testé avec énormément d’enregistrements. Mais j’ai discuté de cela avec Mirsal lundi soir lors de l’apéro Web Event Lyon. Et apparemment, même avec des milliers de billets, la chose ne posera pas trop de problèmes.
Je reviendrai là-dessus dans quelques mois si il y a matière à en dire quelque chose 
Quoi qu’il en soit, je trouve les vues particulièrement intéressantes. Je me retrouve régulièrement frustré par les limitations de SQL.
En développant celles-ci en Javascript, la chose devient virtuellement illimitée.
Mirsal disait également hier: « Les bases de données orientées document sont généralement ce qu’il y a de plus adapté.
C’est SQL qui devrait être utilisé uniquement dans des cas atypiques. »
Je n’irai pas jusqu’à m’avancer comme cela. Mais les possibilités sont tellement impressionnantes que cela laisse rêveur.
