Caindo do Divã (CouchDB)

No último Post, confesso que estava bem extasiado com o CouchDB. Acho que deu pra perceber. Então veio a brilhante ideia:

Vou fazer algo pra mapear JSON – Objetos – JSON em Scala e junto com isso, fazer uma forma mais transparente de interagir com o Couch.

Acontece é que eu e umas 8 mil pessoas tivemos esta mesma idéia, claro.

Antes de constatar que outros estavam fazendo o mesmo, e enquanto tentava construir algo, me veio uma questão:

Is CouchDB best suited for dynamic languages?

Na verdade eu deveria ter perguntado: Are dynamic languages best suited for CouchDB? Enfim… de qualquer forma me entenderam e tive o prazer de receber a resposta do Jorge Ortiz, que fez uma grande contribuição pra nós Scaladores. esta semana. Ortiz criou um conjunto de classes e funções utilitárias para tornar a programação Java/Scala ainda mais  fácil.

Em sua resposta, Ortiz  dizia não só que linguagens estaticamente tipadas – como Scala – são perfeitamente candidatas a trabalhar como um banco de dados schema-free, mas também me mostrou alguns materiais.  Lá, estava  o blog do @n8han, o Coderspiel, onde n8han (criador do Wichet Databinder) mostra sua habilidade com Scala, CouchDB, Twitter API, além de fazer exatamente o que eu tinha proclamado fazer no meu post anterior.

Nathan (n8han), criou uma pequena API chamada Dispatch que facilita iterações sobre Http, agindo como um Wrapper para o Apache HttpClient, facilita a iteração com o CouchDB, e de maneira inusitada e muito interessante, utiliza Symbols e Extractors em Scala para fazer o mapeamento JSON – Objeto – JSON. Breve postarei uns exemplos utilizando Couch + Scala + o Dispatch.

Um ponto negativo da API do @n8han é que ele até agora forneceu pouco, ou quase nenhum exemplo prático/real de como usar sua API. E como ele construiu tudo utilizando recursos como Extractors e muito Pattern Matching em Scala, deu um grande trabalho pra entender como as coisas funcionavam, pois as funções implementadas por ele quase nunca declaram o tipo de dados retornado. Daí o trabalho de ler e tentar entender o código das funções pra detectar que tipo de objeto ela pode retornar. Se não fosse pelo eclipse, eu estaria até agora tentando entender.

Ainda assim, o Dispatch do n8han me permitiu bons momentos de diversão com o SBT (Simples Build Tool) e com o GIT. Depois pretendo falar sobre isso.

Outros caras como o @frank06 e Debasish Ghosh também estão engajados em temas desse tipo, e aqui você pode ver uma palavrinha dos dois neste post – super atual, por sinal – do Alexander Lag.

Alexander até  postou no Slideshade, sua apresentação no  Scotland on Rails, onde ele mostrou alguns frameworks em Ruby para trabalhar com o CouchDB. E para me desanimar de vez, ele não mostrou um, mas meia-dúzia de frameworks pra Ruby com objetivo de facilitar mapeamento JSON – Objeto – JSON e interagir com o CouchDB. Ou seja, por que estou gastando meu tempo tentando fazer algo assim? Se gastar, terei que fazer algo muito melhor e revolucionário.

Dos frameworks mostrados, o Active Couch realmente me surpreendeu, e vai surpreender muita gente que trabalha com Ruby on Rails, permitindo um modelo de dados mais uniforme entre objetos persistidos em uma base relacional e no Couch. De certa forma foi bom pra dar umas boas ideias.

Mas foi aí que o Debasish Ghosh entrou no circuito, complementando o que o Alex Lang vem pregando.
Debasish falou sobre Convenience over Correctness. A prerrogativa é que o Active Couch fornece uma forma tão semelhante de trabalhar com mapeamento de dados em relação ao Active Record que, pra Debasish, programar assim é usar a conveniência. A conveniência do programador conviver com o Framework de estimação sempre.

Debasish fala ainda que consequencia disso é a inércia que o uso de frameworks nos traz, nos deixando comodamente casados com ele (o framework), tal que nos colocamos cegos diante de novos paradigmas e abordagens que fazem o nosso bom e velho parceiro/framework de estimação parecer irrelevante.

Debasish se pronunciou, e com muita propriedade no que disse, pois o Active Couch tenta colocar no uso do CouchDB algo que ele não é: relação entre registros de entidades/tabelas diferentes como se os dados tivesse sido armazenados numa base relacional. Por isso a conveniência do Active Record e a forma “não correta” de tabalhar com o CouchDB, que é schema-free por natureza.

Debasish cita o CouchRest, que permite construções utilizando a mesma semântica do CouchDB: Views com funções do tipo Map-Reduce, e não operações find, find-by para iteragir com os documentos do Couch. Esta sim é uma forma que me inspirou, talvez um port pra Scala seja uma boa saída.

Aproveitando a visão do Debasish sobre deixar a conveniência de lado e procurar a “corretude”, eu penso que trabalhar de forma mais livre com objetos de domínio no CouchDB (em Scala) talvez seja uma alternativa a se considerar. Forma mais livre pode significar não ter propriedade statica alguma no objeto em tempo de desenvolvimento, e sempre obtê-las com um:

get[T]("propertyName")
//ou ainda:
with[T]('propertyName) { //doSomething }
//E mais além, onde m seria um map,
//ou objeto json detentor dos valores:
 def -:[T](s: Symbol)(op: T => Unit) = { op(m(s).asInstanceOf[T])}
// o uso poderia ser:
-:[Int]('age){ n => println("the age is " + n )}
//the age is 26
//Mas ainda dá pra fazer melhor
//se extendermos o Dispatch.
//Estou trabalhando em exemplos com o Dispatch.

Exato, pode soar como um grande Map, ou com o Delphi, mas sem ser exatamente um Map, tão pouco programar em Delphi.

É isso! Este post é como um resumo do que tenho lido, pensado e discutindo com pessoas ao redor do mundo.

Para complementar, tenho analisado com um amigo sobre a possibilidade do uso do CouchDB ou o MongoDB para armazenar logs/auditoria na empresa em que ele trabalha. Outra base não relacional na mira é o Voldemort.

Este final de semana não postei nada por ter utilizado ele pra estudar Erlang e recrusos avançados de Pattern Matching em Scala.

Vamos vendo o que acontece daqui pra frente.