Hello,
I'd like to report a couple of bugs in the sqlite DBD/DBI. Well, the first
is definitely a bug, but you might argue the second with me :-)
The first issue: DBI::DatabaseHandle#do should return a row processed count,
but it returns nil. You can workaround it by using #execute instead, which
gives you a StatementHandle you can call #rows on.
The second problem is to do with transactions and locking. When you open a
sqlite database, and you have 'AutoCommit'=>false (the default and most
useful setting), the DBD sends
begin transaction
immediately to the database. Unfortunately, this causes sqlite to obtain an
exclusive write-lock on the file, and any concurrent connection by another
process (or even a second DBI handle in the first process) is completely
blocked out. An attempt to open a second connection causes an exception to
be raised.
I think it would be better if the 'begin transaction' were deferred until
later, for example when doing
db.transaction do # begin transaction
..
.. stuff
..
end # commit or rollback
However that I think needs some changes to the underlying DBI->DBD API,
which has methods for 'commit' and 'rollback' but not 'begin'.
I'd be interested to hear what people think, but I thought the whole purpose
of DBI/DBD was to isolate me from the differences between databases; for my
application I've now had to write a wrapper object so that I can make it
work both with dbi:sqlite and dbi:mysql, because of this issue.
The main reason for including sqlite is as part of the unit testing suite,
rather than intended for major rollout, but I still think it would be nice
to maintain support for as many backends as possible.
Regards,
Brian Candler.
bug_sqlite1.rb
Description: Text document
bug_sqlite2.rb
Description: Text document
_______________________________________________
Ruby-dbi-devel mailing list
Ruby-dbi-devel@xxxxxxxxxxxxx
http://rubyforge.org/mailman/listinfo/ruby-dbi-devel
|
