Hey everyone,
	I am trying to create a web application and want to store image 
information in a mysql database and store the images on a filesystem.  I 
am also using struts and I am looking for the best way to do this.  I 
want to store the images outside the servlet context so that if I 
redeploy I won't lose the images.
	Let me know if you have any questions and thank you in advance for your 
help.

-- 
Kevin
***************************************************************
"The trouble with programmers is that you can never tell what a
programmer is doing until it's too late."
-Seymour Cray

In article <3JhGk.319018$TT4.249173@attbi_s22>,
 Kevin Moseley <linux_geek@mchsi.com> wrote:

> 	I am trying to create a web application and want to store image 
> information in a mysql database and store the images on a filesystem.

Keeping the image data with the image metadata make the former _much_ 
easier to find in connection with the latter. Storing the image data in 
the file system is conceptually appealing, but it requires keeping a 
global root path, as well as a relative path name for each image. Such 
names are fragile, OS dependent, and entirely outside the aegis of the 
database's referential integrity constraints.

It's possible that you're assuming the file system to be faster. You may 
have to benchmark your particular mix of image size and number to decide 
if going outside the database is worth the effort.

[...]
> I want to store the images outside the servlet context so that if I 
> redeploy I won't lose the images. Let me know if you have any 
> questions
[...]

What does "redeploy" mean in this context? Different server? Different 
servlet container? Different database? How does "store ... outside" 
imply "won't lose the images?"

-- 
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews

On Oct 6, 6:23 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article <3JhGk.319018$TT4.249173@attbi_s22>,
>  Kevin Moseley <linux_g...@mchsi.com> wrote:
>
> >    I am trying to create a web application and want to store image
> > information in a mysql database and store the images on a filesystem.
>
> Keeping the image data with the image metadata make the former _much_
> easier to find in connection with the latter. Storing the image data in
> the file system is conceptually appealing, but it requires keeping a
> global root path, as well as a relative path name for each image. Such
> names are fragile, OS dependent, and entirely outside the aegis of the
> database's referential integrity constraints.
>
> It's possible that you're assuming the file system to be faster. You may
> have to benchmark your particular mix of image size and number to decide
> if going outside the database is worth the effort.
>
> [...]> I want to store the images outside the servlet context so that if I
> > redeploy I won't lose the images. Let me know if you have any
> > questions
>
> [...]
>
> What does "redeploy" mean in this context? Different server? Different
> servlet container? Different database? How does "store ... outside"
> imply "won't lose the images?"
>
> --
> John B. Matthews
> trashgod at gmail dot com
> home dot woh dot rr dot com slash jbmatthews

Hi,
   I am assuming at the moment that re-deploy means restart, and you
don't want it stored in temporary memory.

   Thus if it is stored on mysql then I see no issue as to why re-
deployment would lose the data, so I assume the file storage is a
backup - why not back it up on a weekly basis (or whatever it might
be).
   If you really wanted it in a file system you could save some time
by using EJB (Enterprise Java Bean), but the "best" part of this is
that you could use an encoder (ie: XMLEncoder?) to encode the object
to save it to a file. Btw, I may suggest a custom XMLEncoder (or
another method of Serialization as the Java version is very simple -
but it relies on numerous listeners which I think is dynamic, but in-
efficient). Do beware though as XMLEncoder can be annoying to get
running even though there are few lines of code....

   I was just thinking that perhaps the file system was so you could
personally view the images? You might want to check
http://java.sun.com/docs/books/tutorial/2d/images/index.html - this
should give you all of the information.


For the mysql you need a table of course - my suggestion:
CREATE TABLE images (
ID int NOT NULL AUTO_INCREMENT PRIMARY KEY,
NAME VARCHAR(32),
IMAGE BLOB
);

http://www.java2s.com/Code/Java/Database-SQL-JDBC/BlobJDBCdealswithBinaryData.htm
for an example of reading and writing images with mysql and java.

MSJ121

Msj121 wrote:
> On Oct 6, 6:23 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
>> In article <3JhGk.319018$TT4.249173@attbi_s22>,
>>  Kevin Moseley <linux_g...@mchsi.com> wrote:
>>
>>>    I am trying to create a web application and want to store image
>>> information in a mysql database and store the images on a filesystem.
>> Keeping the image data with the image metadata make the former _much_
>> easier to find in connection with the latter. Storing the image data in
>> the file system is conceptually appealing, but it requires keeping a
>> global root path, as well as a relative path name for each image. Such
>> names are fragile, OS dependent, and entirely outside the aegis of the
>> database's referential integrity constraints.
>>
>> It's possible that you're assuming the file system to be faster. You may
>> have to benchmark your particular mix of image size and number to decide
>> if going outside the database is worth the effort.
>>
>> [...]> I want to store the images outside the servlet context so that if I
>>> redeploy I won't lose the images. Let me know if you have any
>>> questions
>> [...]
>>
>> What does "redeploy" mean in this context? Different server? Different
>> servlet container? Different database? How does "store ... outside"
>> imply "won't lose the images?"
>>
>> --
>> John B. Matthews
>> trashgod at gmail dot com
>> home dot woh dot rr dot com slash jbmatthews
> 
> Hi,
>    I am assuming at the moment that re-deploy means restart, and you
> don't want it stored in temporary memory.
> 
>    Thus if it is stored on mysql then I see no issue as to why re-
> deployment would lose the data, so I assume the file storage is a
> backup - why not back it up on a weekly basis (or whatever it might
> be).
>    If you really wanted it in a file system you could save some time
> by using EJB (Enterprise Java Bean), but the "best" part of this is
> that you could use an encoder (ie: XMLEncoder?) to encode the object
> to save it to a file. Btw, I may suggest a custom XMLEncoder (or
> another method of Serialization as the Java version is very simple -
> but it relies on numerous listeners which I think is dynamic, but in-
> efficient). Do beware though as XMLEncoder can be annoying to get
> running even though there are few lines of code....
> 
>    I was just thinking that perhaps the file system was so you could
> personally view the images? You might want to check
> http://java.sun.com/docs/books/tutorial/2d/images/index.html - this
> should give you all of the information.
> 
> 
> For the mysql you need a table of course - my suggestion:
> CREATE TABLE images (
> ID int NOT NULL AUTO_INCREMENT PRIMARY KEY,
> NAME VARCHAR(32),
> IMAGE BLOB
> );
> 
> http://www.java2s.com/Code/Java/Database-SQL-JDBC/BlobJDBCdealswithBinaryData.htm
> for an example of reading and writing images with mysql and java.
> 
> MSJ121

	I apologize for not being clearer.  I am new to java,struts, tomcat, 
and hibernate. I guess I am curious as to which is better, storing 
images in a database or using the file system and storing the file 
information in the database.  What I want to do is have  users upload 
photos and when they open their profile they can view the files they 
have uploaded.  I am using struts and hibernate and I don't know how to 
pull multiple images in the jsp.
	What is the best practice for uploading and viewing images?  I have 
googled it and it seems the consensus is to store files on the file 
system and use action files to display the images using input streams to 
display the images.  What is causing me problems how to display on the 
page load.
	When I meant reload is if upload a new .war file doesn't is overwrite 
the folder when I restart tomcat and if my images were in there they 
would be lost.

-- 
Kevin
***************************************************************
"The trouble with programmers is that you can never tell what a
programmer is doing until it's too late."
-Seymour Cray

Kevin Moseley wrote:
>     I apologize for not being clearer.  I am new to java,struts, tomcat, 
> and hibernate. I guess I am curious as to which is better, storing 
> images in a database or using the file system and storing the file 
> information in the database.  What I want to do is have  users upload 
> photos and when they open their profile they can view the files they 
> have uploaded.  I am using struts and hibernate and I don't know how to 
> pull multiple images in the jsp.
>     What is the best practice for uploading and viewing images?  I have 
> googled it and it seems the consensus is to store files on the file 
> system and use action files to display the images using input streams to 
> display the images.  What is causing me problems how to display on the 
> page load.
>     When I meant reload is if upload a new .war file doesn't is 
> overwrite the folder when I restart tomcat and if my images were in 
> there they would be lost.

You can store the images 3 places:
a) database
b) file system in directory served by Tomcat
c) file system in directory not served by Tomcat

It can be implemented by:
a) have your pages generate <img src="ImageServlet?imgid=177">
    have ImageServlet set MIME type appropriate, retrieve BLOB from
    database and write to output
b) have your page generate <img src="images/img177.jpg">
c) have your pages generate <img src="ImageServlet?imgid=177">
    have ImageServlet set MIME type appropriate, read image from
    file system and write to output

Which one to chose ?

#b has some problems:
- redeployment that you mention
- lack of security by user
so it is either #a or #c.

It is a well known discussion.

Many people swear that images in the database will kill the
database performance.

And putting images in an Access 95 database on Windows 95 on
a 150 MHz Pentium box indeed did kill database performance.

But a few things ha changed in software and hardware since then.

With a good database system then there should not be any problem
having images of small-medium size in the database.

I once made som tests to verify and performance was OK.

So I will suggest going for #a.

Arne