Conversation
dpgover
left a comment
There was a problem hiding this comment.
Para completar lo que hablamos, falta mejorar la performance ejecutando los merges de joins y bla al hacer el armado del query en el "getQuery" o el "getDQL"
|
Comentario con respecto a la optimización (lo que hablamos por Workplace): 1- es optimización prematura, que realmente no aporta mucho, ya que, cuantos eagerLoadings vas a tener? 200? o cuantos joins únicos vas a tener? |
|
Agreed |
|
El select puede ser tan complejo como se quiera, puede tener subqueries, comparaciones, llamadas a métodos, etc... Entonces no sirve separar por coma y asumir que cada valor es un alias. Vamos a tener que conformarnos con eliminar duplicaciones! Que para la mayoría de los casos nos va a ser útil, por ejemplo, si luego de hacer un join quiero hacer un eager loading de esa relación. |
|
Esta perfecto Marian. Es lo que te dije anteriormente. Es imposible atacar todos los casos. Pero resolvamos los que mas se dan y mas problemas pueden generar. |
$oqb = $em->createQueryBuilder(); // Original QueryBuilder
$oqb->from(Person::class, 'p');
$oqb->select('p');
Ahora la instancia decorada tiene los mismos dqlParts que $oqb
$dqb = new QueryBuilderDecorator($oqb); // DecoratedQueryBuilder
Ahora se pueden combinar from
$dqb->from(Person::class, 'p');
$dqb->from(Person::class, 'p');
$dqb->from(User::class, 'p'); // Esto tira una excepción
$dqb->from(Person::class, 'c'); // Esto NO tira una excepción
Ahora se pueden combinar select
$dqb->addSelect('p, u');
$dqb->addSelect('c');
Ahora se pueden combinar conditions en los joins (toma precedencia el ON, de existir)
$dqb->join('p.user', 'u');
$dqb->join('p.user', 'u', Join::WITH, 'u.activationDate IS NOT NULL');
$dqb->leftJoin('p.user', 'u'); // Esto tira una excepción, ya que el alias está en uso para otro tipo de JOIN