Estoy opensando urilizar SQUERYL en un nuevo proyecto, opiniones?

[Pablo Zebraitis]

[Marcelo Odin]

Hace un tiempo estuve chiveando con el acceso a base de datos con Scala (incluso usando datasources de Spring!). Si estás haciendo una aplicación web p.e. con Play! ¿por qué no ir con Anorm? Me dio la impresión de que había algunas dificultades para integrar Play con otra cosa que no fuera Anorm.

Typesafe, por otro lado, apoya Slick (parecido a LINQ de Microsoft, http://slick.typesafe.com/). Alguna gente prefiere Slick (http://kevinlocke.name/bits/2012/10/03/important-squeryl-limitations/ )

IMHO, ir por lo mainstream puede ayudar si te trancás o precisás soporte. En todo caso, me interesa como sigue tu experiencia con Squeryl.

Saludos,
Marcelo

P.S. Te mando el documento con las pruebas que fui haciendo, por si te sirve. Es un borrador personal así que vas a ver cualquier burrada :-D Obviamente todas las correcciones y sugerencias para mejorar son bienvenidas.

https://dl.dropboxusercontent.com/u/72503141/Acceso%20a%20la%20base%20de%20datos%20desde%20Scala.odt

El 17 de octubre de 2013 08:40, Pablo Zebraitis <pa...@zebraitis.com> escribió:

--
Has recibido este mensaje porque estás suscrito al grupo "Scala Users Group Uruguay" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[fedesilva]

Yo en corto tiempo voy a tener que usar algo y tengo visto Slick. Caballo del comisario, etc etc.

Howeverrrrrr, sqltyped está muy bueno también, y probablemente empiece por ahí. Si durante el desarrollo no veo necesidad de cambiar me parece que me quedo.

Anorm no tocaría. No me preguntes porqué.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-uruguay+unsub...@googlegroups.com.

[Pablo Zebraitis]

Estuve viendo: 

SORM An elegant and scalable way to do persistence in Scala

http://sorm-framework.org/

Parece estar bueno ! 

.)

[Germán Ferrari]

Buenas,

Yo he hecho algunos intentos con Slick y funciona bastante bien en general, pero lamentablemente me he topado con algunos bugs o limitaciones a la hora de usarlo "como yo quiero" que se ve que no es exactamente el uso previsto.
 
Igual 2x3 vuelvo a visitarlo. Ahora está por salir la versión 2.0 que va a generar automáticamente las clases para las tablas y en general resuelve mejor algunas cosas.

No conocía sqltyped. Me resultó interesante. Había visto un experimento que necesitaba type-providers para hacer algo parecido, pero esta biblioteca por lo que vi funciona directamente. A tomar en cuenta definitivamente.

Si no estás usando Oracle otra opción digna de explorar es jOOQ. Es un framework para Java pero tiene cierto soporte para Scala: http://www.jooq.org/doc/3.2/manual-single-page/#jooq-and-scala

Saludos!

2013/10/17 fedesilva <fede....@gmail.com>

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-...@googlegroups.com.

[Pablo Zebraitis]

interesante discusión del tema: https://groups.google.com/forum/#!msg/squeryl/v5QDWnzjxF0/YdtUC4czknMJ

[Rodrigo Cano]

Pablo,

Yo te entendí que estabas usando SLICK no Squeryl, al final cuál es?.

2013/10/17 Pablo Zebraitis <pa...@zebraitis.com>

interesante discusión del tema: https://groups.google.com/forum/#!msg/squeryl/v5QDWnzjxF0/YdtUC4czknMJ

--

[Pablo Zebraitis]

Estoy utilizando slick en un proyecto pero no me satisface, no me gusta el aproach de definir la TABLA (el contenedor) y no la clase en particular del objecto, creo que eso va a cambiar con "direct embedding" como dice Germán (quien creo siente lo mismo).

No tengo problemas con SQL (LANGUAGE), no necesito que alguien haga por mi las consultas y que ese seal al fuerte de este producto.

Como ya te había mensionado antes creo que el resultado, lejos de ser más diáfano queda mucho más complejo, son puntos de vista.

Lo que estoy buscando se acerca bastante a: SORM, que me gustó mucho. Me da "miedito" el soporte que pueda tener  y los bugs que te encuentres una vez lo entrea a usar fuerte...

Obviamente doy por sentado que la solución tiem un motor de base de datos SQL como repositorio, NO NoSql, creo que en esta area el enfoque de SLICK.

En la discusión que postee antes queda bastante claro estos los puntos.

Saludos,

On Thursday, October 17, 2013 2:43:31 PM UTC-2, Rodrigo wrote:

Pablo,

Yo te entendí que estabas usando SLICK no Squeryl, al final cuál es?.

2013/10/17 Pablo Zebraitis <pa...@zebraitis.com>

interesante discusión del tema: https://groups.google.com/forum/#!msg/squeryl/v5QDWnzjxF0/YdtUC4czknMJ

--
Has recibido este mensaje porque estás suscrito al grupo "Scala Users Group Uruguay" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-uruguay+unsub...@googlegroups.com.

[Germán Ferrari]

2013/10/17 Pablo Zebraitis <pa...@zebraitis.com>

Estoy utilizando slick en un proyecto pero no me satisface, no me gusta el aproach de definir la TABLA (el contenedor) y no la clase en particular del objecto, creo que eso va a cambiar con "direct embedding" como dice Germán (quien creo siente lo mismo).

Ojo, el direct-embedding no es a lo que me estaba refiriendo. Creo que le bajaron la prioridad después de que quedó bastante claro que tener type-providers como parte del lenguaje no está en el horizonte cercano. El enfoque de poner anotaciones a los campos nunca me sedujo demasiado de todos modos.

En la versión 2.0 lo que van a hacer es generar automáticamente las clases para poder usar el lifted-embedding sin tener que escribirlo a mano.

 

No tengo problemas con SQL (LANGUAGE), no necesito que alguien haga por mi las consultas y que ese seal al fuerte de este producto.

Como ya te había mensionado antes creo que el resultado, lejos de ser más diáfano queda mucho más complejo, son puntos de vista.

Lo que estoy buscando se acerca bastante a: SORM, que me gustó mucho. Me da "miedito" el soporte que pueda tener  y los bugs que te encuentres una vez lo entrea a usar fuerte...

Obviamente doy por sentado que la solución tiem un motor de base de datos SQL como repositorio, NO NoSql, creo que en esta area el enfoque de SLICK.

En la discusión que postee antes queda bastante claro estos los puntos.

Saludos,

On Thursday, October 17, 2013 2:43:31 PM UTC-2, Rodrigo wrote:

Pablo,

Yo te entendí que estabas usando SLICK no Squeryl, al final cuál es?.

2013/10/17 Pablo Zebraitis <pa...@zebraitis.com>

interesante discusión del tema: https://groups.google.com/forum/#!msg/squeryl/v5QDWnzjxF0/YdtUC4czknMJ

--
Has recibido este mensaje porque estás suscrito al grupo "Scala Users Group Uruguay" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-uruguay+unsub...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

--
Has recibido este mensaje porque estás suscrito al grupo "Scala Users Group Uruguay" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-...@googlegroups.com.

[Pablo Zebraitis]

Lamento no haber visto esto antes:

http://parleys.com/play/52076d7fe4b0f42506c2a3e8/chapter27/about

He cambiado de opinión (creo) ;p

On Thursday, October 17, 2013 8:40:54 AM UTC-2, Pablo Zebraitis wrote:

[Rodrigo Cano]

Acabo de ver todo el video, qué fue lo que te hizo cambiar de opinión (tal vez) con respecto a SLICK?

2013/10/17 Pablo Zebraitis <pa...@zebraitis.com>

[Rodrigo Cano]

Ah, un comentario que quiero agregar, con respecto a lo que dicen en el video de SLICK, sobre acceder a la base de datos para validar el schema utilizando macros como hacen otros frameworks: supongo que en algún flujo de trabajo existe la base de datos independiente del código y es globalmente accesible (la peor idea del mundo), porque de lo contrario, ese setup de los macros accediendo la DB es ideal para hacer que tu build sea local y nunca más ande fuera de esa máquina. Trabajando en grupos, es crucial que el proyecto sea git-cloneable y compilable de una, para eso se hicieron maven y herramientas del estilo, por lo cual me parece que el approach de los macros accediendo una DB es bastante malo.

Usando JOOQ (porque mi proyecto era java), nosotros hicimos un plugin de maven para que en tiempo de generación de recursos (pre compilación) se levantase una base de datos mysql temporal, cargase nuestros scripts de base de datos (esos que distribuimos en los rpms, y que son los que definen la base de datos para nosotros y los sysadmins), y sobre eso correr el generador de jooq. Con eso teníamos validación de los scripts mysql, y typesafety con la DB sin depender de que exista una base de datos (ya que la base de datos temporal era un detalle del build). En mi opinión este es el approach a seguir, y sería más fácil si estos frameworks/libs/whatever soportasen leer directamente los archivos .sql.

Saludos.

2013/10/17 Rodrigo Cano <ioni...@gmail.com>