Final development release of DBD::ODBC 1.42 series
I've just uploaded DBD::ODBC 1.42_5 to CPAN. I'm hoping this is going to be the
final development release of the 1.42 series. If you rely on DBD::ODBC then
please test it. The changes since the last full release are below. In
particular note that there is a small change in behaviour.
=head2 Changes in DBD::ODBC 1.42_5 January 25 2013
[BUG FIXES]
Not all modules used in test code were specified in build_requires.
=head2 Changes in DBD::ODBC 1.42_4 January 21 2013
[ENHANCEMENTS]
odbc_trace and odbc_trace_file are now full connection attributes
so you can set them any time you like, not just in connect.
=head2 Changes in DBD::ODBC 1.42_3 January 17 2013
[ENHANCEMENTS]
Added odbc_trace_file and odbc_trace attributes to the connect
method so you can now enable ODBC API tracing from the connect
method instead of having to use the ODBC Driver Manager. These also
only enable ODBC API tracing in the application which made the call
unlike the ODBC Driver Manager settings.
=head2 Changes in DBD::ODBC 1.42_2 December 17 2012
[MISCELLANEOUS]
Changed any use of if SvUPGRADE to remove the if test as per email
from Dave Mitchell and posting at
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2012-12/msg00424.html.
=head2 Changes in DBD::ODBC 1.42_1 December 12 2012
[BUG FIXES]
DBD::ODBC's ExecDirect method did not return an SQLLEN so if you
managed to affect a massive number of rows it would be cast to an
int and hence precision lost.
[CHANGE IN BEHAVIOUR]
When you called DBI's execute method and odbc_exec_direct was not
set (the default) if you managed to affect more rows than would fit
into an int you would get the incorrect count (NOTE on 32 bit
platforms ODBC's SQLRowCount can only return a 32bit value
anyway). You would get whatever casting an SQLLEN to an int would
give you. The fix for this needs a change to DBI (see RT 81911) and
the change would probably impact every DBD so until then DBD::ODBC
will a) warn if an overflow occurs and Warn is set on the handle b)
return INT_MAX and c) provide a new statement method odbc_rows which
you can use to get the correct value.
[ENHANCEMENTS]
New odbc_rows statement method (see above).
[MISCELLANEOUS]
New rt_81911.t test case.
=head2 Changes in DBD::ODBC 1.42_0 November 28 2012
[BUG FIXES]
MS Access requires a longchar column to be bound using SQL_LONGVARCHAR.
However, MS Access does not support SQLDescribeParam and we default to
SQL_VARCHAR in this case. The point at which we switch to SQL_LONGVARCHAR
was defaulted to 4000 (for MS SQL Server). We now default to SQL_LONGVARCHAR
for MS Access when data is 255. This means you can remove those
{TYPE = SQL_LONGVARCHAR} from your bind_param calls for longchar columns
in MS Access.
I seem to have introduced a bug in the test suite for MS Access.
The last test in the 09bind test binds dates as varchars (by
default) and this cannot work in MS Access (it needs to be a
timestamp). This test was skipped in the past and the skip got
removed.
[MISCELLANEOUS]
Steffen Goeldner reported some issues with execute_array in
DBD::Oracle where if ArrayTupleStatus was not specified and an error
occurred DBD::Oracle did not do the right thing. As I used
DBD::Oracle as a base when I wrote execute_for_fetch in DBD::ODBC I
added tests to the test suite to ensure these issues did not exist
in DBD::ODBC.
Minor change to sql_type_cast.t test which attempts to insert an
integer into a varchar. No databases so far have complained about
this until we ran the test against Derby. Changed to use '100'.
RT 80446 - fix spelling mistake - thanks to Xavier Guimar.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
Cached statements hold strong references to bind values
Re https://rt.cpan.org/Public/Bug/Display.html?id=82942 The key question: is this a bug or a feature? I can argue it either way. I'm open to suggestions. Tim.
Re: Cached statements hold strong references to bind values
On Fri, Jan 25, 2013 at 10:17:11AM +, Tim Bunce wrote: Re https://rt.cpan.org/Public/Bug/Display.html?id=82942 The key question: is this a bug or a feature? Can you walk me through your thought process on what makes this a feature? Not trying to be difficult, I am just having trouble seeing the use-case ;) Cheers
Re: Shared DBI driver test suite
On Wed, Jan 23, 2013 at 10:07:01AM +0100, Jens Rehsack wrote: On 22.01.13 23:42, Tim Bunce wrote: On Tue, Jan 15, 2013 at 09:47:02AM +0100, Jens Rehsack wrote: 1) having a lot of DBD::CSV tests (DBI related like ChopBlanks) moved or copied and maintained in DBI Think bigger. I do :P SQL::Statement can't rely on DBI, because it would create a circular dependency This on its own is not that much of a problem. DateTime can not really function without DateTime::TimeZone, and as such (DateTime) skips about 90% of its tests on a fresh install, with DateTime::TimeZone installing afterwards. Just pointing out that there is precedent, not that I particularly like it.
Re: Shared DBI driver test suite
On 25.01.13 11:45, Peter Rabbitson wrote: On Wed, Jan 23, 2013 at 10:07:01AM +0100, Jens Rehsack wrote: On 22.01.13 23:42, Tim Bunce wrote: On Tue, Jan 15, 2013 at 09:47:02AM +0100, Jens Rehsack wrote: 1) having a lot of DBD::CSV tests (DBI related like ChopBlanks) moved or copied and maintained in DBI Think bigger. I do :P SQL::Statement can't rely on DBI, because it would create a circular dependency This on its own is not that much of a problem. DateTime can not really function without DateTime::TimeZone, and as such (DateTime) skips about 90% of its tests on a fresh install, with DateTime::TimeZone installing afterwards. Just pointing out that there is precedent, not that I particularly like it. All problems we fixed in 1.402 are found by cpantesters - and it were serious issues. My favourite would be a +---+ | DBI(::DBD)?::Test | +---+ /\ | | | +---+--+ | | ++ +-+ | SQL::Statement | | DBI | ++ +-+ And it seems to be okay for all DBI developers right now ... Jens
Re: Cached statements hold strong references to bind values
On Fri, Jan 25, 2013 at 09:40:07PM +1100, Peter Rabbitson wrote:
On Fri, Jan 25, 2013 at 10:17:11AM +, Tim Bunce wrote:
Re https://rt.cpan.org/Public/Bug/Display.html?id=82942
The key question: is this a bug or a feature?
Can you walk me through your thought process on what makes this a feature?
Not trying to be difficult, I am just having trouble seeing the use-case ;)
A cache statement is cached because the user asked for it to be cached.
$sth = $dbh-prepare_cached($sql);
I think it's reasonable to assume that binding a reference value to a
placeholder of a cached statement handle will cause the ref count of the
value to increase.
$sth-bind_param_inout(1, \@foo);
The particular case in the ticket uses an reference to an object with
stringfy magic:
$sth-bind_param(1, $object_that_stringifies);
which is an extra wrinkle.
All this seems like reasonable and natural behaviour to me.
However, it also seems potentially inconvenient, as you've found.
So, the question then is what options do we have for fixing it?
The most obvious thing to do would be to weaken the refs in
values %{ $sth-{ParamValues} }. That could be done in the
application, so a DBI change isn't strictly needed.
If it's agreed that the DBI should weaken the refs then
we'd need to discuss when. As soon as they're bound?
I can imagine cases where values are bound in a lexical scope
that's exited before the $sth-execute() call, so that's not safe.
After the execute()? No, execute might be called again.
After finish()? Maybe. The docs for finish is already say Calling finish ...
may also make some statement handle attributes (such as NAME and TYPE)
unavailable if they have not already been accessed (and thus cached).
It seems reasonable to extend that to say that any references in
ParamValues will be weaked.
Bound values are meant to persist across finish(), so there are still risks.
I'm not keen on adding another attribute just to control this edge case.
Tim.
