Return-Path: owner-postman
Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id CAA04102 for postgres-redist; Thu, 26 Oct 1995 02:12:15 -0700
Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199510260912.CAA04102@nobozo.CS.Berkeley.EDU>
X-Authentication-Warning: nobozo.CS.Berkeley.EDU: Host localhost.Berkeley.EDU didn't use HELO protocol
Sender: owner-postman@postgres.Berkeley.EDU
X-Return-Path: owner-postman
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with ESMTP id CAA04192 for <postgres@nobozo.cs.berkeley.edu>; Thu, 26 Oct 1995 02:11:57 -0700
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.12.33]) by edelweb.fr (8.6.12/8.6.9) with ESMTP id KAA18860; Thu, 26 Oct 1995 10:07:34 +0100
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.12.34]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id KAA13388; Thu, 26 Oct 1995 10:07:34 +0100
Received: from localhost (ziegler@localhost) by chandon.edelweb.fr (8.6.10/8.6.6) with SMTP id KAA03476; Thu, 26 Oct 1995 10:07:34 +0100
Message-Id: <199510260907.KAA03476@chandon.edelweb.fr>
To: Chris Phillips <phillipc@limestone.kosone.com>
cc: Alex Shum <shum@cs.und.nodak.edu>, postgres@postgres.Berkeley.EDU
Subject: Re: Interfacing postgres with WWW 
In-reply-to: Your message of "Wed, 25 Oct 1995 23:13:41 -0400."
             <Pine.SUN.3.91.951025230927.2161A-100000@limestone.kosone.com> 
Date: Thu, 26 Oct 1995 10:07:27 +0100
From: Justin Ziegler <Justin.Ziegler@edelweb.fr>
Resent-To: postgres-redist@postgres.Berkeley.EDU
Resent-Date: Thu, 26 Oct 95 02:12:14 -0700
Resent-XMts: smtp


Hi,

We have managed to interface Postgres95 with a perl5 frontend launch
by a web server. We used the three put together to create a prototype
payement system. All our e-wallets are stored in pg95, and all
commercial transactions also.

Obviously at the beginning we had a few problems to get every thing
compiled, but it is possible if your a bit used to that sort of thing.
Especially at the time, we did not have enough disk space, and could
not install gcc so we used acc on sunos 4.1.3.
Also at the beginning pg95 gave us a few cores here and there, but we
discuvered that only happens when we do things it doesn't like.

Right now, we've had it going for over a month without any problem at
all !!! One regret: to my mind, the db seems to grow quite fast.

In doing our system, we gave ourselves a challenge: only use real SQL
92 requests as long as possible. Thus we did not use the inherits that
pg95 supports. Instead we designed a language to describe our db and
produce loads of perl5 code to interface with the backend. From then
on the whole thing became quite trivial:

require quite,q,few,files,here ;

dbms::openConnection() ;

my $thePerson= new person ;
$thePerson->{attribs}->{name}="someName" ;
$thePerson->store() ;

dbms::closeConnection() ;

And there ! youve got it in the db.

The language (SDL) when interpreted or compiled also produces some
code to initialise and reconstruct the db. I actual fact the language
is now some sort of OMT schema description language.

While experimenting many commercial transactions ot once, we found
that pg95's locking did behave the way we wanted... So I launched it
under debugging mode and found a few of the functions concerned with
looking. I transformed all the read locks into write locks. I know
this is not a very nice hack, but man it works cool ;-) and we had
gone to far to discuver that pg95 was not able to do what we wanted.

The final result works well ! but it is not very nervous ...
If I had time I would try and modify the main function of the db in
order to pre-fork it a little like it is done in the Apache, netsite,
NCSA1.4 Web servers. I reckon this could gain a bit of time on each
simple request. When attacking a db from the Web, you must keep in
mind that for every request you are going to have to open and close
the connection to the backend, and that is quite expensive (~1second
with pg95).

We also found that pg95 was a littl slow on joins. So whenever it was
possible, we avoided them like hell e.i. we made big tables with empty
collums instead of two or three tables. (this concerns our home made
inherits).

All in all pg95 is great for what it costs.

Justin.

PS: We did all this on Version Beta 0.02.

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU".
   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================
              URL: http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/
