sqlobject-discuss

[SQLObject] Odd __connection__ problem

[Bruno T. <bt...@as...>]

Hi there

    I'm going through an odd problem while getting connected to a
    databse within a class context.

    My code has the usual call:

        __connection__ =3D PostgresConnection(...

    the call is made in the module context and then every class that
    inherits SQLObject within the module has access to the connection
    and is able to query the database. This is for the development
    environment.

    In the production environment this isn't working. Although
    __connection__ is a valid database connection, objects created from
    that module classes cannot access the database. If I replace
    the call to __connection__ in the module context to a call like:

        _connection =3D PostgresConnection(...

    in the class __init__ method, then it works fine.

    I guess this is due to some mismatch between the configuration of
    the two environments, so far I have checked for python version
    (running 2.2.1 in both) and SQLObject version (both match, CVS
    latest) and I couldn't find anything.

    Can anyone point me a possible reason for this to happen? Where else
    to look for the problem?

    Thank you,

[]'s

 Bruno Trevisan

 bt...@as...          |=3D| Async Open Source |=3D| D. Alexandrina, 253=
4
 http://www.async.com.br/ |=3D| +55 16 261-2331   |=3D| 13566-290
                          |=3D| +55 16 9781-8717  |=3D| S=E3o Carlos, SP, B=
rasil

Re: [SQLObject] Odd __connection__ problem

[Ian B. <ia...@co...>]

On Feb 4, 2004, at 5:28 PM, Bruno Trevisan wrote:
> Hi there
>
>     I'm going through an odd problem while getting connected to a
>     databse within a class context.
>
>     My code has the usual call:
>
>         __connection__ = PostgresConnection(...
>
>     the call is made in the module context and then every class that
>     inherits SQLObject within the module has access to the connection
>     and is able to query the database. This is for the development
>     environment.

I'm not really confident about __connection__ in general, it seems kind 
of fragile.

The basic mechanism is simple enough.  When the class is instantiated 
(that is, when the class: stuff gets run), we look for a _connection 
attribute.  If it's not found, then we look at 
sys.modules[cls.__module__].__connection__.  If for some reason the 
module can't be found, or __connection__ can't be found, then it will 
fail.  I don't know why this would happen, but I can imagine weird 
things happening in the module loading that would cause the problem.

Otherwise you could track down that code in SQLObjectMeta and put in 
some print statements to see why __connection__ wasn't found.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org

Re: [SQLObject] Odd __connection__ problem

[Bruno T. <bt...@as...>]

Hi

On Wed, 4 Feb 2004, Ian Bicking wrote:

> I'm not really confident about __connection__ in general, it seems kind
> of fragile.

So, given that, is there any problems about adding _connection to
persistent class constructors instead of using __connection__ in the
module context (apart from the obvious code repetition) ?


> Otherwise you could track down that code in SQLObjectMeta and put in
> some print statements to see why __connection__ wasn't found.

I'll do that and if I find something I'll let you know.

[]'s

 Bruno Trevisan

 bt...@as...          |=3D| Async Open Source |=3D| D. Alexandrina, 253=
4
 http://www.async.com.br/ |=3D| +55 16 261-2331   |=3D| 13566-290
                          |=3D| +55 16 9781-8717  |=3D| S=E3o Carlos, SP, B=
rasil

Re: [SQLObject] Odd __connection__ problem

[Ian B. <ia...@co...>]

Bruno Trevisan wrote:
> On Wed, 4 Feb 2004, Ian Bicking wrote:
>>I'm not really confident about __connection__ in general, it seems kind
>>of fragile.
> 
> 
> So, given that, is there any problems about adding _connection to
> persistent class constructors instead of using __connection__ in the
> module context (apart from the obvious code repetition) ?

No, you can add it to the superclass as well, or assign it to the 
superclass, like SuperClass._connection = ..., and all subclasses should 
pick it up (so long as you haven't instantiated any of them of course).

   Ian