From: Jean-Denis Muys <jdmuys@...>
Date: 2009-02-06T19:14:38+09:00
Subject: Re: Bug in SQLite3 Ruby wrapper when results_as_hash=true?

Quoting Ryan Davis <ryand-ruby@zenspider.com>:

>
> On Feb 5, 2009, at 08:06 , Jean-Denis Muys wrote:
>
> >
> > The results is indeed a hash, but with spurious entries:
> >
> > [{"Name"=>"Doe", 0=>"Doe", 1=>"John", 2=>"555-123-4567",
> > "Telephone"=>"555-123-4567", "Firstname"=>"John"}]
>
> looks like that is intentional. You can access a value by column name
> or index (like an array).
>
>

It seems indeed intentional. The Database class uses a [SQL] Statement class,
which uses a ResultSet class.

The ResultSet.next method has the following comment:

    # For hashes, the column names are the keys of the hash, and the column
    # types are accessible via the +types+ property.

Yet, the code looks like this:

        [...]
        if @db.results_as_hash
          new_row = HashWithTypes[ *( @stmt.columns.zip( row ).to_a.flatten ) ]
          row.each_with_index { |value,idx| new_row[idx] = value }
          row = new_row
        else [...]

The line beginning with "row.each_with_index" is the one adding the spurious
entries in the Hash. So this seems intentional, even though the comment seems to
say otherwise.

My suggestion is to get rid of this line. I commented it out from my version,
and it now works as I expected.

However, my change will get reversed next time I "gem update", and the
architecture of sqlite3-ruby makes it rather difficult to subclass.

Yet again, I am a Ruby noob, so I welcome suggestions.

Jean-Denis