Compatibilidad de imagenes en campos Blob

[[Delphius]]

Empezado por ElMug

Delphius,

Nada se "cae en pedacitos" ni mi desarrollo es para nada lo que tu recomiendas que "debe uno de hacer".

Con el sistema convencional del Try, se genera dialogo, precisamente para que nada "se caiga en pedacitos".

Si se va cayendo de a pedacitos... Cada vez que requieras darles unos toques al sistema (que los abrá). En esta parte el sistema tiene unos puntos flojos. El punto flojo es haber atacado demasiado la lógica de la aplicación y muy dependiente a los formatos que utilizas y posteriormente desees incorporar.
Por cada formato que introduzcas, o necesites, te verás condicionado a introducir más código (¡y hasta redundante!) lo que hará de dicho método más complejo innecesariamente.... cada nuevo formato implica incrementar la complejidad V(G) en 2. Para dos formatos tienes V(G) = 4, con 2 más, se va a V(G) = 8 y ya es para alarmarse. Semejante valor para la poca cosa.

Además, si ese método se ha ejecutarse cientos de veces, y con más razón, si está atado a los vaivenes de un componente data-ware como un DBGrid ni que decir... porque se estará ejecutando cada vez que se mueva el cursor.
En lo posible hay que evitar estar mostrando contenido BLOB; en el caso de consultas SELECT por ejemplo no extraer dicho campo a menos que sea (y cuando sea) necesario.

Empezado por ElMug

Ademas, si insistes en proponer el uso de otra columna (muy tu camino), yo te recomendaria, en base al criterio de la informatica, que mejor de una vez guardes EL NOMBRE del archivo que cargaste, incluyendo el .bmp o el .jpeg, pues de esa manera no solo tienes guardado el tipo de archivo, sino el NOMBRE (sin la ubicacion original del archivo).

Para tal caso entonces me evito guardar la imagen en la base de datos (que ya de paso me ahorro una buena cantidad de espacio y no queda tan pesada) y las dispongo en un directorio y cargo via LoadFromFile().
Si tu guardas en un BLOB es por algún motivo que suponemos que ya haz evaluado y consideraste que podría ser lo más óptimo y viable a tu caso.
Hay varios hilos sobre este debate, con buscar te enterarás más.
En ningún momento dije de almacenar todo el nombre, sólo me limité a exponer que se requiere de un campo adicional que sirva para identificar el formato adecuado. Puede ser un CHAR, o un INTEGER, eso lo dejo a elección y necesidades de cada quien.
Y vuelvo a explicar: gracias a ese campo las cosas son más sencillas. Ya no necesitas ir metiendo tanto try, finally y tener un código en base a pruebas. Estoy completamente seguro que si preguntas a la mayoría del foro te van a decir que pongas ese campo. Es que es muy directo, se lee dicho campo e inmediatamente ya sabes que TGraphic emplear.
Ganas tiempo y recursos.

Empezado por ElMug

Si quieren otra columna, pues aprovechenla y tengan MAS informacion. Y aparte que el nombre del archivo, usando el load picture dialog, YA tienen el nobre de el, y lo cargarian automaticamente!

Lee lo que dije antes, si así fuera el caso justamente lo cargo y no tendría que estar almacenando la imagen en la base de datos.
Repito: si tu consideraste el BLOB será por algo. Pero en este hilo lo que ha quedado en claro es que no has sabido apreciar las "contras" que ello implica, y te viste atascado en un problema por tu desconocimiento de lo que es un BLOB y asumiste que así como lo metes lo puedes recuperar sin requerir de "algo" que lo interprete. Todo se resume a una ignorancia de tu parte sobre BLOB.

No te recomiendo el campo por el hecho de poner más información, sino por una combinación de NECESIDAD OPERATIVA y una mejor propuesta que equilibra mejor la tercia {codigo,logica,tiempo}. Añadir UN campo más no supone un desperdicio. Distinto fuera si te digo que agregues 50... Pasa por una una combinación de Necesito (Requisito/Restricción) vs Facilidad (Factibilidad Técnica) vs Operatoria (Factibilidad Operativa).

Empezado por ElMug

Y con el simple codigo de checar que la columna con el NOMBRE del archivo contenga los caracteres ".bmp", o ".jp", seria suficiente para saber que tipo de archivo guardaron. No necesitan checar si es "jpeg" o "jpg".

Definitivamente no entras en razón ni entiendes nada.

Empezado por ElMug

No se conformen con solo saber que es ".bmp", o "jpeg". De una vez sepan el nombre de la imagen, con un minimo de pensarle, y con unos cuantos caracteres mas que se almacenarian en la columna, tienen mucha mas informacion util. Por ejemplo, que alguien va la imagen y leyendo la mucho mas util columna "NombreDeArchivo", diga: "ESE no es Juan Perez".

O me van a salir conque guardar ".bmp" o "jpg" en la columna extra sirve para algo mas?

Hasta luego.

Pues si consideras que te van a ser útil pues ¡métele!
Lo que veo es que no has sabido apreciar un enfoque que te podría ser mucho más sano, no sólo ahora, sino en el futuro cuando te toque ver de nuevo ese código y veas tanto try finally para hacer algo que se puede hacer de forma más directa.

Y ahora finalizo dando una mejora a mi propuesta. Debido a que disponer de un case of también implica disponer de la misma creciente V(G) y de retoques en el código para añadir más formatos (aunque es más limpio) aprovechando el campo Tipo/Formato y considerando que se trata de crear una serie de objetos que responden a una fnecesidad poliformica, y como buen defensor de los patrones de diseño propongo: tener una fábrica de TGraphic, esta fábrica recibe como parámetro el tipo indicado y regresa el TGraphic adecuado, de este modo el cliente sólo hace uso de la llamada polimórfica que dispone éste.

Es decir algo simple como:

Código Delphi [-]
Image1.Picture.Graphic := Factoria.CreateGraphic(SQLQuery.FieldByName('Pic'));
Image1.Picture.Graphic.LoadFromStram(BM);

Fíjate en como tu haces doble trabajo, tienes código redundante como por ejemplo:

Código Delphi [-]
BlobField := FieldByName('Pic'); {'Pic' is name of column with photo}
BS := CreateBlobStream(BlobField,bmRead);

Elimina esa redundancia, y gracias a la Fábrica te despreocupas de estar complicándote más.

Lo que resta es registrar a cada TGraphic en la Fábrica. Con esto se separa la lógica entre creación y uso de cada TGraphic. La creación de cada tipo se centra y pasa a estar controlado por una fábrica, ofreciendo una clara abstracción frente a los cambios para quien haga uso de los TGraphic. El cliente, el Image1, ni se entera de si un TBitmap, o algún otra clase descendiente de TGraphic simplemente para él es un TGraphic más y le delega el trabajo ya que el mismo sabe que hacer.
Si se ha de añadir un nuevo TGraphic sólo hay que agregar una línea de código, algo como:

Código Delphi [-]
Fabrica.Register(ElNuevoGraphic, Tipo);

Puede centrarse todas las registraciones en una única unidad, o incluso de un RegisterAllTGrahic() que asuma todo el control y no hay que tocar el código en donde se usan a estos TGraphic y adaptar el código.

Recomiendo una lectura sobre el patrón Fábrica (también llamado Factoría). Aquí mismo en el foro se ha discutido sobre el patrón. La fábrica es uno de los patrones más limpios que hay (bueno, en realidad todos los patrones buscan la limpieza y equilibrio entre acoplamiento/cohesión a sus formas) y justamente su potencial está en separar el potencial crecimiento y dependencia de nuevos objetos a crear de sus clientes ofreciendo un alto grado de reutilización (tan alto como se diseñe la fábrica y esté definido el polimorfismo que ofresca las clases Productos).

Saludos,