sqlobject-discuss

[SQLObject] Adding support for additional database

[David <dvk...@gm...>]

I would like to add support to SQLObject for the www.rdbhost.com service.

Rdbhost provides Postgresql databases via web-service.   We have a DB
API 2 interface module, called 'Rdbhdb', to facilitate using our
hosted databases from Python, and I would like to provide 'drop-in'
support for SQLObject.

In that pursuit, I have a suggestion and a question or two:

It seems that the scheme from an opener URI is used to select the
driver, but is not provided to that driver's constructor.  For
example, the 'Pygresql' scheme will instantiate a
'pgconnection::PostgresConnection', but the __init__ is not provided
the scheme name; a Pygresql user would have to provide an explicit
backend parameter to identify the Pygresql api module.  I suggest that
dbconnection.py be modified to pass a 'scheme' parameter to the
constructors, where it would appear as part of the **kw param.

In the pgconnection init, the self.use_dsn parameter is set, and then
the self.dsn_dict and self.dsn are both created.  Why are those two
built, when a dsn string is already available?  The makeConnection
method uses only the self.dsn or only the self.dsn_dict, depending on
self.use_dsn.

What is the preferred tool for patch-making under WinXP?

Are there preconditions for adding a new database to SQLObject?

Thank you,
David

-- 
dk...@tr...
Rdbhost -> SQL databases as a webservice [www.rdbhost.com]

Re: [SQLObject] Adding support for additional database

[Oleg B. <ph...@ph...>]

Hi!

On Thu, Dec 31, 2009 at 09:56:32AM -0700, David wrote:
> I would like to add support to SQLObject for the www.rdbhost.com service.

   Welcome!

> It seems that the scheme from an opener URI is used to select the
> driver, but is not provided to that driver's constructor.  For
> example, the 'Pygresql' scheme will instantiate a

   These schemas are aliases for *schemas*. Only PostgresConnection has
more than one aliases. And there is no 'pygresql' schema - it was removed
in 0.12.

> 'pgconnection::PostgresConnection', but the __init__ is not provided
> the scheme name; a Pygresql user would have to provide an explicit
> backend parameter to identify the Pygresql api module.  I suggest that

   The 'backend' parameter selects a *DB API driver*. I.e., you can select
psycopg2, psycopg1 or pygresql driver regardless of the schema.

> dbconnection.py be modified to pass a 'scheme' parameter to the
> constructors, where it would appear as part of the **kw param.

   A Connection class knows it's name via cls.dbName. All Connection
classes except for PostgresConnection have one alias that is exactly the
same as dbName. PostgresConnection has 2 aliases, but dbName is 'postgres'.
   If you want to change the schema probably it's best to create a new
Connection class. Inherit it from PostgresConnection and redefine its
dbName.

> In the pgconnection init, the self.use_dsn parameter is set, and then
> the self.dsn_dict and self.dsn are both created.  Why are those two
> built, when a dsn string is already available?  The makeConnection
> method uses only the self.dsn or only the self.dsn_dict, depending on
> self.use_dsn.

   DSN strings is a rather old concept. I maintain it just in case, but I
use dsn_dict and I think it's te preferred way.

> What is the preferred tool for patch-making under WinXP?

   No idea. I develop on Linux.

> Are there preconditions for adding a new database to SQLObject?

   License. SQLObject is LGPL-licensed. A code you want to add to SQLObject
itself must be LGPL-licensed. External code (DB API drivers not included
into the SQLObject code base) doesn't matter.

PS. Happy New Year to all!

Oleg.
-- 
     Oleg Broytman            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.