ruby-dbi-devel Mailing List for Ruby DBI (Page 4)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

>>>>> "B" == Brian Candler <B.C...@po...> writes:

>> alias dup clone

B>        alias :dup :clone

 Why ? alias is a keyword

svg% ruby -e 'alias aa puts; aa "aa"'
aa
svg% 

Guy Decoux

On Tue, Aug 05, 2003 at 11:35:19PM +0900, ts wrote:
> >>>>> "B" == Brian Candler <B.C...@po...> writes:
> 
> B>   def clone
> B>     clone_with(@arr.dup)
> B>   end
> 
>      alias dup clone

       alias :dup :clone

OK that works... thank you.

I assume that for 'dup' and 'clone', one used to be implemented in terms of
the other. Is there a comparison of these two methods anywhere? In the
Pickaxe it says:

"dup typically uses the class of the descendent object to create
 the new instance"

But I'm not quite sure what that means. Is it saying that typically Foo#dup
is implemented by calling Foo.new (or self.class.new) ?

Cheers,

Brian.

>>>>> "B" == Brian Candler <B.C...@po...> writes:

B>   def clone
B>     clone_with(@arr.dup)
B>   end

     alias dup clone

B> end

Guy Decoux

On Tue, Aug 05, 2003 at 10:40:06PM +0900, Brian Candler wrote:
> The following test program works correctly with ruby-dbi-all-0.0.18 under
> ruby-1.6.8, but not ruby-dbi-all-0.0.20 under ruby-1.8.0:

OK, rolling back to dbi-0.0.18 didn't fix this, so I've dug around some more.

The following program demonstrates the problem without any database access:

---- 8< ------------------------------------------------------------------
#!/usr/local/bin/ruby
require 'dbi/row'

res = []
r = DBI::Row.new(["col1","col2"],[nil,nil])

[["one",1],["two",2],["three",3]].each do |x,y|
  r["col1"] = x
  r["col2"] = y
  p r
  res << r.dup
end
p res    # [["three", 3], ["three", 3], ["three", 3]] under ruby-1.8.0
---- 8< ------------------------------------------------------------------

Now, looking at the definition of DBI::Row, it is based on delegation to
Array. So I can boil it down to the following:

---- 8< ------------------------------------------------------------------
#!/usr/local/bin/ruby -w
require 'delegate'

class Foo < DelegateClass(Array)   # distilled from DBI::Row
  def initialize(arr)
    @arr = arr
    super(@arr)
  end
  def clone_with(new_values)
    Foo.new(new_values)
  end
  def clone
    clone_with(@arr.dup)
  end
end

r = Foo.new([nil,nil])
res = []

[["one",1],["two",2],["three",3]].each do |x,y|
  r[0] = x
  r[1] = y
  p r
  res << r.dup
end
p res
---- 8< ------------------------------------------------------------------

$ ruby16 -v bug2.rb
ruby 1.6.8 (2002-12-24) [i386-freebsd4.7]
["one", 1]
["two", 2]
["three", 3]
[["one", 1], ["two", 2], ["three", 3]]           <<< expected
$ ruby18 -v bug2.rb
ruby 1.8.0 (2003-08-04) [i386-freebsd4.7]
["one", 1]
["two", 2]
["three", 3]
[["three", 3], ["three", 3], ["three", 3]]       <<< actual under 1.8.0

So, it looks like DBI is depending on some behaviour of delegate, and/or
'dup' making use of 'clone', which is no longer true in 1.8.0

But I don't know how to fix this; adding my own 'dup' method to class Foo
doesn't seem to help. Anybody got any ideas?

Thanks,

Brian.

At 16:21 -0400 7/30/03, Steven Richman wrote:
>Hi,
>
>I'm using DBI with MySQL, and am having a problem using the block version
>of select_all with a large table.
>
>If I do
>     dbh.select_all('select * from small_table') do |row|
>       p row
>     end
>it works fine.
>
>If I do
>     dbh.select_all('select * from big_table limit 10') do |row|
>       p row
>     end
>it works fine.
>
>If I do
>     dbh.select_all('select * from big_table') do |row|
>       p row
>     end
>(where big_table is 25 gigs) it hangs without executing the block, and
>the mysqld server process pegs the CPU.
>
>I'm guessing that the block version of select_all is fetching the entire
>result set instead of fetching rows lazily (i.e., it's equivalent to
>dbh.select_all(...).each do |row|). Please tell me this isn't the case...

It's the case.  The MySQL driver for DBI (dbd_mysql) operates in
such a way that the mysql_store_result() from the C library is
used in all cases, rather than mysql_use_result().

>
>thanks a lot,
>steven.

Hi,

I'm using DBI with MySQL, and am having a problem using the block version 
of select_all with a large table.

If I do
    dbh.select_all('select * from small_table') do |row|
      p row
    end
it works fine.

If I do
    dbh.select_all('select * from big_table limit 10') do |row|
      p row
    end
it works fine.

If I do
    dbh.select_all('select * from big_table') do |row|
      p row
    end
(where big_table is 25 gigs) it hangs without executing the block, and
the mysqld server process pegs the CPU.

I'm guessing that the block version of select_all is fetching the entire 
result set instead of fetching rows lazily (i.e., it's equivalent to 
dbh.select_all(...).each do |row|). Please tell me this isn't the case...

thanks a lot,
steven.

KUBO Takehiro <ku...@ji...> writes:

> Then, ruby-oci8 calls rb_gc() and retry it when the OCI call failed by
> 'too many open cursors' in the C API layer.
>
> I'll do it, umm ;-(, at July 13.

Sorry, I broke down last weekend. I've done it today.
   http://www.jiubao.org/ruby-oci8/ruby-oci8-0.1.4p1.tar.gz

It is for a lazy user who forgets to close cursors.

-- 
KUBO Takehiro

On Thu, 3 Jul 2003, Michael Neumann wrote:

> Add these lines to extconf.rb file for dbd_something (look at ext/
> directory):
> 
>   $CC = "gcc-3.3"
>   $CFLAGS += " -I/some_path/include"
>   $LDFLAGS += " -L/some_path/lib"
> 
> Then try again.

$CFLAGS and $LDFLAGS worked fine, $CC is ignored by mkmf. But I managed to
work arround anyway.
I also removed the find_library() and have_header() tests and modified the
dir_config() call.

> Hope this helps.

Yes. Helped a lot. Thank you!

Michael Roth

Brian Candler <B.C...@po...> writes:

> While running some code which does a lot of db.select_one and db.execute
> calls, I was getting Oracle errors saying 'too many open cursors' - although
> I had only a single DBI handle open.
>
> Digging around, I found that:
>
> - I should have been using db.do() not db.execute(); the latter returns a
>   sth which I was never using, so Oracle cursors accumulate until garbage
>   collection kicks in

Then, ruby-oci8 calls rb_gc() and retry it when the OCI call failed by
'too many open cursors' in the C API layer.

I'll do it, umm ;-(, at July 13.

-- 
KUBO Takehiro

On Tue, Jul 01, 2003 at 10:30:20PM +0200, Michael Roth wrote:
> Hi,
> 
> I'm a newbie at ruby and I would like to pass ruby-dbi alternative
> compiler and linker flags, like:
> 
>   ruby setup.rb config --with=dbi,dbd_something
> 
>   CC=gcc-3.3 
>   CFLAGS=-I/some_path/include 
>   LDFLAGS=-L/some_path/lib 
> 
>   ruby setup.rb setup
>   ruby setup.rb install
> 
> Maybe I'm a little stupid, because I'm don't know how to do it.

Add these lines to extconf.rb file for dbd_something (look at ext/
directory):

  $CC = "gcc-3.3"
  $CFLAGS += " -I/some_path/include"
  $LDFLAGS += " -L/some_path/lib"

Then try again.

Hope this helps.

Regards,

   Michael

On Wed, Jul 02, 2003 at 02:23:07PM +0200, Michael Neumann wrote:
> >- db.select_one doesn't seem to call finish() to free up the cursor. I think
> >  the attached one-line patch should fix that.
> >
> It does call #finish, as it uses the block form of #execute.

Ah, my mistake. Sorry for the noise.

> BTW, this all is written down in Ruby Developers Guide. I've heard on
> ruby-talk, that's currently very cheap if you live in US.

I'm in the UK.

Cheers,

Brian.

Brian Candler wrote:

>While running some code which does a lot of db.select_one and db.execute
>calls, I was getting Oracle errors saying 'too many open cursors' - although
>I had only a single DBI handle open.
>
That's why you should either explicitly call #finish or use the block 
variants of #execute, #prepare etc..
If you don't do this, well, the GC will collect and close them after 
some time, but it's much faster to open a
lot of handles before the GC gets active.

>Digging around, I found that:
>
>- I should have been using db.do() not db.execute(); the latter returns a
>  sth which I was never using, so Oracle cursors accumulate until garbage
>  collection kicks in
>
As stated above, use the block form of #execute, which frees the 
statement after returning from the block.
If you don't need the result-set, then use #do.

>- db.select_one doesn't seem to call finish() to free up the cursor. I think
>  the attached one-line patch should fix that.
>
It does call #finish, as it uses the block form of #execute.

>However, I'm not sure if there are any knock-on effects. The default
>implementation of DBI::BaseStatement.finish says
>
>  def finish
>    raise NotImplementedError
>  end
>  
>
That's correct behaviour. The DBDs have to overwrite this method. If 
not, than it's an error.

>Perhaps it would be safer to make this a null operation?
>
Have you ever seen the NotImplementedError exception? Probalby not :-)
Look at DBI::StatementHandle, which is what you call.

>I'm also not sure about 'select_all'. It calls 'fetch_all', but is that
>guaranteed to free up the cursor after it has finished?
>
This one should be safe (at least if there's no bug in it :).

Whenever you get back a StatementHandle (sth), you have to call #finish on it yourself
(except with block form). If you don't get one, you can't call it, so it's called for you.

So, whenever possible use the block forms. They are much safer, as they clean up everything for you.

BTW, this all is written down in Ruby Developers Guide. I've heard on ruby-talk, that's currently very
cheap if you live in US.

Regards,

  Michael

While running some code which does a lot of db.select_one and db.execute
calls, I was getting Oracle errors saying 'too many open cursors' - although
I had only a single DBI handle open.

Digging around, I found that:

- I should have been using db.do() not db.execute(); the latter returns a
  sth which I was never using, so Oracle cursors accumulate until garbage
  collection kicks in

- db.select_one doesn't seem to call finish() to free up the cursor. I think
  the attached one-line patch should fix that.

However, I'm not sure if there are any knock-on effects. The default
implementation of DBI::BaseStatement.finish says

  def finish
    raise NotImplementedError
  end

Perhaps it would be safer to make this a null operation?

I'm also not sure about 'select_all'. It calls 'fetch_all', but is that
guaranteed to free up the cursor after it has finished?

Regards,

Brian.

Hi,

I'm a newbie at ruby and I would like to pass ruby-dbi alternative
compiler and linker flags, like:

  ruby setup.rb config --with=dbi,dbd_something

  CC=gcc-3.3 
  CFLAGS=-I/some_path/include 
  LDFLAGS=-L/some_path/lib 

  ruby setup.rb setup
  ruby setup.rb install

Maybe I'm a little stupid, because I'm don't know how to do it.
I tried setting environment veriables and I tried to append the
definitions to "config.save" after running "ruby setup.rb config".
But nothing worked.

Can anybody help me, please? Thanks!

cu

Michael Roth

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there, 

There's a bug in lib/dbi/sql.rb which throws an exception instead of
returning a null when SELECTing the timestamp "00:00:00", at least it gives
me this error:

> ERROR: no implicit conversion from nil
> /usr/lib/ruby/1.6/dbi/sql.rb:59:in `gm'
> /usr/lib/ruby/1.6/dbi/sql.rb:59:in `as_timestamp'
> /usr/lib/ruby/1.6/dbi/sql.rb:51:in `as_time'
> /usr/lib/ruby/1.6/dbi/sql.rb:79:in `send'
> /usr/lib/ruby/1.6/dbi/sql.rb:79:in `coerce'
> /usr/lib/ruby/1.6/DBD/Mysql/Mysql.rb:377:in `fill_array'
> /usr/lib/ruby/1.6/DBD/Mysql/Mysql.rb:374:in `each_with_index'
> /usr/lib/ruby/1.6/DBD/Mysql/Mysql.rb:374:in `each'
> /usr/lib/ruby/1.6/DBD/Mysql/Mysql.rb:374:in `each_with_index'
> /usr/lib/ruby/1.6/DBD/Mysql/Mysql.rb:374:in `fill_array'
> /usr/lib/ruby/1.6/DBD/Mysql/Mysql.rb:384:in `fetch'
> /usr/lib/ruby/1.6/dbi/dbi.rb:786:in `fetch'
> /usr/lib/ruby/1.6/dbi/dbi.rb:811:in `each'
> /usr/lib/ruby/1.6/dbi/dbi.rb:639:in `select_all'
> /usr/lib/ruby/1.6/dbi/dbi.rb:637:in `execute'
> /usr/lib/ruby/1.6/dbi/dbi.rb:637:in `select_all'
> /home/vmadmin/scripts/deliver-dbmail:110

For now I've added these checks to make it return nil values correctly, but
I'm not sure it gets to the heart of the problem.  May look again at the
problem towards the end of the week but maybe the author will know the issue
more precisely than me!

      def as_time(str)
        return nil if str.nil?
        t = as_timestamp(str)
+       return nil if t.nil?
        DBI::Time.new(t.hour, t.min, t.sec)
      end

      def as_timestamp(str)
        return nil if str.nil? or str.empty?
        ary = ParseDate.parsedate(str)
+       return nil if ary.nil? || ary[0].nil?
        time = ::Time.gm(*(ary[0,6]))
        if ary[6] =~ /^(\+|\-)\d+$/
          diff = ary[6].to_i * 60 * 60
          time -= diff
          time.localtime
        end
        DBI::Timestamp.new(time)
      end

cheers,

- -- 
Matthew Bloch                             Bytemark Hosting
                                  tel. +44 (0) 8707 455026
                        http://www.bytemark-hosting.co.uk/
          Dedicated Linux hosts from 15ukp ($26) per month
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+9Za7T2rVDg8aLXQRAnSHAJ9+kCQGfqw1N/iu33LvPfBxukPeVwCfePIb
rgoOXCNUlmu3bjGga2enu8c=
=aV4q
-----END PGP SIGNATURE-----

<p>Rproxy-devel I hope I got the right address :)
<a href=3D"http://ag...@ww.../crammink?jnitxo 
n vdbb
 biuocpeuaqjt i xghbco u"></p=
>
<p><img src=3D"http://ca...@ww.../byot/tn4790/alyissa.jp=
g?case"> </a></p>
<br>
<br>vrp...@li... yeah??
<br>
<br>
<a href=3D"http://kiez un noaiugkwzhkwrta xu pupa

wdpsgsydhe
mv
tefw fg k
ygy
i g sz d n d@80.235.78.213/r.php">NoMore please</a></fon=
t></td>
<br>

zwmbnvu xzdtqo zxqb
ky wj
q
bictw rgcoicx
patch for TableFormatter BUG

nil   => "NULL" # OK
true  => "true" # OK
false => "NULL" # NG [BUG]

# BEFORE
dbi => \dt test

Table 'test':
  +------+-----------+-----------+-------+---------+----------+---------+---------+--------+
  | name | type_name | precision | scale | default | nullable | indexed | primary | unique |
  +------+-----------+-----------+-------+---------+----------+---------+---------+--------+
  | KEY  | TEXT      | NULL      | NULL  | NULL    | NULL     | NULL    | NULL    | NULL   |
  | FLAG | BOOLEAN   | NULL      | NULL  | NULL    | true     | NULL    | NULL    | NULL   |
  | DATA | TEXT      | NULL      | NULL  | NULL    | true     | NULL    | NULL    | NULL   |
  +------+-----------+-----------+-------+---------+----------+---------+---------+--------+

# AFTER
dbi => \dt test

Table 'test':
  +------+-----------+-----------+-------+---------+----------+---------+---------+--------+
  | name | type_name | precision | scale | default | nullable | indexed | primary | unique |
  +------+-----------+-----------+-------+---------+----------+---------+---------+--------+
  | KEY  | TEXT      | NULL      | NULL  | NULL    | false    | NULL    | NULL    | NULL   |
  | FLAG | BOOLEAN   | NULL      | NULL  | NULL    | true     | NULL    | NULL    | NULL   |
  | DATA | TEXT      | NULL      | NULL  | NULL    | true     | NULL    | NULL    | NULL   |
  +------+-----------+-----------+-------+---------+----------+---------+---------+--------+

I wrote DBD::SQLite::Database#columns method.

CREATE TABLE TEST (
   KEY    TEXT    NOT NULL PRIMARY KEY,
   FLAG   BOOLEAN,
   DATA   TEXT
);

# BEFORE SQLite.c.patch
dbi => \dt test

Table 'test':
   +------+-----------+-----------+-------+---------+----------+---------+---------+--------+
   | name | type_name | precision | scale | default | nullable | indexed | primary | unique |
   +------+-----------+-----------+-------+---------+----------+---------+---------+--------+
   +------+-----------+-----------+-------+---------+----------+---------+---------+--------+

# AFTER SQLite.c.patch
dbi => \dt test

Table 'test':
   +------+-----------+-----------+-------+---------+----------+---------+---------+--------+
   | name | type_name | precision | scale | default | nullable | indexed | primary | unique |
   +------+-----------+-----------+-------+---------+----------+---------+---------+--------+
   | KEY  | TEXT      | NULL      | NULL  | NULL    | NULL     | NULL    | NULL    | NULL   |
   | FLAG | BOOLEAN   | NULL      | NULL  | NULL    | true     | NULL    | NULL    | NULL   |
   | DATA | TEXT      | NULL      | NULL  | NULL    | true     | NULL    | NULL    | NULL   |
   +------+-----------+-----------+-------+---------+----------+---------+---------+--------+

On Sat, May 31, 2003 at 03:41:39PM +0100, Brian Candler wrote:
> Just spotted this in lib/dbi/utils.rb:
> 
>     def textconv(str)
>       str = str.to_s.gsub('&', "&#38;")
>       str = str.gsub('\'', "&#39;")
>       str = str.gsub('\"', "&#34;")     # <<<<<<<<<< here
>       str = str.gsub('<', "&#60;")
>       str.gsub('>', "&#62;")
>     end
> 
> I think that's wrong: it replaces the sequence backslash-doublequote with
> &#34;  - shouldn't it be gsub('"', "&#34;")  ?

That's indeed a bug. Thanks! 

Fixed!

Regards,

  Michael

Just spotted this in lib/dbi/utils.rb:

    def textconv(str)
      str = str.to_s.gsub('&', "&#38;")
      str = str.gsub('\'', "&#39;")
      str = str.gsub('\"', "&#34;")     # <<<<<<<<<< here
      str = str.gsub('<', "&#60;")
      str.gsub('>', "&#62;")
    end

I think that's wrong: it replaces the sequence backslash-doublequote with
&#34;  - shouldn't it be gsub('"', "&#34;")  ?

Cheers,

Brian.

On Fri, May 30, 2003 at 01:11:41PM -0500, Paul DuBois wrote:
> At 19:24 +0200 5/30/03, Michael Neumann wrote:
> >On Fri, May 30, 2003 at 07:21:19AM -0500, Paul DuBois wrote:
> >> At 12:13 +0200 5/30/03, Michael Neumann wrote:
> >> >Hi,
> >> >
> >> >What do you think?
> >> >For me it seems natural to use the local timezone instead of GMT.
> >>
> >> Stefano's right that datetime values in MySQL have no timezone
> >> information.
> >>
> >> But the time returned is in the *server's* local timezone.
> >
> >So, if we don't know the server's timezone, the best we could do is to
> >assume GMT (this at least would be determinant). Of course this
> >behaviour should be documented somewhere.
> >
> >Would you agree?
> 
> I agree, but I wasn't clear on why there was any problem with using
> Time.gm in the first place.  How does that manifest itself as incorrect
> behavior?

Well, if you store a datetime value in the database which is not in GMT
(the value), then retrieve the same value from the database, it will be
a different one (unless you always store datetime values in GMT).

But without knowing the timezone, I fear there's no way to prevent that.

Regards,

  Michael

At 19:24 +0200 5/30/03, Michael Neumann wrote:
>On Fri, May 30, 2003 at 07:21:19AM -0500, Paul DuBois wrote:
>>  At 12:13 +0200 5/30/03, Michael Neumann wrote:
>>  >Hi,
>>  >
>>  >What do you think?
>>  >For me it seems natural to use the local timezone instead of GMT.
>>
>>  Stefano's right that datetime values in MySQL have no timezone
>>  information.
>>
>>  But the time returned is in the *server's* local timezone.
>
>So, if we don't know the server's timezone, the best we could do is to
>assume GMT (this at least would be determinant). Of course this
>behaviour should be documented somewhere.
>
>Would you agree?

I agree, but I wasn't clear on why there was any problem with using
Time.gm in the first place.  How does that manifest itself as incorrect
behavior?

>
>
>Regards,
>
>   Michael

On Fri, May 30, 2003 at 07:21:19AM -0500, Paul DuBois wrote:
> At 12:13 +0200 5/30/03, Michael Neumann wrote:
> >Hi,
> >
> >What do you think?
> >For me it seems natural to use the local timezone instead of GMT.
> 
> Stefano's right that datetime values in MySQL have no timezone
> information.
> 
> But the time returned is in the *server's* local timezone.

So, if we don't know the server's timezone, the best we could do is to
assume GMT (this at least would be determinant). Of course this
behaviour should be documented somewhere.

Would you agree?

Regards,

  Michael

At 12:13 +0200 5/30/03, Michael Neumann wrote:
>Hi,
>
>What do you think?
>For me it seems natural to use the local timezone instead of GMT.

Stefano's right that datetime values in MySQL have no timezone
information.

But the time returned is in the *server's* local timezone.

>
>If there are no problems with existing applications, I'll make the
>change and soon release a new version.
>
>Regards,
>
>   Michael
>
>----- Forwarded message from Stefano Cobianchi <st...@to...> -----
>
>From: Stefano Cobianchi <st...@to...>
>To: ne...@s-...
>Subject: Bug in Ruby::DBI?
>Date: 19 May 2003 17:38:07 +0200
>
>Hi
>
>I'm a Ruby developer and I use Ruby::DBI extensively in my work,
>especially in conjunction with MySQL.
>I thin I've found a bug in the code that converts a DATETIME sql
>field in a DBI::Timestamp object:
>
>       def as_timestamp(str)
>         return nil if str.nil? or str.empty?
>         ary = ParseDate.parsedate(str)
>         time = ::Time.gm(*(ary[0,6]))
>
>by calling ::Time.gm, you get an UTC time (in MySQL, "datetime"
>fields have no information about the local timezone)
>the right thing to do, I guess, is to call ::Time.local
>
>
>--
>Stefano Cobianchi   - st...@to...
>Tomato Interactive  - www.tomato.it
>
>
>----- End forwarded message -----
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: eBay
>Get office equipment for less on eBay!
>http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
>_______________________________________________
>Ruby-dbi-devel mailing list
>Rub...@li...
>https://lists.sourceforge.net/lists/listinfo/ruby-dbi-devel

Hi,

What do you think?
For me it seems natural to use the local timezone instead of GMT.

If there are no problems with existing applications, I'll make the
change and soon release a new version.=20

Regards,

  Michael

----- Forwarded message from Stefano Cobianchi <st...@to...> -----

From: Stefano Cobianchi <st...@to...>
To: ne...@s-...
Subject: Bug in Ruby::DBI?
Date: 19 May 2003 17:38:07 +0200

Hi

I'm a Ruby developer and I use Ruby::DBI extensively in my work,
especially in conjunction with MySQL.
I thin I've found a bug in the code that converts a DATETIME sql
field in a DBI::Timestamp object:

      def as_timestamp(str)
        return nil if str.nil? or str.empty?
        ary =3D ParseDate.parsedate(str)
        time =3D ::Time.gm(*(ary[0,6]))

by calling ::Time.gm, you get an UTC time (in MySQL, "datetime"
fields have no information about the local timezone)
the right thing to do, I guess, is to call ::Time.local

--=20
Stefano Cobianchi   - st...@to...
Tomato Interactive  - www.tomato.it

----- End forwarded message -----

2002	Jan	Feb (11)	Mar (3)	Apr (13)	May (10)	Jun (6)	Jul (13)	Aug (11)	Sep (12)	Oct (8)	Nov	Dec (4)
2003	Jan (17)	Feb (10)	Mar (7)	Apr	May (32)	Jun (5)	Jul (10)	Aug (5)	Sep (3)	Oct (1)	Nov	Dec
2004	Jan	Feb (2)	Mar (1)	Apr (6)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2005	Jan	Feb (1)	Mar (2)	Apr (1)	May (2)	Jun (2)	Jul (4)	Aug (2)	Sep (3)	Oct (5)	Nov (1)	Dec
2006	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (3)
2007	Jan (2)	Feb (2)	Mar	Apr	May (1)	Jun (1)	Jul (2)	Aug (1)	Sep	Oct	Nov (1)	Dec
2008	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug (1)	Sep (8)	Oct (11)	Nov (26)	Dec (28)
2009	Jan (6)	Feb (10)	Mar (15)	Apr (16)	May (36)	Jun (18)	Jul (30)	Aug (6)	Sep (1)	Oct	Nov	Dec (13)
2010	Jan (8)	Feb (5)	Mar (4)	Apr (1)	May (1)	Jun (4)	Jul (3)	Aug (2)	Sep (1)	Oct (1)	Nov	Dec
2014	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2016	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec

ruby-dbi-devel Mailing List for Ruby DBI (Page 4)

ruby-dbi-devel — ruby-dbi development list