Persistência flexível com BoxSQL

Não gosto da idéia de ter 3 ou quatro queries embutidas em annotations dentro dessa classe.

Lembrando que você pode sempre externalizar isso, não necessariamente precisa ficar como annotation.

JavaChild Membro desde: 07/11/2006 14:10:54 Mensagens: 125 Offline

Ficaria em XMLs. É válido também, mas se não formos utilizar nenhuma outra funcionalidade da JPA, acho que os templates em .SQL seriam melhores do que os XMLs ou mesmo melhor do que colocar essas annotations em uma única classe.

o que voces acham?

A discussao é... qual a vantagem do BoxSQL ? só estou vendo uma... curva de aprendizado não tão ingrime...

JPA te dá 4 ou 5 maneiras diferentes de fazer o que o boxSQL faz... e ainda é integrado.... transacoes etc....

This message was edited 1 time. Last update was at 12/09/2007 22:01:01

JPA e BoxSQL são diferentes.

Eu uso Ibatis e não tenho problema em ter minhas queries em XML, gosto da maneira do Ibatis.

Você deu dois exemplos gerando exceções.
No ibatis você consegueria fazer o mesmo resultando colocando o retorno da query em um dois objetos.(como foram usado no exemplo)

Tem como fazer isso?

E isso?

aew feliperod qual a diferença entre usar o boxsql.properties e nao usa-lo.
Verifiquei que na video aula em q o manoel ministra, este nao usa o .properties,
entou pergunto ha alguma diferença de performace entre usa-lo ou não ?

JavaChild Membro desde: 07/11/2006 14:10:54 Mensagens: 125 Offline

A versção que ele usava quando gravou a video-aula não possuía o arquivo properties ainda.
Hoje é obrigatório o properties.

Tivemos que fazer isso para que o BoxSQL fizesse a conexão automaticamente, e dar a opção de escolha entre conexão JDBC ou JNDI.

A versão que ele usava era denominada 2.21, mas depois de pensarmos um pouco e acabarmos um refactoring estrutural no BoxSQL, decidimos resetar o numero da versão.

QQ dúvida posta aí.

JavaChild Membro desde: 07/11/2006 14:10:54 Mensagens: 125 Offline

Seguinte,

Estive testando algumas situações no JPA e não precisei ir muito longe.
Imagine que tenho uma tabela simples, com uma primaryKey e um unique constraint para um campo.

Como faria para obter um objeto a partir daquele unique constraint usando JPA?

Simples, teria que construir uma query. Colocar o SQL no meio do código. Ou como já citado aqui, usar uma named query, que na minha opinião deve ser usado para casos mais complexos.

Dessa forma temos que chamar em.createQuery("seu sql aqui no meio do código").getResultList()

Tá, ele já retorna a lista populada, mas o BoxSQL também faz isso. Então fica minha pergunta, quando a funcionalidade de queries simples estiver implementada no BoxSQL, sem precisar de templates e também a funcionalidade de um DAO generico utilizando Generics já embutido no BoxSQL, qual será a vantagem de se usar JPA?

PS.: Falta ainda citar que a parte de Log e Transaction do BoxSQL precisar ser repensada.

Mas o que eu quero dizer é, imagine um framework com 51Kb, que faz tudo que o JPA faz com muito menos configuração. Entre qual do dois você optaria?

Sua situacao eh bem particular... porem..

te devolvou com outra pergunta...

e qual eh a vantagem em NAO usar JPA ?

JavaChild Membro desde: 07/11/2006 14:10:54 Mensagens: 125 Offline

chun wrote:Sua situacao eh bem particular... porem..

te devolvou com outra pergunta...

e qual eh a vantagem em NAO usar JPA ?

Não acho que minha situação seja realmente tão particular assim.

Imagine uma situação simples, de uma tela de login. O cara digita o email e o password.

Mas meu banco de dados tem uma primaryKey pelo CPF e uma unique constraint pelo email.

Tenho que usar uma Query pra fazer isso. Mas e daí? No BoxSQL tb tenho que usar uma query.
Mas o BoxSQL é um framework em evolução e tem apensa 51KB. A curva de aprendizado é bem menor e tem a vantagem de não colocar o SQL dentro do código java.

E para obter uma simples lista de registros usando JPA? Eu preciso de uma Query também. Putz, mas mudou a clausula where, e agora? Compila tudo de novo porque o SQL tá dentro do código. Mas em que classe?

A única vantagem que vejo para JPA é que é especificado pelo JCP. O o torna um padrão no desenvolvimento. Porque os outros itens de vantagem são temporários.

Mapeamento de Herança no BoxSQL é Transparente, indice e constraints também, pois são definidos no código.

Ps.: Eu optei por usar JPA no projeto atual, fato que demonstra que não acho JPA ruim, porém acho o BoxSQL muito promissor.

rapaz... me desculpe... esta estoria de "vai ter que recompilar tudo" para mim eh pura baboseira... hoje em dia um "play" no netbeans e vc tem o .jar na mao pronto. Acho que posso contar nos dedos as vezes que abri um .jar na unha para a alterar o conteudo dele... de alguma conf...

Vantagens temporarias ? Hibernate oferece vantagens temporarias as muito tempo hein ? JPA veio padronizando isso...

Acho que nao tem nada de temporario...

JavaChild Membro desde: 07/11/2006 14:10:54 Mensagens: 125 Offline

Vou tentar preparar 2 exemplos pra postar...

A mesma estrutura, uma usando o BoxSQL e outra usando JPA.

A todo mundo pode decidir qual se encaixe em seu projeto.

Ps.: Com Vantagem temporária eu me referi às vantagens que o JPA tem sobre o BoxSQL, como geração de queries simples automaticamente, porém que estão sendo implementadas no BoxSQL, por isso chamei de temporárias as vantagens.

Perfeito

valeu !

JavaChild Membro desde: 07/11/2006 14:10:54 Mensagens: 125 Offline

afsrj wrote:JPA e BoxSQL são diferentes.

Eu uso Ibatis e não tenho problema em ter minhas queries em XML, gosto da maneira do Ibatis.

Você deu dois exemplos gerando exceções.
No ibatis você consegueria fazer o mesmo resultando colocando o retorno da query em um dois objetos.(como foram usado no exemplo)

Tem como fazer isso?
<select id="findEmployees" resultMap="empResult"> SELECT * FROM emp <dynamic prepend="WHERE"> <isNotEmpty prepend="AND" property="id"> empno=#id# </isNotEmpty> <isNotEmpty prepend="OR" property="name"> ename=#name# </isNotEmpty> </dynamic> </select>

E isso?
<select id="findByDept" resultMap="empResult"> SELECT * FROM emp <dynamic prepend="WHERE"> <iterate property="departments" open="(" close=")" conjunction="OR"> deptno=#departments[]# </iterate> </dynamic> </select>

Cara, desculpa a demora em responder ao seu tópico... na verdade eu nãotinah visto sua pergunta.

Agora dessa forma com ofoi feita no iBatis, o BoxSQL não faz, porém é possivel criar a clausula WHERE como uma string no código java, ou mesmo obter somente a clausula WHERE a partir de um template separado, e "concatenar" ao resto do código, como se fosse um parâmetro normal.

Resumindo, dá pra fazer isso de uma forma diferente.

feliperod wrote:Mas o que eu quero dizer é, imagine um framework com 51Kb, que faz tudo que o JPA faz com muito menos configuração.

Faz TUDO o que o JPA faz? Não acha que essa afirmativa foi um pouco exagerada?

JavaChild Membro desde: 07/11/2006 14:10:54 Mensagens: 125 Offline

J2Alex wrote:

feliperod wrote:Mas o que eu quero dizer é, imagine um framework com 51Kb, que faz tudo que o JPA faz com muito menos configuração.

Faz TUDO o que o JPA faz? Não acha que essa afirmativa foi um pouco exagerada?

Como falei em um dos posts acima. No momento você tem razão, o BoxSQL não faz tudo o que o JPA faz, mas após conseguirmos diminuir a lista de novas features e issues, ele fará tudo o que o JPA faz. Claro que do ponto de vista de um framework de persistência, sem tocar na parte de EJB3.

Eu me pergunto se a galera só olhou no site ou se tentou usar mesmo, sem preconceito e pensou nas possibilidades.

Experimentem o framework e verão que o BoxSQL é um sério framework em termos de persistência e que com um pouco de ajuda (OpenSource precisa da galera mesmo) o BoxSQL pode se tornar melhor e se livrar de alguns issues.