On Saturday, June 16, 2001, at 08:41 PM, Andreas Repp wrote:

(quoting himself)

...

... To solve the performance problem I´d suggest to cache the user connections for a certain period of time. ...

Of course I haven't meant to 'cache' the connections but to keep em alive while the respective user is active and shut it down after a timeout period has passed.

I was reading the Oracle9i OCI documentation (Oracle 9i was just released) and one of the interesting things it has is connection pooling, with some kind of proxy authorization. As I get a chance I may investigate this further; first to see if it works, then to get a feel for for how to integrate it into Zope. It looks like an extension of something you could already do, but the documentation is frustratingly light on examples. In any case, the promising part was that you could leave the proxied user's password blank, as long as session was authorized for proxies. That would eliminate the whole necessity of having to track the database level user passwords.

##default_connection_id=(changed via ZSQL manage_main Interface) ##connection_type=[ standard | custom | optional ] ##connection_options=(individual Oracle Connection String) sql yada yada

'standard' = obvious 'custum' = forced custom connection - will raise error if connection_options dont' have a valid connection string 'optional' = try 'custom' and fallback to 'standard' if it fails

btw: would be nice to have a drop box in the manage_main screen for this stuff in a _far future_ release of ZSQL-Methods ;-)

Well there are still userid mapping problems present. It's not necessarily reasonable to assume there is a 1:1 mapping between Zope userids and the database userids. What I'd probably be inclined to do is change the *connection* object to look for some other acquired authenticator, which it could use to start a session. That way you can write your own authentication conversions and plug them in.