Scala no Divã (CouchDB)

Muito se tem falado em bases de dados não relacionas. Então, desde que comecei a ler sobre o Dynamo da Amazon e o Big Table do Google me interessei pelo tema.

De fato, uma Base de Dados Relacional não é a bala de prata da persistência de dados. Existem muitas situações onde uma abordagem livre de schema, orientada a documentos ou chave-valor é mais conveniente.

A verdade é que ultimamente eu e muitos amigos discutimos bastante sobre o por quê de certas coisas dentro da tecnologia de desenvolvimento de software, e uma delas é a “obrigatoriedade” de persistir dados no que se tornou padrão pra aplicações corporativas: Bases de Dados Relacionais. Existem outros questionamentos sobre a natureza estatica da web e a escravidão que nos sujeitamos ao usar certas tecnologias. Mas isso é outro tema.

O post de Dion Hinchcliffe foi o que faltava motivação para estudar uma base não-relacional. A escolhida foi o Apache CouchDB, depois que Ted Neward opinou sobre o Book of JOSH, que compartilhei no meu Reader esta semana. Ted sugeriu o Couch como mecanismo de persistência na pilha Json Osgi Scala e Http.

O CouchDB é orientado a documentos expressos no formato JSON, e o mais interessante é que ele é acessado via HTTP por uma API REST. A princípio também soou estranho pra mim.

O CouchDB conta com algumas libs (construídas por terceiros) que evitam invocações HTTP “manualmente” para diversas linguagens. Dentre as linguagens encontramos Java, Ruby, PHP, Erlang, e até Javascript. Que tal persistir direto do seus formulário HTML usando Javascript? Não vejo mal algum. Alias, as receita de bolo 3 e 4 camadas para a construção de aplicações tendem a se tronar mais raras com o fortalecimento do SOA, das próprias bases de dados não-relacionais dentre outros fatores. Veja o post do Dion.

Instalei o Couch no meu Ubuntu 8.04 com sucesso seguindo este passo-a-passo (observe um comentário no final do post, é o que faz funcionar corretamente) e comecei a brincar usando CouchDB4J e o Futon, uma especie de console Web muito legal.

Obviamente iniciei meus teste com um objeto Person de todos os meus posts :). Que em JSON vira:

{"_id":"4b32206602c372304530a69813a7a0ae","_rev":"741003815","name":"Paulo","age":"26","type":"Person"}

O Couch não possui tabelas, ou seja, todos os documentos são tratados igualmente, por isso adicionei uma propriedade type pra facilitar a criação de Views no Couch. O _id foi fornecido pelo próprio Couch, nos livrando da preocupação de um identificador único, _rev é a revisão do documento, que se alterado ganha um novo valor neste campo junto com as alterações. As revisões permitem enchergarmos um mesmo documento em pontos distintos no tempo.

As Views são o recurso mais interessante do Couch, e permitem a aplicação de funções Map/Reduce nos documentos. O que isso quer dizer? Quer dizer que é possível construir consultas e relatórios com os documentos e até mesmo junções. Views são armazenadas em documentos, que devem possuir no seu identificador o valor _design/ como prefixo . As Views são então armazenadas no campo views deste documento.

Aqui um documento que define três Views de exemplo:

{"_id":"_design\/pview",
 "_rev":"713212252",
 "views":{
       "by-name":{
           "map":"function(doc) { if (doc.type == 'Person') emit(doc.name, null) }"},
       "by-age":{
           "map":"function(doc) { if (doc.type == 'Person') emit(doc.age, null) }"},
       "teens":{
           "map":"function(doc) { if (doc.type == 'Person' && doc.age <= 18) emit (doc.name, null) }"}
  },
 "language":"javascript"}

As views foram escritas em Javascript, mas podem ser escritas em Ruby e Erlang também. Ao acessar http://localhost:5984/mydb/_view/pview/teens, que retorna o nome dos documentos de type Person menores de 18 anos, o resultado é:

{"total_rows":1,"offset":0,"rows":[
{"id":"1f8630284bbe5912a32990908933f00b","key":"Gabriel","value":null}
]}

Bem, a intenção do post não é mesmo fazer uma mega introdução, nem um tutorial sobre o CouchDB, mas sim  anunciar que a partir de agora você não vai encontrar apenas posts sobre Scala, mas também sobre essa maravilha criada por Damien Katz

Como pontapé inicial, comecei a escrever uma pequena lib pra facilitar o mapeamento de um objeto em scala
para documentos JSON, para então fazer comunicação com o Couch. Você pode dizer, por que não usar o
CouchDB4J? A princípio para que Scala possua um lib para este fim construída em Scala.

Aqui vai uma prévia. Mas comecei a escrever de uma forma desordenada e sem muito planejamento e devo recomeçar.
Os primeiros testes já funcionam, mas não achei muito bonito:

class JSONPerson(n: String, a : Int) extends Person(n, a) with JSONifier {

  property("name"){
    mapsTo (name) (name = _)}

  property("age") {
    mapsTo (age.toString)( (n) => age = Integer.parseInt(n))
  }

  metaProperty("type", "Person")

}

Lembrando que Person possui apenas dois atributos (name, age), a propriedade type se comporta como uma meta-propriedade que ajuda na hora das Views. Ou seja, a função property recebe a chave da propriedade e  um objeto que deve conhecer como ler  e gravar a propriedade, respectivamente. Pra isso a função mapsTo foi usada pra gerar este objeto, recebendo como parâmetro as duas funções de leitura/escrita.

Para gerar um Document (do CouchDB4J) basta usar a função json da trait  JSONifier e então usar o CouchDB4J (por enquanto) para salvar o documento. É um misto de DSL que permite mapear Objetcts2JSON/JSON2Object em Scala com a criação de uma lib para se comunicar com o Couch. De repente não vai ser necessário criar uma forma de mapear os objetos pra JSON, e sim uma forma mais conveniente de usar o proprio XStream, ou o JSON-lib.

É isso. Estou avaliando a viabilidade disso e o quanto vale a pena fazer tal coisa, enquanto isso aguarde mais coisas sobre CouchDB e Scala, e claro, relaxe.