JDBC in Jython, prepared statements

1.1k Views Asked by At

I am looking arround for prepared statements in Jython with JDBC (zxJDBC) / SQLite. All I find is examples like this (book, Jython documentation):

qry = "select continent from country where name = ?"
cursor.executemany(qry,['Austria'])

However I always understood prepared statements as a way to let the Database optimize a statement without knowing the values inserted for the placeholders. One then receives a handle to this statement wich has been passed through the optimizer and can execute this with different values, saving the query optimization effort, thus I would expect that the following approach is better:

qry = cursor.prepare("SELECT * FROM `table` WHERE `field`=? AND `field2`=?") #usually mor complex queries
qry.execute(cursor, ?, (val1, val2)??) #here is the problem

unfortunately I can't find examples of how to use the execute and the documentation is lacking.

PyStatement.execute(cursor, params, bindings)

Could you explain me what params is for and if my guess at how to use bindings is correct. My best guess for params would be, that they are the first parameter to the setInt-Method (or the like) from Javas JDBC, put that would be rather surprising. I expected to be Jython more short handed and for it to simply expect the parameters in the right(front to back) order.

Bonus: Is there a way to free a resultset? (Besides closing the cursor)

1

There are 1 best solutions below

1
On

It looks like this extension uses the normal Python Database Specification v2

For execute it says:

A reference to the operation will be retained by the cursor. If the same operation object is passed in again, then the cursor can optimize its behavior. This is most effective for algorithms where the same operation is used, but different parameters are bound to it (many times).

And for executemany it says:

The same comments as for .execute() also apply accordingly to this method.

So if this drivers actually implements these suggested semantics, then just passing in the same string into execute or executemany should reuse the preparedstatement, however you might want to check the implementation (or ask the implementer) to be sure