Re: numRows()

"James L. Pine" wrote: > > On Fri, 8 Dec 2000, Stig S. Bakken wrote: > > > What does affectedRows return for Oracle when you do "delete from > > table"? Mysql_affected_rows() returns 0 in this case. This can be > > emulated by sneaking in a "select (*) from" first, but that's not giving ^ There's a "count" missing up here ----' > > me a warm fuzzy feeling. > > you can do a delete from foo where 1=1 and get the number of rows as > well... but this is still slower. we'll probably have to wait until the > addition of real transaction support in mysql before they start deleting > instead of truncating. > > as far as I know, mysql is the only database that doesn't actually know > how many rows it deletes when it does an unconditional delete from a > table. I'm not sure what kind of performance impact it would be to add a > fake condition to the end of these deletes... in benchmark tests, it's a > big difference, but I don't know how important this would be to the > typical web application. (how many times have you unconditionally deleted > from a table with a very large number of rows in a web app... without > transactions?) it's likely to be more overhead from checking for > unconditional deletes than from the addition of an always-true condition. > > oh, what a boring world it would be without the special case. Maybe we could have an "optimized" option in each DB object that lets you disable the ugliest compatibility hacks. By default it should be on (optimize portability). - Stig