Re: [Ruby-DBI-devel] Rows Affected and Postgres

[Zakaria <zak...@so...>]

he changes in the #3 solution is not that big and doesn't break
backward compatibility at all.

We just add DBI::DatabaseHandle#dml_prepare and
DBI::DatabaseHandle#dml_execute (for the shortcut).
dml_prepare method will result in a DMLHandle class that
have rows method but no fetch method.

Anybody knows how they handle it in Perl DBI?

On Min, 2002-04-21 at 04:07, Gabriel Emerson wrote:
> You have good points.  What I don't like about #2 is the
inconsistency,
> but #3 is a large change to impose.  If rows_affected() was added, and
> rows() still worked, but was deprecated for DML, that would give us a
> way out that could keep everyone happy.  Then we can obsolete the
> affected_rows behavior of rows() after sufficient warning.
> 
> As far as I know this only affects PostgreSQL.  I wouldn't want to
> impose as large an API change as #3 on users of other DBDs.  I use DBI
> in production, as I think more and more businesses are, so API
> preservation and measured change are important.
> 
> Just my 2 cents.
> 
> --Gabriel
> 
> > Hi,
> >
> >
> > 2. Add DBI::StatementHandle#num_rows
> >    While this is easy, but this make the API less elegant because
> >    it force the programmer to remember two different method
> >    for the same operation (number of rows processed).
> >
> > 3. Add special method for DML Query (insert, update, delete)
> >    so we can reliably separate Select and Non-Select query.
> >    This is reasonable because you can't use row fetching method
> >    on DBI::DatabaseHandle#execute('UPDATE something...') result.
> >

Regards,


-- Zakaria                         
   http://pemula.linux.or.id