By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,035 Members | 1,984 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,035 IT Pros & Developers. It's quick & easy.

problem with quoted strings while inserting into varchar field ofdatabase.

P: n/a
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.
May 6 '07 #1
Share this Question
Share on Google+
11 Replies


P: n/a
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

May 6 '07 #2

P: n/a
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.
May 7 '07 #3

P: n/a
On 7 Mag, 08:55, "krishnakant Mane" <researchb...@gmail.comwrote:
On 6 May 2007 11:22:52 -0700, Daniele Varrazzo <daniele.varra...@gmail.comEvery 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

May 7 '07 #4

P: n/a
On Mo, 7.05.2007, 10:30, Daniele Varrazzo wrote:
On 7 Mag, 08:55, "krishnakant Mane" <researchb...@gmail.comwrote:
>On 6 May 2007 11:22:52 -0700, Daniele Varrazzo
<daniele.varra...@gmail.comEvery 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.
May 7 '07 #5

P: n/a
On 7 Mag, 10:46, "Stefan Sonnenberg-Carstens"
<stefan.sonnenb...@pythonmeister.comwrote:
On Mo, 7.05.2007, 10:30, Daniele Varrazzo wrote:
On 7 Mag, 08:55, "krishnakant Mane" <researchb...@gmail.comwrote:
On 6 May 2007 11:22:52 -0700, Daniele Varrazzo
<daniele.varra...@gmail.comEvery 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

May 7 '07 #6

P: n/a
On Mo, 7.05.2007, 11:32, Daniele Varrazzo wrote:
On 7 Mag, 10:46, "Stefan Sonnenberg-Carstens"
<stefan.sonnenb...@pythonmeister.comwrote:
>On Mo, 7.05.2007, 10:30, Daniele Varrazzo wrote:
On 7 Mag, 08:55, "krishnakant Mane" <researchb...@gmail.comwrote:
On 6 May 2007 11:22:52 -0700, Daniele Varrazzo
<daniele.varra...@gmail.comEvery 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
May 7 '07 #7

P: n/a
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

May 7 '07 #8

P: n/a
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.

May 7 '07 #9

P: n/a
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

May 7 '07 #10

P: n/a
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
May 7 '07 #11

P: n/a
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.
May 7 '07 #12

This discussion thread is closed

Replies have been disabled for this discussion.