Defining the expected behavior of DatabaseStatements.execute()

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.

V/r Anthony Eden

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

One more thing - now that 1.2 is out the door, surely now is a good time to rationalize ActiveRecord and the various adapters. To start the debate rolling, I'd like to say add_limit_offset! smells really bad. Surely there's a cleaner way to manipulate the SQL than bouncing it between ActiveRecord::Base and the adapter?

Thoughts?

Tom

One more thing - now that 1.2 is out the door, surely now is a good time to rationalize ActiveRecord and the various adapters. To start the debate rolling, I'd like to say add_limit_offset! smells really bad. Surely there's a cleaner way to manipulate the SQL than bouncing it between ActiveRecord::Base and the adapter?

It definitely would be nice to refactor all the SQL generation out of Base and into the adapters, where they can safely override whatever behaviour they need to. I don't know that there's necessarily going to be any debate over that :).

By all means, start another thread with what you have in mind :slight_smile: