Persistência flexível com BoxSQL

Esquecer esses .sql seria uma ótima... usando anotações...

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Acho que talvez colocar as duas opções seria uma saida para esse caso. Só não vejo nenhuma vantagem em se usar anotações para armazenar SQL.

Se for pra criar uma classe só para conter templates, poderíamos usar constantes ao invés de anotations.

Além disso se um sistema tiver muitas queries que devam ser utilizada como nesse caso (300 por exemplo), quantas classes de templates criaríamos?
E a organização do código SQL?
Ah, e a concatenação do SQL (caso ele seja muito grande)?
E as famosa confusão das aspas que são motivos de muitos bugs em sistemas que utilizam SQL no código java?

Tudo isso pra que? Pra usar annotations e ficar na moda?

Sou a favor das annotations sim, como já falei, mas para casos onde elas são necessárias.

PS.: Alguma opinião diferente da nossa? Só pra enriquecer a discussão?

Olá a todos,

Só para lembrar, uma das futuras versões do BoxSQL, vai ser exatamente o recurso de anotações para gerar automaticamente os códigos SQL mais simples e diminuir a necessidade dos arquivos SQL.

Porém, digamos que o BoxSQL, reúne o melhor de 2 mundos, pois ele nasceu em um ambiente de aplicação, onde havia milhares de registros, várias tabelas, e um forte requisito de performance, por isso, era importante ter a possibilidade de usar querys otimizadas apartir de planos de execução (coisa de DBA's), e como não queria deixar o SQL no próprio código Java, criei esse framework com o objetivo de ser simples, de fácil configuração, leve, que valoriza-se o uso de bons códigos SQL e favorece-se a criação de códigos java simples com forte adoção de padrões e boas práticas de programação.

E desde então, o BoxSQL vem evoluindo, de maneira simples, sem grandes pretensões e agradando um púplico seleto em outros projetos pelo Brasil.

Por isso, sabedores que muito temos a evoluir, aceitamos sugestões, que visem melhora-lo ainda mais.

Grato,

Manoel Pimetel

douglasfs wrote:Felipe, ao meu ver ele é um concorrente do Ibatis, certo ?

http://www-128.ibm.com/developerworks/websphere/techjournal/0510_col_barcia/0510_col_barcia.html

Qual seria a diferença do BoxSQL para o Ibatis ?

[]s

Douglas

Olá,

Pelo o que conheço do iBatis, uma das principais diferenças, é que ele usa arquivos XML para conter os códigos SQL e fazer os mapeamentos em cada classe.

E o BoxSQL, usa o conceito de "convenção ao invéis de configuração" , por isso, temos apenas um arquivo .properties para centralizar as configurações de acesso ao banco(JDBC ou JNDI). e os arquivos SQL que seão usados pela aplicação.

Grato,

Manoel Pimentel
manoelpimente.blogspot.com

This message was edited 1 time. Last update was at 10/09/2007 18:11:20

Olá

Meu pitaco sobre a questão porque fazer isto se já existe aquilo.

Quando surgiu o hibernate o iBatis já existia (ou vice versa) e o JDO também. Quando surgiu sei lá o que outro sei lá o que já existia.

Depois de recentemente ler o livro The Miths of Innovation, aprendi que é melhor não encarar muito negativamente coisas novas.

Se vai pegar, se é melhor do que o que já existe e se promete ter a mesma evolução do que o que já existe é uma outra história. Antes de detonar, o momento ainda é de tentar entender para que serve e quais vantagens deste tal de BoxSQL que eu por exemplo ainda não percebi claramente.

[]s
Luca

JavaTeenager Membro desde: 27/07/2004 11:23:41 Mensagens: 186 Offline

Fiquei com uma dúvida. E quando houver relacionamentos entre as tabelas? Como o framework vai identificar a qual entidade pertence o atributo?

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Bom, nesse caso ainda não está implementada essa funcionalidade.
Que ainda será implementada utilizando Annotations.

Veja um exemplo que explica como fazer isso:

Imagine que você tenha uma Classe Departamento e nela tem um atributo do tipo Pessoa.
Para você inserir esse departamento completo, incluindo o atributo comples do tipo Pessoa, o código ficaria assim:

Você tb pode setar os parâmetros manualmente, o que seria uma opção um pouco m ais trabalhosa, porém em alguns casos é necessário.

Para recuperar do banco de dados voce terá que fazer assim também. Primeiro recuperar o dpto e depois a pessoa.

Essa funcionalidade está na fila para ser implementada, mas com oeu já disse antes, tá faltando mao-de-obra, hehehhe...
Porém, mesmo sem essa funcionalidade não é tão difícil de realizar essa operaão. O único problema é que terá que ter um SQL para o objeto principal e um SQL para o atributo complexo.

Espero que tenha ajudado.

Felipe

JavaTeenager Membro desde: 27/07/2004 11:23:41 Mensagens: 186 Offline

A minha dúvida estava mais para consultas com select. No fim das contas eu gostaria de saber como faço para consultas em mais de uma tabela. Se tem alguma convenção para isso, ou se tem uma maneira de não esperar pela reflection que o framework faz. Estou fazendo essas peguntas porque gostei do framework e pretendo usá-lo em casos que o mapeamento objeo/relaciona não seja viável.

Valeu

feliperod wrote:Bom, nesse caso ainda não está implementada essa funcionalidade.
Que ainda será implementada utilizando Annotations.

Veja um exemplo que explica como fazer isso:

Imagine que você tenha uma Classe Departamento e nela tem um atributo do tipo Pessoa.
Para você inserir esse departamento completo, incluindo o atributo comples do tipo Pessoa, o código ficaria assim:

public void insertDpto(Departamento dpto) throws Exception { try{ BoxSQL box = new BoxSQL(); // Insere o departamento int result1 = box.executeUpdate("insertDpto.sql", dpto); // Insere o atributo complexo; int result2 = box.executeUpdate("inserePessoaDpto.sql", dpto.getPessoa()); if(result1 == 0 || result2 == 0) throw new Exception("não inseriu completo!"); }finally{ box.release(); } }

Você tb pode setar os parâmetros manualmente, o que seria uma opção um pouco m ais trabalhosa, porém em alguns casos é necessário.

Para recuperar do banco de dados voce terá que fazer assim também. Primeiro recuperar o dpto e depois a pessoa.

Essa funcionalidade está na fila para ser implementada, mas com oeu já disse antes, tá faltando mao-de-obra, hehehhe...
Porém, mesmo sem essa funcionalidade não é tão difícil de realizar essa operaão. O único problema é que terá que ter um SQL para o objeto principal e um SQL para o atributo complexo.

Espero que tenha ajudado.

Felipe

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Ok,
Para consultas voce pode fazer qualquer tipo de cruzamento entre as tabelas, já que você está utilizando SQL normal.

Quando à esperar pela reflection, tb pode ser evitada na hora de setar os parametros, porém não vejo ganho de performance, já que a API de reflection já é bastante otimizada.

Veja um exemplo para fazer sem reflection:

Viu a simplicidade?
Isso também poderá ser resolvido quando tivermos uma annotation que defina a recursividade de consultas e updates.
Ainda temos que pensar como serão as annotations para esse caso, mas sempre teremos a opção de fazer da forma
mostrada acima.

Olá,

Eu estava lendo todas mensagens pra entender um pouco do framework mas parei quando li essa parte.

manoelp wrote:Porém, digamos que o BoxSQL, reúne o melhor de 2 mundos, pois ele nasceu em um ambiente de aplicação, onde havia milhares de registros, várias tabelas, e um forte requisito de performance, por isso, era importante ter a possibilidade de usar querys otimizadas apartir de planos de execução (coisa de DBA's),

Acredito que o problema que voces tiveram não foi qual framework de ORM utilizar, mas sim problema no banco. Pra eu ter que me preocupar com o plano de execucao de uma query meu banco tem que estar trabalhando por regra ou estar com as estatisticas desatualizadas (o mais comum). Entao ao invez do DBA enxer o saco do pessoal do desevolvimento ele devia era se preocupar em fazer o trabalho dele.

Se o problema fosse consultas gigantes por ter muitos relacionamentos sem necessidade eu até entenderia o argumento, mas esse do plano de execucao em pleno 2007 nao tem mais sentido.

]['s

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

fabio.patricio wrote: Acredito que o problema que voces tiveram não foi qual framework de ORM utilizar, mas sim problema no banco. Pra eu ter que me preocupar com o plano de execucao de uma query meu banco tem que estar trabalhando por regra ou estar com as estatisticas desatualizadas (o mais comum). Entao ao invez do DBA enxer o saco do pessoal do desevolvimento ele devia era se preocupar em fazer o trabalho dele.

Se o problema fosse consultas gigantes por ter muitos relacionamentos sem necessidade eu até entenderia o argumento, mas esse do plano de execucao em pleno 2007 nao tem mais sentido.

Talvez você esteja certo quando nos referimos a sistemas onde podemos modelar o banco de dados do zero, ou mesmo sistemas onde o banco está bem modelado. Mas não é raro encontrar situações onde o Banco de Dados está altamente fragmentado e incompatível com o modelo Orientado a Objetos.

Outra situação bem comum, são casos onde funções do banco devem ser chamadas durente um select ou um insert. Já vi vários sistemas que obtém informações que ao invés de estarem em um campo da tabela, são resultado de uma função, e devem ser adcionados dentro de um select específco.

Bom, eu ainda vejo muitos e muitos programadores PL/SQL por aí, isso significa que planos de execução e funções para tratamento de regras de negócios ainda são muito usadas.

Agora, se fossemos falar sobre um banco de dados perfeitinho, com um DBA compreensivo e alinhado com Orientação a Objetos, aí sim... Concordo plenamente com você.

feliperod wrote:
Talvez você esteja certo quando nos referimos a sistemas onde podemos modelar o banco de dados do zero, ou mesmo sistemas onde o banco está bem modelado. Mas não é raro encontrar situações onde o Banco de Dados está altamente fragmentado e incompatível com o modelo Orientado a Objetos.

Note que em nenhum momento eu falei em banco de dados preparado para OOP, o que eu quis dizer é que fazer query baseado em regras é coisa de no minimo uns 7 anos atras. Hoje em dia usar query baseada em custo, as famosas estatisticas do banco, é o mais correto. Se as consultas precisam trabalhar baseadas em regras nos dias de hoje o DBA nao anda fazendo o trabalho dele.

feliperod wrote:Outra situação bem comum, são casos onde funções do banco devem ser chamadas durente um select ou um insert. Já vi vários sistemas que obtém informações que ao invés de estarem em um campo da tabela, são resultado de uma função, e devem ser adcionados dentro de um select específco.

Ja passei por isso tambem, mas não seria essa uma situacao que me faria abandonar as facilidades de um ORM.

feliperod wrote:Bom, eu ainda vejo muitos e muitos programadores PL/SQL por aí, isso significa que planos de execução e funções para tratamento de regras de negócios ainda são muito usadas.

O fato de existir muitos programadores PL/SQL por ai não tem nada a ver com o fato de precisar ou não usar RBO. Eu ainda me considero programador PL/SQL e la por 2003 já não usava mais esse tipo de "regra" para minhas consultas.

Certa vez fui até repreendido por um DBA por estar forcando um indice com um hint do Oracle.

feliperod wrote:Agora, se fossemos falar sobre um banco de dados perfeitinho, com um DBA compreensivo e alinhado com Orientação a Objetos, aí sim... Concordo plenamente com você.

Pois é, mas eu nem falei isso, estou falando de banco de dados todo torto mesmo...ja mexeu com IFS Applications? Se sim deve imaginar o que to falando.

]['s

Bom, acho que meu caso se encaixa perfeitamente neste tópico !!!!

Trabalho num empresa onde o principal produto é um ERP feito em Delphi + Oracle, que já existe a quase 8 anos. Os projetos web em java é tudo baseado neste banco, onde existem milhares de tabelas com milhares de Triggers e Pkg's !!!

Estou desenvolvendo um projeto utilizando JSP + VRaptor + Hibernate, neste projeto tive que usar algumas funções específicas do Oracle, por isso 10% do SQL tive que usar Query Nativa.

Agora tenho um caso de um projeto já desenvolvido em JSP + JavaBeans + JDBC, onde pretendo migrar para JSP + VRaptor + Hibernate. Neste novo padrão 50% do SQL deverá ficar em Query Nativa devido ao uso de várias funções específicas do Oracle. Neste caso ficaria melhor usar o BoxSQL ???

Valew.

Pra não dar Quote em cima :

As experiências em cada empresa variam bastante, já encontrei projetos que seguem DDD e outros com tabelas fragmentadas como o amigo citou.

Gostaria só de argumentar em cima de características do Hibernate como Named Queries, para você externalizar e qual o ganho do BoxSQL dessa feature.

Lembrando que pode utilizar de formas diferentes, como XML ou Annotations :

mport javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EntityResult;
import javax.persistence.FieldResult;
import javax.persistence.Id;
import javax.persistence.NamedNativeQuery;
import javax.persistence.SqlResultSetMapping;

@Entity
@SqlResultSetMapping(name = "implicit", entities = @EntityResult(entityClass = data.Employee.class))
@NamedNativeQuery(name = "implicitSample", query = "select e.empno empNumber, e.ename empName, e.job empJob, e.sal empSalary, salg.grade empGrade from emp e, salgrade salg where e.sal between salg.losal and salg.HISAL", resultSetMapping = "implicit")

public class Employee {

private String empNumber;

private String empName;

private String empJob;

private Double empSalary;

private int empGrade;

@Column
 @Id
 public int getEmpGrade() {
   return empGrade;
 }

public void setEmpGrade(int empGrade) {
   this.empGrade = empGrade;
 }

@Column
 public String getEmpJob() {
   return empJob;
 }

public void setEmpJob(String empJob) {
   this.empJob = empJob;
 }

@Column
 public String getEmpName() {
   return empName;
 }

public void setEmpName(String empName) {
   this.empName = empName;
 }

@Column
 public String getEmpNumber() {
   return empNumber;
 }

public void setEmpNumber(String empNumber) {
   this.empNumber = empNumber;
 }

@Column
 public Double getEmpSalary() {
   return empSalary;
 }

public void setEmpSalary(Double empSalary) {
   this.empSalary = empSalary;
 }

}

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

marceloplis wrote:
Agora tenho um caso de um projeto já desenvolvido em JSP + JavaBeans + JDBC, onde pretendo migrar para JSP + VRaptor + Hibernate. Neste novo padrão 50% do SQL deverá ficar em Query Nativa devido ao uso de várias funções específicas do Oracle. Neste caso ficaria melhor usar o BoxSQL ???

Valew.

Eu sugiro utilizar as 2 soluções. Você poderia utilizar o BoxSQL para manter o seu SQL simples e organizado e o JPA ou alguma outra coisa para os outros 50%.

Vale lembrar que o BoxSQL faz isso com 51Kb, então não é nenhum elefante branco para resolver seu problema. É uma API simples, com um objetivo simples.

Mas em minha opinião a flexibilidade que o BoxSQL oferece em relação às NamedQueries do JPA é bem maior, podendo passar várias coisas como parâmetros.

O exemplo do Kenobi ficou muito bom e parece muito simples, mas se você reparar o banco está bem similar ao objeto.
Imagine que essa Classe citada pelo Kenobi tivesse 3 tipos de queries diferentes. Isso pode acontecer por inúmeros motivos.
Uma tabela só de valores e outra só de metadados da entidade. Em momentos você precisa cruzar as duas tabelas para obter os metadados junto com os valores ou momentos que só precisamos dos metadados (para montar telas com campos dinâmicos).
Não gosto da idéia de ter 3 ou quatro queries embutidas em annotations dentro dessa classe.

Aí numa dessa eu pergunto, por que não usar o BoxSQL?
Será que vai ferir muito os conceitos da JPA? O BoxSQL não pode vir a somar num casos como o citado acima ou mesmo o caso do ERP com Java Beans e JDBC? A reestruturação do projeto em JSP + JavaBeans + JDBC para utilização do BoxSQL é bem simples. Remove a linhas de código do DAO, pões as consultas em templates e coloca de 3 a 10 linhas do BoxSQL. E quanto à migração desse projeto para a JPA?

Mais uma vez volto a falar. Em sistemas novos com entidades sólidas e não fragmentadas, não precisamos do BoxSQL (apesar dele atender tb a esse publico). Mas em situações de banco de dados tortos e eu chamo de torto um banco com várias tabelas para formar um único objeto (o que não tem relação com execução por regras), o BoxSQL é realmente uma boa opção para resolver isso.

Notícias, artigos e o maior fórum brasileiro sobre Java