The lastest version of ruby's dbi is build at 2003-09-07, 2 years ago
And the las version of the perl 's is build at 2005-11-29....
So when can we a newer version of ruby's dbi ?
The 0.0.21 is out of date and lack of many important features
The lastest version of ruby's dbi is build at 2003-09-07, 2 years ago
And the las version of the perl 's is build at 2005-11-29....
So when can we a newer version of ruby's dbi ?
The 0.0.21 is out of date and lack of many important features
Yes. There is now a team consisting of myself, Daniel Berger, Francis Hwang,
and Patrick May on the DBI project. We are in the process of updating the
source code repository for DBI on Rubyforge with the latest source so that we
can continue development on DBI.
Thanks,
Kirk Haines
On Wednesday 14 December 2005 8:07 pm, cap wrote:
The lastest version of ruby's dbi is build at 2003-09-07, 2 years ago
And the las version of the perl 's is build at 2005-11-29....So when can we a newer version of ruby's dbi ?
The 0.0.21 is out of date and lack of many important features
As Kirk said, we're moving forward ... but slowly. These sorts of
projects, unfortunately, don't always attract that much attention since
they're difficult and unglamorous. Everyone involved has lots of other
projects to maintain, which is often the way.
Anyway, which "important features" are important to you? It'd be
helpful to us to know more about people's expectations of what ruby dbi
should do.
cap wrote:
The lastest version of ruby's dbi is build at 2003-09-07, 2 years ago
And the las version of the perl 's is build at 2005-11-29....So when can we a newer version of ruby's dbi ?
The 0.0.21 is out of date and lack of many important features
Thanks for your reply and I appreciate your work for providing this lib
for ruby. Now I am promoting ruby in our java team and starting to
write some database maintain tool, but I found that dbi has some bugs
(error while fetching NULL Time column) and lack of some functions (the
DBI::Timestamp doesn't implements == method, can't use Row while
offline...), I thought fixing these is easy but I haven't see any
change from 2003 to now, so I thought the dbi project is stopped and
post this message. I think a new version of dbi is very import now. (I
feel it's hard to use a 0.0.21's lib in 2003 to persuade my colleague
into using it)
Thanks for your reply and I appreciate your work for providing this lib
for ruby. Now I am promoting ruby in our java team and starting to
write some database maintain tool, but I found that dbi has some bugs
(error while fetching NULL Time column) and lack of some functions (the
DBI::Timestamp doesn't implements == method,
I am running into a lot of issues with this too.
Another annoying thing (correct me if I'm insane), but it seems like
depending on the DBMS you are using, StatementHandle#rows can be
inconsistant as to whether it gives you 0 or nil.
My assumption is that StatementHandle#fetchable? is based on one or
the other (i'm guessing nil)
and this means that fetchable? is not platform independant.
For someone who codes on Gentoo(mysql 4.x) and builds his gems on OS X
(mysql 5) and runs his code on Win2k pro(SQL Server via ODBC), this
gets annoying quick.
can't use Row while offline...)
What do you mean by this?
If you're looking for a sort of hash / array type access to datarows,
you could use Ruport to execute your query and then serialize to YAML
and bring back the DataRows easily.
I imagine this could be done with DBI::Rows too though, cant it?
On 12/16/05, cap <capitain@gmail.com> wrote:
I found a patch can fix the NULL(alos include "0000-00-00 00:00:00")
TIME column error
http://sourceforge.net/tracker/index.php?func=detail&aid=902490&group_id=43737&atid=437253
Gregory Brown wrote:
> Thanks for your reply and I appreciate your work for providing this lib
> for ruby. Now I am promoting ruby in our java team and starting to
> write some database maintain tool, but I found that dbi has some bugs
> (error while fetching NULL Time column) and lack of some functions (the
> DBI::Timestamp doesn't implements == method,I am running into a lot of issues with this too.
Another annoying thing (correct me if I'm insane), but it seems like
depending on the DBMS you are using, StatementHandle#rows can be
inconsistant as to whether it gives you 0 or nil.My assumption is that StatementHandle#fetchable? is based on one or
the other (i'm guessing nil)
and this means that fetchable? is not platform independant.For someone who codes on Gentoo(mysql 4.x) and builds his gems on OS X
(mysql 5) and runs his code on Win2k pro(SQL Server via ODBC), this
gets annoying quick.> can't use Row while offline...)
What do you mean by this?
I means using DBI::Rows after connection of db is closed,change some
value ,then put them back to the database,
If you're looking for a sort of hash / array type access to datarows,
you could use Ruport to execute your query and then serialize to YAML
and bring back the DataRows easily.I imagine this could be done with DBI::Rows too though, cant it?
Yes, I already used my own keyable-array class to store these data... I
just thought making DBI::Row have these function is valuable.
On 12/16/05, cap <capitain@gmail.com> wrote:
I found a patch can fix the NULL(alos include "0000-00-00 00:00:00")
TIME column errorRuby DBI / Patches / #5 Fix to bug with zero datetime fields in MySQL
Neat.
Gregory Brown wrote:
> I imagine this could be done with DBI::Rows too though, cant it?Yes, I already used my own keyable-array class to store these data... I
just thought making DBI::Row have these function is valuable.
Yeah, it would definitely help. I think pretty much everyone is
rolling their own, and that kind of fragmentation isn't good.
On 12/16/05, cap <capitain@gmail.com> wrote:
There is a variety of broken time/date handling that I have completed or
partial patches for that will be applied. The NULL timestamp issue is one of
them.
Kirk Haines
On Friday 16 December 2005 9:12 am, cap wrote:
I found a patch can fix the NULL(alos include "0000-00-00 00:00:00")
TIME column errorhttp://sourceforge.net/tracker/index.php?func=detail&aid=902490&group_id=43
737&atid=437253