Hacer INNER JOIN no normal en propel

[sonickseven]

tengo una consulta que no se como pasar a propel, la verdad es un inner join sencillo pero con esa vuelta de propel se me ha complicado algo.

este es la consulta:

Código MySQL:

SELECT us.Name, us.ID
FROM SI_Users us 
INNER JOIN SI_ClientCompany cp ON us.ClientCompanyId=cp.Id
INNER JOIN SI_DocTransport dt ON dt.ClientCompanyId=cp.Id
INNER JOIN SI_DO DO ON DO.DocTransportId=dt.Id
WHERE us.UserTypeId=1;
 

la cosa es que la medio pude hacer pero mostrando los campos de la tabla SI_ClientCompany, peroasi no me sirve. Necsito es solo de usuario. Ya busque pero no hay alguna ayuda sobre ese tipo de join,

este es el esquema




les agradeceria mucho si me pueden ayudar con ese problema.

[hhs]

Revisa la documentación siempre puedes ejecutar una consulta sin el orm:
http://propelorm.org/documentation/03-basic-crud.html revisa la sección using custom sql

[sonickseven]

yo lo solucfione con una consulta casi que directa, ya que esa documentacion de propel es para robots!!!, Al igual por mas perfecto que sea Propel nunca se va a acomodar a un sintax sql.

Gracias de todas maneras

[NSD]

Aca hay un ejemplo de como hacer joins en Propel.

Por cierto, dbal o querys builders los hay mucho mejores que Propel.

[hhs]

Iniciado por sonickseven

yo lo solucfione con una consulta casi que directa, ya que esa documentacion de propel es para robots!!!, Al igual por mas perfecto que sea Propel nunca se va a acomodar a un sintax sql.

Gracias de todas maneras

LOs ORM no son la panacea tienen limites como cualquier software así que el problema no es el ORM si no quien lo usa.
Para que alguien te ayudara de forma mas completa se requiere conocer tu modelo, lo que te comente era la solución basado en lo que publicaste, pero si hubieras publicado tus clases hubiera sido mas sencillo decirte algo mas acertado. La próxima vez toma en cuenta eso.

La solución como consulta directa estaba a la mano en la documentación: http://propelorm.org/documentation/03-basic-crud.html con un ejemplo:

Código PHP:

use Propel\Runtime\Propel;
$con = Propel::getWriteConnection(\Map\BookTableMap::DATABASE_NAME);
$sql = "SELECT * FROM book WHERE id NOT IN "
        ."(SELECT book_review.book_id FROM book_review"
        ." INNER JOIN author ON (book_review.author_id=author.ID)"
        ." WHERE author.last_name = :name)";
$stmt = $con->prepare($sql);
$stmt->execute(array(':name' => 'Austen'));
 

Ahora tu consulta "compleja" también puede ser resuelta desde el query builder de propel sin ningún problema: http://propelorm.org/documentation/r...-criteria.html, pero el detalle es que tienes que acostumbrarte no solo a leer documentación, también tienes que conocer que hay detrás de estas cosas para que comprendas como puedes usarlas. Así que quítate esa Apatía, cambia tu paradigma y toma como área de oportunidad tus deficiencias. Sobre todo si vas a trabajar con este tipo de herramientas

Iniciado por NSD

Aca hay un ejemplo de como hacer joins en Propel.

Por cierto, dbal o querys builders los hay mucho mejores que Propel.

Propel cuenta con un Query Builder muy potente, que opciones recomiendas NSD ?

[NSD]

Iniciado por hhs

Propel cuenta con un Query Builder muy potente, que opciones recomiendas NSD ?

No he usado Propel en un proyecto real por lo que no estoy calificado como para decir realmente cuales son sus limitaciones, al ser parte de un ORM, también es difícil de saber (sin ponerse a usarlo y a probar, me refiero) si los que a simple vista lo parecen, son realmente limitantes.

La impresión que me lleve al leer la documentación (que por cierto, la leí semi-completa hace un tiempo, no solo este caso particular) es que tiene muchas cosas para hacer poco, y que las tareas mundanas de todos los días se vuelven complejas (por ejemplo este caso de hacer un par de joins) a cambio de simplificar otras tareas que rara vez son requeridas.

Un query builder que me gusto desde el punto de vista de la usabilidad es el de Laravel, sumamente elegante y que no complica las cosas mas de lo estrictamente necesario.

Otro que es un poco mas complejo pero interesante es el de Zend, si bien es mas complejo que el de Laravel, también es mas extensible que este.

Doctrine por su parte también tiene uno interesante aunque no tan completo como los anteriores.

Al lado de estos, Propel, (desde mi punto de vista) es mas limitado.

No obstante, todos los mencionados previamente, tienen 3 grandes problemas:
1) Dependencia del entorno:
Cada uno esta pensado para integrarse perfectamente con su Framework o con componentes de este, pero al sacarlo de allí y querer usarlo de forma aislada presentan inconvenientes o molestias que obligan a adaptarse a su forma de trabajar.

2) Eficiencia y organización:
En general, cada QB son decenas de archivos, decenas de clases, cientos de métodos, muchas interfaces, muchas lineas de código, etc que terminan por lograr, que solo el que las programo las entienda y que un simple SELECT demore mucho mas de lo que debería simplemente por el nivel de abstracción del modelo.

3) Ineficiencia en sentencias preparadas:
Ninguno de estos query-builder saca provecho de las sentencias preparadas. Las usan como medio de seguridad pero no de optimizacion.
Así, si yo quiero realizar 20 consultas, termino preparando 20 sentencias en vez de reutilizar las anteriores.
Ni hablar de los que ademas, se basan en PDO.

Personalmente prefiero usar DBAL simples, de un solo archivo, una única clase, menos de 1500 lineas de código incluyendo documentación. Por ejemplo esta que es la que actualmente me encuentro desarrollando, donde intento implementar de forma minimalista, los métodos y características mas útiles de los QB antes mencionados y de muchos otros mas pequeños que son muy precarios pero que tienen una idea interesante dentro.

[hhs]

Iniciado por NSD

No he usado Propel en un proyecto real por lo que no estoy calificado como para decir realmente cuales son sus limitaciones, al ser parte de un ORM, también es difícil de saber (sin ponerse a usarlo y a probar, me refiero) si los que a simple vista lo parecen, son realmente limitantes.

La impresión que me lleve al leer la documentación (que por cierto, la leí semi-completa hace un tiempo, no solo este caso particular) es que tiene muchas cosas para hacer poco, y que las tareas mundanas de todos los días se vuelven complejas (por ejemplo este caso de hacer un par de joins) a cambio de simplificar otras tareas que rara vez son requeridas.

No es asi, es lo mismo que con cualquier otro QB de los que mencionas mas abajo solo cambia como están diseñados y sus interfaces.

Un query builder que me gusto desde el punto de vista de la usabilidad es el de Laravel, sumamente elegante y que no complica las cosas mas de lo estrictamente necesario.

Otro que es un poco mas complejo pero interesante es el de Zend, si bien es mas complejo que el de Laravel, también es mas extensible que este.

Doctrine por su parte también tiene uno interesante aunque no tan completo como los anteriores.

Al lado de estos, Propel, (desde mi punto de vista) es mas limitado.

De los que mencionas el unico con el que no e trabajado es con el de Zend y reduciendo las cosas a sus QB con todos puedes hacer lo mismo mas prestaciones propias de cada diseño como en el caso de Laravel con su interfaz fluida.

No obstante, todos los mencionados previamente, tienen 3 grandes problemas:
1) Dependencia del entorno:
Cada uno esta pensado para integrarse perfectamente con su Framework o con componentes de este, pero al sacarlo de allí y querer usarlo de forma aislada presentan inconvenientes o molestias que obligan a adaptarse a su forma de trabajar.

Falso, pueden ser usados de forma independiente, algunos usan cosas de terceros como Propel pero son facilidades. Tampoco te obligan puede usarlos a diferente nivel de abstracción segun te convenga, las molestias están en el nivel de preparación del programador.

2) Eficiencia y organización:
En general, cada QB son decenas de archivos, decenas de clases, cientos de métodos, muchas interfaces, muchas lineas de código, etc que terminan por lograr, que solo el que las programo las entienda y que un simple SELECT demore mucho mas de lo que debería simplemente por el nivel de abstracción del modelo.

Son eficientes y están perfectamente organizados y ese centenar de archivos molestos tienen un razón de ser. la demora es es algo que no tiene menor problema todos los ORM te permiten trabajar a diferentes niveles de abstracción; asi que si necesitas mejores tiempos estos QB son suficientemente felxibles para hacer lo que necesites.

3) Ineficiencia en sentencias preparadas:
Ninguno de estos query-builder saca provecho de las sentencias preparadas. Las usan como medio de seguridad pero no de optimizacion.
Así, si yo quiero realizar 20 consultas, termino preparando 20 sentencias en vez de reutilizar las anteriores.
[/code]
Falso, si optimizan sus consultas de forma diferente cuentan con una forma de construir la gramatica que soporta un RDBM especifico y tener la consulta preparada para su reutilización.

Vuelvo al punto no es el ORM o el QB si no la mente de quien lo usa lo que crea una ventaja o una limitación.

Personalmente prefiero usar DBAL simples, de un solo archivo, una única clase, menos de 1500 lineas de código incluyendo documentación. Por ejemplo esta que es la que actualmente me encuentro desarrollando, donde intento implementar de forma minimalista, los métodos y características mas útiles de los QB antes mencionados y de muchos otros mas pequeños que son muy precarios pero que tienen una idea interesante dentro.

Te felicito y es valida

Es valido tu punto de vista, cada quien decide la forma de abordar y solucionar un problema.

[NSD]

Voy a discernir en un par de detalles de lo que mencionas.

No es asi, es lo mismo que con cualquier otro QB de los que mencionas mas abajo solo cambia como están diseñados y sus interfaces.

No es la impresión que me lleve al leer la documentación, pero como no lo he usado, confiare en tu palabra (hasta que lo pruebe por mi mismo).

Falso, pueden ser usados de forma independiente, algunos usan cosas de terceros como Propel pero son facilidades. Tampoco te obligan puede usarlos a diferente nivel de abstracción segun te convenga, las molestias están en el nivel de preparación del programador.

Yo no lo veo asi.
Si los saco y los quiero usar por separado con otro conjunto de librerías hay que hacer algunas adaptaciones, como tu dices, depende del nivel del programador si hacerlas se convierte en una odisea épica o solo es juego de niños.
¿O acaso usar Doctrine con el QB de Laravel o viceversa solo se trata de cambiar los archivos de carpeta?
Eso es lo que la abstracción te vende, pero no lo que ocurre en la practica.
Por supuesto, si se hacen las adaptaciones correspondientes pueden funcionar correctamente, pero volvemos a lo anterior.
Como programador si agarro un QB (o cualquier otro componente) es porque quiero usarlo, no adaptarlo o modificarlo.

Son eficientes y están perfectamente organizados y ese centenar de archivos molestos tienen un razón de ser. la demora es es algo que no tiene menor problema todos los ORM te permiten trabajar a diferentes niveles de abstracción; asi que si necesitas mejores tiempos estos QB son suficientemente felxibles para hacer lo que necesites.

No pongo en duda la importancia para el buen funcionamiento de cada linea de código en cada archivo del componente. Pero no es lo mismo levantar una clase que 20, es tiempo muerto que se pierde parsenado, compilando, definiendo, instanciando, es memoria que se gasta en guardar definiciones y referencias, etc. Cuando hay muchos usuarios simultáneos la suma de estos tiempos muertos se vuelve significante, ¿Y que haces ahi? bajar el nivel de abstracción, remover clases e interfaces y trabajar a un menor nivel, entonces, ¿para que quiero un QB gigante si cuando necesito respuestas rápidas tengo que reducirlo únicamente a su núcleo? ¿no seria mejor tener de entrada solo el núcleo, pero que sea lo mas completo posible?

Falso, si optimizan sus consultas de forma diferente cuentan con una forma de construir la gramatica que soporta un RDBM especifico y tener la consulta preparada para su reutilización.

Voy a informarme mas sobre el tema antes de responder a esto, pero las pruebas que he realizado con varios QB no hacían uso de esta optimizacion en consultas repetitivas.

Vuelvo al punto no es el ORM o el QB si no la mente de quien lo usa lo que crea una ventaja o una limitación.

Claro que no, tampoco lo es el FW ni el lenguaje, los programadores con buena mente logran ventajas programando sitios web en hexadecimal, para ellos no existen limitaciones.

Como la gran mayoría somos personas limitadas, necesitamos de un FW que nos imponga la menor cantidad de limitaciones posibles, ya son bastantes las que nos ponemos nosotros mismos.


PD: Mas allá del discernimiento, voy a investigar los puntos que mencionas por si estoy equivocado.