On the far-out front, a few people have asked how you might do user-specific connections to the database (ie instead of pooling by a common connection, you individually authenticate to Oracle with your own password). Clearly, cloning the base Connection object would be fairly straighforward, but authenticating it to Oracle would not be, as the user password wouldn't be available. If anyone feels strongly about that (ie you have a notion on how you would make it work and/or you need it),feel free to write me. From a performance standpoint it would be terrible, but security auditors would love it.
Hello Matthew, I think this feature would be most useful ! Since I am no (not yet ;-) zope-product developer I can't help you integrating this kind of stuff but I think I can give you some thoughts about it: Of course it would be a great advantage from a security point of view but it would also make it possible to use Oracle's transaction machinery. This would make it much easier for users of OR-mapping products (ie ZPatterns) to wrap insert, update, delete SQL methods into an user Oracle transaction. (I don't know witch impact it would have on products like OracleStorage ...) That way several of above mentioned SQL methods can be aborted in the end without interfering with other users´ actions. Without user based connections this would only be possible, if at all, with a high coding effort. To solve the performance problem I´d suggest to cache new user connections for a certain period of time. To be at all able to transfer the DB-user connection string I´d propose to use a structure similar to Pythonscript for the ZSQL methods. enhanced ZSQL-example: ##(new)connection_id=<dtml-var "username+','+password' or default_connection_id"> ##arguments=ID,NAME insert into SAMPLE (ID,NAME) values ( <dtml-sqlvar ID type="int">, <dtml-sqlvar NAME type="string"> ) (I know that dtml inside the pythonscipt-header is not evaluated but the product developer should be able to make it work that way ...) I assume that this might be a backward compatible approach to solve the issue until some greater spirit has thought about it. A session based connection would be useful as well, but I guess that are dreams of the future ;-) as allways: any comment is very appreciated Andy ---------------------------------------------------------------------- Andreas Repp andreas.repp@lrz-muenchen.de Leibniz Rechenzentrum Muenchen www.lrz.de ----------------------------------------------------------------------