[DB-SIG] Towards a single parameter style

Stuart Bishop zen@shangri-la.dropbear.id.au
Wed, 19 Feb 2003 15:05:56 +1100


On Tuesday, February 18, 2003, at 11:01  PM, Kevin Jacobs wrote:

>   connection = connect(...)
>   cursor = connection.cursor()
>   command = cursor.prepare(sql)
>   cursor.execute(command, (arg1, arg2, arg3))

As this example stands, I don't see what this syntax gains us except an 
extra
needless line.
     connection = connect(...)
     command = connection.cursor()
     command.execute(sql, (arg1, arg2, arg3))

It also makes things a lot more complex:
	- We now have to make sure that both our cursor *and* our
	  prepared statements are being used in a thread safe manner.
	- Can my command be used with cursor that didn't create it? Or a cursor
       created from a different connection?

One of your previous examples gave a better justification, where you 
had a
'print statement.description' in between the prepare and execute 
commands.
You then gave a reason why this isn't a good idea because 'this syntax
_requires_ that the backend support prepared statements'.

The only use I can see for a PreparedStatement object would be to:
	Query it for its 'description'
	Execute it

So would a better alternative be to simply have a new (optional)
cursor method?:
	cursor.fetchDescription(sql) -- returns the cursor.description
		sequence for the given statement, without actually executing
		it. This method will not be implemented if the backend cannot
		retrieve this information without actually executing the statement,
		or it may be defined and raise NotImplementedError in this case.

> So instead of the cursor keeping a reference to command, the command is
> returned to the user and passed back in as the first argument to 
> execute.

Icky. If you go this way, the command should have a reference to the 
cursor
IMHO. At which point it becomes apparent that only one object is 
actually
desired :-)

-- 
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/