#108 Columns with keyword names are problematic for some queries

[Darren Janeczek]

Assume you create a SQLObject out of an existing table that happens to have a column named "group".
This crude patch will protect most queries that involve columns with names like "group" etc, by using a function that wraps the names with back quotes: `group`.
NOT THOROUGHLY TESTED.

[Oleg Broytman]

Thanks. Alas, the patch quotes special names with backticks which AFAIK are only valid on MySQL. Any idea if there are other backends that use backticks to quote names?

Postgres, as well as most other databases use double quotes (") to quote names. Can you rework the patch so it takes the quote character from the DB Connection?

[Darren Janeczek]

This patch actually causes another problem:
`table_name.field_name` is produced instead of `table_name`.`field_name`

My work around was to change the method to:

def escape_keywords(keyword):
#Use this function to allow for the potential of field items with SQL syntax
if '.' in keyword:
#The dot implies that this item contains the table name -- making it legal
return keyword
return "`%s`" % (keyword)

[Darren Janeczek]

Another possibly more generally compatible solution would be to explicitly state table_name.field_name for each.

Note however that the use of "`" is coded in a central function (escape_keywords) and could easily be changed to get the quotes from the db-specific abstraction. I have a few deadlines to fight and don't know the inner workings to do it efficiently at this time.

[Darren Janeczek]

(Removed invalid patch. Will try again shortly)

[Darren Janeczek]

New patch: table.column format is used each time a column is referenced to prevent clashing with keywords like SELECT and GROUP. Only tested with mysql.

[Darren Janeczek]

I wrote a simplistic test which covers some of the functionality.
Unfortunately, I wasn't able to invoke the testing suite, and I won't have time to dive too deeply into the docs for a while.
The new solution should be more generally compatible.

[Oleg Broytman]

Interesting approach. I'll have a deeper look into into it and fix tests
if possible.

[Darren Janeczek]

Thanks.
How do you invoke the tests anyway?

[Oleg Broytman]

Using a complex set of shell wrapper over py.test. The central part is
like the following:

for test in "$@"; do
py.test "$test" -D "$TESTDB_URI"
done

If you are interested in all details I can send you an archive of all
shell scripts I use to maintain SQLObject. Give me your email; if you
don't want to publish it -- send it to me by a private message.

I'm going to try nose. The usage should be something like
python -c "import nose; nose.run_exit()"

[Oleg Broytman]

Alas, doesn't work too. SQLite:
cur.execute('INSERT INTO test (test.name) VALUES (?)', ('text',))
pysqlite2.dbapi2.OperationalError: near ".": syntax error

PostgreSQL:
cur.execute('INSERT INTO test VALUES (test.id, test.value)', (1, 'test'))
psycopg2.ProgrammingError: invalid reference to FROM-clause entry for table "tes
t"
LINE 1: INSERT INTO test VALUES (test.id, test.value)
^
HINT: There is an entry for table "test", but it cannot be referenced from this
part of the query.