Michael Neumann wrote:
On Fri, May 28, 2004 at 08:28:53AM +0000, Andreas Schwarz wrote:
Michael Neumann wrote:
On Mon, May 24, 2004 at 02:26:25PM +0000, Andreas Schwarz wrote:
Michael Neumann wrote:
On Mon, May 24, 2004 at 01:42:10AM +0200, Andreas Schwarz wrote:
Automatic binary encoding for BLOB or BINARY datatypes would be great.
Decoding is no problem, but should the automatic encoding happen if a
string contains "\0", for objects of a special class, or in some other
case?
No, only for BINARY and BLOB types. Strings should raise an error.
This would require parsing the SQL to detect if the data will be
inserted into a VARCHAR or BLOB column. I would want to avoid SQL
parsing by all means, it only creates problems.
Yes, but I guess this is the way some bindings in other languages are
working.
I would find that highly astonishing.
And aren't we looking at the SQL to determine whether it's an
integer etc. or not?
No. Appearently it was done like this in the old SQLite DBD (I just
removed the type detection code and did not really try to understand
it), but as the type information is returned by sqlite_step this is
completely unnecessary.
This would work for decoding values returned by a SELECT statement.
Detecting the type of the returned columns is no problem.
To encoding values, the user should wrap the string inside a DBI::Binary.
That was all that I wanted to know :)
There are some databases that start a transaction by default after a
commit/rollback, so there's no need for an explicit start_transaction,
others do not.
This decision could be made in Database#start_transaction.
You can get into trouble when you manually issue a COMMIT
or ROLLBACK command via DBI, due to internally bookkeeping of whether
we're in a transaction or not. This really sucks, but I've no idea how
to make it better.
Why is this bookkeeping necessary? Database#transaction could just call
start_transaction at the beginning and commit or rollback when it's
done; or am I wrong here?
You might have a look at the Postgres DBD (Pg.rb). Postgres for example
starts in unchained mode (AutoCommit on). #commit and #rollback do nothing
(and I really mean that nothing is sent to the database) when called
outside a transaction (we need to know whether we are in a transaction
or not).
I understand, so this is only an issue with AutoCommit?
My proposal would be to make AutoCommit optional for DBDs and let them
much more freedom in how they do their work.
Yes. I would also mark AutoCommit as deprecated in the specification
because I really see no use in this feature and it only seems to be
causing problems.
This is really an issue we should handle in the near future (this would
also make Ruby/DBI easier RubyGem-able). But I've strong aversions to
modify the directory structure and move files inside the CVS
repositoy, that's simply too ugly (loosing all history).
I hope Rubyforge will have Subversion soon, it wouldn't be a problem there.
Doing this step, I'd suggest that we could then move from 0.0.23 to 0.5
for the DBI (or 0.1 if you like :-).
0.1 sounds good :)
Well, back to your question. But AutoCommit is working, right? So, why
should we remove it?
The autocommit (de)activation code is duplicated, so there would be some
cleaning work necessary.
Andreas
|
