problem with quoted strings while inserting into varchar field ofdatabase.

[krishnakant Mane]

hello,
I finally got some code to push a pickled list into a database table.
but now the problem is technically complex although possible to solve.
the problem is that I can nicely pickle and store lists in a blob
field with the help of dumps() for picklling into a string and then
passing the string to the blob.
I am also able to get back the string safely and do a loads() to
unpickle the object.
but this only works when list contains numbers.
if there is a list such als
lst = ["a","b","c"] then after a dumpls I get a pickled object into a
string but when I try to insert this into the blob field it refuses to
get into the table.
there is an sql syntax error.
I further discovered that the string variable that contains the
pickled object contains a lot of single quots "'" and this is what is
probably preventing the sql insert from succedding. can some one
suggest how to work around this problem?
regards,
Krishnakant.

[Daniele Varrazzo]

I further discovered that the string variable that contains the

pickled object contains a lot of single quots "'" and this is what is
probably preventing the sql insert from succedding. can some one
suggest how to work around this problem?

Every serious database driver has a complete and solid SQL escaping
mechanism. This mechanism tipically involves putting placeholders in
your SQL strings and passing python data in a separate tuple or
dictionary. Kinda

cur.execute("INSERT INTO datatable (data) VALUES (%s);",
(pickled_data,))

instead of:

cur.execute("INSERT INTO datatable (data) VALUES ('%s');" %
(pickled_data,))

It is the driver responsibility to serialize the data (which usually
involves adding enclosing quotes and escape odd charaters such as
quotes themselves).

What database/driver are you using? PostgreSQL+psycopg2 or any other
wrong one? ;) In eiither case, read the driver documentation and the
DBAPI documentation (http://www.python.org/dev/peps/pep-0249/) for
further details.

-- Daniele

[krishnakant Mane]

On 6 May 2007 11:22:52 -0700, Daniele Varrazzo <da**************@gmail.com

Every serious database driver has a complete and solid SQL escaping
mechanism. This mechanism tipically involves putting placeholders in
your SQL strings and passing python data in a separate tuple or
dictionary. Kinda

cur.execute("INSERT INTO datatable (data) VALUES (%s);",
(pickled_data,))

I will try doing that once I get back to the lab.
mean while I forgot to mention in my previous email that I use MySQLdb
for python-mysql connection.
I did not find any such reference to storing pickled objects in the API.

any Idea what could be done with the mysql python module I am using?
regards,
Krishnakant.

[Daniele Varrazzo]

On 7 Mag, 08:55, "krishnakant Mane" <[e-mail]:

On 6 May 2007 11:22:52 -0700, Daniele Varrazzo <[e-mail] serious database driver has a complete and solid SQL escaping

mechanism. This mechanism tipically involves putting placeholders in
your SQL strings and passing python data in a separate tuple or
dictionary. Kinda

cur.execute("INSERT INTO datatable (data) VALUES (%s);",
(pickled_data,))

I will try doing that once I get back to the lab.
mean while I forgot to mention in my previous email that I use MySQLdb
for python-mysql connection.

OK: MySQLdb implements the escaping mechanism i described. You can
find the documentation if you look for it harder.

I did not find any such reference to storing pickled objects in the API.

Storing pickled object is not different from storing anything else
into BLOB. You would have faced the same problem if you had to write
"O'Reilly" in a VARCHAR field.

-- Daniele

[Stefan Sonnenberg-Carstens]

On Mo, 7.05.2007, 10:30, Daniele Varrazzo wrote:

On 7 Mag, 08:55, "krishnakant Mane" <[e-mail]:

>On 6 May 2007 11:22:52 -0700, Daniele Varrazzo
<[e-mail] serious database driver has a
complete and solid SQL escaping

mechanism. This mechanism tipically involves putting placeholders in
your SQL strings and passing python data in a separate tuple or
dictionary. Kinda

cur.execute("INSERT INTO datatable (data) VALUES (%s);",
(pickled_data,))

I will try doing that once I get back to the lab.
mean while I forgot to mention in my previous email that I use MySQLdb
for python-mysql connection.

OK: MySQLdb implements the escaping mechanism i described. You can
find the documentation if you look for it harder.

>I did not find any such reference to storing pickled objects in the API.

Storing pickled object is not different from storing anything else
into BLOB. You would have faced the same problem if you had to write
"O'Reilly" in a VARCHAR field.

-- Daniele

--
http://mail.python.org/mailman/listinfo/python-list

Why not use qmark parameter passing (PEP 249) ?

cur.execute("INSERT INTO datatable (data) VALUES (?);" , (pickled_data,))

Then the DB driver will take care for you.

[Daniele Varrazzo]

On 7 Mag, 10:46, "Stefan Sonnenberg-Carstens"
<[e-mail]:

On Mo, 7.05.2007, 10:30, Daniele Varrazzo wrote:

On 7 Mag, 08:55, "krishnakant Mane" <[e-mail]:

On 6 May 2007 11:22:52 -0700, Daniele Varrazzo
<[e-mail] serious database driver has a
complete and solid SQL escaping
mechanism. This mechanism tipically involves putting placeholders in
your SQL strings and passing python data in a separate tuple or
dictionary. Kinda

cur.execute("INSERT INTO datatable (data) VALUES (%s);",
(pickled_data,))

I will try doing that once I get back to the lab.
mean while I forgot to mention in my previous email that I use MySQLdb
for python-mysql connection.

Why not use qmark parameter passing (PEP 249) ?

cur.execute("INSERT INTO datatable (data) VALUES (?);" , (pickled_data,))

Then the DB driver will take care for you.

>>import MySQLdb
print MySQLdb.paramstyle

format

MySQLdb (as many other drivers) use format parameter passing. Not much
difference w.r.t. qmark, at least when passing positional parameters:
the placeholder is "%s" instead of "?". A difference is that "format"
also allows named parameters (actually it should have been "pyformat",
but IIRC MySQLdb can also use named placeholders, even if they
advertise "format").

Anyway it is only a matter of placeholder style: they both allow the
driver to take care of data escaping, the concept the OT didn't know
about.

-- Daniele

[Stefan Sonnenberg-Carstens]

On Mo, 7.05.2007, 11:32, Daniele Varrazzo wrote:

On 7 Mag, 10:46, "Stefan Sonnenberg-Carstens"
<[e-mail]:

>On Mo, 7.05.2007, 10:30, Daniele Varrazzo wrote:

On 7 Mag, 08:55, "krishnakant Mane" <[e-mail]:
On 6 May 2007 11:22:52 -0700, Daniele Varrazzo
<[e-mail] serious database driver has a
complete and solid SQL escaping
mechanism. This mechanism tipically involves putting placeholders

in

your SQL strings and passing python data in a separate tuple or
dictionary. Kinda

cur.execute("INSERT INTO datatable (data) VALUES (%s);",
(pickled_data,))

>I will try doing that once I get back to the lab.
mean while I forgot to mention in my previous email that I use

MySQLdb

>for python-mysql connection.

Why not use qmark parameter passing (PEP 249) ?

cur.execute("INSERT INTO datatable (data) VALUES (?);" ,
(pickled_data,))

Then the DB driver will take care for you.

>>>import MySQLdb
print MySQLdb.paramstyle

format

MySQLdb (as many other drivers) use format parameter passing. Not much
difference w.r.t. qmark, at least when passing positional parameters:
the placeholder is "%s" instead of "?". A difference is that "format"
also allows named parameters (actually it should have been "pyformat",
but IIRC MySQLdb can also use named placeholders, even if they
advertise "format").

Anyway it is only a matter of placeholder style: they both allow the
driver to take care of data escaping, the concept the OT didn't know
about.

-- Daniele

--
http://mail.python.org/mailman/listinfo/python-list

%s is not a placeholder IMHO.
What happens when using %s is, that the string given will be inserted where
%s is; that is something python does as with every print or such.
By using the qmark style, it is up the the implementation of the
cursor.execute method to decide what to do. python itself, and it's string
implementation, don't know anything to do with the qmark.
So, IMHO it *makes* a difference:
with %s the execute function sees a string and nothing more as the
parameters are consumed away by the % substitution.
with ?, the execute implementation must do it's best, it gets a string and
a list/tuple with values.

Cheers,
Stefan

[Daniele Varrazzo]

cur.execute("INSERT INTO datatable (data) VALUES (%s);",

(pickled_data,))

%s is not a placeholder IMHO.

What happens when using %s is, that the string given will be inserted where
%s is; that is something python does as with every print or such.

It is indeed. The behavior you describe would be true if i had used
the "%" operator. Read better what i have written: There is no "%"
operator.

cur.execute() receives 2 parameters: a SQL string with placeholders
and a tuple with values: it's not me mangling values into the SQL
string. This is the driver responsibility and it has the chance
because it receives SQL and values as two distinct parameters. The
driver can ask the SQL string to contain placeholders either in qmark
"?" or in format "%s" style, but there is no functional difference.
Notice that the placeholder is always "%s" and not "%d" or "%f" for
integers or float: there is always an escaping phase converting each
python object into a properly encoded string and then the placeholders
are replaced with the value. This happens into the execute()
machinery.

By using the qmark style, it is up the the implementation of the
cursor.execute method to decide what to do. python itself, and it's string
implementation, don't know anything to do with the qmark.
So, IMHO it *makes* a difference:
with %s the execute function sees a string and nothing more as the
parameters are consumed away by the % substitution.
with ?, the execute implementation must do it's best, it gets a string and
a list/tuple with values.

Again, this would be true for "cur.execute(sql % data)": what i wrote
is "cur.execute(sql, data)".

-- Daniele

[Stefan Sonnenberg-Carstens]

On Mo, 7.05.2007, 16:26, Daniele Varrazzo wrote:

cur.execute("INSERT INTO datatable (data) VALUES (%s);",
(pickled_data,))

>%s is not a placeholder IMHO.

>What happens when using %s is, that the string given will be inserted
where
%s is; that is something python does as with every print or such.

It is indeed. The behavior you describe would be true if i had used
the "%" operator. Read better what i have written: There is no "%"
operator.

cur.execute() receives 2 parameters: a SQL string with placeholders
and a tuple with values: it's not me mangling values into the SQL
string. This is the driver responsibility and it has the chance
because it receives SQL and values as two distinct parameters. The
driver can ask the SQL string to contain placeholders either in qmark
"?" or in format "%s" style, but there is no functional difference.
Notice that the placeholder is always "%s" and not "%d" or "%f" for
integers or float: there is always an escaping phase converting each
python object into a properly encoded string and then the placeholders
are replaced with the value. This happens into the execute()
machinery.

>By using the qmark style, it is up the the implementation of the
cursor.execute method to decide what to do. python itself, and it's
string
implementation, don't know anything to do with the qmark.
So, IMHO it *makes* a difference:
with %s the execute function sees a string and nothing more as the
parameters are consumed away by the % substitution.
with ?, the execute implementation must do it's best, it gets a string
and
a list/tuple with values.

Again, this would be true for "cur.execute(sql % data)": what i wrote
is "cur.execute(sql, data)".

-- Daniele

--
http://mail.python.org/mailman/listinfo/python-list

Ashes on my head.

[Daniele Varrazzo]

Ashes on my head.

My fault: the difference is hard to spot indeed in the rather long
line of the example. I should have been more explicit stating that the
differences were:

1. missing explicit quotes around the placeholders (they are part of
the escaped values),

2. no % operator: two parameters are passed instead.

Best regards,

-- Daniele

[Carsten Haese]

On Mon, 2007-05-07 at 07:26 -0700, Daniele Varrazzo wrote:

cur.execute("INSERT INTO datatable (data) VALUES (%s);",
(pickled_data,))

%s is not a placeholder IMHO.

What happens when using %s is, that the string given will be inserted where
%s is; that is something python does as with every print or such.

It is indeed. The behavior you describe would be true if i had used
the "%" operator. Read better what i have written: There is no "%"
operator.

This confusion is precisely why I think the (py)format paramstyles
should be deprecated in a future version of the DB-API spec. Question
marks make it immediately obvious that something other than string
formatting is happening, and if I'm not mistaken, question marks are SQL
standard.

--
Carsten Haese
http://informixdb.sourceforge.net

[Stefan Sonnenberg-Carstens]

On Mo, 7.05.2007, 16:50, Carsten Haese wrote:

On Mon, 2007-05-07 at 07:26 -0700, Daniele Varrazzo wrote:

cur.execute("INSERT INTO datatable (data) VALUES (%s);",
(pickled_data,))

%s is not a placeholder IMHO.

What happens when using %s is, that the string given will be inserted

where

%s is; that is something python does as with every print or such.

It is indeed. The behavior you describe would be true if i had used
the "%" operator. Read better what i have written: There is no "%"
operator.

This confusion is precisely why I think the (py)format paramstyles
should be deprecated in a future version of the DB-API spec. Question
marks make it immediately obvious that something other than string
formatting is happening, and if I'm not mistaken, question marks are SQL
standard.

--
Carsten Haese
http://informixdb.sourceforge.net
--
http://mail.python.org/mailman/listinfo/python-list

At least, qmark style is well known to people working with
prepared stmts etc.
They look "natural" - and avoid (even my!) mistakes.
On python-forum.de there was a discussion regarding inserting
data into a sqlite db recently. If I remember correctly the guy
was using the "%s" % data approach (yes, % operator) and failed.
The pysqlite driver did the right thing using the qmark style.
Even in the "Python phrasebook" there are examples of this ugly style.

A deprecation warning for now would be fine.