Any particular reason why a shortcut to db._cursor.rowcount  (or a
db.rowcount wrapper) is not goot enough ? I actually considered this
mod some time ago, but in the end I found it easier to use .rowcount,
as it is compatible with inserts (think 'insert into select') for
cases when you are branching between an update and an insert, or doing
an insert that results in multiple rows being inserted. Also, it's
potentially easier to learn/more reusable knowledge as it works the
same way as regular python.

On Dec 16, 12:56 am, billf <[email protected]> wrote:
> The Python API Spec v2.0 contains the following:
>
> .rowcount
>
>             This read-only attribute specifies the number of rows that
>             the last .execute*() produced (for DQL statements like
>             'select') or affected (for DML statements like 'update' or
>             'insert').
>
>             The attribute is -1 in case no .execute*() has been
>             performed on the cursor or the rowcount of the last
>             operation is cannot be determined by the interface. [7]
>
>             Note: Future versions of the DB API specification could
>             redefine the latter case to have the object return None
>             instead of -1.
> ...and, under Major changes from Version 1 to version 2...
> The definition of the .execute() return value changed.
>           Previously, the return value was based on the SQL statement
>           type (which was hard to implement right) -- it is undefined
>           now; use the more flexible .rowcount attribute
>           instead. Modules are free to return the old style return
>           values, but these are no longer mandated by the
>           specification and should be considered database interface
>           dependent.
>
> Consequently, I believe the change to sql.py update() and delete()
> methods should be to change
>
> self._db._execute(query)
>
>  to
>
> self._db._execute(query)
> return self._db._cursor.rowcount
>
> I will test this with sqlite3 and mysql - can anyone with access to
> other db's confirm that rowcount is supported?
>
> On Dec 15, 11:33 pm, billf <[email protected]> wrote:
>
> > Ok - I will try to determine if there is a "standard" way to do this.
> > Can you tell me whether the drivers for the current supported
> > databases conform to any particular specification?  Python Database
> > API Specification v2.0 seems the appropriate one but I'd like it
> > confirmed.
>
> > On Dec 15, 7:17 pm, mdipierro <[email protected]> wrote:
>
> > > I would very much like to include this but this has to work on all
> > > supported databases. Can you send me a patch? It will be included.
>
> > > On Dec 15, 2:26 am, billf <[email protected]> wrote:
>
> > > > I would like access to the rowcount returned from update and delete
> > > > actions.  There are a couple of reasons:
>
> > > > a) it could be used to detect rare errors, e.g. expect 1 row to be
> > > > updated and zero returned.
>
> > > > b) if the update/delete affects several rows, I'd like to know how
> > > > many rows were updated without running a separate select, e.g.
> > > > rowcount=db(db.employee.role==request.vars.role).update(request.vars)
>
> > > > I believe that this can be achieved quite simply by a patch to sql.py
> > > > update() and delete() methods.
>
> > > > Change "self._db._execute(query)" to "return self._db._execute(query)"
>
> > > > If you wanted to access "rowcount" with SQLFORM then other changes
> > > > would be required.
>
> > > > My questions are:
>
> > > > 1) can anyone see a problem with the suggestion?
>
> > > > 2) does anyone object to including the proposed patch?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to