Enhorabuena por esta intersante iniciativa. He revisado la informaci�n
disponible en el sitio web del proyecto. Me parece muy �til la
posibilidad de convertir errores sint�cticos en sentencias SQL, que dan
lugar a errores en tiempo de ejecuci�n, en errores de compilaci�n.

Este mismo es uno de los objetivos de dise�o de la tecnolog�a SQLJ de
Oracle, si bien las aproximaciones son totalmente distintas. SQLJ emplea
sentencias SQL embebidas en el c�digo Java que son posteriormente
convertidas a c�digo JDBC mediante un preprocesador. QueryJ por lo que
he podido entender, se basa en un modelo de objetos para representar la
sintaxis SQL. De esta manera se prescinde de la fase de precompilaci�n,
simplificando el proceso de build, quiz� a costa de una mayor
complejidad en el programa.

En cualquier caso, debido a la similitud de objetivos, puede ser buena
idea que se a�ada un elemento a las FAQ del sitio con una comparativa
entre QueryJ y SQLJ.

Rafa
 

On Tue, 2003-09-02 at 14:01, Jose San Leandro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hola,
> 
> Solo queria informar que acabo de crear un nuevo proyecto GPL, cuyo nombre es 
> QueryJ.
> Es un proyecto que parte de una idea simple: evitar utilizar consultas SQL 
> directamente como cadenas de texto. Lo que se pretende es garantizar que no 
> habra errores sintacticos en operaciones con la base de datos.
> Sobre esta idea simple, ofrece o planea ofrecer otras funcionalidades:
> - -Autocompletado de tablas y columnas.
> - -Gestion de la parametrizacion de los PreparedStatements: referencia semantica 
> a los parametros (no por posicion).
> - -Posibilidad de optimizacion de consultas (hints, supresion de joins, etc.) 
> independientemente del codigo Java.
> - -Sincronizacion con los metadatos del esquema de la base de datos.
> El proyecto en si no tiene excesiva complejidad. A pesar de enfrentarse con 
> los tipicos "razonamientos" de "yo siempre he usado JDBC", considero que es 
> un ejemplo claro de libreria poco ambiciosa, con unos requisitos especificos, 
> no ambiguos, y que permite la separacion de roles (el desarrollador garantiza 
> que la consulta esta bien formada sintacticamente, y no obstaculiza la labor 
> del analista de bd a la hora de analizar el execution plan y tratar de 
> optimizarla).
> En cualquier caso, el proyecto lo podeis visitar aqui:
> http://queryj.sourceforge.net
> 
> Un saludo.
> Jose.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE/VFxpCAvt6RF8M0cRApN2AJ4jlSF4UHyewG02bkCGvVBf6bg1NQCfXi+O
> FniDXX1DuUpV3iK7etioovQ=
> =HngZ
> -----END PGP SIGNATURE-----
> 
> 
> ---------------------------------------------------------------------
> Para eliminar la suscripci�n, mail a: [EMAIL PROTECTED]
> Para comandos adicionales, mail a: [EMAIL PROTECTED]
> 
> 
> 
-- 
Rafael Luque, <[EMAIL PROTECTED]>

Metadatos RDF: http://www.orange-soft.com/people/luque/contacto.rdf
Clave PGP: http://www.orange-soft.com/people/luque/clavepgp


---------------------------------------------------------------------
Para eliminar la suscripci�n, mail a: [EMAIL PROTECTED]
Para comandos adicionales, mail a: [EMAIL PROTECTED]


Responder a