Обсуждение: DISPLAYING BLOBS/images/text
Dear all, I have a pgsql database table packed with images and another one packed with text files, all blobs. I have a script in perl which first extracts the images/text via the lo_export into a temp directory on my server and then it'll display the contents of the file on an HTML page passing HTML headers inbetween. it seems to work fine but it is an extra overhead when it creates a tmp file. How can this be cached? Or can it be directed directly to the web page instead of having to go through another step of createing a temp file. What do you all say? Thanks
Hi, You can use the lo_open() - lo_read() - lo_write() - lo_seek() C like functions that allow to read, write and more directly into your blobs and so display data on the fly... This is already in the documentation - PostgreSQL Programmer's Guide - Chapter 15. Large Objects. Martin Wong wrote: > Dear all, > > I have a pgsql database table packed with images and another one packed with > text files, all blobs. I have a script in perl which first extracts the > images/text via the lo_export into a temp directory on my server and then > it'll display the contents of the file on an HTML page passing HTML headers > inbetween. > > it seems to work fine but it is an extra overhead when it creates a tmp > file. How can this be cached? Or can it be directed directly to the web page > instead of having to go through another step of createing a temp file. > > What do you all say? > > Thanks
On Fri, 22 Jan 1999, Martin Wong wrote:
# it seems to work fine but it is an extra overhead when it creates a tmp
# file. How can this be cached? Or can it be directed directly to the web
# page instead of having to go through another step of createing a temp
# file.
Your application should cache that, that has nothing to do with
the database server. If you use lo_export, it will write to a file, since
that's what lo_export does, but there are more direct ways of dealing with
BLOBs. See the man page on large_objects(3).
--
SA, beyond.com My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________
At 14:02 +0200 on 22/1/99, Martin Wong wrote:
> I have a pgsql database table packed with images and another one packed with
> text files, all blobs. I have a script in perl which first extracts the
> images/text via the lo_export into a temp directory on my server and then
> it'll display the contents of the file on an HTML page passing HTML headers
> inbetween.
>
> it seems to work fine but it is an extra overhead when it creates a tmp
> file. How can this be cached? Or can it be directed directly to the web page
> instead of having to go through another step of createing a temp file.
Well, what I would have done is:
(a) Create a small CGI which, given sufficient parameters to locate the
specific BLOB (OID, I suppose, but cases vary), reads it using
lo_read() and dumps what it reads to its standard output.
(b) Note that this CGI should return the appropriate MIME type in its
Content-type line. For example, if the image is a JPEG image, its
standard output should start with "Content-type: image/jpeg".
(c) You could actually make it general-purpose by giving it the content
type as a parameter. This way it blindly gives the given content
type and dumps the given large object, so it can be used for both
image applications and text applications implemented with large
objects.
In short, you should have a cgi whose URL may look something like:
http://my.domain.com/cgi-bin/lo-dumper.cgi?oid=NNNNN&mime=image/jpeg
When you have one, you can use it as your image source. Just write your
image output with the above URL as its source:
<IMG SRC="/cgi-bin/lo-dumper.cgi?oid=123456@mime=image/jpeg"
WIDTH=100 HEIGHT=40 ALT="Image of a bear">
How did all the parameters get there? Well, I assume that anybody holding
an image database will have an image table, which has fields for the image
name or details (which can be used in the ALT), its width and height, and
if there are several image types, also its type (jpeg, gif, png).
So, at the bottom line, you have two CGIs. One CGI is the one you already
had - the one that displays the HTML that surrounds the image, as well as
selecting which image to display. In this case, this CGI will have to have
a select statement of the general form:
SELECT image_lo, image_type, width, height, description
FROM image_table
WHERE ....;
And it should then print out the call to the other CGI in the form of an
IMG tag as before, based on the details retrieved in the above select
statement.
You make your choice of languague for writing those two CGIs (or servlets).
Hope this gives you a more complete picture of how things should be done
for direct display of images.
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
On Sun, 24 Jan 1999, Herouth Maoz wrote:
It actually gets cooler if you're using Netscape 4.5 because you
don't need two CGIs. Check out http://bleu.west.spy.net/~dustin/photo/
with Netscape 4.5 (it does the ol' two CGI thing otherwise).
// Well, what I would have done is:
//
// (a) Create a small CGI which, given sufficient parameters to locate the
// specific BLOB (OID, I suppose, but cases vary), reads it using
// lo_read() and dumps what it reads to its standard output.
//
// (b) Note that this CGI should return the appropriate MIME type in its
// Content-type line. For example, if the image is a JPEG image, its
// standard output should start with "Content-type: image/jpeg".
//
// (c) You could actually make it general-purpose by giving it the content
// type as a parameter. This way it blindly gives the given content
// type and dumps the given large object, so it can be used for both
// image applications and text applications implemented with large
// objects.
//
// In short, you should have a cgi whose URL may look something like:
//
// http://my.domain.com/cgi-bin/lo-dumper.cgi?oid=NNNNN&mime=image/jpeg
//
// When you have one, you can use it as your image source. Just write your
// image output with the above URL as its source:
//
// <IMG SRC="/cgi-bin/lo-dumper.cgi?oid=123456@mime=image/jpeg"
// WIDTH=100 HEIGHT=40 ALT="Image of a bear">
//
// How did all the parameters get there? Well, I assume that anybody holding
// an image database will have an image table, which has fields for the image
// name or details (which can be used in the ALT), its width and height, and
// if there are several image types, also its type (jpeg, gif, png).
//
// So, at the bottom line, you have two CGIs. One CGI is the one you already
// had - the one that displays the HTML that surrounds the image, as well as
// selecting which image to display. In this case, this CGI will have to have
// a select statement of the general form:
//
// SELECT image_lo, image_type, width, height, description
// FROM image_table
// WHERE ....;
//
// And it should then print out the call to the other CGI in the form of an
// IMG tag as before, based on the details retrieved in the above select
// statement.
//
// You make your choice of languague for writing those two CGIs (or servlets).
//
// Hope this gives you a more complete picture of how things should be done
// for direct display of images.
//
// Herouth
//
// --
// Herouth Maoz, Internet developer.
// Open University of Israel - Telem project
// http://telem.openu.ac.il/~herutma
//
//
//
//
--
Principle Member Technical Staff, beyond.com The world is watching America,
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L______________________________________________ and America is watching TV. __