problems with mysql db

[golu]

here i have posted my code...plz tell why am i getting the error "int
argument required" on the hash marked line(see below) although i am
giving an int value
#the code
import os
import string
import MySQLdb
import stopcheck
conn = MySQLdb.connect(host='localhost',user='root',db='urdb')

def file_extractor(dir_name):
url_count = 0

for file in os.listdir(dir_name):
if(file[-4:] == '.txt'):
file_path = os.path.join(dir_name,file)
curse = conn.cursor()
url_count += 1
curse.execute("INSERT INTO URL_TABLE VALUES(%d,%s)",
(url_count,file_path)) #error
word_extractor(url_count,file_path)
def word_extractor(url_count,file):
fhandle = open(file)
line = fhandle.readline()
k=stopcheck.checker()
k.create()

while line:
words = line.split()
cursor = conn.cursor()
for word1 in words:
if word1 not in string.punctuation:
if (k.check(word1) is 0) and (word1[0:4] != 'http') :
word_count+=1
try:
cursor.execute("INSERT INTO word_table(id,word)
VALUES(%d,%s)" , (word_count,word1))
cursor.execute("INSERT INTO wordmatch
(word_id,url_id) values(%d,%d)",(word_count,url_count))
except MySQLdb.Error, e:
print "Error %d: %s" % (e.args[0], e.args[1])
line=fhandle.readline()

if __name__ == '__main__':
#url_count=0
#word_count=0

dir = os.path.join('D://','acm')
file_extractor(dir)

 

[Petr Messner]

Hi,

use %s instead of %d in SQL statements, because (AFAIK) conversions
(including SQL escaping) from Python values to SQL values are done
before the % operator is called - that value is not a number by that
point.

I hope you understood it, sorry for my English You can also check
MySQLdb module source, it's pretty clear.

PM

 

[Gabriel Genellina]

use %s instead of %d in SQL statements, because (AFAIK) conversions
(including SQL escaping) from Python values to SQL values are done
before the % operator is called - that value is not a number by that
point.

I hope you understood it, sorry for my English You can also check
MySQLdb module source, it's pretty clear.

It's best to think of %s as just a marker; other adapters use ? or :3 for
the same purpose, and other styles exist too.
The fact that it's the same character used for formatting strings with the
% operator is an unfortunate coincidence (or a very bad choice, I don't
know).

 

[Lawrence D'Oliveiro]

The fact that it's the same character used for formatting strings with the
% operator is an unfortunate coincidence (or a very bad choice, I don't
know).

That's not the problem. The problem is that MySQLdb IS indeed using Python
format substitution to do its argument substitution. Python expects the
value for "%d" to be an integer. But MySQLdb has already converted all the
argument values to strings. Hence the error.

If MySQLdb were doing its own parsing of the format string, it could produce
a more meaningful error message when it sees "%d" (e.g. "only %s
substitutions allowed").

 

[Dennis Lee Bieber]

The fact that it's the same character used for formatting strings with the
% operator is an unfortunate coincidence (or a very bad choice, I don't
know).

At the core -- if one looks at the Python source of the module and
takes into account that, prior to MySQL 5.x, MySQL did not support
"prepared statements", everything being sent as a full string query --
MySQLdb actually uses string interpolation to fill in the fields...
AFTER, of course, passing all the arguments through a function that
"safes" them (escaping sensitive characters, converting numerics to
string equivalent, etc., wrapping quotes about them).

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Gabriel Genellina]

En Tue, 30 Jun 2009 03:33:52 -0300, Dennis Lee Bieber

At the core -- if one looks at the Python source of the module and
takes into account that, prior to MySQL 5.x, MySQL did not support
"prepared statements", everything being sent as a full string query --
MySQLdb actually uses string interpolation to fill in the fields...
AFTER, of course, passing all the arguments through a function that
"safes" them (escaping sensitive characters, converting numerics to
string equivalent, etc., wrapping quotes about them).

Thanks for the historical reference. Even then, the code *could* have used
other markers, like ?, doing the appropiate substitutions before the final
string interpolation...
(but critisizing the original design after many years isn't fair!)