libreqda / libreQDA

Other
10 stars 7 forks source link

52 or more characters filenames support (Soporte de nombre de archivos de mas de 52 caracteres) #17

Open jmunoz298 opened 10 years ago

jmunoz298 commented 10 years ago

Issue creado por Alen en Git-Tryolabs

1234567890123456789012345678901234567890123456789012.docx SI 12345678901234567890123456789012345678901234567890123.docx NO Da el error: Warning at /project/7/document/add/ Data truncated for column 'file' at row 1 Request Method: POST Request URL: http://demo.libreqda.edu.uy/project/7/document/add/ Django Version: 1.4.3 Exception Type: Warning Exception Value:

Data truncated for column 'file' at row 1 Exception Location: /usr/local/lib/python2.7/dist-packages/MySQLdb/cursors.py in warningcheck, line 117 Python Executable: /usr/bin/python Python Version: 2.7.3 Python Path:

['/usr/share/libreqda', '/usr/local/lib/python2.7/site-packages', '/usr/share/libreqda/src/docx', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/local/lib/python2.7/dist-packages/PIL', '/usr/lib/python2.7/dist-packages'] Server time: mar, 2 Abr 2013 00:39:53 -0300

jmunoz298 commented 10 years ago

AMARTINEZUY commented:

Es correcto, la restricción actual es la siguiente:

Largo máximo de nombre de archivo = 100 - LARGO(ruta a carpeta donde se guardan los archivos)

Es posible aumentar el largo máximo (el actual es el que Django pone por defecto). Es importante entender que este cambio implica modificar los modelos de la aplicación. Para eso deberíamos agregar South a los requerimientos del proyecto.

jmunoz298 commented 10 years ago

Considero que si hay que tocar el modelo, podríamos asumir esta restricción

marcbria commented 10 years ago

Estoy con Juan. En cualquier caso, aunque el funcionamiento sea el mismo, un mensaje como "El nombre del fichero es demasiado largo" da mucha más tranquilidad al usuario final.

¿Podemos cambiar el issue por "Derivar los errores estrepitosos a un log y informar al usuario del problema detectado"?

La idea que propongo NO es pedir a los desarrolladores que implementen una mejor gestión de errores, sino que entre todos reportemos aquellos errores habituales (que se informan como si fuese el fin del mundo) y se cambien por mensajes comprensibles.

Juan ¿este "reportar errores habituales con mensajes comprensibles" te parece algo que deba entrar en la 1.0? Si la respuesta es si, deberíamos hacer una lista de errores a filtrar (ahora me miro el resto de bugs a ver si ya lo contemplan).