Bruno Pereira

A documentação do Ibatis não explica adequadamente como funciona o mecanismo de Lazy Load do framework, e como este conhecimento é importante e útil, resolvi explicar brevemente por aqui.

Para habilitar o mecanismo de lazy load, é necessário declarar o elemento settings no sql-map-config, como o exemplo a seguir:

<sqlMapConfig>
	<settings
		cacheModelsEnabled="true"
		enhancementEnabled="true"
		lazyLoadingEnabled="true"
		maxRequests="128"
		maxSessions="10"
		maxTransactions="5"
		useStatementNamespaces="false"
		defaultStatementTimeout="5"	/>
</sqlMapConfig>

Nestas configurações, dois elementos são importantes. O parâmetro lazyLoadingEnabled habilita globalmente o uso de lazy loading no framework. Sem declarar esse parâmetro, todas as buscas serão eager, possivelmente gerando uma grande quantidade de acessos ao banco, dependendo da estrutura de classes.

O outro parâmetro importante é o enhancementEnabled. Com ele habilitado, o Ibatis usa proxies cglib no mecanismo de carregamento das classes, e ele aumenta o escopo do carregamento lazy.

Com o enhancement desligado, serão carregadas de forma lazy apenas as coleções de um objeto, como a lista de produtos de um pedido. Com o enhancement ligado, é feito também o carregamento lazy de atributos complexos de um objeto, como o endereço de entrega do pedido.

Este mecanismo é bem simples de utilizar, e ajuda bastante, pois não precisamos tratar disso no código da aplicação.

Bom, certamente o que eu estou falando não é nenhuma novidade, e nem fui eu que descobri isso ou falei isso pela primeira vez. Entretanto, devido à quantidade de vezes que eu já vi a utilização de atributos de classes para representar chaves estrangeiras (Foreign Keys - FKs), quis comentar isso por aqui para dar meus palpites.

Chaves estrangeiras são componentes importantes de um bom modelo de banco de dados. Elas são muito úteis no controle da integridade referencial e também são usadas com freqüência para indexar tabelas. Porém, não devemos nos esquecer que elas fazem parte do modelo relacional de dados, e não existem em um modelo orientado a objetos.

Esse assunto me veio à cabeça essa semana, quando eu estava analisando algumas coisas na JPetStore, a aplicação de exemplo do Ibatis, e que possui algumas das famigeradas chaves estrangeiras no modelo de domínio. Bom, se até projetos da Apache fazem isso, não me surpreende a quantidade de aplicações que já vi com uma porção de atributos long qualquerClasseReferenciadaId.

Pois bem, eu me lembrava de ter visto essa aplicação Pet Store em mais algum lugar além do Ibatis. Após uma breve pesquisa, encontrei de novo a aplicação da lojinha de bichinhos feita em Java, no catálogo de Blue Prints Java EE 5.

Claro que imediatamente baixei a aplicação e fui olhar as classes de domínio. Tamanha foi a minha surpresa ao constatar que também nesta implementação existem vários exemplos de atributos representando FKs. Na classe Product há um belo String categoryId. Na classe Item há um belo String productId. Achei curioso que nesta mesma classe Item há um atributo SellerContactInfo, que é uma outra classe de domínio, com atributos coerentes. Eles podiam ter colocado um atributo String contactInfoID, mas em vez disso colocaram a classe efetivamente. Ou seja, dentro de uma mesma classe há políticas diferentes de uso das FKs.

Me deixou um tanto desapontado ver isso num catálogo de Blue Prints (boas práticas). Provavelmente muita gente toma esses Blue Prints como referência de implementação, então isso me esclareceu um dos motivos pelos quais as FKs estão tão difundidas em modelos de domínio por aí.

Eu estou ainda com 2 vouchers da Sun que pretendo usar na certificação SCEA. Quando eu comprei esses vouchers eu achei que fosse usá-los na certificação de EJB 3 e na de Web Services, porém não estou animado para fazer nenhuma das 2, então me decidi pela prova de arquiteto.

Dentro do conteúdo da certificação de arquiteto está esse tipo de coisa dos Blue Prints, catálogos de padrões de projeto, entre outras coisas. Isso me lembrou mais uma vez que temos sempre que ler as coisas com olhar bastante crítico, para julgar de fato o que podemos aproveitar e o que temos que descartar.

It’s worth saying that these Blue Prints are looking more like Brown Prints, and some annoying smell is coming from them…

Algum tempo atrás o Fabiano me perguntou qual implementação de persistência em Java eu julgava a melhor opção. Na época conversamos um pouco sobre isso e eu estava para escrever sobre o assunto faz tempo.

Essa semana falei novamente sobre o assunto numa thread do CEJUG e então vou finalmente expôr algumas opiniões por aqui.

Provavelmente a implementação de persistência que está mais “na moda” atualmente é a Java Persistence Architecture (JPA) ou frameworks independentes com a mesma proposta, como o Hibernate e o Toplink. Realmente a proposta desta tecnologia é excelente. Quem programa usando orientação a objetos de verdade sempre prefere manipular classes de domínio ricas, e não gosta muito de lidar com as diferenças de paradigma que existem entre este modelo e o modelo relacional de bancos de dados.

A JPA aparentemente é bem fácil de usar, colocando anotações para mapear as classes e atributos em tabelas e colunas do banco de dados e colocando algumas anotações para declarar os relacionamentos entre as entidades. O problema que eu vejo é que as anotações de JPA são um tanto confusas. Em algumas situações você vê uma quantidade razoável de opções, e não fica tão óbvia a forma que você tem que usar as anotações.

Além disso, o esforço de analisar o comportamento da JPA é muitas vezes considerável. Você não escreve as queries, mas precisa acompanhar muito bem as queries que estão sendo geradas, se está sendo feito JOIN ou múltiplas queries, etc. Esse tipo de coisa a JPA abstrai da gente, mas muitas vezes os comportamentos não são triviais, e o esforço de monitorar isso não é desprezível. Uma anotação mal colocada pode te trazer problemas graves de performance e alguns dias de análise para otimização.

Eu gosto bastante da idéia de frameworks de mapeamento objeto-relacional. Quem trabalha verdadeiramente com orientação a objetos sempre quer ter a comodidade de usar este paradigma na aplicação toda. Entretanto, essas opções que temos em Java são complexas e muitas vezes não trazem ganhos de produtividade comparando com alternativas como o Ibatis por exemplo.

A parte mais chata da persistência em Java é escrever o código JDBC de gravação de objetos no BD e recuperação dos mesmos. Aqueles tratamentos altamente repetitivos e trabalhosos de conversão de colunas do BD de diferentes tipos para seus atributos das classes. Eu odeio escrever esse tipo de código, e o Ibatis ajuda demais nesse sentido, sem introduzir complexidade.

Uma coisa positiva que eu vejo no Ibatis é que ele é bem simples de usar e muito óbvio e previsível. Você manipula as coisas com o paradigma relacional, que embora tenha seus defeitos é amplamente conhecido de todo mundo e fácil de manipular. Usamos a DSL que é provavelmente a mais bem-sucedida até hoje (SQL).

A implementação de mapeamento objeto-relacional do Django (framework Python) por exemplo é excepcional, extremamente inteligente e produtiva. Muito dificilmente trocaria ela pelo Ibatis (assumindo que trocar fosse uma opção). Mas já há algum tempo eu estou desiludido com a JPA e vejo o Ibatis como uma opção com melhor custo-benefício.

Em situações em que o time todo domina plenamente JPA e já têm uma boa experiência com a mesma, é possível que o time ganhe um pouco de produtividade ao usá-la. Entretanto, em muitas situações o custo-benefício pode ser pior do que usar o Ibatis.

Já presenciei alguns casos em que a adoção de JPA em diferentes equipes prejudicou mais do que ajudou.  Os principais motivos para isso foram:

• Falta de experiência geral do time com a tecnologia
• Modelos legados de BD que não permitem um mapeamento de classes tão interessante
• Grande esforço de tunning

Eu e outros profissionais que eu respeito muito já passamos por esse tipo de situação, em que acabou prevalecendo o pragmatismo e a visão do que é valor para o negócio.

Eu li uma entrevista com o Carlos Ghosn (o brasileiro presidente da Renault e Nissan) na qual ele falou que a Nissan passou a ter bons resultados quando os engenheiros pararam de colocar ítens que eles achavam “bonitos” nos projetos, mas que os usuários nem percebiam. O argumento era mais ou menos esse: o usuário quer que o carro funcione bem, não importa para ele se o revestimento do motor vai ser de adamantium e resistente a criptonita

Decisões técnicas devem ser tomadas com foco no valor de negócio, em vez de focar na tecnologia que ficará mais bonita no currículo. Não esqueçam do exemplo do Carlos Ghosn

Hoje foi anunciado que a HP está comprando a EDS. O valor divulgado da compra é de US$ 13.9 bi.

Li algumas notícias dizendo que este movimento da HP tem como objetivo fortalecer a empresa para competir com a IBM. Entretanto, tenho sérias dúvidas se isso terá sucesso. A HP tem muita força na venda de equipamentos, e também presta serviços de manutenção de infra-estrutura. Já a EDS é uma gigante na prestação de serviços de software, tanto na área de manutenção de infra-estrutura como no outsourcing de aplicações, e consultoria de uma maneira geral. Como algumas áreas das empresas claramente se sobrepõem, imagino que muitos empregos serão cortados.

A HP passará a ter uma estrutura gigantesca, mas ainda ficará atrás da IBM em termos de faturamento. Além disso, embora fortaleça a empresa na disputa com a IBM, não fortalece tanto. A IBM tem uma área enorme de produtos de software que a HP continuará não tendo. Será muito difícil para a HP ganhar espaço contra a IBM sem um braço de software forte. Principalmente na área de middleware, onde a IBM está muito forte. E além da IBM, a HP teria que brigar também contra a Oracle neste nicho, depois que ela comprou a BEA.

É bom lembrarmos que a HP não tem lá um bom histórico em compras. A aquisição da Compaq foi bem traumática e não teve custo-beneficio muito bom para a HP. O mercado americano também não reagiu bem a essa compra da EDS. As ações de ambas as empresas caíram razoavelmente, mostrando que a maioria das pessoas do mercado não achou este negócio uma boa idéia para as empresas.

Na minha opinião, a HP após esta compra ainda é uma empresa incompleta para competir com a IBM, Oracle e Sun. Antes dessa compra a HP não era tida como concorrente direta dessas empresas, mas agora ela é. Penso que para a HP ter realmente relevância nessa disputa, ela precisará de um braço forte de middleware, e uma boa pilha de software em geral.

Com o histórico que a empresa tem, duvido que ela se transforme nisso por conta própria. Na minha visão o que faz sentido é a HP comprar mais alguma(s) empresa(s), para conseguir complementar suas ofertas de serviços. Considerando a consolidação atual do mercado, acho que faria sentido que a HP comprasse a Red Hat, levando o JBoss de lambuja. Além disso seria interessante que eles contassem com algum servidor de BD na pilha, já que os concorrentes possuem isso (DB2, Oracle e MySql). Uma ótima opção seria comprar a EnterpriseDB, que oferece uma versão comercial do Postgres, o excepcional BD open source.

De todas as grandes aquisições que rolaram recentemente, esta da HP é a que menos faz sentido, pelo menos atualmente. Dependendo das ações que eles tomarem em seguida, esta compra pode ser uma boa jogada ou um episódio lamentável como a compra da Compaq. Torço para que a HP aumente seus já fortes vínculos com Linux e Open Source e compre a Red Hat para se apresentar firmemente como competidora de peso. E claro, continuo torcendo pelo sucesso do meu estimado Postgres

Ontem fui no Tech Talk de MySql aqui na Globo.com, que me trouxe algumas idéias interessantes e também fomentou algumas discussões. Não vou falar muito sobre o tech talk especificamente, mas sobre uma discussão paralela.

Algumas pessoas sabem da minha preferência pelo Postgres sobre o MySql. Durante a apresentação ontem o Rafael me perguntou porque tanta gente utiliza o MySql e nem tanta gente usa o Postgres. Ele me perguntou isso porque usa o Postgres em alguns projetos e não viu vantagens em utilizar o MySql em vez do Postgres.

Bom, a resposta pra isso na minha opinião vem da diferença de estratégia. Banco por banco, sou mais o Postgres, embora eu considere que em boa parte dos casos, qualquer banco atende aos requisitos. Mas porque então o MySql ganhou bem mais adoção do que o Postgres?

Na minha opinião, o fator principal que levou a isso é que o MySql já há muito tempo oferece instalador nativo para o Windows. O MySql foi lançado em 1996 e começou com suporte apenas a Linux, mas desde 1998 permite instalação nativa no Windows. O Postgres começou como um projeto acadêmico em 1986, mas em 1996 se tornou um projeto open source com participação da comunidade de software livre. Podemos ver que nesta vertente atual de desenvolvimento, ambos estão disponíveis desde 1996. Enquanto o MySql suporta nativamente o Windows desde 1998, no Postgres isso só foi ocorrer em Janeiro de 2005, com o lançamento da versão 8.0. Anteriormente o Postgres só podia ser instalado no Windows com uso do Cygwin, que está longe de ser algo prático.

Considerando os recursos que ambos os bancos ofereceram ao longo de sua história, não restam dúvidas de que o Postgres é historicamente superior tecnicamente, e na minha opinião continua sendo. Entretanto, com a enorme quantidade de desenvolvedores que só utilizavam Windows (what a shame!), o fato de poder rodar o banco de dados na mesma máquina de desenvolvimento tornou o MySql muito mais conveniente para quem precisava de um banco de dados gratuito para suas aplicações.

Quando o Postgres lançou a versão 8.0 em Janeiro de 2005, muitos desenvolvedores já utilizavam o MySql há anos, e com isso sua adoção já estava bem grande. Neste ponto podemos ver claramente a diferença que fez uma estratégia correta. O fato de ser limitado tecnicamente em comparação com o Postgres não impactou o sucesso do MySql, porque durante muitos anos ele foi simplesmente muito mais conveniente para o desenvolvedor.

Atualmente, só vejo chances do Postgres aumentar seu sucesso se for comprado por alguma grande empresa e colocado em uma pilha de produtos interessante. Eu gosto muito do banco, e nos meus projetos pessoais ele é minha opção default. Entretanto, temo que ele nunca saia da sua abrangência atual, pelos erros na estratégia. É uma pena, devido à qualidade do projeto. Mas é muito difícil qualquer mérito técnico sobreviver a uma estratégia perdedora.

Essa semana fiquei sabendo pelo blog do Savio Rodrigues que a IBM investiu US$ 10 milhões no EnterpriseDB, uma derivação comercial do Postgresql, mas cujos desenvolvedores atuam no desenvolvimento do produto open source também.

Com isso, até o momento o EnterpriseDB já recebeu no total US$ 37,5 mi, o que é bem próximo dos US$ 39 mi que o MySql havia recebido antes de ser comprado pela Sun. Torço para que isso ajude bastante no desenvolvimento do banco de dados e que eles consigam trazer ainda mais qualidade aos seus produtos. O Postgresql é um banco open source muito maduro e confiável já há muitos anos e o EnterpriseDB adiciona recursos interessantes para grandes empresas. Entre as principais forças do EnterpriseDB está a sua garantia de compatibilidade com código feito para o Oracle. Eles garantem por contrato que a sintaxe SQL, tipos de dados, packages, stored procedures, trigger e views desenvolvidas para o Oracle irão funcionar conforme esperado no EnterpriseDB. Isto sem dúvida é um facilitador para empresas que possuam grandes bases Oracle e queiram progressivamente migrar seus bancos de dados.

Eu usei pela primeira vez o Postgresql no começo de 2003, e sempre o considerei melhor que o Mysql. A principal razão pela qual o Postgres perdeu espaço para o MySql foi o fato de que o Postgres não tinha um instalador nativo para Windows antes da versão 8.0, que saiu em janeiro de 2005. O MySql tinha muito menos funcionalidades e confiabilidade, mas como era fácil utilizá-lo no Windows, sua adoção aumentou rapidamente.

Eu ainda considero o Postgres melhor do que o MySql e ele é o meu banco de dados preferido quando eu tenho a liberdade de escolher. Espero que eles continuem desenvolvendo bastante o produto e recebam mais investimentos. Eles merecem um ótimo lugar no mercado de bancos de dados, e torço para que eles consigam tanto ou mais sucesso que o MySql.

Aproveitando esta discussão, algo que me veio à cabeça diz respeito à consolidação das pilhas de produtos no mercado. Será que faria sentido que a Red Hat comprasse o EnterpriseDB e a Oracle comprasse uma distribuição Linux?

A Sun atualmente possui a pilha completa, indo do sistema operacional até o middleware Java, e inclui um banco de dados (MySql). A IBM não vende mais sistemas operacionais próprios (até onde sei), mas suporta bastante o Linux e tem seu banco de dados e o middleware Java EE.

A Oracle tem tudo menos o sistema operacional, especialmente depois da compra da BEA. A Red Hat tem tudo menos o banco de dados. Ambas fizeram compras significativas no passado. Será que veremos as 2 empresas completando sua pilha de produtos em breve?

Isto é algo que eu gostaria de saber, e seria bem interessante ver como o mercado se comportaria depois de tais movimentos.

Nos últimos meses trabalhei em uma boa diversidade de projetos, no trabalho, em projetos pessoais e artigos. Sem motivo nenhum especial, lidei nestes projetos com uma boa variedade de servidores de bancos de dados.

A maioria das coisas que faço no trabalho envolvem o Oracle, mas nos projetos pessoais utilizei o SQL Server, Postgresql, MySql e o Derby. 5 produtos diferentes, cada um com suas particularidades. Este convívio com diferentes bancos de dados me permitiu uma boa análise do momento em que já estamos em relação ao uso dos mesmos.

Na prática, basicamente o que mudava para mim de um BD para o outro era saber qual ferramenta de administração que eu deveria utilizar e qual driver jdbc precisaria baixar. Nos casos em que a camada de persistência era com jdbc diretamente (em vez de mapeamento objeto-relacional), eu precisava também prestar um pouco de atenção com pequenas diferenças na sintaxe SQL de cada um.

Algo que me chamou a atenção quando parei para pensar sobre isso foi que para a maioria dos projetos, qualquer servidor de banco de dados que eu utilizasse me atenderia sem problemas. Em termos de funcionalidades, o que eu preciso em um banco de dados não é nada sofisticado. Eu gosto de tratar do SGBD como um repositório confiável e eficiente para persistência de dados. Prefiro deixar toda a inteligência da aplicação fora do BD. O que eu espero de um bom servidor de BD é que ele mantenha os dados íntegros, ofereça recursos de restrições de integridade, índices, sub-queries e mais algumas funcionalidades nada extraordinárias.

Como falei, não gosto de colocar inteligência no banco de dados, então descarto o uso de stored procedures, triggers e coisas do gênero sempre que possível. A maioria dos SGBDs atuais suporta todos estes recursos que mencionei. Para a maioria das aplicações que desenvolvemos, o Oracle, Sql Server, DB2, Postgres ou MySql sem dúvida servem tranqüilamente. O conjunto de aplicações que tem acessos suficientes para derrubar qualquer um destes servidores é muito pequeno. Se na maioria dos casos qualquer SGBD serve, será que já podemos considerar os bancos de dados como commodities?

É claro que existem aplicações nas quais as exigências sobre o banco de dados são muito críticas. Alguns sistemas usam intensamente o servidor de banco de dados e possuem tabelas com milhões de registros que precisam de uma indexação muito eficiente. Embora talvez seja possível usar perfeitamente o Postgres e o MySql nestes casos, eu tomaria uma postura mais conservadora e só adotaria um dos 2 após diversos testes de carga sobre a aplicação usando eles.

Da mesma forma que existem aplicações que precisam de um servidor de banco de dados extremamente robusto, existem aplicações nas quais a praticidade de uso é o requisito mais importante. Temos por exemplo casos em que utilizar o Derby ou HSQLDB no modo embedded podem ser muito convenientes. É claro que o Derby e o HSQLDB não agüentam a mesma carga que os outros servidores mencionados. Todavia, a capacidade de empacotar o banco de dados dentro da sua aplicação pode ser muito conveniente, e nestes casos o Derby e o HSQLDB não poderiam ser substituídos por nenhum outro desta lista.

Nos casos em que os requisitos de banco de dados não são convencionais, algumas opções podem se mostrar muito mais adequadas do que outras. Entretanto, na maioria das aplicações, a troca de um produto pelo outro não fará muita diferença. Os recursos que realmente precisamos a maior parte do tempo estão disponíveis na maioria dos produtos.

A forte competição imposta pelos BDs open source fez com que os SGBDs comerciais passassem a oferecer versões gratuitas de seus produtos, com algumas limitações de uso. Para enfrentar este novo desafio, o Postgresql e o Mysql foram investindo cada vez mais esforço em seus produtos e hoje já têm uma ampla gama de recursos que antigamente só víamos em produtos comerciais. Com esta evolução do mercado, temos um largo leque de opções para escolher e estimo que em 90% dos casos, qualquer uma das opções atenderá plenamente.

Na minha opinião, isto já é suficiente para classificar os bancos de dados como commodities, na maioria dos casos. Já podemos ir na farmácia e pedir pelo genérico