On Wed, 16 Mar 2005 12:24:24 -0600, Ian Bicking <ianb@...> wrote:
> Ultimately I think StringCol should support unicode, relying on the
> database to natively store unicode -- that's contingent both on database
> unicode support, driver unicode support, and moving to DB-API
> parameters. UnicodeCol is for supporting Python unicode strings when
> the database does not (or when any piece of the chain does not). Though
> I think if StringCol becomes more capable, UnicodeCol will seem
> redundant and a hinderance to database portability -- for those
> databases that don't support Unicode (for instance, maybe SQLite will
> stick with the columns-as-bytes perspective) it would be most convenient
> to indicate a default encoding for the connection (e.g.,
> 'sqlite:/file?encoding=UTF-8'), and the rest of SQLObject can pretend
> the database is unicode-aware.
As a side note, I was thinking today about some issues that popped up
recently with my usage of SQLObject. It's still a rough draft, a
'half-baked' idea. At the risk of sounding silly, let's share it :-)
I have a web framework that is capable of running several
'applications' simultaneously (it's not Rails, but it could be :-).
Each application declares its own DB connection and tables. There are
a number of issues in this scenario:
-- applications can declare tables with the same name, which will
cause clashes in the sqlobject registry. I thought about having a
separate 'namespace' for each connection.
-- the application is multithreaded. How does SQLObject handle the
multithreading in this case? Is it safe?
One idea that popped up was to use the same 'declarative' style to
create DB connections. For example:
class myDB(SQLObjectConnection):
connectionURI = '...'
then I could use:
class Person(SQLObject):
_connection = myDB
Specific connections can be declared also:
class myDB(MySQLConnection):
user = '...'
port = '...'
The advantage is that the 'myDB' object would act as a container for
several things; for example, it could hold the registry for tables, as
a 'per-DB' object. It also could handle multithreading, creating new
connections to the database per thread if the backend requires it. And
finally, it would be easier to add connection-specific arguments.
Is it reasonably, or is it a bad idea?
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro@...
mail: carribeiro@...
|