Re: [SQLObject] Any intent to support bound variables [in the database-centric sense of the word]?

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

Oleg Broytmann wrote:
> I've started to work on this:
> 
> http://svn.colorstudy.com/home/phd/SQLObject/paramstyles/
> 
>    I use
> http://svn.colorstudy.com/home/phd/SQLObject/paramstyles/sqlobject/include/DBSingleStyle.py
>    to generate parametrized queries. Look into
> http://svn.colorstudy.com/home/phd/SQLObject/paramstyles/sqlobject/dbconnection.py
>    to see how it's used.

SQLObject 2 is also using only bound parameters:

   http://svn.colorstudy.com/SQLObject2/trunk

Actual SQL is via SQL-API:

   http://svn.colorstudy.com/sqlapi/trunk

All the same portability problems exist.

>    Wanna help with it?
> 
>    On the other hand there are problems with paramterized queries. DB API
> drivers do all sort of Bad Thiongs, really. For example, pysqlite1
> "interprets" a parametrized query by running
>    query % parameters :(
> And I remember there was a major problem with datetim on psycopg1.

I was getting problems with pysqlite and dates too.  It seems not to 
respect the DB-API.  But there's so damn many versions of pysqlite, I 
can never keep track of which bugs I have to work around where :(

In SQL-API I'm running all parameters through a database-specific 
wrapper, so they can futz with types if they need to (e.g., if they 
can't support normal datetime objects).  Probably anything that uses 
pyformat should also have % quoted in non-parameter text; I think they 
all use "query % parameters".  The portability part is definitely a pain 
in the butt, which is part of the motivation of splitting this off from 
SQLObject into SQL-API, so that maybe this can be implemented properly 
once, instead of per-ORM.

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