You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Gabriel Lozano <gh...@gmail.com> on 2006/10/18 02:54:21 UTC

problem with images

Hi all

I want some help on this issue:

I want to know which is the best way to work with images. If I saved them on
a folder inside the application, the next time I deploy the application I
will loose all the images. I was thinking on saving them in the db, but I
dont know how can I retrieve them and show them in the html. If I generate a
temp file per request, then I will end up with a file representing an image
for everytime the image is requested.

Any help would be welcome, I was looking for this and I didnt find anything
on this topic.

Gabriel Lozano M.

Re: problem with images

Posted by Gabriel Lozano <gh...@gmail.com>.
Thanks for your answer. Well, what I did in the end was to save the images
in another directory on the server. I had some trouble because I dont have
full access to the server but now it is working. About Ryans idea of the
service, I have access to Kent's book and I looked the chapter but I dont
have much time ( and neither the book ) so for now this is just ok. But what
Im doing now is to create for me a kind of framework for developing apps so
I'm looking for the best way of doing things so thanks for your advice.

On 10/18/06, Patrick Moore <tr...@gmail.com> wrote:
>
> But in the end why would you? if not then it will always be slower to
> get the images out and the code will be beating on what will no doubt
> be your most stressed, weakest link ... your database.
>
> Think about how hard you are making to check that an image is correct
> on your system. You are going to have to write some sort of utility
> just to look at the images stored. Your database could start having
> issues with trying to manage such large data items.
>
> Do you need the ACID properties of a database? If you, really, really
> do a hybrid approach that has some value is using a database like
> apache's derby to store your images. (in other words not your main
> database)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: problem with images

Posted by Patrick Moore <tr...@gmail.com>.
But in the end why would you? if not then it will always be slower to
get the images out and the code will be beating on what will no doubt
be your most stressed, weakest link ... your database.

Think about how hard you are making to check that an image is correct
on your system. You are going to have to write some sort of utility
just to look at the images stored. Your database could start having
issues with trying to manage such large data items.

Do you need the ACID properties of a database? If you, really, really
do a hybrid approach that has some value is using a database like
apache's derby to store your images. (in other words not your main
database)

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


Re: problem with images

Posted by Ryan Holmes <ry...@hyperstep.com>.
Assuming you're talking about user uploaded images or something  
similar, there are of course different opinions on the "best" way but  
here are my thoughts:

1.) You are absolutely right not to store uploaded images in the  
application directory. They are external data just like data in a  
database.

2.) As far as actually storing BLOBs in the DB, it's definitely worth  
considering. The pros are a lack of synchronization issues between  
records that represent image files with the actual files on disk and  
of course not having to deal with the file system period (no unique  
file name issues, images get backed up with the rest of your data,  
etc.). The cons are a lack of standardized access (or no access) to  
BLOBs through O/RM frameworks,  varying support among RDMS's / JDBC  
drivers, and performance overhead. If you're building a high-volume  
site, you really want to be able to serve images from a dedicated  
media server like a stripped-down Apache, Boa, kHTTPd, etc. and you  
can't easily do that if your images are in a database.

As much as I like the idea of storing images directly in the  
database, I've always ended up using objects/records that represent  
files (via a relative file path + a global root path) and storing the  
files themselves in a directory structure outside the application.

3.) Buy Kent Tong's book, "Enjoying Web Development with Tapestry"  
and read the chapter on building an image upload/download service.  
It's really not very hard, but it's too much to squeeze into an email.

HTH,
-Ryan

On Oct 17, 2006, at 5:54 PM, Gabriel Lozano wrote:

> Hi all
>
> I want some help on this issue:
>
> I want to know which is the best way to work with images. If I  
> saved them on
> a folder inside the application, the next time I deploy the  
> application I
> will loose all the images. I was thinking on saving them in the db,  
> but I
> dont know how can I retrieve them and show them in the html. If I  
> generate a
> temp file per request, then I will end up with a file representing  
> an image
> for everytime the image is requested.
>
> Any help would be welcome, I was looking for this and I didnt find  
> anything
> on this topic.
>
> Gabriel Lozano M.


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