Proyecto

General

Perfil

Errores #2701

Errores MySQL 5.7

Añadido por Santiago Ramos hace casi 8 años. Actualizado hace casi 7 años.

Estado:
Resuelta
Prioridad:
Alta
Asignado a:
Santiago Ramos
Categoría:
Desarrollo
Versión prevista:
Versión 2.51
Fecha de inicio:
2016-04-28
Fecha fin:
% Realizado:

100%

Descripción

La versión de MySQL 5.7 rompe algunas querys de gong provocando errores del tipo:

Expression of SELECT list is not in GROUP BY clause and contains nonaggregated column

Esta versión de MySQL es la instalada en actualizaciones desde brew de OSX y en la última versión de Ubuntu (16.04) y el error se produce por cambios que han hecho para ajustarse a la norma SQL92 y evitar resultados no deterministas:

https://dev.mysql.com/doc/refman/5.7/en/group-by-handling.html

Se puede forzar la implementación de group_by anterior al cambio (cambio en sql-mode del servidor de bbdd) pero la mejor solución es corregir las querys para que no presenten errores.

Peticiones relacionadas

relacionada con Gong - Errores #3270: Errores MySQL 5.7 Resuelta 2018-02-09

Histórico

#1 Actualizado por Santiago Ramos hace casi 8 años

  • Asunto cambiado Error SQL92 por Error group_by SQL92

#2 Actualizado por Santiago Ramos hace casi 8 años

  • Asunto cambiado Error group_by SQL92 por Errores MySQL 5.7

Otro error más:

En el listado de gastos de un proyecto se produce el siguiente error:

Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'gong_oei.gasto.fecha' which is not in SELECT list; this is incompatible with DISTINCT: SELECT  DISTINCT `gasto`.id FROM `gasto` INNER JOIN `gasto_x_proyecto` ON `gasto_x_proyecto`.`gasto_id` = `gasto`.`id` LEFT OUTER JOIN `partida` ON `partida`.`id` = `gasto`.`partida_id` LEFT OUTER JOIN `agente` ON `agente`.`id` = `gasto`.`agente_id` WHERE `gasto_x_proyecto`.`proyecto_id` = 582 ORDER BY fecha ASC LIMIT 20 OFFSET 0

Si eliminamos el will paginate, la query queda como:

Gasto.joins(joins).where(condiciones_marcado).
          joins(:partida, :gasto_x_proyecto, :agente).where(condiciones).
          order(session[:gasto_proyectos_cadena_orden] + " " + session[:gasto_proyectos_asc_desc])

y no tiene errores, por lo que el fallo está en el will_paginate.

En el Gemfile está definida la versión 3.0.x. Si actualizamos a la versión 3.1.x surge un error:

  ArgumentError (unsupported parameters: :include):
  app/controllers/gasto_proyectos_controller.rb:191:in `listado'

pero se resuelve facilmente reformulando la query:

    @gastos = @paginado =  Gasto.joins(joins).where(condiciones_marcado).
                                 joins(:partida, :gasto_x_proyecto, :agente).where(condiciones).
                                 order(session[:gasto_proyectos_cadena_orden] + " " + session[:gasto_proyectos_asc_desc]).
                                 paginate(:page => (params[:format]=='xls' ? nil : params[:page]), :per_page => (params[:format_xls_count] || session[:por_pagina]) )

#3 Actualizado por Santiago Ramos hace casi 8 años

  • Estado cambiado Nueva por Asignada
  • Asignado a establecido a Santiago Ramos
  • Versión prevista establecido a Versión 2.51

Lo muevo a la 2.51 para indicar que se modifica la gema del will paginate y todas sus querys

#4 Actualizado por Santiago Ramos hace casi 8 años

Resuelto en los cambios:

  • r7650
  • r7652

#5 Actualizado por Jaime Ortiz hace casi 8 años

Jelou,

Hemos visto que en el listado de proyectos (habra que echarle un ojo a otros) las busquedas con joins:

  @proyectos = @paginado = Proyecto.joins(join_tables)

Producen:

SELECT DISTINCT `proyecto`.* FROM `proyecto` INNER JOIN `estado` ON `estado`.`proyecto_id` = `proyecto`.`id` AND estado.estado_actual INNER JOIN `definicion_estado` ON `definicion_estado`.`id` = `estado`.`definicion_estado_id` INNER JOIN `proyecto_x_pais` ON `proyecto_x_pais`.`proyecto_id` = `proyecto`.`id` INNER JOIN `convocatoria` ON `convocatoria`.`id` = `proyecto`.`convocatoria_id` INNER JOIN `proyecto_x_sector_intervencion` ON `proyecto_x_sector_intervencion`.`proyecto_id` = `proyecto`.`id` INNER JOIN `proyecto_x_area_actuacion` ON `proyecto_x_area_actuacion`.`proyecto_id` = `proyecto`.`id` INNER JOIN `proyecto_x_sector_poblacion` ON `proyecto_x_sector_poblacion`.`proyecto_id` = `proyecto`.`id` INNER JOIN `usuario_x_proyecto` ON `proyecto`.`id` = `usuario_x_proyecto`.`proyecto_id` WHERE (convenio_id IS NULL AND definicion_estado.cerrado = 0) ORDER BY proyecto.nombre ASC LIMIT 200 OFFSET 0

Los INNER JOIN hacen que muchos proyectos que no tienen las otras tablas de la asociación con datos no aparezcan (ejemplo: si no tienes ningun sector de intervencion).

Al cambiarlo por inlcude:

  @proyectos = @paginado = Proyecto.includes(join_tables)

SELECT DISTINCT `proyecto`.id FROM `proyecto` LEFT OUTER JOIN `estado` ON `estado`.`proyecto_id` = `proyecto`.`id` AND estado.estado_actual LEFT OUTER JOIN `definicion_estado` ON `definicion_estado`.`id` = `estado`.`definicion_estado_id` LEFT OUTER JOIN `proyecto_x_pais` ON `proyecto_x_pais`.`proyecto_id` = `proyecto`.`id` LEFT OUTER JOIN `convocatoria` ON `convocatoria`.`id` = `proyecto`.`convocatoria_id` LEFT OUTER JOIN `proyecto_x_sector_intervencion` ON `proyecto_x_sector_intervencion`.`proyecto_id` = `proyecto`.`id` LEFT OUTER JOIN `proyecto_x_area_actuacion` ON `proyecto_x_area_actuacion`.`proyecto_id` = `proyecto`.`id` LEFT OUTER JOIN `proyecto_x_sector_poblacion` ON `proyecto_x_sector_poblacion`.`proyecto_id` = `proyecto`.`id` INNER JOIN `usuario_x_proyecto` ON `proyecto`.`id` = `usuario_x_proyecto`.`proyecto_id` WHERE  (convenio_id IS NULL AND definicion_estado.cerrado = 0) ORDER BY proyecto.nombre ASC LIMIT 200 OFFSET
Es decir hace las asociaciones con LEFT JOIN. Asi no perdemos en el listado ningun dato. Se hace un commit con este caso:

r7664
r7665

Es esto correcto ?
Puede suceder esto en mas casos ?

Mersi!

#6 Actualizado por Santiago Ramos hace casi 8 años

Es correcto.

He intentado por lo general usar los includes en lugar de joins para evitar lo que dices, pero en ese caso se me ha debido olvidar.

Repasando el listado de cambios:

https://gong.org.es/projects/gor/repository/revisions/7650/diff

veo también alguna cosa rara en el controlador "tarea" que resuelvo en el commit r7670 .

En el controlador "documento_busqueda" también está cambiado desde "include" a "join", pero en este caso creo que tiene sentido el join (el include usa un having para excluir no encontrados).

El problema de usar el includes en lugar del joins es que la consulta que indicas que se genera aparece en la forma:

SELECT DISTINCT `proyecto`.id FROM `proyecto`

en lugar de

SELECT DISTINCT `proyecto`.* FROM `proyecto`

Esto hace que salte el error de SQL (que pensaba se había resuelto):

Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'gong_oei.proyecto.nombre' which is not in SELECT list

Es decir, como el select es solo de ids, el nombre no esta y no puede hacer el order por él.

Para no liarla más, he modificado el comportamiento de mi MySQL para evitar esos errores, eliminando "ONLY_FULL_GROUP_BY" de los modos soportados:

mysql> SELECT @@GLOBAL.sql_mode;
+-------------------------------------------------------------------------------------------------------------------------------------------+
| @@GLOBAL.sql_mode                                                                                                                         |
+-------------------------------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+-------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0,00 sec)

mysql> SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
Query OK, 0 rows affected (0,00 sec)

mysql> SELECT @@GLOBAL.sql_mode;
+------------------------------------------------------------------------------------------------------------------------+
| @@GLOBAL.sql_mode                                                                                                      |
+------------------------------------------------------------------------------------------------------------------------+
| STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+------------------------------------------------------------------------------------------------------------------------+
Query OK, 0 rows affected (0,00 sec)

#7 Actualizado por Jaime Ortiz hace casi 8 años

  • Versión prevista cambiado Versión 2.51 por 2.52

Creo que este ticket esta cerrado. Por si todavia tuviese trabajo pendiente se mete en la 2.52. Si ya esta cerrado se puede volver a la versión y lo cerramos o incluirlo ya para la proxima.

Gracias!

#8 Actualizado por Santiago Ramos hace casi 8 años

  • Versión prevista cambiado 2.52 por Versión 2.51

Uppss... no habia visto los comentarios. Por mi parte sí lo considero cerrado y si aparece algún otro error en el futuro creo que mejor abrir un nuevo ticket.

#9 Actualizado por Santiago Ramos hace casi 7 años

  • Estado cambiado Asignada por Resuelta
  • % Realizado cambiado 0 por 100

Por error, seguía como activo un ticket cerrado.

#10 Actualizado por Santiago Ramos hace alrededor de 6 años

Exportar a: Atom PDF

Financiado por:
Desarrollado por:
Software libre forjado en: