Re: storing images in the database or on disk

[Olve Hansen <ol...@intermedia.uib.no>]

ons, 28,.09.2005 kl. 15.16 -0400, skrev Dan Adams:

> Ok, this is related to my earlier post. If I have a business object that
> has an uploaded image associated with it (as a field in the object) then
> there are two approaches i'm looking at and i could use some insight
> into which one is better in this situation:
> 
> 1. The uploaded image gets serialized as some sort of object and stored
> in a blob (i'm using hibernate).
> 2. The object only holds the filename of the object, not the object
> itself and is stored on the server somewhere.
> 
> In case 1 it is much easier to ensure that the image gets deleted when
> the object does since hibernate would do that automatically. However,
> this means I will probably have to write an engine service to handle
> accessing these images and I'm not sure if web browsers will cache them
> or not. Also, I would then have to worry about size issues if the object
> ever gets put into the user's session (which it does).
> 
> Case 2 is easier to deal with how to get the image off the server (I
> could just use it as an asset) except that I'm not sure where I would
> store it. But I'm not sure how I would make sure that the image is
> deleted from the server when the entity is deleted from the db. Updates
> pose a similar problem.
> 
> Any thoughts on how to approach this would be appreciated.
> 


To make things utterly confusing, we do both.
I have all images and binary resources in a blob column. Since we use
Hibernate I have made a Hibernate User Type that upon requesting the
java.io.File it represents, first check if the file exists in the
temporary store, and if not, it streams it out, using the primary key as
filename, in  a known folder. 

This way I can keep the files consistent in database over the cluster of
tomcats, in addition to leveraging the staticness of files on disk. This
works pretty well, although my Hibernate type needs some harnessing to
be completely usable - e.checking for new versions of the binary data in
db is not bulletproof yet.

This of course depends on your persistence framework... But I am sure
the principle could be used in all settings.

I would be happy to give away details... Just ask.

Hope this helped...

Olve

RE: storing images in the database or on disk

[Patrick Casey <pa...@adelphia.net>]

 

            Try this:

 

            package services;

 

import java.io.IOException;

 

import javax.servlet.ServletException;

 

import org.apache.tapestry.IComponent;

import org.apache.tapestry.IRequestCycle;

import org.apache.tapestry.engine.AbstractService;

import org.apache.tapestry.engine.IEngineServiceView;

import org.apache.tapestry.engine.ILink;

import org.apache.tapestry.request.ResponseOutputStream;

 

import survey.InternalImage;

import data.HibHelper;

 

public class InternalImageServer extends AbstractService {

            public static final String SERVICE_NAME = "InternalImageServer";

 

            public ILink getLink(IRequestCycle cycle, IComponent component,

                                    Object[] parms) {

                        String[] context;

                        String pageName = component.getPage().getPageName();

                        String idPath = component.getIdPath();

 

                        if (idPath != null) {

                                    context = new String[2];

                                    context[1] = idPath;

                        } else

                                    context = new String[1];

 

                        context[0] = pageName;

                        return constructLink(cycle, SERVICE_NAME, context,
parms, true);

            }

 

            public void service(IEngineServiceView acrg0, IRequestCycle
cycle,

                                    ResponseOutputStream response) throws
ServletException, IOException {

                        Object[] parms = this.getParameters(cycle);

                        

                        String id = (String) parms[0];

                        InternalImage ii = (InternalImage)
HibHelper.getSession().get(InternalImage.class, id);                      

                        response.setContentType(ii.getType());

                        response.write(ii.getData());                    

            }

 

            public String getName() {

 

                        return SERVICE_NAME;

            }

 

}

 

  _____  

From: Olve Hansen [mailto:olve.hansen@intermedia.uib.no] 
Sent: Tuesday, November 08, 2005 6:31 AM
To: Tapestry users
Subject: Re: storing images in the database or on disk

 

ons, 28,.09.2005 kl. 15.16 -0400, skrev Dan Adams: 

 
Ok, this is related to my earlier post. If I have a business object that
has an uploaded image associated with it (as a field in the object) then
there are two approaches i'm looking at and i could use some insight
into which one is better in this situation:
 
1. The uploaded image gets serialized as some sort of object and stored
in a blob (i'm using hibernate).
2. The object only holds the filename of the object, not the object
itself and is stored on the server somewhere.
 
In case 1 it is much easier to ensure that the image gets deleted when
the object does since hibernate would do that automatically. However,
this means I will probably have to write an engine service to handle
accessing these images and I'm not sure if web browsers will cache them
or not. Also, I would then have to worry about size issues if the object
ever gets put into the user's session (which it does).
 
Case 2 is easier to deal with how to get the image off the server (I
could just use it as an asset) except that I'm not sure where I would
store it. But I'm not sure how I would make sure that the image is
deleted from the server when the entity is deleted from the db. Updates
pose a similar problem.
 
Any thoughts on how to approach this would be appreciated.
 


To make things utterly confusing, we do both.
I have all images and binary resources in a blob column. Since we use
Hibernate I have made a Hibernate User Type that upon requesting the
java.io.File it represents, first check if the file exists in the temporary
store, and if not, it streams it out, using the primary key as filename, in
a known folder. 

This way I can keep the files consistent in database over the cluster of
tomcats, in addition to leveraging the staticness of files on disk. This
works pretty well, although my Hibernate type needs some harnessing to be
completely usable - e.checking for new versions of the binary data in db is
not bulletproof yet.

This of course depends on your persistence framework... But I am sure the
principle could be used in all settings.

I would be happy to give away details... Just ask.

Hope this helped...

Olve