[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/