From: Zakaria <z4...@bi...> - 2002-04-20 02:08:30
|
Hi, Sorry for jumping in but I also bitten by this problem. I think the problem is an architechtural problem. There at least 3 solution for this problem 1. Analyze the Query to check whether this a Select or Non-Select This is a big NO NO, because I don't want my database interface to be "smarter" then me and I think this is quite difficult to made if we consider stored procedure call. 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. Also this separation also occur in AOLServer Database API where they have ns_db select and ns_db dml. So, what do you think about this? Any other solution? On Jum, 2002-04-19 at 05:25, Gabriel Emerson wrote: > I should have said; it is in the postgres dbd. Most databases return > the affected rows and row counts in one call. Postgresql uses two > calls to do this. > > I have patched my copy of postgres. I sent a patch to the > Ruby-Postgresql maintainer as well, which supports the change to the > Pg.rb in DBI (it is in the latest version on the Ruby-Postgresql site.) > What I did was create another function just like rows > called "rows.affected", which returns @pgresult.cmdtuples instead of > num_tuples. > > I couldn't think of an easy way to make rows() return either value > depending without analyzing the query... maybe it is simple. > > Thanks, > Gabriel > > (btw, I sent a similar patch to the SQLrelay maintainers, so the > postgresql driver there returns either rows or affected rows, so the DBI > interface to SQLRelay for Postgres should be correct) > > > On Thu, 18 Apr 2002, Sean Chittenden wrote: > > > > Has any decision been reached on whether to include the affected > > > rows count in rows(), or if a new method will be created for the > > > purpose? > > > > > > It's the last feature that keeps me from using a stock dbi on our > > > system. > > > > I think that's a function of the underlying DBD. What database are > > you using? I might be able to toss you a patch if it's postgres... -sc > > > > -- > > Sean Chittenden Regards, -- Zakaria Private: z4...@bi... Yahoo!: z4k4ri4 http://pemula.linux.or.id |