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
|
