[mod_python] example of the PythonImport directive

To avoid having to do it in lots of different places, for example if  
using
mod_python.publisher, you can define a fixup handler which does it
for you. The one fixup handler will be invoked for every request in that
context. You could even cache a reference to the database connection
handle in the request object ready for the subsequent response handler
to use it.

Graham

On 27/12/2006, at 7:26 PM, m.banaouas wrote:

> I just started to use mod_python (2 weeks) version 3.2.10.
> I understand that I would switch to version 3.3 (yet beta).
> Concerning PythonImport directive, it seems like it is not the only  
> (best?) way to init database connexions.
> Is there any other way to do it late, I mean just before first call/ 
> usage from requests?
> thanks
>
> >
> > On 27/12/2006, at 11:05 AM, m.banaouas wrote:
> >
> >> hi,
> >> Can anyone give me an example of how the PythonImport directive/ 
> code works?
> >> I expect to use it to pre-open an sql database connexion, keep  
> it opened and make it accessible from later requests.
> >> thanks for any suggestion
> >
> > Presuming you are using mod_python 3.3.0b, as per documentation at:
> >
> >   http://www.modpython.org/live/mod_python-3.3.0b/doc-html/dir- 
> other-pimp.html
> >
> > use:
> >
> >   PythonImport module::function interpreter_name
> >
> > Change names as appropriate.
> >
> > Do the database initialisation within function() inside the  
> module, not at global
> > scope because if done at global scope and it fails and raises an  
> exception it
> > will cause import of module to fail and only way around that is  
> an Apache
> > restart.
> >
> > By doing it within the function, although it may still fail, a  
> handler which requires
> > the database stuff can always call the function still with it  
> doing nothing if it did
> > previously work at time of PythonImport, otherwise it would do  
> delayed database
> > initialisation at time of first request. If it still fails,  
> handle can test for that and
> > return an appropriate error page.
> >
> > Note that the module should not be a candidate for reloading if  
> you are caching
> > data at global scope such as database connection pool, unless you  
> have specifically
> > coded the module to be safe in the face of automatic module  
> reloading.
> >
> > If you aren't using 3.3.0b, although you might get something  
> going by having it
> > done at global scope, it will not be reliable and also may suffer  
> problems
> > because of old importer bugs.
> >
> > Graham
>
>
>
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python