2015-06-29 9:20 GMT+02:00 Antonio Roncero ronc...@gmail.com:
El lunes, 29 de junio de 2015, 7:21:32 (UTC+1), Jesús Martín Jiménez
escribió:
Hola Antonio,
El 27 de junio de 2015, 10:56, Antonio Roncero ron...@gmail.com
escribió:
El viernes, 26 de junio de 2015, 14:42:55 (UTC+1), Jesús Martín Jiménez
escribió:
Hola Antonio,
El 26 de junio de 2015, 15:33, Antonio Roncero ron...@gmail.com
escribió:
Hola,
estoy trabajando con campos tipo binary en los modelos y no se si podrá
hacer lo siguiente (y si no podria ser una propuesta):
Decirle de alguna manera al tipo Binary, con un campo en la firma o
algo asi, que el binario se almacene o en la base de datos (por defecto) o
en el sistema de archivos para, si nos interesase, no almacenarlo siempre
en
la base de datos y no tratarlo como un ir.attachment.
Los ficheros que se guardan en el modelo ir.attachment no se guardan en
la base de datos sino en el sistema de ficheros. Por lo tanto, si quieres
guardar algún fichero desde tryton y que éste no te lo guarde en la base de
datos, creo que es una buena opción hacerlo mediante un campo M2O que
apunte
a ir.attachment y allí guardarlo.
Por eso comentaba, al existir un campo Binary, que no necesita relación,
sino que es parte del modelo en si, seria interesante que tuviera la opcion
de guardarlo en el sistema de archivos.
Para hacer eso yo definiría un mínimo de tres campos:
1.- Un campo booleano para indicar si quieres guardar el fichero en la
base de datos o en el sistema de ficheros.
2.- El campo binario para guardar el fichero en la base de datos en el
caso de que el anterior campo así lo estableciese. Este campo no sería
visible desde las vistas.
3.- Un campo binario dentro de un campo funcional que, dependiendo del
campo booleano, guardase el fichero en el sistema de ficheros o en la base
de datos (el campo anterior). Para ello tendría que definir las funciones
getter y setter.
Por lo tanto entiendo que lo que quieres hacer, ya se puede hacer con lo
que hay. No se si eso responde a tu pregunta.
Hola, tengo claro que ya se puede hacer (pero por esa regla de tres sobra
fields.Integer, big integer porque a partir del float lo podria tener...),
pero me parecia una opción interesante por poder decidir el almacenamiento
en la propia definicion de un tipo existente y que tiene repercusiones de
espacio y rendimiento. Simplemente me parecia una posible mejora del tipo
Sólo aclarar que no debería afectar al rendimiento del ERP [1]. Sólo
en los dumps/restores de la base de datos.
[1] http://www.postgresql.org/docs/9.4/static/storage-toast.html
Saludos,
¿Se puede hacer? o lo veis interesante... o ¿hay alguna alternativa?
gracias
Saludos,
--
Jesús Martín
Zikzakmedia SL
C/ de Sant Jaume, 9, baixos, 2ª
08720 Vilafranca del Penedès
☏ 93 890 21 08
--
Jesús Martín
Zikzakmedia SL
C/ de Sant Jaume, 9, baixos, 2ª
08720 Vilafranca del Penedès
☏ 93 890 21 08
--
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com
