ruby-dbi-devel

Re: [Ruby-DBI-devel] RPC and Postgres Reprise

[Michael N. <uu...@rz...>]

On Sun, Jun 30, 2002 at 10:02:00PM -0500, Dave Thomas wrote:
> 
> Somewhat lamely I posted the lack of a row count with Postgres #do as
> a bug, then went back through the mailing list archives to see that it
> had been discussed back in April. However, I didn't see a resolution.
> 
> Is this something that can be addressed? If I had a vote, I'd go with
> the option that assumed a #do was used with a none-SELECT statement.

Please correct me if I'm wrong or I misunderstood something.

Method #do returns PGresult#num_tuples, i.e. the number of tuples in the query result.
But that's not what #do in other DBDs return; num_tuples != rows processed count. 
Furthermore #do is usually not called with a SELECT statement, so I don't think that 
anyone is depending on the return value of method #do. 

Statement#rows also returns PGresult#num_tuples, but should return the rows processed count
instead.

So what do you (and others) suggest?

- Add a method to return the number of rows in a query result (that is what #rows currently return) 
- Add a method to return the rows processed count

For the first time, I would leave method #rows as is (we can correct it's behaviour later) and
add a method which returns the same value as #rows currently returns, i.e. the number of rows
in a query result. 

Would it suffice to make it a driver specific function (e.g. sth["dbd_rows_in_result"] or 
sth.func("rows_in_result")), as not all databases supports this?

This would be a temporary solution as long as the DBD/DBI specs will get updated.

> Right now, this is something of a problem for me, as I need to check
> the count following an update to ensure integrity of a long-running
> transaction.

Regards,

  Michael

[Ruby-DBI-devel] Re: RPC and Postgres Reprise

[Gabriel E. <ga...@de...>]

>
> I've now changed method Statement#rows (which is called and returned by
> Database#do) to return the Row Processed Count (affected rows).
> Old behaviour is still available through method Statement#['pg_row_count'].
>
> Both changes are in -current (as well as license change from GNU GPL to BSD).
>
> Regards,
>

Yahoo!  Thanks!  Now I can run our ruby apps with stock DBI...

Re: [Ruby-DBI-devel] RPC and Postgres Reprise

[Dave T. <Da...@Pr...>]

Michael Neumann <uu...@rz...> writes:

> On Sun, Jun 30, 2002 at 10:02:00PM -0500, Dave Thomas wrote:
> > 
> > Somewhat lamely I posted the lack of a row count with Postgres #do as
> > a bug, then went back through the mailing list archives to see that it
> > had been discussed back in April. However, I didn't see a resolution.
> > 
> > Is this something that can be addressed? If I had a vote, I'd go with
> > the option that assumed a #do was used with a none-SELECT statement.
> 
> Please correct me if I'm wrong or I misunderstood something.
> 
> Method #do returns PGresult#num_tuples, i.e. the number of tuples in the query result.
> But that's not what #do in other DBDs return; num_tuples != rows processed count. 
> Furthermore #do is usually not called with a SELECT statement, so I don't think that 
> anyone is depending on the return value of method #do. 
> 
> Statement#rows also returns PGresult#num_tuples, but should return
> the rows processed count instead.

I'm suggesting changing #do to return the number of rows processed
by non-select statements. I think this would be consistent with the
intent.

If you need the number of rows returned by a select, there are (many)
other ways to do it. But right now there's no way to find the number
affected by an update or a delete.

I'd rather not see a driver-specific method: this is a pretty
fundamental feature, and making it non-portable would be a shame.

Cheers


Dave

Re: [Ruby-DBI-devel] RPC and Postgres Reprise

[Michael N. <uu...@rz...>]

On Mon, Jul 01, 2002 at 08:34:26AM -0500, Dave Thomas wrote:
> Michael Neumann <uu...@rz...> writes:
> 
> > On Sun, Jun 30, 2002 at 10:02:00PM -0500, Dave Thomas wrote:
> > > 
> > > Somewhat lamely I posted the lack of a row count with Postgres #do as
> > > a bug, then went back through the mailing list archives to see that it
> > > had been discussed back in April. However, I didn't see a resolution.
> > > 
> > > Is this something that can be addressed? If I had a vote, I'd go with
> > > the option that assumed a #do was used with a none-SELECT statement.
> > 
> > Please correct me if I'm wrong or I misunderstood something.
> > 
> > Method #do returns PGresult#num_tuples, i.e. the number of tuples in the query result.
> > But that's not what #do in other DBDs return; num_tuples != rows processed count. 
> > Furthermore #do is usually not called with a SELECT statement, so I don't think that 
> > anyone is depending on the return value of method #do. 
> > 
> > Statement#rows also returns PGresult#num_tuples, but should return
> > the rows processed count instead.
> 
> I'm suggesting changing #do to return the number of rows processed
> by non-select statements. I think this would be consistent with the
> intent.

Yes, of course.

> If you need the number of rows returned by a select, there are (many)
> other ways to do it. But right now there's no way to find the number
> affected by an update or a delete.
> 
> I'd rather not see a driver-specific method: this is a pretty
> fundamental feature, and making it non-portable would be a shame.

I've now changed method Statement#rows (which is called and returned by 
Database#do) to return the Row Processed Count (affected rows).
Old behaviour is still available through method Statement#['pg_row_count'].

Both changes are in -current (as well as license change from GNU GPL to BSD).

Regards,

  Michael