Re: Defining the expected behavior of DatabaseStatements.execute()

Tom Ward
Fri, 19 Jan 2007 12:14:30 -0000

On 18/01/07, Michael Koziarski <michael@koziarski.com>
wrote:
>
> > It would be very helpful if the core team could define and document
> > the expected behavior of DatabaseStatements.execute(). The
> > implementations appear to vary. Most adapters will return some sort of
> > native result set, SQL Server returns nil and expects a block, DB2 and
> > Sybase return the affected row count.
> >
> > So please, will someone in core explain the expected behavior and can
> > the execute() documentation in the DatabaseStatements module be
> > updated to reflect the required behavior. Thanks.
>
> My understanding is that the return value of execute is undefined, but
> that it shouldn''t require a block.   The use case is essentially:
>
> "Run  this statement, I don''t need a return value"

I agree, the behaviour of execute is undefined, beyond ''do this on the
database''.    select_one, select_all, select_value, insert, update and
delete provide a standard interface to the db across adapters, while
execute gives much lower level access to the underlying connection.
So in general, you''re much better off using the former rather than the
latter.

BTW, while the SQLServerAdapter.execute can take a block, it shouldn''t
require one.  The block is used to give access to the result set from
the database, without returning it (and running the risk that it isn''t
closed after use).  If no block is provided, the command should run
with no return value.

Tom