Volta e meia vemos pela internet alguém falando que open source não dá dinheiro. Quem tem um pouco mais de conhecimento (e vivência) em ambientes desse tipo, sabe que muitas vezes o dinheiro pode não vir diretamente da empresa “guarda-chuva” do projeto, mas através de reconhecimento por se ter participado do desenvolvimento de algum software que é usado por dezenas, centenas ou mesmo milhares de desenvolvedores. E com um pouco mais de dedicação(e expertise), é possível ser contrato pela empresa (e ainda ganhar um bom dinheiro). No Brasil mesmo, temos excelentes exemplos de gente trabalhando para projetos open source full time, como o Fernando Meyer, que trabalha no projeto Jboss Drools contratado pela RedHat e também o Rodrigo Kumpera (ou louds), trabalhando pela Novell no projeto Mono, ambos amigos pessoais. Além deles, com certeza devem existir outros que não conheço.

Pensando nesse pessoal, Jason Allen e Scott Collison criaram um site de relacionamentos para desenvolvedores: o Ohloh. O nome é tão estranho quanto o “primo” famoso, orkut, mas o foco é bem diferente. O Ohloh oferece uma série de recursos para quem participa de projetos open source, como possibilidade de criar “profiles” dos seus projetos e indexar o código fonte, permitindo que os desenvolvedores linkem seu profile aos seus commits no repositório. Também é possível dar um kudo(segundo a definição que está no site: (ku·do) a statement of praise or approval; accolade; compliment.) como forma de demonstrar sua confiança/admiração em algum desenvolvedor. Excenlente oportunidade pra quem colabora em algum projeto mostrar seu trabalho. Quem se cadastrar e tiver curiosidade pode dar uma passada no meu profile lá.

Na mesma linha, nas últimas semanas (ok, fazia meses que não postava), acabei ganhando alguns “pontos de confiança” em alguns projetos. Me tornei commiter (é, versão aportuguezada de quem pode dar commit no repositório), dos projetos Hibernate (e seus subprojetos) e do Vraptor (junto com o pessoal da Caelum) – tanto o Hibernate quanto o VRaptor já estão indexados no Ohloh. Motivo à mais pra gatar um tempo extra codando na frente do micro

Uns meses atrás tive um problema com o uso do Hibernate, em um caso um tanto quanto incomum: o projeto usava Ingres, um banco de dados muito pouco usado, e com algumas particularidades idiotas (sendo gentíl com eles). O tipo responsável por armazenar as datas no Ingres, diferentemente de todos os outros bancos que já vi, aceita três “estados” nas colunas de data: uma data (óbvio), null, ” – sim, uma empty string.

Com isto, eu não poderia usar as classes padrão para datas no Java, acabei criando uma classe Data para tratar desses estados. Como o tipo foi criado por mim, o Hibernate não oferece nada pronto (por razões óbvias), tive que achar uma alternativa.

Lendo um pouco a referência, mais especificamente o capítulo Custom value types, descobri que para esses casos especiais, onde muitos já apelariam para alguma forma menos ortodoxa, o Hibernate oferece um mecanismo muito poderoso : os UserTypes.

Um UserType é basicamente uma interface que permite a implementação de como um determinado tipo será recuperado e persistido no seu banco de dados. Este recurso é extremamente útil e me salvou graciosamente.

E porque estou escrevendo isso tudo? Recebi hoje uma dúvida bem interessante por mensagem privada no GUJ. O usuário perguntava se haveria possibilidade de usar Hibernate em conjunto com o banco PostGIS – focado em armazenar dados geométricos.

O principal desafio é como mapear os dados que são armazenados em Geometry, como são chamados os tipos geométricos no PostGIS. Como não existe nenhum tipo nativo do Java que seria correspondente (e nem a especificação do JDBC preve isso – tipos clob, lobs e variantes não contam!), o trabalho pode ser um pouco mais complicado que se imagina.

Dando uma pesquisada, acabei encontrado uma thread da lista de users do PostGIS que trata exatamente disso. Nela é apresentada uma solução elegante para o tratamento dos tipos no Hibernate – e que acabou virando parte do projeto. SpatialEJB3 nada mais é que um UserType (GeometryType no caso) com a implementação responsável por tratar o tipo Geometry. Ele pode ser usadao tanto com Hibernate puro, quanto para EJB3. Só achei estranho que as classes ainda não estão no postgis.jar.

Para usar o recurso, fica extremamente simples:

@Type(type = "org.postgis.hibernate.GeometryType")
public Geometry getLocation(){
return location;
}

No site é possível encontrar a documentação do projeto.

Por mais vasta que a documentação do Hibernate seja, sempre ficam pontos da API que precisam de melhorias na documentação. Um exemplo claro disso é esclarecer qual a diferença entre dois métodos da Session, o save() e o persist(). Ambos tem a mesma função: tornar uma instância transient em persistent. Segundo a doc da API:

• persist() – Make a transient instance persistent.
• save() – Persist the given transient instance, first assigning a generated identifier.

O método persist(), não garante que será atribuito um id à instância imediatamente, sendo que a associação ocorrerá quando o flush ocorrer. Além disso, ele garante que só irá executar um insert se estiver dentro do contexto de uma transaction. Já o save(), atribui a chave imediatamente, não importando se isso exige um insert (no caso do identity generator) ou se existe um contexto de transação. Isso explica também porque o save() retorna o Id gerado e o persist() é void.

Mais informações podem ser encontradas no Jira e no fórum do Hibernate.

update: não é somente eu que acha que a documentação precisa de melhorias nesse caso: HHH-1682

update 2: acabei de comitar a alteração na documentação, para a próxima versão do Hibernate (3.2.5), a seção Making objects persistent irá trazer informações mais detalhadas sobre a diferença entre os dois métodos.