MySQL for Python

Catching different exceptions

To customize which error is caught, we need different except clauses. The basic structure of this strategy is as follows:
try:

except ErrorType1:

except ErrorType2:

Each of the previous types can be caught with the DatabaseError type. However, catching them separately allows you to customize responses. For example, you may want the application to fail softly for the user when a ProgrammingError is raised but nonetheless want the exception to be reported to the development team. You can do that with customized exception handling.

For exceptions see:
http://python.about.com/od/pythonstandardlibrary/a/lib_exceptions.htm
For warnings visit:
http://python.about.com/od/pythonstandardlibrary/a/lib_warnings.htm
The Python documentation also covers them at:
http://docs.python.org/library/exceptions.html

except MySQLdb.Error, e:
print "An error has been passed. %s" %e

An exception is only explicitly registered when raise is used. Instead of the print statement used in the except clause previously, we can raise an error and update the print statement with the following line of code:
raise MySQLdb.Error
Instead of the friendly statement about an error passing, we get a stack trace that ends as follows:
_mysql_exceptions.Error

The executemany() method may be used not only to insert or update data, but may also be used to run multiple queries.

Note that % is a universal quantifier and matches any number of any characters—even zero occurrences of characters.

The savings here are in memory usage—more or less the same system resources are allotted for each iteration and then released back to the system to be allotted again. So memory usage does not ramp up with each iteration.

Where fetchone() was simply a method of the cursor object, fetchmany() requires the desired number of records to be passed as an argument. The basic syntax of the call is as follows:
= .fetchmany()

The common, non-technical view is that servers can process requests from multiple users at one time. This is erroneous. Servers process requests quickly using a first-in first-out (FIFO) queue system.