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

Tom Ward
Fri, 19 Jan 2007 12:28:40 -0000

On 19/01/07, Tom Ward <tom@popdog.net> wrote:
> 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.

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