You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(37) |
Oct
(180) |
Nov
(5) |
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(26) |
Feb
(15) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Enrique R. L. <las...@ja...> - 2006-03-08 14:12:57
|
Es funcional como la describ=ED y no os gusto. En NHT aun no las usamos. Esperaba hacer funcionar licurgo-xml para leer los ficheros de = configuraci=F3n y poder cambiar el formato a algo m=E1s intuitivo y f=E1cil de = configurar. > -----Mensaje original----- > De: lic...@li... [mailto:licurgo-devs- > ad...@li...] En nombre de Alberto Molpeceres > Enviado el: mi=E9rcoles, 08 de marzo de 2006 13:41 > Para: lic...@li... > Asunto: [Licurgo-devs] Named queries? >=20 > Hola, >=20 > una preguntita... como est=E1 el asunto de las queries por nombre?. Es > funcional?. Hasta que nivel?. >=20 > al. >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Licurgo-devs mailing list > Lic...@li... > https://lists.sourceforge.net/lists/listinfo/licurgo-devs |
From: Alberto M. <alb...@gm...> - 2006-03-08 12:40:54
|
Hola, una preguntita... como est=E1 el asunto de las queries por nombre?. Es funcional?. Hasta que nivel?. al. |
From: <rd...@ya...> - 2006-02-21 13:18:37
|
Si se quiere que licurgo respecte la especificacion, en algun momentohay que hacer este cambio e impactarlo en las aplicaciones que estan utilizando licurgo. Licurgo no se accede desde servicios OCAS? no se podrian hacer adaptadores o diferentes servicios para acceder a licurgo (antes de ser SDO-compliant) y a licurgo SDO-compliant. Diego Enrique Rodriguez Lasterra <las...@ja...> escribió: El lun, 20-02-2006 a las 17:50 -0300, Diego Campodónico escribió: > Buenas gente. > Una pregunta, el test unitario JDBCTest ejecuta correctamente? A mi no > me esta funcionando en 6 test y 3 si me funcionan bien. Igualmente me > pondre a mirar en detalle porque no funcionan y vere si es un error > mio. La ultima vez que subi los test los ejecute contra postgresql, voy a probar a ver si funcionan, deberia, contra hsqldb. > > Por otro lado queria comentarles que estuve mirando la API de > licurgo-sql y me tope con la interface DataSource, y segun veo tiene > metodos para acceder/obtener DataObjects, pero no seria correcto desde > el punto de vista de la especificacion que se accedan a estos objetos > desde un DataGraph? > Se podria hacer este cambio dejando que un DataSource se concentre en > la forma de conectarse con una fuente de datos, devolviendo DataGraph > y atraves de este manipular los DataObject, que les parece? Me parece muy bien, porque si creo q es lo que dice la especificación. Ahora bien, me preocupa que un cambio asi rompa las aplicaciones que tenemos ya funcionando con licurgo. saludos. > > gracias y saludos > Diego > > > > ______________________________________________________________________ > 1GB gratis, Antivirus y Antispam > Correo Yahoo!, el mejor correo web del mundo > Abrí tu cuenta aquí -- _______________________________ Enrique Rodriguez Lasterra lasterra AT javahispano DOT org http://www.javahispano.org Asociación sin ánimo de lucro sobre java Spanish non profit association about java ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Licurgo-devs mailing list Lic...@li... https://lists.sourceforge.net/lists/listinfo/licurgo-devs --------------------------------- 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo Abrí tu cuenta aquí |
From: Alberto M. <alb...@gm...> - 2006-02-21 07:54:08
|
> > > > Por otro lado queria comentarles que estuve mirando la API de > > licurgo-sql y me tope con la interface DataSource, y segun veo tiene > > metodos para acceder/obtener DataObjects, pero no seria correcto desde > > el punto de vista de la especificacion que se accedan a estos objetos > > desde un DataGraph? > > Se podria hacer este cambio dejando que un DataSource se concentre en > > la forma de conectarse con una fuente de datos, devolviendo DataGraph > > y atraves de este manipular los DataObject, que les parece? > > Me parece muy bien, porque si creo q es lo que dice la especificaci=F3n. > Ahora bien, me preocupa que un cambio asi rompa las aplicaciones que > tenemos ya funcionando con licurgo. Mi intenci=F3n inicial fu=E9 la de "separar" entre DataSource y DataMediatorService. Utilizando el segundo al primero internamente para cumplir la especificaci=F3n, pero sin impedir un uso "m=E1s sencillo de cara a las bases de datos", porque me temo que al final es lo que la gente va a buscar :-(. al. |
From: Enrique R. L. <las...@ja...> - 2006-02-20 21:43:37
|
El lun, 20-02-2006 a las 17:50 -0300, Diego Campodónico escribió: > Buenas gente. > Una pregunta, el test unitario JDBCTest ejecuta correctamente? A mi no > me esta funcionando en 6 test y 3 si me funcionan bien. Igualmente me > pondre a mirar en detalle porque no funcionan y vere si es un error > mio. La ultima vez que subi los test los ejecute contra postgresql, voy a probar a ver si funcionan, deberia, contra hsqldb. > > Por otro lado queria comentarles que estuve mirando la API de > licurgo-sql y me tope con la interface DataSource, y segun veo tiene > metodos para acceder/obtener DataObjects, pero no seria correcto desde > el punto de vista de la especificacion que se accedan a estos objetos > desde un DataGraph? > Se podria hacer este cambio dejando que un DataSource se concentre en > la forma de conectarse con una fuente de datos, devolviendo DataGraph > y atraves de este manipular los DataObject, que les parece? Me parece muy bien, porque si creo q es lo que dice la especificación. Ahora bien, me preocupa que un cambio asi rompa las aplicaciones que tenemos ya funcionando con licurgo. saludos. > > gracias y saludos > Diego > > > > ______________________________________________________________________ > 1GB gratis, Antivirus y Antispam > Correo Yahoo!, el mejor correo web del mundo > Abrí tu cuenta aquí -- _______________________________ Enrique Rodriguez Lasterra lasterra AT javahispano DOT org http://www.javahispano.org Asociación sin ánimo de lucro sobre java Spanish non profit association about java |
From: <rd...@ya...> - 2006-02-20 20:50:37
|
Buenas gente. Una pregunta, el test unitario JDBCTest ejecuta correctamente? A mi no me esta funcionando en 6 test y 3 si me funcionan bien. Igualmente me pondre a mirar en detalle porque no funcionan y vere si es un error mio. Por otro lado queria comentarles que estuve mirando la API de licurgo-sql y me tope con la interface DataSource, y segun veo tiene metodos para acceder/obtener DataObjects, pero no seria correcto desde el punto de vista de la especificacion que se accedan a estos objetos desde un DataGraph? Se podria hacer este cambio dejando que un DataSource se concentre en la forma de conectarse con una fuente de datos, devolviendo DataGraph y atraves de este manipular los DataObject, que les parece? gracias y saludos Diego --------------------------------- 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo Abrí tu cuenta aquí |
From: Alberto M. <alb...@gm...> - 2006-02-17 21:54:39
|
> Yo estoy estudiando de nuevo la especificaci=F3n SDO, por ejemplo, albert= o no > utilizo el objeto DataGraph en licurgo-sql cuando parece que la definici= =F3n > lo utiliza como el elemento a trav=E9s del cual se accede a los data obje= cts. DataGrpah y ChangeSummary. As=ED como todo lo referente a XQuery. esos son los aspectos m=E1s "peliagudos" que faltan, as=ED como limpiar algunas dependencias que no nos deber=EDan intenresar. Pero como he dicho, la situaci=F3n de la especificaci=F3n no se=B4s si nos deber=EDa hacer pensar algunas cosas, y considerarlo un framework de persistencia para ser transparente JDBC/XML/LDAP deber=EDa ser un fin a tener en cuenta tambi=E9n. al. |
From: Alberto M. <alb...@gm...> - 2006-02-17 21:51:53
|
Bueno, la verdad es esa. No quer=EDa empezar a implementar "nada" sin saber si realmente funcionaba. Luego las cosas se fueron hasta cierto punto complicando, por distintas razones, hasta encontrarnos d=F3nde nos encontramos. Si me hubiera puesto a usar DataGraph desde el principio Enrique y Roberto que vienen de OREO me matan! ;-). Enrique, que no puedas usar mucho de la interface "datasource" me sorprende. Si que hay m=E9todos que lo han podido ensuciar, pero vamos, que el 80% son de "save", "query", "delete", etc. OREO ten=EDa soporte para las dos cosas en un api muy similar. al. On 2/17/06, Enrique Rodriguez Lasterra <las...@ja...> wrote: > > Si, los tiros van un poco por ahi, aunque no se si tendria mucho sentido = un > licurgo-hibernate, pero por poderse se podr=EDa hacer. > > Yo estoy estudiando de nuevo la especificaci=F3n SDO, por ejemplo, albert= o no > utilizo el objeto DataGraph en licurgo-sql cuando parece que la definici= =F3n > lo utiliza como el elemento a trav=E9s del cual se accede a los data obje= cts. > > La especificaci=F3n tb habla de los MediatorService (hablo de memoria) qu= e > seria el punto a traves del cual se accede a la capa oculta de cada > implementacion (sql, xml, ldap, etc) > > Estos objectos sin embargo no tienen definido ningun interfaz en la > especificaci=F3n y por tanto queda un poco en manos del implementador, en= caso > de alberto creo el interfaz datasource para licurgo-sql del cual no creo = que > pueda aprovechar mucho para licurgo-xml. > > He corregido hoy algunos bugs hoy y la versi=F3n de cvs vuelve a ser esta= ble. > lo comento por si te interesa completar los test que tenemos. > > saludos. > > > > ________________________________ > De: lic...@li... > [mailto:lic...@li...] En nombre > de Diego Campod=F3nico > Enviado el: viernes, 17 de febrero de 2006 13:46 > Para: lic...@li... > Asunto: [Licurgo-devs] Re: estudiando licurgo > > > Bueno, creo empezar a entender! > Supongo que tambien se podria hacer un licurgo-hibernate donde trate de s= er > una implementacion del standard para acceder a base de datos pero dejando= a > hibernate todo lo realcionado con persistencia, como ser transacciones, > cache, etc.? > Por su parte, licurgo-xml sera la implementacion para acceder a xml, es > decir donde la informacion que sera populada en los DataGraph esta plasma= da > en archivos XML, esto es asi? > Si es asi, entiendo que se podria implementar N implementaciones (valga d= e > redundancia) de licurgo-xxx para acceder a diferentes datasource. Entonce= s > esto no serian DMS en si? > > Otra cosa que veo es que la especificacion tiene pocas interfaces que > implementar y como bien dice al, hay muchas cosas dejadas al criterio de > cada uno > > Para continuar con mi investigacion de licurgo tratare de hacer un par de > test cases para ver un poco mas el funcionamiento de est e. > > > ________________________________ > 1GB gratis, Antivirus y Antispam > Correo Yahoo!, el mejor correo web del mundo > Abr=ED tu cuenta aqu=ED > > -- Alberto Molpeceres alb...@li... (+34) 661 304 614 Linking Paths Francisco Maci=E1 11, 7=BA - 48014 Bilbao (+34) 944 764 328 http://www.linkingpaths.com |
From: Enrique R. L. <las...@ja...> - 2006-02-17 17:58:35
|
Si, los tiros van un poco por ahi, aunque no se si tendria mucho sentido = un licurgo-hibernate, pero por poderse se podr=EDa hacer. =20 Yo estoy estudiando de nuevo la especificaci=F3n SDO, por ejemplo, = alberto no utilizo el objeto DataGraph en licurgo-sql cuando parece que la = definici=F3n lo utiliza como el elemento a trav=E9s del cual se accede a los data = objects. =20 La especificaci=F3n tb habla de los MediatorService (hablo de memoria) = que seria el punto a traves del cual se accede a la capa oculta de cada implementacion (sql, xml, ldap, etc) =20 Estos objectos sin embargo no tienen definido ningun interfaz en la especificaci=F3n y por tanto queda un poco en manos del implementador, = en caso de alberto creo el interfaz datasource para licurgo-sql del cual no creo = que pueda aprovechar mucho para licurgo-xml. =20 He corregido hoy algunos bugs hoy y la versi=F3n de cvs vuelve a ser = estable. lo comento por si te interesa completar los test que tenemos. =20 saludos. =20 _____ =20 De: lic...@li... [mailto:lic...@li...] En nombre de Diego Campod=F3nico Enviado el: viernes, 17 de febrero de 2006 13:46 Para: lic...@li... Asunto: [Licurgo-devs] Re: estudiando licurgo Bueno, creo empezar a entender! Supongo que tambien se podria hacer un licurgo-hibernate donde trate de = ser una implementacion del standard para acceder a base de datos pero = dejando a hibernate todo lo realcionado con persistencia, como ser transacciones, cache, etc.? Por su parte, licurgo-xml sera la implementacion para acceder a xml, es decir donde la informacion que sera populada en los DataGraph esta = plasmada en archivos XML, esto es asi? Si es asi, entiendo que se podria implementar N implementaciones (valga = de redundancia) de licurgo-xxx para acceder a diferentes datasource. = Entonces esto no serian DMS en si? Otra cosa que veo es que la especificacion tiene pocas interfaces que implementar y como bien dice al, hay muchas cosas dejadas al criterio de cada uno Para continuar con mi investigacion de licurgo tratare de hacer un par = de test cases para ver un poco mas el funcionamiento de est e. _____ =20 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo Abr=ED tu cuenta <http://login.yahoo.com/config/mail?.intl=3Dar> aqu=ED |
From: <rd...@ya...> - 2006-02-17 12:46:19
|
Bueno, creo empezar a entender! Supongo que tambien se podria hacer un licurgo-hibernate donde trate de ser una implementacion del standard para acceder a base de datos pero dejando a hibernate todo lo realcionado con persistencia, como ser transacciones, cache, etc.? Por su parte, licurgo-xml sera la implementacion para acceder a xml, es decir donde la informacion que sera populada en los DataGraph esta plasmada en archivos XML, esto es asi? Si es asi, entiendo que se podria implementar N implementaciones (valga de redundancia) de licurgo-xxx para acceder a diferentes datasource. Entonces esto no serian DMS en si? Otra cosa que veo es que la especificacion tiene pocas interfaces que implementar y como bien dice al, hay muchas cosas dejadas al criterio de cada uno Para continuar con mi investigacion de licurgo tratare de hacer un par de test cases para ver un poco mas el funcionamiento de este. --------------------------------- 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo Abrí tu cuenta aquí |
From: Alberto M. <alb...@gm...> - 2006-02-17 08:13:08
|
Aqu=ED supongo que tengo algo que decir. Lo primero es que tienes raz=F3n, y lo que hay "actualmente" se aleja un poquito de lo que es SDO. Hay demasiadas clases en paquetes que "diluyen" lo que es SDO, por no hablar de que hay una gran parte de SDO que est=E1 tan abierta que cada uno implementa como "puede" (por ejemplo los DAtaSoources, o DataMediatorService que dicen en SDO). Limpiar eso es "peliagudo", pero bueno, hasta d=F3nde yo s=E9, todos lo usamos a trav=E9s de OCAS, por lo que en un futuro podr=EDa ser posible hacer algo al respecto. Ya veremos, hasta que no tengamos dos implementaciones no lo consider=E9 especialmetne prioritario. Y lo segundo es sobre SDO, modelos din=E1micos y frameworks de persistencia. La verdad es que SDO deber=EDa poder funcionar de las dos formas: modelos din=E1micos y modelos est=E1ticos. Ya se habla en la especificaci=F3n (en la versi=F3n 1 aparece en la p=E1gina 3) del requerimiento de soportar APIs de datos din=E1micos y est=E1ticos. Pero Diego, reiterar que tienes raz=F3n, que el fin de Licurgo es uno, pero su estado actual es otro, por nuestro inter=E9s en hacer algo usable antes de embarcarnos en demasiadas historias. Por ejemplo, el concepto de "transacci=F3n" en SDO es el de los cambios producidos (ChangeSummary) en un DataGraph, que de momento hemos dejado de lado por: - necesidades - complejidad a la hora de usarlo. De cara al futuro a mi me gustar=EDa tener un paquete como "framework de persistencia en distintas fuentes", y uno estrictamente SDO que use por debajo el otro, pero tengo mis dudas debido a: - el poco detalle en aspectos tan imporrtantes como el acceso a los dat= os - el hecho de que se hayan "salido" del JCP le resta inter=E9s a la especificaci=F3n. Vaya lio. Supongo que queda poco claro. al. On 2/16/06, Enrique Rodriguez Lasterra <las...@ja...> wrote: > Hi, > > SDO es uns standard que define un acceso a datos a traves de objetos > din=E1micos. > > Licurgo-sql intenta ser una implementaci=F3n de ese estandard para accede= r > a base de datos. Licurgo-xml ser=E1 un sistema ce lectura y escritura de > xml mediante modelos din=E1micos. > > Modelos dinamicos de objetos al contrario de los POJOS permite al > programador crear nuevos campos en los objetos. A d=EDa de hoy que yo sep= a > se puede hacer de dos formas > > 1.- Modificando la estructura de las clases compiladas en tiempo de > ejecuci=F3n > 2.- Utilizando SDO, y en definitiva un HashMap por entidad en vez de un > pojo por entidad. De esta forma yo hago get("id") y me devuelve el id, > pero tb puedo hacer set("nombre","Enrique") y creo un campo nombre con > valor Enrique. No se si me explico. > > > > El jue, 16-02-2006 a las 20:59 +0000, Diego Campod=F3nico escribi=F3: > > dos los aspectos de persistencia a una framework y concentrarse en la > > especificacion de SDO? > > > > Tal ves estas preguntas surgan de mi ignorancia, por eso me gustaria > > preguntar: cual es el objetivo final de licurgo (al menos de > > licurgo-sql y que lo diferencia de licurgo-xml)? > -- > _______________________________ > Enrique Rodriguez Lasterra > lasterra AT javahispano DOT org > http://www.javahispano.org > Asociaci=F3n sin =E1nimo de lucro sobre java > Spanish non profit association about java > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Licurgo-devs mailing list > Lic...@li... > https://lists.sourceforge.net/lists/listinfo/licurgo-devs > -- Alberto Molpeceres alb...@li... (+34) 661 304 614 Linking Paths Francisco Maci=E1 11, 7=BA - 48014 Bilbao (+34) 944 764 328 http://www.linkingpaths.com |
From: Enrique R. L. <las...@ja...> - 2006-02-16 21:31:09
|
Hi, SDO es uns standard que define un acceso a datos a traves de objetos dinámicos. Licurgo-sql intenta ser una implementación de ese estandard para acceder a base de datos. Licurgo-xml será un sistema ce lectura y escritura de xml mediante modelos dinámicos. Modelos dinamicos de objetos al contrario de los POJOS permite al programador crear nuevos campos en los objetos. A día de hoy que yo sepa se puede hacer de dos formas 1.- Modificando la estructura de las clases compiladas en tiempo de ejecución 2.- Utilizando SDO, y en definitiva un HashMap por entidad en vez de un pojo por entidad. De esta forma yo hago get("id") y me devuelve el id, pero tb puedo hacer set("nombre","Enrique") y creo un campo nombre con valor Enrique. No se si me explico. El jue, 16-02-2006 a las 20:59 +0000, Diego Campodónico escribió: > dos los aspectos de persistencia a una framework y concentrarse en la > especificacion de SDO? > > Tal ves estas preguntas surgan de mi ignorancia, por eso me gustaria > preguntar: cual es el objetivo final de licurgo (al menos de > licurgo-sql y que lo diferencia de licurgo-xml)? -- _______________________________ Enrique Rodriguez Lasterra lasterra AT javahispano DOT org http://www.javahispano.org Asociación sin ánimo de lucro sobre java Spanish non profit association about java |
From: <rd...@ya...> - 2006-02-16 20:59:57
|
Buenas, mi nombre es Diego Campodonico. Durante estos dias estuve estudiando un poco los fuentes de licurgo y me surgen algunas dudas: Licurgo trata de ser una implementacion de la JSR-235 (SDO), pero a mi me parece mas una framework de persistencia que trata de resulver un problema en particular, el manejo de atributos dinamicos, estoy en lo correcto? No se podria dejar todos los aspectos de persistencia a una framework y concentrarse en la especificacion de SDO? Tal ves estas preguntas surgan de mi ignorancia, por eso me gustaria preguntar: cual es el objetivo final de licurgo (al menos de licurgo-sql y que lo diferencia de licurgo-xml)? gracias diego --------------------------------- A tu celular ¿no le falta algo? Usá Yahoo! Messenger y Correo Yahoo! en tu teléfono celular. Más información aquí. |
From: Enrique R. L. <las...@ja...> - 2006-02-11 12:29:05
|
Hola Diego, hemos recibido tu petición de incorporarte al proyecto licurgo. El proyecto empezó sus andaduras en javahispano.net, pero por problemas que hubo en su día lo movimos a sourceforge.net. Ahora mismo estamos pensando en volver, pero aún no es el momento. ;-) Licurgo se esta usando en varios proyectos en producción, por lo que acceder a realizar commits en el proyecto no puede estar al alcance de cualquiera. EL primer paso debe ser estudiar y comprender licurgo y sus objetivos. Posteriormente iremos viendo como integrarte en el desarrollo del proyecto. Actualmente yo soy quien mas cambios hace y mi roadmap es el siguiente. 1.- Crear la version 0.1 de licurgo-xml, sistema para leer y escribir archivos xml basandose en xml-schema como meta-información de los documentos. 2.- Utilizar licurgo-xml en la lectura de los propios archivos de configuración de licurgo-sql 3.- Dar soporte de cache de primer nivel para licurgo-sql mediante multiples sistemas de cache ehcache, JCS y otros 4.- Crear un soporte de transacciones paralelo al actual que ligue las transacciones al hilo de ejecución actual como hace hibernate. 5.- Adaptarnos mejor al estandard SDO. Mas o menos son las cosas que tengo en el TODO. Tampoco tienen porque ser en ese orden, pero mas o menos es el plan que tengo en la cabeza. En cualquier caso el primer paso es apuntarte en sourceforge y hacer un checkout del proyecto. No olvides apuntarte a la lista de distribución de desarrolladores donde puedes preguntarnos cualquier duda sobre licurgo. I cu Un saludo, Enrique. -- _______________________________ Enrique Rodriguez Lasterra lasterra AT javahispano DOT org http://www.javahispano.org Asociación sin ánimo de lucro sobre java Spanish non profit association about java |
From: Enrique R. L. <las...@ja...> - 2006-02-05 11:32:41
|
Aparentemente licurgo no soportaba nulls. Supongo q esto pasa desde que cambie licurog para que funcionara con PreparedStatments. He realizado un commits para que licurgo pueda utilizar nulos con Query.Equals, Query.NOT_EQUALS, Query.IS_NULL and Query.IS_NOT_NULL. Mi pregunta ahora es que debería hacer licurgo con sentencias como esta 1.- query.addAndPredicate("total", null, Query.LIKE); 2.- query.addAndPredicate("total", null, Query.IN); 3.- query.addAndPredicate("total", null, Query.GREATER_THAN); En las 2 primeras yo lanzaria una excepcion porque creo q no tiene sentido En la 3ª dejaría que la base de datos lo intentará. Saludos. -- _______________________________ Enrique Rodriguez Lasterra lasterra AT javahispano DOT org http://www.javahispano.org Asociación sin ánimo de lucro sobre java Spanish non profit association about java |
From: Enrique R. L. <las...@ja...> - 2006-02-04 11:15:43
|
Si hombre, ya te lo comente un dia q estuvimos hablando en nht sobre licurgo. Alias y ( undo-redo) creo q eran los cambios mas importantes. El vie, 03-02-2006 a las 10:16 +0100, Alberto Molpeceres escribió: > Hi, > > Ni me había enterado, SDO 2.0. A lo mejor ahí se define todo lo que en > la primera quedaba en el aire. > > http://www-128.ibm.com/developerworks/library/specification/ws-sdo/?ca=drs- > > al. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 > _______________________________________________ > Licurgo-devs mailing list > Lic...@li... > https://lists.sourceforge.net/lists/listinfo/licurgo-devs -- _______________________________ Enrique Rodriguez Lasterra lasterra AT javahispano DOT org http://www.javahispano.org Asociación sin ánimo de lucro sobre java Spanish non profit association about java |
From: Alberto M. <alb...@gm...> - 2006-02-03 09:17:03
|
Hi, Ni me hab=EDa enterado, SDO 2.0. A lo mejor ah=ED se define todo lo que en la primera quedaba en el aire. http://www-128.ibm.com/developerworks/library/specification/ws-sdo/?ca=3Ddr= s- al. |
From: Alberto M. <alb...@gm...> - 2006-01-31 08:46:28
|
Hola, Oficialmente ya tenemos fichero de Licurgo para descarga, y tag en el CVS, v_0_4. Me falta meter en la documentaci=F3n las p=E1ginas del wiki (si alguno tiene inter=E9s esta el ejemplo en OCAS), pero bueno, que lo sepais. https://sourceforge.net/project/showfiles.php?group_id=3D138690 al. |
From: Enrique R. L. <las...@ja...> - 2006-01-29 13:05:36
|
> No sé como, pero bueno, ya veremos el día que haya soporte para > LDAP o XML, si algún día lo hay!. Quizas tenga alsun secreto.. pero quizas sea pronto para contarlo. > -- _______________________________ Enrique Rodriguez Lasterra lasterra AT javahispano DOT org http://www.javahispano.org Asociación sin ánimo de lucro sobre java Spanish non profit association about java |
From: Alberto M. <alb...@gm...> - 2006-01-29 12:50:10
|
On 1/29/06, Enrique Rodriguez Lasterra <las...@ja...> wrote: > > > > > - He cambiado muchos m=E9todos de JDBCDataSource de public a protected. > > Espero que no supong aun problema a nadie, no creo que esteis > > us=E1ndolos fuera. Al menos no deber=EDais. > > Umm, ahora reviso tus cambios, si es cierto que hay veces que he hecho > algun metodo publico porque necesitaba que ca=F1amo lo llamase. Hombre. Creo que s=F3lo he cambiado los que afectaban a las transacciones, los que recib=EDan la conexi=F3n. Alguno m=E1s tambi=E9n, pe= ro creo que nada que pareciera demasiado importante. Pero bueno, con actualziar el jar y recompilar canyamo lo ver=E1s enseguida. Sorry. > > - No s=E9, hay demasiados cast por ah=ED un poco raros qu tendr=EDamos = que > > mirar. Mios en gran parte supongo tambi=E9n. E "ifs" sin llaves!. Eso s= i > > que me mata!. Supongo que ser=E1 de alguna decompilaci=F3n, porque no l= o > > entiendo. > Si, yo tb me he dado cuenta que en lagunos metodos utilizamos Type y en > otros JDBCType o DataType. Creo q si estamos trabajando en el paquete > jdbc deberiamos de utilizar siempre el mas cercano a el, en este caso > JDBCType. Hombre, lo que a mi me preocupa es que te pueden pasar "cualquier otra cosa". No s=E9 como, pero bueno, ya veremos el d=EDa que haya soporte para LDAP o XML, si alg=FAn d=EDa lo hay!. al. |
From: Alberto M. <alb...@gm...> - 2006-01-29 12:47:48
|
> El otro dia comentaba con marcos como hacia esto hibernate. Hibernate > cuando trabaja con transacciones asocia la conexi=F3n al hilo que esta > ejecutando el proceso. De esta forma queda mucho mas limpio el codigo. > Ejemplo. > > TransacionManager.startTransaction();//aqui se asocia una conexion al > hilo de ejecuci=F3n > > ... > ... > Trabajamos normal con licurog accediendo al datasource, este se encarga > de buscar si tenemos una conexion asociada eal hilo, en ese caso, la > utiliza. > ... > > TransacitonManager.commit() No s=E9. =DAltimamente eh estado trabajando con JDO, que utiliza un sistema similar. La verdad es que no me ha gustado demasiado. En realidad, ten=EDa casi toda la aplicaci=F3n basada en JDO y he tirado para atr=E1s, reemplez=E1ndolo por Licurgo (por eso todo el tema de las transacciones). A mi me gusta como esta ahora, puesto que te permite tener dos accesos a la base de datos simult=E1neos. Por ejemplo... quiero estar por una parte haciendo mi transacci=F3n completa (por ejemplo, borrar todos los registros, cargarlos y despu=E9s hacer un update de "algo"), mientras que por otra parte puedo tener otro acceso a la base de datos para registrar en un log lo que pasa. Me pareci=F3 limpio, pero me ocasionaba m=E1s problemas que alegr=EDas. Por no hablar del tema de lazyloading. > No he tenido mucho tiempo de mirarlo mas. Simplemente queria comentarlo > por si querias darle un vistazo. Nosotros no utlilizamos transacciones y > los test al menos a mi no me pasaban como estaba programado. Los test no los he mirado, eso es cierto. > > - He hecho un nuevo m=E9todo para "delete", que recibe una Query. Es > > decir, borrar=E1 todo lo que devuelva esa query. Ese ya funciona, dentr= o > > y fuera de la transacci=F3n. > Perfecto, estaria bien hacer algo parecido con las updates. Tienes > alguna idea de como implementarlo. Ummm..... Hombre. M=E1s dif=EDcil, aunque se puede hacer. Para el delete ha sido muy f=E1cil. He creado una query, cogido su SQL, y reemplazado el "select ....." (hasta el from) por "delete ". F=E1cil e indoloro. Parece. > > - Ya que he a=F1adido cosas a la interface (de DataSource, Transaction = y > > DataSourceRegistry) he subido el n=FAmero de versi=F3n a la 0.4. Sin be= ta > > ni nada. Aunque hasta que no termine las "novedades" de las > > transacciones no sea final (al menos por mi parte). > > Bueno.. como veas. Yo quiero mejorar lo de las queries by name, pero > podemos dejarlo para la 0.5. Hombre. Se trataba m=E1s que nada de una actualizaci=F3n "urgente". Me parece bien seguir planteando la 0.5 como la siguiente versi=F3n. aunque supongo que a lo mejor te refieres a lo de "quitar el beta". La verdad es que no estar=EDa de m=E1s poner un paquete para descarga por si algui=E9n se pasa por la web despu=E9s de leeer mi art=EDculo, que no se cuando se publicar=E1 en jH (en Solo Programadores ser=E1 este mes). al. |
From: Enrique R. L. <las...@ja...> - 2006-01-29 12:40:36
|
Me asustaste. Estos cambios los hice esta semana y solo los estamos usando en un proyecto. La semana pasada implemente la posibilidad de hacer subqueries con licurgo. En principio funciona pero nos faltan pruebas. La idea es esta query.addAndCondition("id", anotherQuery, Query.In); El sáb, 28-01-2006 a las 16:59 +0100, Alberto Molpeceres escribió: > Hola, > > Bueno, pues no tengo muy claro por qué, pero tenía una versión de > AbstractRDBMS vieja (el resto estaba up-to-date), de modo que el tema > del +1 o +2 de las update está solucionado y no hay que hacer el +2 > que yo cometnaba. No he mirado los diff para ver que pasaba, pero > bueno, que lo sepais. > > al. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 > _______________________________________________ > Licurgo-devs mailing list > Lic...@li... > https://lists.sourceforge.net/lists/listinfo/licurgo-devs -- _______________________________ Enrique Rodriguez Lasterra lasterra AT javahispano DOT org http://www.javahispano.org Asociación sin ánimo de lucro sobre java Spanish non profit association about java |
From: Enrique R. L. <las...@ja...> - 2006-01-29 12:38:31
|
> > - He cambiado muchos métodos de JDBCDataSource de public a protected. > Espero que no supong aun problema a nadie, no creo que esteis > usándolos fuera. Al menos no deberíais. Umm, ahora reviso tus cambios, si es cierto que hay veces que he hecho algun metodo publico porque necesitaba que cañamo lo llamase. > > - Había un "getNewIDFromSequence" que estaba en JDBCDataSource pero no > en DataSource. Lo he añadido. De momento sólo lo usa un UIDGenerator, > pero bueno, tiene sentido. Ok. > > - No sé, hay demasiados cast por ahí un poco raros qu tendríamos que > mirar. Mios en gran parte supongo también. E "ifs" sin llaves!. Eso si > que me mata!. Supongo que será de alguna decompilación, porque no lo > entiendo. Si, yo tb me he dado cuenta que en lagunos metodos utilizamos Type y en otros JDBCType o DataType. Creo q si estamos trabajando en el paquete jdbc deberiamos de utilizar siempre el mas cercano a el, en este caso JDBCType. |
From: Enrique R. L. <las...@ja...> - 2006-01-29 12:35:59
|
El sáb, 28-01-2006 a las 12:23 +0100, Alberto Molpeceres escribió: > Hola, > > Bueno, voy a subir un par de cambios ahora mismo. > > - Por un parte, he empezado a aumentar lo que las transacciones pueden > hacer. Enrique quería que pudieran hacer select, etc. y dentro de poco > ya podrán. Al menos los métodos están ahí. Ahora sólo hay que > "duplicar" los métodos en el DataSource para que acepten recibir o no > la conexión. El otro dia comentaba con marcos como hacia esto hibernate. Hibernate cuando trabaja con transacciones asocia la conexión al hilo que esta ejecutando el proceso. De esta forma queda mucho mas limpio el codigo. Ejemplo. TransacionManager.startTransaction();//aqui se asocia una conexion al hilo de ejecución ... ... Trabajamos normal con licurog accediendo al datasource, este se encarga de buscar si tenemos una conexion asociada eal hilo, en ese caso, la utiliza. ... TransacitonManager.commit() No he tenido mucho tiempo de mirarlo mas. Simplemente queria comentarlo por si querias darle un vistazo. Nosotros no utlilizamos transacciones y los test al menos a mi no me pasaban como estaba programado. > > - He hecho un nuevo método para "delete", que recibe una Query. Es > decir, borrará todo lo que devuelva esa query. Ese ya funciona, dentro > y fuera de la transacción. Perfecto, estaria bien hacer algo parecido con las updates. Tienes alguna idea de como implementarlo. > > - En DataSourceRegistry había un método "get" que devolvía todos los > datasources en forma de lista. Pero de lista de HashMap$Entry, no sé > por qué. Lo he deprecado y he puesto un getAll que devuelve una lsita > de DataSource. No sé si lo usabais directamente. Esto ya lo comentamos hace tiempo, porque rober y yo nos quedamos flipados. Es posible q sea por alguna descompilación. > > - Ya que he añadido cosas a la interface (de DataSource, Transaction y > DataSourceRegistry) he subido el número de versión a la 0.4. Sin beta > ni nada. Aunque hasta que no termine las "novedades" de las > transacciones no sea final (al menos por mi parte). Bueno.. como veas. Yo quiero mejorar lo de las queries by name, pero podemos dejarlo para la 0.5. > > Creo que no me dejo nada. > > al. > > -- > Alberto Molpeceres > alb...@li... > (+34) 661 304 614 > > Linking Paths > Francisco Maciá 11, 7º - 48014 Bilbao > (+34) 944 764 328 > http://www.linkingpaths.com > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 > _______________________________________________ > Licurgo-devs mailing list > Lic...@li... > https://lists.sourceforge.net/lists/listinfo/licurgo-devs -- _______________________________ Enrique Rodriguez Lasterra lasterra AT javahispano DOT org http://www.javahispano.org Asociación sin ánimo de lucro sobre java Spanish non profit association about java |
From: Alberto M. <alb...@gm...> - 2006-01-28 15:59:39
|
Hola, Bueno, pues no tengo muy claro por qu=E9, pero ten=EDa una versi=F3n de AbstractRDBMS vieja (el resto estaba up-to-date), de modo que el tema del +1 o +2 de las update est=E1 solucionado y no hay que hacer el +2 que yo cometnaba. No he mirado los diff para ver que pasaba, pero bueno, que lo sepais. al. |