[ANN] Ruby/DBI 0.0.23

[Michael Neumann]

Hi,

I released Ruby/DBI 0.0.23.

Fixed several bugs.
See http://ruby-dbi.rubyforge.org/ChangeLog for more changes.

* DBD::ODBC: Implemented DNS-less connections.

* DBD:SQLite: #do returns number of rows changed

* DBD::Oracle: Database#tables returns tables AND views

* DBI: Timezone parsing and quoting issues fixed.

* DBD::SQLite: raise exception if sql statement
contains NUL characters (patch by Shirai,Kaoru)

WWW: http://rubyforge.org/projects/ruby-dbi

Regards,

Michael

 

[Daniel Berger]

Hi,

I released Ruby/DBI 0.0.23.

Fixed several bugs.
See http://ruby-dbi.rubyforge.org/ChangeLog for more changes.

* DBD::ODBC: Implemented DNS-less connections.

* DBD:SQLite: #do returns number of rows changed

* DBD::Oracle: Database#tables returns tables AND views

<snip>

Hmm....I was just wondering if views should be included as part of the
tables() method or have there own views() method because, after all,
views are not tables. Or is this a standard defined somewhere? I
realize that this is how Perl (and others?) do things but I'm not sure
that it's appropriate. I'm open to arguments for or against.

Regards,

Dan

 

[Nicholas Van Weerdenburg]

Excuse me if this is a silly questions, but why such a low number,
0.0.23? Does it fit some general sense of library revision numbers that
I can use to assess whether I can use it for certain types of projects?

Thanks,
Nick

 

[Michael Neumann]

Excuse me if this is a silly questions, but why such a low number,
0.0.23? Does it fit some general sense of library revision numbers that
I can use to assess whether I can use it for certain types of projects?

It's just that I was/am too lazy to go to a 0.1 or even 1.0 version.
This was discussed long time before, but I never made that change. The
major problem I currently have with going to 1.0 is that I think it's
not good to have one and the same version number for the DBI and all the
included DBDs (database drivers). Some DBDs are still very experimental,
whereas the DBI is quite stable.

Regards,

Michael

 

[Michael Neumann]

<snip>

Hmm....I was just wondering if views should be included as part of the
tables() method or have there own views() method because, after all,
views are not tables. Or is this a standard defined somewhere? I
realize that this is how Perl (and others?) do things but I'm not sure
that it's appropriate. I'm open to arguments for or against.

I think tables() should return everything that can be queried using a
SELECT statement. This method is quite useful for example for the
sqlsh.rb script (interactive sql shell), but not that useful for most
other applications. I think there should be a more advanced method that
knows more about the type of object table/view/stored procedure.

But I am not sure if there's currently a real need for this. I think
there are still more important tasks to do, but I am open for
discusssion.

Regards,

Michael