Re: Advice on dynamic graphics with WO
Re: Advice on dynamic graphics with WO
- Subject: Re: Advice on dynamic graphics with WO
- From: Pierre Frisch <email@hidden>
- Date: Sat, 3 Jan 2004 15:22:55 -0800
Jonathan,
I know that storing images in the database has bad reputation for WO
developers but there is nothing wrong with it. The only thing that is
wrong is the brain damage way WOImage handle the problem. Fixing it is
non trivial I agree but it is well worth it. The purpose of a database
is to keep all the information in one "system" so that it can be
managed and tracked efficiently; having pieces of data in the file
system defeat the purpose.
As for fixing WOImage there are a few area that need to be looked at
the first one is to build a special graphic request handler to return
images that are cacheable by the browser. WO default are not which is
one of the reason serving images from the application has such a bad
reputation. The other one is to be careful in not storing copies of the
images in the snapshots. Otherwise there is nothing wrong with the idea
of storing images in the database.
We have an application that stores images, html and wod in the database
and run pretty fast and without much troubles, but of course we have
devoted quite a bit of time at looking at the underlying mechanism and
doing some optimization.
Happy new year.
Pierre
On Jan 3, 2004, at 14:55, Jonathan Rochkind wrote:
I am curious to know what mechanism you use to actually return the
images (stored in the db) to the browser. The ordinary way to do this
in WO would be with WOImage with a 'data' binding, but there are a
variety of problems with this involving memory management. If you
haven't encountered them even if your heavily accessed app, more power
to you. But I'm curious exactly how you are deliving the images, and
if you did anything special for memory management purposes.
--Jonathan
At 8:46 AM -0500 1/2/04, Tom Pelaia wrote:
We grab images from the database in our WebObjects application
(electronic logbook). It is a very heavily accessed site and allows
users to make entries that have text, images and other attachments.
We
have found additional "pros" for loading images from a database.
Additional database pros:
1) The logbook isn't the only application that uses our database. We
just use a subset of the database. Other applications write to the
database and make entries into our logbook and use data from our
logbook. Storing complete logbook entries (images, text, attachments)
in the database means other applications have easy access to logbook
entries. Hence we are integrated well.
2) The database is the one official source of all data
3) Backups are consistent and easy. When the database is backed up,
all
logbook data is backed up and the backups are self consistent.
4) It is easier to transfer data from one machine to another since you
only have one thing to transfer.
5) Since the images are provided by users, the database provides a way
to avoid file names collisions. If you use a file system you need to
save filenames carefully to avoid duplication.
6) The first logbook we developed several years ago (without WO)
stored
data including images in the filesystem. That turned out to be very
inflexible. If you want to reorganize the folder layout, lots of
links
will break. This is simply a non-issue for database storage.
7) Databases are simply much more flexible. Filesystem storage is
very
rigid. You can store your files for the present application, but
needs
tend to change in time and database storage is much more flexible in
supporting future needs that you might not be considering today.
Whether you choose database storage or filesystem storage really
depends
on your application. For our application, the electronic logbook is
becoming more integrated with other systems and the database has
turned
out to be critical in that integration.
Subject:
Re: Advice on dynamic graphics with WO
From:
Arturo Pirez <email@hidden>
Date:
Thu, 1 Jan 2004 10:47:58 -0500
To:
Geoff Hopson <email@hidden>
My opinion and experience FWIW, having done it both ways. I keep
having this discussion so
I'd thought I'd put it all down in one place.
Database pros:
1. It's really easy.
2. It works well.
3. It's consistent with everything else; i.e. all data comes from
the
database.
Database cons:
1. There are some tuning issues around BLOBs if you're using those
(or
equivalent).
2. I don't understand people saying "It solves single point of
failure." Didn't you just move
the single point of failure from a file system to the database?
Sure,
databases offer replication
but you can achieve the same with a clusterable file system like
Transarc or the Andrew File System (AFS).
3. It "makes no sense." It's just storing a bunch of non-relational
data in a relational database. It feels
unclean :-)
4. If you need to manipulate the data it's much much harder. For
example, if it's text and you want to
fix a typo it's problematic. If it's an image updating EXIF headers
would be a chore. It's much easier
to run a perl script over a directory of files.
Filesystem pros:
1. It scales better.
2. It's easier to manipulate the images if that's necessary.
Particularly offline from serving them.
> 3. It's cheaper. (Disks are cheaper costwise than databases esp.
if
you need a DBA).
Filesystem cons:
1. It's a little harder to manage. And you might still need a
database to keep track of the images.
2. It's harder to build a content management system that can upload
images. WebDAV might address this issue.
Well, my 2 farthings.
----
WO in philadelphia - wanna cheesesteak with that?
Please visit webobjects.meetup.com.
--
Tom Pelaia
SNS Project, 701 Scarboro Road, MS-6473, Oak Ridge, TN 37830
phone: (865)574-6421, fax: (865)574-6617
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.