You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Dan Adams <da...@ifactory.com> on 2005/09/28 21:16:38 UTC

storing images in the database or on disk

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.

-- 
Dan Adams
Software Engineer
Interactive Factory


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: storing images in the database or on disk

Posted by The Chris Method <th...@gmail.com>.
We do case 1 for most things. The images will generally be cached by users
browsers. As long as the url is the same, it'll usually stay cached. You
probably shouldn't put the object in the user's session. Just stick the id
of the object in the session and pull the object out when necessary.

On 9/28/05, Dan Adams <da...@ifactory.com> wrote:
>
> 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.
>
> --
> Dan Adams
> Software Engineer
> Interactive Factory
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

RE: storing images in the database or on disk

Posted by 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 


Re: storing images in the database or on disk

Posted by 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

Posted by Patrick Casey <pa...@adelphia.net>.
	Dan,

	Using case 2 is going to give you better performance because web
servers are *really good* at serving static resources and the overhead of
serving a static <img> is a *lot* lower than the overhead of running an
entire servlet just to serve back 12k of binary data.

	The downside, however, of such a use case is that you end up having
to backup (and restore, and manage), two different things and keep them in
sych: the database that stores filenames, and the physical files themselves
that reside in your /img/stuff/ directory. Having shipped a system that
relied on case 2, I have to say it was, for lack of a better word, frail and
awkward to work with. I won't do it again, although your tolerance for
awkwardness may, of course, vary.

	As for doing case 1, don't let writing an engine service scare you.
Just use the source for the existing asset service as a starting point and
change it to serve the asset from the datastore. Additionally, you can cache
the images yourself, either in something like an LinkedHashMap or, if you're
using hibernate, just set up your own ehcache region since that's a pretty
bulletproof cache.

	--- Pat

> -----Original Message-----
> From: Dan Adams [mailto:dan@ifactory.com]
> Sent: Wednesday, September 28, 2005 12:17 PM
> To: Tapestry users
> Subject: storing images in the database or on disk
> 
> 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.
> 
> --
> Dan Adams
> Software Engineer
> Interactive Factory
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org