Multiple database connections

2 views
Skip to first unread message

Christoph Zwerschke

unread,
Apr 25, 2008, 6:10:30 AM4/25/08
to turbogea...@googlegroups.com
Does anybody know why multiple database support for SQLObject was
implemented with a *Package*Hub class and config settings such as
<*package*name>.dburi? It seems the idea was to have different DB
connections for different subpackages of a project. But often different
DB connections have nothing to do with different packages. So instead of
associating them with a package name, I would just associate them with a
neutral connection name that may or may not reflect a package name. I.e.
instead of a PackageHub just a NamedHub, and instead of
<packagename>.dburi, just <name>.dburi.

Also, since we dinstinguish between sqlobject.dburi and
sqlalchemy.dburi, shouldn't we dinstinguish between
<name>.sqlobject.dburi and <name>.sqlalchemy.dburi as well? Or, the
other way round, not make distinctions, and just call the setting
"dburi" for unnamed connections?

It seems database conmection handling needs to be somewhat refactored.
Or maybe there is just something I don't understand?

-- Christoph

Jorge Godoy

unread,
Apr 25, 2008, 6:26:44 AM4/25/08
to turbogea...@googlegroups.com, Christoph Zwerschke

Refactoring is indeed needed... Specially after we added SA to the game. The
first implementation is always "duplicate what exists and change names".

I belive the simplification (just 'dburi') is the best one, but this might not
make it clear what is the ORM in use. I.e., how to decide which code path to
go if you have only "dburi='postgres:localhost:5432:/db_name'"? Is this SO
or SA that should be used? We can add other parameters, but then this
becomes:

if orm == 'sqlobject':
so.start.conn(dburi)
elif orm == 'sqlalchemy':
so.start.conn(dburi)
elif ...

And things start getting more complicated to test and check with multiple
decision points.

Using a package makes some things easy: adding a new ORM? Add a new package
and implement the same methods existing for other ORMs (i.e., copy & edit).


--
Jorge Godoy <jgo...@gmail.com>

Christopher Arndt

unread,
Apr 25, 2008, 2:13:01 PM4/25/08
to turbogea...@googlegroups.com
Jorge Godoy schrieb:

>> It seems database conmection handling needs to be somewhat refactored.
>> Or maybe there is just something I don't understand?
>
> Refactoring is indeed needed... Specially after we added SA to the game. The
> first implementation is always "duplicate what exists and change names".

I created a task ticket:

http://trac.turbogears.org/ticket/1813


Chris

Reply all
Reply to author
Forward
0 new messages