SQL-Statement
On request from Jens: $ git clone github.com:perl5-dbi/dbi.git SQL-Statement is now a full copy of https://github.com/rehsack/SQL-Statement The new location does NOT know about the old, as it can now be used as the new decisive source: that is up to Jens. Enjoy! -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
[perl5-dbi/dbi] 363d50: Suggested fix for unknown skip count in t/48
Branch: refs/heads/tux Home: https://github.com/perl5-dbi/dbi Commit: 363d500381258b777b225e962a8941ac55ab2188 https://github.com/perl5-dbi/dbi/commit/363d500381258b777b225e962a8941ac55ab2188 Author: H.Merijn Brand - Tux Date: 2013-04-05 (Fri, 05 Apr 2013) Changed paths: M t/48dbi_dbd_sqlengine.t Log Message: --- Suggested fix for unknown skip count in t/48 As we are using done_testing, we do not need a skip block at all You /might/ want to add a warning in the else
Re: Moving DBI to github - and the perl5-dbi organization
On Fri, 5 Apr 2013 00:20:52 +0100, Tim Bunce wrote: > The new git repo is up at https://github.com/perl5-dbi/dbi There are no branches in this repo. DBI-git > git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master vs DBI-svn > git branch -a DBI * master sqlengine remotes/git-svn remotes/sqlengine did you leave out the sqlengine branch on purpose? There are no tags (yet) in the new repo. Shall I add them? DBI-git > git tag -l (no output) DBI-svn > git tag -l 1.41 1.42 1.43 1.44 1.45 1.46 1.47 1.48 1.49 1.50 1.51 1.52 1.53 1.54 1.55 1.56 1.57 1.58 1.59 1.601 1.602 1.603 1.604 1.605 1.606 1.607 1.609 1.611 1.611_90 1.611_91 1.611_92 1.611_93 1.611_94 1.612 1.613 1.613_70 1.613_71 1.613_90 1.613_91 1.613_92 1.613_93 1.614 1.614_90 1.615 1.616 1.617 1.618 1.619 1.620 1.621 1.622 1.623 1.624 1.625 > Please consider the svn repo closed! > > I've enabled irc notifications to #dbi and email notifications > to dbi-dev@perl.org. > > I've enabled the wiki but left issues disabled for now. > > That's all for now. I'll sort out admin access and suchlike later. > Meanwhile feel free to clone, fork, and submit pull requests etc. > > Tim. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Moving to git - (Fwd) svn.perl.org shutdown
On Sun, 31 Mar 2013 08:28:51 +0100, Tim Bunce wrote: > I had been thinking I'd make the move to git, and github, during the > summer. Looks like it'll be sooner than that. I already have a complete git clone from the svn repo, including the release tags. Wil you clone yourself, or do you want my repo clone? > Any driver authors using svn.perl.org have presumably also got an email. > > Tim. > > - Forwarded message from Robert - > > Date: Sat, 30 Mar 2013 13:27:48 -0700 > From: Robert > Cc: Ask Bjoern-Hansen , Robert Spier > Subject: svn.perl.org shutdown > >Dear very short list of module authors who still use [1]svn.perl.org, >Due to declining usage and increased maintenance costs, we've decided to > shut down the SVN hosting on >[2]svn.perl.org. >We are currently planning to shut the service down in a month, on April > 27th, 2013. For various reasons, >we'd love to do so sooner, so it would be appreciated if you could migrate > quickly. >[3]Google Project Hosting and [4]GitHub are popular hosting options, but > you can use anything you want. >After you have migrated, please commit a note to your repository updating > the README or adding a MOVED >file that says where you've moved to. You do not need to delete the old > files unless you want to. >You can find a filtered svndump file at > [5]http://svn.perl.org/modules-dumps/ that contains only your >project for easier migration using svnsync or svn2git. >Please email [6]s...@perl.org if you have any questions or need help >Thanks! >-R > > References > >Visible links >1. http://svn.perl.org/ >2. http://svn.perl.org/ >3. http://code.google.com/p/ >4. http://www.github.com/ >5. http://svn.perl.org/modules-dumps/ >6. mailto:s...@perl.org > > - End forwarded message - -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: 1.524
On Mon, 25 Mar 2013 17:24:41 +, Tim Bunce wrote: > On Mon, Mar 25, 2013 at 04:54:42PM +, Martin J. Evans wrote: > > > > The test only applies if a) you have JSON::XS installed and b) you > > want to test DiscardString with JSON::XS (see above for reason why). > > By all means take the test out if you like, I only included it because > > it was my specific usage case which led to DiscardString and > > StrictlyTyped. > > Which is important and worth keeping, I think. I never disagreed with that > Failing due to a locally patched module is a local problem. But easily caught. I pushed the change. IMHO no need for a ChangeLog entry though. > Tim. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: 1.524
On Mon, 25 Mar 2013 14:48:07 +, "Martin J. Evans" wrote: > On 25/03/13 14:28, H.Merijn Brand wrote: > > On Mon, 25 Mar 2013 13:55:26 +, "Martin J. Evans" > > wrote: > > > >> On 25/03/13 11:51, Tim Bunce wrote: > >>> On Sun, Mar 24, 2013 at 09:08:33PM +0100, H.Merijn Brand wrote: > >>>> PASSes on all my boxes but one > >>>> > >>>> The failing box has JSON::XS installed (temporary to check Schmorp's > >>>> claims, for which I so far found no proof) > >> > >> What are those claims - is he claiming Perl has broken JSON::XS by any > >> chance? > > > > If you have (a lot of) time, read > > https://rt.cpan.org/Public/Bug/Display.html?id=42462 > > and > > https://rt.perl.org/rt3//Ticket/Display.html?id=117239 > > I don't have /that/ much time. :) > > The thing(s) I wanted to check are if the module is now 100% C89 safe > > (it is not) and if his claim that > > > > #if defined(__BORLANDC__) || defined(_MSC_VER) || defined(__STDC__) > > HE **hes = Perl_malloc (count * sizeof (HE *)); > > #else > > HE *hes [count]; > > #endif > > > > will slowdown the code significantly on systems that do support C99 > > nc I will try to find out on a real-world example > >>>> The formatted output - I might have an output patch applied to make the > >>>> output style meet our requirements - causes this mismatch. > >>> > >>> Am I right in thinking that the goal of the JSON::XS test is to check > >>> whether JSON::XS puts quotes around values? > >> > >> It was a check to make sure that JSON::XS saw numbers in Perl as numbers > >> and not strings and so does not put quotes around them - the > >> DiscardString bit. > >> > >>> I'd suggest adding s/\s+//g, plus a comment, to make that explicit. > >> > >> Why are there extra spaces in the result - there are not when I run it. > > > > Because it is installed with a patch on this box to conform to the style > > we require. Obviously this is an old and incomplete patch, that I never > > bothered to fix as this module is prohibited in our company. > > > > What I was pointing at, is that I would most like not be the only one > > in the world to patch modules to behave as required, as not all modules > > have decent ways for configurating needs and - as this is open source - > > patching is allowed :) > > People who change their modules to work differently from the ones on CPAN > surely need to accept that their change might break other things. I do > The test in question can work around it this time (because you've told us > how you changed it) but what about when you make another change to > modify the JSON::XS module. I already have sent patches to other CPAN authors where tests failed on *formatted* output because the module used changed its unpatched defaults. What I learned is that one should write tests that are not depending on the layout *formatted* output from third parties give. JSON::XS is just an example here, but the same happens with HTML and xml, where a lot of whitespace is not important for the final output. What I am aiming at here is that you test what you want to test: quotation. The use of quotation is documented. As a counterexample: I had to file patches for perltidy, as they did not take into consideration that someone might test perltidy with a ~/.perltidyrc already present. Even the smallest change would break the complete test suite. This can happen to *any* module that has external influences on the produced output. > It seems like the test fails on this box because you changed JSON::XS > and you want the DBI test suite to keep up with you. yes and no: I want tests to test what they want to test, not depend on side effects. That is why I just test on error NUMBERS and not on the error string when the string can be locale depending. > Having said that white space is allowed in JSON but you might find > yourself on a slippery slope as white space in quotes needs to be > maintained. Why not use JSON::PP? It is CORE and the test has *tiny* structures to test, so speed is irrelevant. > > If, as both Tim and me already assumed, JSON::XS is just used to check > > quoting, s/\s+//g is a valid and safe fix. > > > >> Something else seems horribly broken here - admittedly I've not been > >> keeping up. > > > > broken? IMHO JSON::XS is very very broken when ran on anything other > > than GNU gcc supported platforms. > > Merijn, I know your feelings on Marc Lehmann
Re: 1.524
On Mon, 25 Mar 2013 13:55:26 +, "Martin J. Evans"
wrote:
> On 25/03/13 11:51, Tim Bunce wrote:
> > On Sun, Mar 24, 2013 at 09:08:33PM +0100, H.Merijn Brand wrote:
> >> PASSes on all my boxes but one
> >>
> >> The failing box has JSON::XS installed (temporary to check Schmorp's
> >> claims, for which I so far found no proof)
>
> What are those claims - is he claiming Perl has broken JSON::XS by any chance?
If you have (a lot of) time, read
https://rt.cpan.org/Public/Bug/Display.html?id=42462
and
https://rt.perl.org/rt3//Ticket/Display.html?id=117239
The thing(s) I wanted to check are if the module is now 100% C89 safe
(it is not) and if his claim that
#if defined(__BORLANDC__) || defined(_MSC_VER) || defined(__STDC__)
HE **hes = Perl_malloc (count * sizeof (HE *));
#else
HE *hes [count];
#endif
will slowdown the code significantly on systems that do support C99
> >> The formatted output - I might have an output patch applied to make the
> >> output style meet our requirements - causes this mismatch.
> >
> > Am I right in thinking that the goal of the JSON::XS test is to check
> > whether JSON::XS puts quotes around values?
>
> It was a check to make sure that JSON::XS saw numbers in Perl as numbers
> and not strings and so does not put quotes around them - the
> DiscardString bit.
>
> > I'd suggest adding s/\s+//g, plus a comment, to make that explicit.
>
> Why are there extra spaces in the result - there are not when I run it.
Because it is installed with a patch on this box to conform to the style
we require. Obviously this is an old and incomplete patch, that I never
bothered to fix as this module is prohibited in our company.
What I was pointing at, is that I would most like not be the only one
in the world to patch modules to behave as required, as not all modules
have decent ways for configurating needs and - as this is open source -
patching is allowed :)
If, as both Tim and me already assumed, JSON::XS is just used to check
quoting, s/\s+//g is a valid and safe fix.
> Something else seems horribly broken here - admittedly I've not been
> keeping up.
broken? IMHO JSON::XS is very very broken when ran on anything other
than GNU gcc supported platforms.
> > Tim.
>
> Martin
>
> >> I don't mind when the verdict is: we cannot expect people to alter
> >> whitespacing in module output, but having cpanprefs not only makes that
> >> easy, but make installing a lot of modules suddenly become more logical
> >> as I can "fix" the decisions the author made that I do not agree with.
> >>
> >> Personally I don't think prettied output checks in tests should ever
> >> test on whitespace (including newlines) unless the output is completely
> >> generated by the module itself or guaranteed by the module or its
> >> documentation to not add or remove whitespace.
> >>
> >> The change to prevent this specific case is maybe somthing like
> >> --8<---
> >> --- a/t/90sql_type_cast.t 2013-03-24 21:00:02.167352360 +0100
> >> +++ b/t/90sql_type_cast.t 2013-03-24 21:05:07.251376420 +0100
> >> @@ -116,7 +116,7 @@ foreach my $test(@tests) {
> >> skip 'DiscardString not supported in PurePerl', 1
> >> if $pp && ($test->[3] & DBIstcf_DISCARD_STRING);
> >>
> >> -my $json = JSON::XS->new->encode([$val]);
> >> +(my $json = JSON::XS->new->encode([$val])) =~ s/\s+]$/]/;;
> >> #diag(neat($val), ",", $json);
> >> is($json, $test->[5], "json $test->[0]");
> >> };
> >> -->8---
> >>
> >> but it doesn't catch changes that generate extra spaces output as
> >> like " [ 99 ] "
> >>
> >> For me, the tests will pass again next week, as JSON::XS will be banned
> >> to trash again
> >>
> >> t/87gofer_cache.t ... ok
> >> t/90sql_type_cast.t . 1/45
> >> # Failed test 'json undef'
> >> # at t/90sql_type_cast.t line 121.
> >> # got: '[null ]'
> >> # expected: '[null]'
> >>
> >> # Failed test 'json invalid sql type'
> >> # at t/90sql_type_cast.t line 121.
> >> # got: '["99" ]'
> >> # expected: '["99"]'
> >>
> >> # Failed test 'json non numeric cast to int'
> >> # at t/90sql_type_cast.t line 121.
> >
Re: 1.524
On Mon, 25 Mar 2013 11:51:09 +, Tim Bunce
wrote:
> On Sun, Mar 24, 2013 at 09:08:33PM +0100, H.Merijn Brand wrote:
> > PASSes on all my boxes but one
> >
> > The failing box has JSON::XS installed (temporary to check Schmorp's
> > claims, for which I so far found no proof)
> >
> > The formatted output - I might have an output patch applied to make the
> > output style meet our requirements - causes this mismatch.
>
> Am I right in thinking that the goal of the JSON::XS test is to check
> whether JSON::XS puts quotes around values?
Note that up to now I never had JSON::XS installed anywhere, so I never
ran that test.
This file is completely mje's work (entered 2009-11-27 18:03:49)
git-svn-id: http://svn.perl.org/modules/dbi/trunk@13615
50811bd7-b8ce-0310-adc1-d9db26280581
Commit messages since
Tests for DBI::sql_type_cast - not necessarily finished but wanted to let
Tim see them.
Fix test count and tidy output for a full make test - disable warnings when
we expect them, remove diag calls
Needs SQL types and DBIstcf_XXX
Fix tests for conversions to IV on machines where IVs are 8 bytes
was testing longsize and it should have been ivsize
Added DBIstcf_STRICT and DBIstcf_DISCARD_STRING to DBI::PurePerl.
Added rough draft of sql_type_cast to DBI::PurePerl.
Fixed typo in Changes.
Removed DBI:: prefixes from t/90sql_type_cast.t
(Some tests still fail)
Some tests cannot be performed with PurePerl e.g., DiscardString (skipped)
and number overflows do not work the same (don't overflow).
Omit some tests on Perl < 5.10.1 due to a change in sv_2nv.
Fixed "Argument "aa" isn't numeric in addition" warnings from
t/zvp_90sql_type_cast.t
Only warn in PurePerl sql_type_cast if warnings are enabled.
> I'd suggest adding s/\s+//g, plus a comment, to make that explicit.
I think I agree, but I'd like to hear Martin's voice
> Tim.
>
> > I don't mind when the verdict is: we cannot expect people to alter
> > whitespacing in module output, but having cpanprefs not only makes that
> > easy, but make installing a lot of modules suddenly become more logical
> > as I can "fix" the decisions the author made that I do not agree with.
> >
> > Personally I don't think prettied output checks in tests should ever
> > test on whitespace (including newlines) unless the output is completely
> > generated by the module itself or guaranteed by the module or its
> > documentation to not add or remove whitespace.
> >
> > The change to prevent this specific case is maybe somthing like
> > --8<---
> > --- a/t/90sql_type_cast.t 2013-03-24 21:00:02.167352360 +0100
> > +++ b/t/90sql_type_cast.t 2013-03-24 21:05:07.251376420 +0100
> > @@ -116,7 +116,7 @@ foreach my $test(@tests) {
> > skip 'DiscardString not supported in PurePerl', 1
> > if $pp && ($test->[3] & DBIstcf_DISCARD_STRING);
> >
> > -my $json = JSON::XS->new->encode([$val]);
> > +(my $json = JSON::XS->new->encode([$val])) =~ s/\s+]$/]/;;
> > #diag(neat($val), ",", $json);
> > is($json, $test->[5], "json $test->[0]");
> > };
> > -->8---
> >
> > but it doesn't catch changes that generate extra spaces output as
> > like " [ 99 ] "
> >
> > For me, the tests will pass again next week, as JSON::XS will be banned
> > to trash again
> >
> > t/87gofer_cache.t ... ok
> > t/90sql_type_cast.t . 1/45
> > # Failed test 'json undef'
> > # at t/90sql_type_cast.t line 121.
> > # got: '[null ]'
> > # expected: '[null]'
> >
> > # Failed test 'json invalid sql type'
> > # at t/90sql_type_cast.t line 121.
> > # got: '["99" ]'
> > # expected: '["99"]'
> >
> > # Failed test 'json non numeric cast to int'
> > # at t/90sql_type_cast.t line 121.
> > # got: '["aa" ]'
> > # expected: '["aa"]'
> >
> > # Failed test 'json non numeric cast to int (strict)'
> > # at t/90sql_type_cast.t line 121.
> > # got: '["aa" ]'
> > # expected: '["aa"]'
> >
> > # Failed test 'json small int cast to int'
> > # at t/90sql_type_cast.t line 121.
> > # got: '["99" ]'
> > # expected: '["99"]'
> >
> > # Failed test 'json 2 byte max signed int cast to int'
> > # at t/90sql_type_cast.t line 121.
> > # got: '["32767" ]'
> > # expected: '["32767"]'
> >
> > # Failed test 'json 2 byte max unsigned int cast to int'
> > # at t/90sql_type_cast.t line 121.
> > # got: '["65535" ]'
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
1.524
PASSes on all my boxes but one
The failing box has JSON::XS installed (temporary to check Schmorp's
claims, for which I so far found no proof)
The formatted output - I might have an output patch applied to make the
output style meet our requirements - causes this mismatch.
I don't mind when the verdict is: we cannot expect people to alter
whitespacing in module output, but having cpanprefs not only makes that
easy, but make installing a lot of modules suddenly become more logical
as I can "fix" the decisions the author made that I do not agree with.
Personally I don't think prettied output checks in tests should ever
test on whitespace (including newlines) unless the output is completely
generated by the module itself or guaranteed by the module or its
documentation to not add or remove whitespace.
The change to prevent this specific case is maybe somthing like
--8<---
--- a/t/90sql_type_cast.t 2013-03-24 21:00:02.167352360 +0100
+++ b/t/90sql_type_cast.t 2013-03-24 21:05:07.251376420 +0100
@@ -116,7 +116,7 @@ foreach my $test(@tests) {
skip 'DiscardString not supported in PurePerl', 1
if $pp && ($test->[3] & DBIstcf_DISCARD_STRING);
-my $json = JSON::XS->new->encode([$val]);
+(my $json = JSON::XS->new->encode([$val])) =~ s/\s+]$/]/;;
#diag(neat($val), ",", $json);
is($json, $test->[5], "json $test->[0]");
};
-->8---
but it doesn't catch changes that generate extra spaces output as
like " [ 99 ] "
For me, the tests will pass again next week, as JSON::XS will be banned
to trash again
t/87gofer_cache.t ... ok
t/90sql_type_cast.t . 1/45
# Failed test 'json undef'
# at t/90sql_type_cast.t line 121.
# got: '[null ]'
# expected: '[null]'
# Failed test 'json invalid sql type'
# at t/90sql_type_cast.t line 121.
# got: '["99" ]'
# expected: '["99"]'
# Failed test 'json non numeric cast to int'
# at t/90sql_type_cast.t line 121.
# got: '["aa" ]'
# expected: '["aa"]'
# Failed test 'json non numeric cast to int (strict)'
# at t/90sql_type_cast.t line 121.
# got: '["aa" ]'
# expected: '["aa"]'
# Failed test 'json small int cast to int'
# at t/90sql_type_cast.t line 121.
# got: '["99" ]'
# expected: '["99"]'
# Failed test 'json 2 byte max signed int cast to int'
# at t/90sql_type_cast.t line 121.
# got: '["32767" ]'
# expected: '["32767"]'
# Failed test 'json 2 byte max unsigned int cast to int'
# at t/90sql_type_cast.t line 121.
# got: '["65535" ]'
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
DBI-1.623, DBD::Pg-2.19.3, bind_param ()
Before I file an RT ticket, I want to verify that I didn't miss the obvious …
When I use bind_param on a char (4) field in DBD::Pg, it only loads the
first character:
--8<---
use 5.016;
use warnings;
use DBI;
use Data::Peek;
my $dbh = DBI->connect ("dbi:Pg:", undef, undef, {
PrintError => 1,
RaiseError => 1,
AutoCommit => 1,
ShowErrorStatement => 1,
}) or die "Connection failed";
my $tt = "testbind";
$dbh->do ("drop table if exists $tt");
$dbh->do ("create table $tt (c_test int4, test char (4))");
my $sts = $dbh->prepare ("select * from $tt");
$sts->execute;
my @stt = @{$sts->{TYPE}};
DDumper {
type => $sts->{TYPE},
tpnm => [ map { $dbh->type_info ($_)->{TYPE_NAME} } @{$sts->{TYPE}} ],
name => $sts->{NAME_lc},
size => $sts->{PRECISION},
};
my $sti = $dbh->prepare ("insert into $tt values (?, ?)");
$sti->bind_param ($_ + 1, undef, $stt[$_]) for 0 .. $#stt;
$sti->execute (0, "0301");
$sts->execute;
while (my $row = $sts->fetch) {
DDumper $row;
}
$dbh->do ("drop table $tt");
-->8---
=>
{ name => [
'c_test',
'test'
],
size => [
4,
8
],
tpnm => [
'int4',
'bpchar'
],
type => [
4,
1
]
}
[ 0,
'0 '
]
The field attributes for c_test:
{ LINK => undef,
NAME => 'c_test',
NAME_lc => 'c_test',
NAME_uc => 'C_TEST',
NULLABLE => 1,
PRECISION=> 4,
SCALE=> undef,
TYPE => 4,
TYPE_NAME=> 'int4',
dbd_type => 'int4',
pg_async => undef,
pg_bound => undef,
pg_cmd_status=> undef,
pg_current_row => undef,
pg_direct=> undef,
pg_numbound => undef,
pg_oid_status=> undef,
pg_placeholder_dollaronly => undef,
pg_prepare_name => undef,
pg_prepare_now => undef,
pg_segments => 'select * from testbind where 0 = 1',
pg_server_prepare => undef,
pg_size => 4,
pg_type => 'int4'
}
the field attributes for test:
{ LINK => undef,
NAME => 'test',
NAME_lc => 'test',
NAME_uc => 'TEST',
NULLABLE => 1,
PRECISION=> 4,
SCALE=> undef,
TYPE => 1,
TYPE_NAME=> 'bpchar',
dbd_type => 'bpchar',
pg_async => undef,
pg_bound => undef,
pg_cmd_status=> undef,
pg_current_row => undef,
pg_direct=> undef,
pg_numbound => undef,
pg_oid_status=> undef,
pg_placeholder_dollaronly => undef,
pg_prepare_name => undef,
pg_prepare_now => undef,
pg_segments => undef,
pg_server_prepare => undef,
pg_size => -1,
pg_type => 'bpchar'
}
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
QAH - QA Hackthon Lancaster, UK
Act soon or pass … On our target list for this QAH is: --8<--- Test::DBI or DBI::Test Write a test suite or test framework that is to be used by both DBI itself and all DBD's to test basic DBI functionality By: H.Merijn Brand (Tux) (hopefully together with ribasushi and Sno) -->8--- Perl QA attendees list closes soon QA Hackathon Close of Applications Applications Close: 3rd March, 2013: 23:59:59 GMT As many of you know, or by now you certainly should know, the Perl QA Hackathon will be held in Lancaster, United Kingdom, from 12th-14th April 2013. On Sunday, 3rd March, we will be closing the date where you can apply to join us at the event and taking the current list of attendees as our master list to attempt to sponsor/fund. If you wish to join us please make sure you head to the wiki and fill in the relevant attendees, expenses, catering and travel pages. This event is a great contribution to the lifeblood of the Perl language and the Perl community and as many events it relies on the generosity of sponsorship and donations to make it a success. Any contribution, large or small, makes a huge difference and we would like to encourage you to help us raise the necessary funds to host the event and to continue to hold it in the future. If you are unable to donate to the event you can still help by spreading the word and encouraging others to donate or sponsor. We would like to thank you in advance for your time and consideration. [perlqa]: http://2013.qa-hackathon.org/qa2013/ [wiki]: http://2013.qa-hackathon.org/qa2013/wiki [attend]: http://2013.qa-hackathon.org/qa2013/wiki?node=Attendees [targets]: http://2013.qa-hackathon.org/qa2013/wiki?node=Hackathon-Targets [expense]: http://2013.qa-hackathon.org/qa2013/wiki?node=Expenses [cater]: http://2013.qa-hackathon.org/qa2013/wiki?node=Catering [travel]: http://2013.qa-hackathon.org/qa2013/wiki?node=Travel [donate]: https://members.enlightenedperl.org/drupal/donate-perlqa?id=6 -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Defining type_info Was: DBIstcf_DISCARD_STRING and DBIstcf_STRICT
;
> ODBC added a new column just recently:
>
> perl -le 'use DBI; my $h = DBI->connect; my $x =h->type_info_all; use
> Data::Dumper; print Dumper($x)'
> $VAR1 = [
>{
> 'UNSIGNED_ATTRIBUTE' => 9,
> 'MAXIMUM_SCALE' => 14,
> 'INTERVAL_PRECISION' => 18,
> 'CREATE_PARAMS' => 5,
> 'NUM_PREC_RADIX' => 17,
> 'SEARCHABLE' => 8,
> 'USERTYPE' => 19, <- see here
> 'LOCAL_TYPE_NAME' => 12,
> 'AUTO_INCREMENT' => 11,
> 'MONEY' => 10,
> 'LITERAL_PREFIX' => 3,
> 'COLUMN_SIZE' => 2,
> 'MINIMUM_SCALE' => 13,
> 'TYPE_NAME' => 0,
> 'NULLABLE' => 6,
> 'DATA_TYPE' => 1,
> 'SQL_DATA_TYPE' => 15,
> 'CASE_SENSITIVE' => 7,
> 'LITERAL_SUFFIX' => 4,
> 'SQL_DATETIME_SUB' => 16
>},
DBD::Unify:
$ dbperl -MDP -lE'use DBI;DDumper($d->type_info_all->[0])'
{ AUTO_UNIQUE_VALUE => 11,
CASE_SENSITIVE => 7,
COLUMN_SIZE => 2,
CREATE_PARAMS=> 5,
DATA_TYPE=> 1,
FIXED_PREC_SCALE => 10,
INTERVAL_PRECISION => 18,
LITERAL_PREFIX => 3,
LITERAL_SUFFIX => 4,
LOCAL_TYPE_NAME => 12,
MAXIMUM_SCALE=> 14,
MINIMUM_SCALE=> 13,
NULLABLE => 6,
NUM_PREC_RADIX => 17,
SEARCHABLE => 8,
SQL_DATA_TYPE=> 15,
SQL_DATETIME_SUB => 16,
TYPE_NAME=> 0,
UNSIGNED_ATTRIBUTE => 9
}
DBD::Pg:
$ dbperl -MDP -lE'use DBI;DDumper($d->type_info_all->[0])'
{ AUTO_UNIQUE_VALUE => 11,
CASE_SENSITIVE => 7,
COLUMN_SIZE => 2,
CREATE_PARAMS=> 5,
DATA_TYPE=> 1,
FIXED_PREC_SCALE => 10,
INTERVAL_PRECISION => 18,
LITERAL_PREFIX => 3,
LITERAL_SUFFIX => 4,
LOCAL_TYPE_NAME => 12,
MAXIMUM_SCALE=> 14,
MINIMUM_SCALE=> 13,
NULLABLE => 6,
NUM_PREC_RADIX => 17,
SEARCHABLE => 8,
SQL_DATA_TYPE=> 15,
SQL_DATETIME_SUB => 16,
TYPE_NAME=> 0,
UNSIGNED_ATTRIBUTE => 9
}
DBD::Oracle:
$ dbperl -MDP -lE'use DBI;DDumper($d->type_info_all->[0])'
{ AUTO_UNIQUE_VALUE => 11,
CASE_SENSITIVE => 7,
COLUMN_SIZE => 2,
CREATE_PARAMS=> 5,
DATA_TYPE=> 1,
FIXED_PREC_SCALE => 10,
INTERVAL_PRECISION => 18,
LITERAL_PREFIX => 3,
LITERAL_SUFFIX => 4,
LOCAL_TYPE_NAME => 12,
MAXIMUM_SCALE=> 14,
MINIMUM_SCALE=> 13,
NULLABLE => 6,
NUM_PREC_RADIX => 17,
SEARCHABLE => 8,
SQL_DATA_TYPE=> 15,
SQL_DATETIME_SUB => 16,
TYPE_NAME=> 0,
UNSIGNED_ATTRIBUTE => 9
}
DBD::CSV:
$ dbperl -MDP -lE'use DBI;DDumper($d->type_info_all->[0])'
{ AUTO_INCREMENT => 11,
CASE_SENSITIVE => 7,
CREATE_PARAMS=> 5,
DATA_TYPE=> 1,
LITERAL_PREFIX => 3,
LITERAL_SUFFIX => 4,
LOCAL_TYPE_NAME => 12,
MAXIMUM_SCALE=> 14,
MINIMUM_SCALE=> 13,
MONEY=> 10,
NULLABLE => 6,
PRECISION=> 2,
SEARCHABLE => 8,
TYPE_NAME=> 0,
UNSIGNED_ATTRIBUTE => 9
}
> > I think at this point, a big question is: Does the DBI just want to
> > emulate ODBC's SQLSetTypeInfo function, or does it want to have
> > something that goes a bit further and possibly does it a bit better?
>
> I'm ok with someone defining better but I've never had a case where
> I needed something better. I have code that looks at most of the
> type_info_all fields and uses this data to work out how to create
> tables but it was really just a port of some old C code. Mostly, I'm
> not using any code which creates schemas now, just using existing ones.
>
> Martin
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
bind_param () - did something change?
I have a table with 5 BLOB's. BLOB's are easy in DBD::CSV and
DBD::Unify, but they need "some help" in Oracle.
I had a script that did load a table from a CSV file by first inserting
all the records without the blob's and then update each blob in turn
((DBD::Oracle would not allow me to have 5 BLOB's in one insert or
update).
Given that c_ll + m_nr are a primary key, I had to change
foreach my $blob (qw( w_tl w_xml0 w_xml1 w_xml2 w_xml3 attr )) {
print STDERR "Setting $blob in ll_verz_rel ...\n";
my $sth = $dbh->prepare ("update ll_verz_rel set $blob = ? where c_ll = ?
and m_nr = ?");
for (@llvr) {
$_->{$blob} or next;
$sth->bind_param (1, $_->{$blob}, { ora_type => ORA_BLOB });
$sth->bind_param (2, $_->{c_ll}, { ora_type => ORA_NUMBER });
$sth->bind_param (3, $_->{m_nr}, { ora_type => ORA_NUMBER });
$sth->execute ();
}
}
to
foreach my $blob (qw( w_tl w_xml0 w_xml1 w_xml2 w_xml3 attr )) {
print STDERR "Setting $blob\tin ll_verz_rel ... ";
my $sth = prepar ("update ll_verz_rel set $blob = ? where c_ll = ? and m_nr
= ?");
$sth->bind_param (1, undef, { ora_type => ORA_BLOB, ora_field => $blob
});
for (@llvr) {
$_->{$blob} or next;
$sth->execute ($_->{$blob}, $_->{c_ll}, $_->{m_nr});
}
}
to get it to insert the records. It FAILED to work without the
ora_field addition
Now in this case I don't really mind the change. It makes my code
easier, but if I bind to one parameter only, the bind should/could know
what to bind to, it shouldn't need the ora_field entry in the hashref.
In above case, there is one ONE blob in the statement at any time, so
there is no conflict at all, ever.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Shared DBI driver test suite
On Wed, 23 Jan 2013 10:07:01 +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 - but my far distance goal was a test
> base common for DBI, DBD::* and SQL::Statement - and maybe
> more ...
>
> But I want start somewhere and not finish anything because
> of the long way (I think about my goal to improve
> Proc::ProcessTable, which stalls because I don't find
> a near goal to reach soon and have not enough free time to
> do it all in one big task).
>
> > One of my biggest regrets about the implementation of the DBI is that I
> > didn't create a separate test suite that could be reused by driver authors.
> >
> > So each driver has only it's own set of tests that are really only
> > testing the authors interpretation of the barely-specified behavior.
> >
> > I'd *love* to see that error fixed so all drivers authors could make use
> > of, and contribute to, a common DBI driver test suite.
>
> You suggest a DBI::Test suite which is a separate module and is required
> by DBI? This completely different to previous statements
> where DBI should have no additional dependencies ...
>
> Let's discuss this as Merijn suggested at Perl QA hackathon.
But this is almost exactly what I had in mind when I started DBD::Unify
I somehow have never been able to express those thoughts in words :)
The "problem" is requiring DBI::Test (or whatever) from the DBD in
question, where DBI::Test only depends on DBI. DBI::Test could then do
the DBD-less tests to DBI (again) before being 'use DBI::Test;'d in
DBD's t/ set of files
use DBI::Test; # subclasses Test::More
setup ({ … }); # Things DBI::Test should know to connect, use temp
# tables, and more
dbd_dbi_ok (); # set of sub-tests - can I load DBI
dbd_drv_ok (); # set of sub-tests - can I load DBD
dbd_dbh_ok (); # set of sub-tests - can I connect/disconnect/cache
dbd_sth_ok (); # set of sub-tests - can I do standard things
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBI / S::S / DBD::CSV ... related hackathon
On Tue, 15 Jan 2013 20:18:44 +1100, Peter Rabbitson wrote: > On Tue, Jan 15, 2013 at 09:47:02AM +0100, Jens Rehsack wrote: > > So at first I would be great if all interested persons can > > tell if they would like to join - let's say until end of January > > (for a date in March/April 2013) with a limit how far they're > > willing to travel. > > Always happy to join, will travel considerably far if need be. As far as > the date goes - make sure not to clash with the QAH[1]. Also I am > personally unavailable the weekend of March 16/17. > > P.S. Jens, first saw your nrpm mail, then this one, ignore the noise ;) > > Cheers > > [1] http://shadow.cat/blog/mark-keating/2013/perl-qa/ 15-01-2013 19:14:28 #dbi <[Tux]> [Sno], Sno|, mje is http://2013.qa-hackathon.org/qa2013/ an alternative? I will be there anyway for Test::Smoke <[Tux]> and help to other related QA projects <[Tux]> unifying DBI/DBD tests for sure is QA related! The more I think about it, the more sense it makes -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: RDBMS comparison tool
On Sun, 30 Dec 2012 02:53:33 +, Lyle wrote: > Hi All, >Whilst working on another project it made sense to write a tool for > comparing the various RDBMSs. I'm talking about the database management > systems themselves, not databases within them. So far I've done parts > that use $dbh->type_info_all() to compare what types SQL Server, > Postgres, Oracle and MySQL have available and their details. Generating > reports like: > http://cosmicperl.com/rdbms/compare_types.html > http://cosmicperl.com/rdbms/compare_type_details.html Very useful indeed, but I'm afraid that it also depends on the version of the database(s). I've done several talks about the deficiencies of RDBMS's and basically, there is no perfect database: they all have their hatred areas *). Choose the one that best fits your current needs (even if that is a flat-file solution). What would you need (as perl-script output) to extend that info for DBD::Unify (which I still have access to) and DBD::CSV, DBD::SQLite *) http://tux.nl/Talks/DBDc/quo1.html http://tux.nl/Talks/DBDc/name.html http://tux.nl/Talks/DBDc/null.html > I'm not yet sure as to whether the mapping from the RDBMSs local sql > type to the ones the DBI recognises is done by the DBD driver, or > whether this is already predetermined by the RDBMS... > > Let me know if this isn't interesting to you all and I'll keep it off list. > > Lyle > -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::File / DBI::DBD::SqlEngine updates and doc review
On Fri, 21 Dec 2012 14:13:31 +0100, Jens Rehsack wrote: > Hi all, > > as I didn't catch anyone on IRC, I remember that many of you irc.perl.org/6667 #dbi Jens = [Sno] Merijn = Tux > had questions about Pure-Perl device drivers basing on DBD::File > (or DBI::DBD::SqlEngine) for several reasons. > > Currently we're finished most of development cycles for upcoming > DBI release and reworking the documentation. It might be a good > idea for anyone to read the updated documents from the sqlengine > branch or next dev-release. For svn users … $ svn checkout http://svn.perl.org/modules/dbi/trunk (I don't know how to switch branches in svn) For git users … $ git svn clone http://svn.perl.org/modules/dbi/trunk DBI-svn $ git checkout remotes/sqlengine and instead of git pull $ git stash && git svn fetch && git svn rebase && git stash pop Please test against sanity and your modules > We will try to answer all remaining questions about DBI driver > development (read: everything which isn't documented) with the > current doc update. Everything which is not clear, should be > asked. > > Thanks in advance and merry Christmas for everyone. Likewise! -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Fw: JROBINSON grant report, #13
Begin forwarded message:
Date: Tue, 18 Dec 2012 12:20:47 -
From: "Jess Robinson"
To: perl5-port...@perl.org
Subject: Re: JROBINSON grant report, #13
On Tue, 18 Dec 2012 11:48:51 -, Jess Robinson
wrote:
> diff -ru ./lib/DBI/DBD.pm
> /usr/src/perl/perl-cross-compile/repo/perl/cpan/DBI/lib/DBI/DBD.pm
> --- ./lib/DBI/DBD.pm 2012-02-04 20:51:40.0 +
> +++
> /usr/src/perl/perl-cross-compile/repo/perl/cpan/DBI/lib/DBI/DBD.pm
> 2012-12-16
> 15:11:29.0 +
> @@ -3283,7 +3283,7 @@
>
> BEGIN {
> $is_dbi = (-r 'DBI.pm' && -r 'DBI.xs' && -r 'DBIXS.h');
> -require DBI unless $is_dbi;
> +require DBI unless $is_dbi or $ENV{PERL_CORE};
> }
>
> my $done_inst_checks;
> @@ -3437,13 +3437,27 @@
> sub dbd_dbi_arch_dir {
> _inst_checks();
> return '$(INST_ARCHAUTODIR)' if $is_dbi;
> -my $dbidir = dbd_dbi_dir();
> my %seen;
> +my $dbi_version = '';
> +if($ENV{PERL_CORE}) {
> +## also if($Config{usecrosscompile}) ? - cant load DBI as built
> for other arch.
> +my $updir = File::Spec->updir;
> +my $CORElibdir = File::Spec->catdir(($updir) x 2, 'lib');
> +my $DBI_pm = File::Spec->catfile($CORElibdir, 'DBI.pm');
> +my $autoDBIdir = File::Spec->catdir($CORElibdir, 'auto', 'DBI');
> +if(!-d $autoDBIdir) {
> +die "Running under PERL_CORE, can't find $autoDBIdir";
> +}
> +$dbi_version = ExtUtils::MM_Unix->parse_version($DBI_pm);
> +} else {
> +$dbi_version = $DBI::VERSION;
> +}
> my @try = grep { not $seen{$_}++ } map { vmsify( unixify($_) .
> "/auto/DBI/" ) } @INC;
> my @xst = grep { -f vmsify( unixify($_) . "/Driver.xst" ) } @try;
> Carp::croak("Unable to locate Driver.xst in @try") unless @xst;
> Carp::carp( "Multiple copies of Driver.xst found in: @xst") if
> @xst > 1;
> -print "Using DBI $DBI::VERSION (for perl $] on $Config{archname})
> installed in $xst[0]\n";
> +print "Using DBI $dbi_version (for perl $] on $Config{archname})
> installed in $xst[0]\n";
> return File::Spec->canonpath($xst[0]);
> }
>
> Looking at the above I've just realised I failed to change actual
> finding of Driver.xst somewhere other than @INC, no wonder I had issues
> with the actual building... I'll go fix that now!
>
Oops, nope, I was wrong. Somehow my brain read %INC not @INC, so this
locating of Driver.xst does work without changes.
Jess
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Fw: JROBINSON grant report, #13
-time, we need
# the required version of DBI very early.
my $DBI_required = 1.57;
-eval {
- require DBI;
-};
-if ( $@ or DBI->VERSION < $DBI_required ) {
- print "DBI 1.57 is required to configure this module; please
install it or upgrade your CPAN/CPANPLUS shell.\n";
- exit(0);
+unless($ENV{PERL_CORE}) {
+$ENV{PERL_CORE} = 1 if grep { $_ eq 'PERL_CORE=1' } @ARGV;
+}
+my $dbi_version = '';
+if($ENV{PERL_CORE}) {
+## Avoid actually loading DBI, as we might be cross-compiling
+my $updir = File::Spec->updir;
+my $CORElibdir = File::Spec->catdir(($updir) x 2, 'lib');
+my $DBI_pm = File::Spec->catfile($CORElibdir, 'DBI.pm');
+if(!-e $DBI_pm) {
+die "Building under PERL_CORE, but $DBI_pm doesn't exist";
+}
+$dbi_version = ExtUtils::MM_Unix->parse_version($DBI_pm);
+} else {
+eval {
+require DBI;
+};
+$dbi_version = DBI->VERSION;
+
+}
+if ( $@ or $dbi_version < $DBI_required ) {
+print "DBI 1.57 is required to configure this module; please
install it or upgrade your CPAN/CPANPLUS shell.\n";
+exit(0);
}
# See if we have a C compiler
@@ -356,7 +373,6 @@
use Config;
sub postamble {
- require DBI;
require DBI::DBD;
my $postamble = eval {
DBI::DBD::dbd_postamble(@_)
Looking at the above I've just realised I failed to change actual
finding of Driver.xst somewhere other than @INC, no wonder I had issues
with the actual building... I'll go fix that now!
Summary
---
0:30h - Admin (writing up)
2:00h - Compiling and testing RunPerl with Object-Remote-Java
2:00h - Gitifying and documenting RunPerl
3:00h - Cross-compiling DBI and DBD::SQLite
Total: 7:30h
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: [rt.cpan.org #81516] Test failures due to hash randomisation in perl 5.17.6
On Sat, 1 Dec 2012 22:14:00 +, Tim Bunce wrote: > > Remaining question in that proposal: where's the fence between "must > > be last" and "insert unnamed attrs here"? > > I don't know, but I would like a working DBI for 5.17.6+ before too long. After some discussion on IRC, we agreed on this: http://svn.perl.org/viewvc/modules?view=revision&revision=15511 which is likely to be integrated into the main trunk and released the next DBI. > Tim. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Topics DBI::DBD::SqlEngine & derived
On Tue, 04 Dec 2012 18:52:06 +0100, Jens Rehsack
wrote:
> Hi Merijn,
Reply to summarize progress
> we should talk about
> - how to modify DBI::DBD::SqlEngine::TableSource and
>DBI::DBD::SqlEngine::DataSource to allow chaining
>(eg. fetch via http/ssh & decompress)
Still open, planned for today
> - easy way to configure the table-/datasources
Still open, planned for today
> - making DBD::CSV ready for dev-release (to get ideas about
>chop-blank errors)
Ready, thanks to intens coorporation on IRC. Waiting for a
SQL::Statement release. Then I'll release a new DBD::CSV
that depends on it
> - feature request:
>* skip-lines + columns line is first/second line
>* columns line is "commented"
No priority. I'll have to think about these
> - compatibility support for $dbh->{f_meta}
Open, planned for discussion on IRC today
> - RT#81516 (close connected to $dbh->{f_meta} stuff}
Two possible fixes were posted by Jens yesterday. We'd
really (yes, REALLY) appreciate feedback on that ASAP.
> It would be great if Sven could join the discussion
> for AnyData/DBD::AnyData work (to avoid doing incompatible
> stuff) and Tim as well as Martin to have more people with
> better knowledge about DBI::DBD::SqlEngine/DBD::File internals.
>
> I would also agree parts of the discussion happens via Skype,
> TeamSpeak (I can provide a server) or any other voice chat,
> if necessary.
Not an option in my $work environment
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: [rt.cpan.org #81516] Test failures due to hash randomisation in perl 5.17.6
On Wed, 12 Dec 2012 16:31:44 +0100, Jens Rehsack
wrote:
> On 01.12.12 23:14, Tim Bunce wrote:
> > On Thu, Nov 29, 2012 at 10:15:19PM +0100, Jens Rehsack wrote:
> >>
> >> But back to the issue - now it seems dbm_tables is fetched earlier
> >> in some cases than f_dir which causes an invocation of
> >> DBI::DBD::SqlEngine::Table::get_table_meta (including
> >> DBI::DBD::SqlEngine::Table::bootstrap_table_meta) before f_dir
> >> has been set. This causes $dbh->{sql_meta}->{fred}->{f_dir} being
> >> initialized to the default value of $dbh->{f_dir} which is
> >> always cur_dir().
> >>
> >> Looking into DBI::DBD::SqlEngine::dr::connect around line 180
> >> it could be seen that there's already some magic for "some
> >> settings must be done before others".
> >>
> >> A quick fix for "now" could be: keys: ("sql_meta", $dbh->{dbm_meta},
> >> ...) must be initialized last - after any other k/v pair from %$attrs.
> >> Another quick should could be forbid setting meta info during connect(),
> >> as it's documented - but this would be a hugh step backwards in my
> >> effort making DBI::DBD::SqlEngine and derived DBD's usable through
> >> Gofer proxy. So I'd prefer the first quick shot ...
> >>
> >> For longer way, I'd like to refactor the order procedure to a
> >> more flexible way:
> >> $dbh->{dbd_init_order} = [
> >>[qw(Profile RaiseError PrintError AutoCommit)],
> >>[qw(ReadOnly ...)],
> >>...
> >>[qw(sql_meta dbm_tables ...)]
> >> ];
> >>
> >> Remaining question in that proposal: where's the fence between "must
> >> be last" and "insert unnamed attrs here"?
> >
> > I don't know, but I would like a working DBI for 5.17.6+ before too long.
>
> Well, we developed two patches for now:
>
> 1) Merijn's patch - http://pasta.test-smoke.org/385
>
> + looks simple, easy to understand
+ easy to extend
+ easy to override
+ one single point of maintenance
> - makes assumptions about attribute names of derived DBD's
>(e.g. dbm_tables, but this can be easily renamed by assigning
> new name for it to $dbh->{dbm_meta} (by driver author), eg.
> $dbh->{dbm_meta} = "dbm_sources")
which makes me/us/you want more documentation about what DBI/DBD
guarantees, expects, supports etc. there is no real "you should do
this" or "this is officially off-bound"
> - increases complexitiy when more issues came up with similar
>patterns (eg. /_meta$/ can't be set from outside, but from
>derived driver)
but still offers easy documentation for every single entry
> 2) Jens' patch - http://pasta.test-smoke.org/387
>
> + backward compatible to ancient attributes (csv_file, csv_ext, ...)
though I value this point, we are talking about DBD's we all
control. The newest DBD::CSV and DBD::DBM will require the new DBI
so conflicts are not likely to happen. To be honest, I - as
maintainer of DBD::CSV - didn't even know csv_file was still
supported
> + no assumptions on derived DBD's
a very good point
> + no false positives on pattern match
if everything is well-documented, then false positives should not
happen or better cause havoc
> - more complicated for quick review
can be solved by well-chosen inline docs
- This patch will probably need to have extra code in (many) other
places, which my patch tried to avoid
> Any other +/- comments?
Yes please, don't feel shy!
Tell us!
> In general both versions would fix the root cause of RT#81516,
> while the maintainers (Merijn, me) cannot choose the right one.
What he said
> Jens
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
clang
90sql_type_cast.t . ok t/pod-coverage.t .... skipped: Test::Pod::Coverage 1.04 required for testing POD coverage t/pod.t . skipped: Test::Pod 1.00 required for testing POD -- skip the z tests -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
DBD::CSV failures hidden in the deep
my $dummy = [];
my $dummy = {};
These cause PASS:
my $dummy = { bonkers => 1 };
my $dummy = [ 1, 2 ];
my $dummy = \[];
my $dummy = \{};
As Tim nicely put it: this smells like the canary in the coalmines
I am currently trying to get all the prereqs installed on perl-5.17.6
compiled with clang -fsanitize=address, but I cannot install a lot of
the prereq's including DBI. I will post a separate message about that
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: some fixes / new test for DBD::CSV
On Fri, 26 Oct 2012 16:58:13 +0200, Jens Rehsack wrote: > Hi Merijn, > > as talked in IRC here are the patches. They currently cover the 2 things > I missed tests for (file-handle, col_names + skip_rows). > > You can do me a favour and apply the attached patches using > 'git am' and modify them later (allows me to fast-forward instead > of merging). I did, but this isn't good: DBD-CSV 509 > prove -vwb t/61_meta.t t/61_meta.t .. plan() doesn't understand skipall DBD::File 0.41 required at t/61_meta.t line 12. Use of uninitialized value $fn in unlink at t/61_meta.t line 54. Dubious, test returned 22 (wstat 5632, 0x1600) No subtests run Test Summary Report --- t/61_meta.t (Wstat: 5632 Tests: 0 Failed: 0) Non-zero exit status: 22 Parse errors: No plan found in TAP output Files=1, Tests=0, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.07 cusr 0.00 csys = 0.09 CPU) Result: FAIL I fixed those in the commit after yours (+ tidying) Requiring DBD::File-0.41 also implies requiring the non-released DBI-6.123 Setting my env to use that unreleased DBI, I get CPAN/DBD-CSV 523 > prove -vwb t/61_meta.t t/61_meta.t .. ok 1 - find new test table ok 2 # skip memory i/o currently unsupported by DBD::File ok 3 # skip memory i/o currently unsupported by DBD::File DBD::CSV::st execute failed: Can't use an undefined value as a symbol reference at /pro/3gl/CPAN/DBI-svn/blib/lib/DBD/File.pm line 445, line 7. at /pro/3gl/CPAN/DBI-svn/blib/lib/DBI/DBD/SqlEngine.pm line 1191. [for Statement "SELECT * FROM data"] at t/61_meta.t line 73, line 7. DBD::CSV::st fetchall_arrayref failed: Attempt to fetch row without a preceeding execute () call or from a non-SELECT statement [for Statement "SELECT * FROM data"] at t/61_meta.t line 74, line 7. not ok 4 - all rows found - file-handle w/o col_names # Failed test 'all rows found - file-handle w/o col_names' # at t/61_meta.t line 75. # Structures begin differing at: # $got->[0] = Does not exist # $expected->[0] = ARRAY(0x9145bfc) not ok 5 - column names - file-handle w/o col_names # Failed test 'column names - file-handle w/o col_names' # at t/61_meta.t line 76. # Structures begin differing at: # $got->[0] = Does not exist # $expected->[0] = 'id' DBD::CSV::st execute failed: Can't use an undefined value as a symbol reference at /pro/3gl/CPAN/DBI-svn/blib/lib/DBD/File.pm line 445, line 7. at /pro/3gl/CPAN/DBI-svn/blib/lib/DBI/DBD/SqlEngine.pm line 1191. [for Statement "SELECT * FROM data"] at t/61_meta.t line 88, line 7. DBD::CSV::st fetchall_arrayref failed: Attempt to fetch row without a preceeding execute () call or from a non-SELECT statement [for Statement "SELECT * FROM data"] at t/61_meta.t line 89, line 7. not ok 6 - all rows found - file-handle w col_names # Failed test 'all rows found - file-handle w col_names' # at t/61_meta.t line 90. # Structures begin differing at: # $got->[0] = Does not exist # $expected->[0] = ARRAY(0x9145bfc) not ok 7 - column names - file-handle w col_names # Failed test 'column names - file-handle w col_names' # at t/61_meta.t line 91. # Structures begin differing at: # $got->[0] = Does not exist # $expected->[0] = 'foo' ok 8 - all rows found - file-name w/o col_names ok 9 - column names - file-name w/o col_names ok 10 - all rows found - file-name w col_names ok 11 - column names - file-name w col_names 1..11 # Looks like you failed 4 tests of 11. Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/11 subtests (less 2 skipped subtests: 5 okay) Test Summary Report --- t/61_meta.t (Wstat: 1024 Tests: 11 Failed: 4) Failed tests: 4-7 Non-zero exit status: 4 Files=1, Tests=11, 0 wallclock secs ( 0.01 usr 0.00 sys + 0.08 cusr 0.00 csys = 0.09 CPU) Result: FAIL Pushed anyway, so you can move on … > Thanks, > Jens -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: list_tables / table_info failures ...
On Fri, 05 Oct 2012 15:54:31 +0200, Jens Rehsack
wrote:
> Hi Merijn,
>
> We have to think about both tests ...
Here ya go …
--8<---
diff --git a/t/49dbd_file.t b/t/49dbd_file.t
index 4bae4bd..61f75ea 100644
--- a/t/49dbd_file.t
+++ b/t/49dbd_file.t
@@ -99,7 +99,7 @@ SKIP: {
my @tfhl;
# Now test some basic SQL statements
-my $tbl_file = File::Spec->catfile (Cwd::abs_path( $dir ), "$tbl.txt");
+my $tbl_file = File::Spec->catfile (Cwd::abs_path ($dir), "$tbl.txt");
ok ($dbh->do ("create table $tbl (txt varchar (20))"), "Create table $tbl") or
diag $dbh->errstr;
ok (-f $tbl_file, "Test table exists");
@@ -122,12 +122,12 @@ is_deeply ($dbh->f_get_meta ([$tbl, "t_sbdgf_53442Gz"],
[qw(f_dir f_ext)]),
my @layer = grep { $_ eq "encoding($encoding)" } @tfhl;
is (scalar @layer, 1, "encoding shows in layer");
-my @tables = $dbh->func( "list_tables" );
-is_deeply( \@tables, ["000_just_testing", $tbl], "Listing tables gives test
table" );
+my @tables = sort $dbh->func ("list_tables");
+is_deeply (\@tables, [sort "000_just_testing", $tbl], "Listing tables gives
test table");
-ok ($sth = $dbh->table_info(), "table_info");
-@tables = $sth->fetchall_arrayref;
-is_deeply( \@tables, [ [ map { [ undef, undef, $_, 'TABLE', 'FILE' ] }
("000_just_testing", $tbl) ] ], "table_info gives test table" );
+ok ($sth = $dbh->table_info (), "table_info");
+@tables = sort { $a->[2] cmp $b->[2] } @{$sth->fetchall_arrayref};
+is_deeply (\@tables, [ map { [ undef, undef, $_, 'TABLE', 'FILE' ] }
"000_just_testing", $tbl ], "table_info gives test table");
SKIP: {
$using_dbd_gofer and skip "modifying meta data doesn't work with
Gofer-AutoProxy", 4;
@@ -145,7 +145,7 @@ SKIP: {
$dbh->errstr and diag $dbh->errstr;
}
-my $uctbl = uc($tbl);
+my $uctbl = uc ($tbl);
ok ($sth = $dbh->prepare ("select * from $uctbl"), "Prepare select * from
$uctbl");
$rowidx = 0;
SKIP: {
-->8---
All tests successful.
Files=183, Tests=10373, 63 wallclock secs ( 1.58 usr 0.32 sys + 51.42 cusr
5.10 csys = 58.42 CPU)
Result: PASS
PERL_DL_NONLAZY=1 /pro/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
test.pl
DBI test application $Revision$
Switch: DBI 1.623 by Tim Bunce, 1.623
Available Drivers: AnyData, CSV, DBM, ExampleP, File, Gofer, Multiplex, ODBC,
Oracle, Pg, Proxy, SQLite, Sponge, iPod, mysql
dbi:ExampleP:: testing 3 sets of 20 connections:
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
Connecting... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Disconnecting...
connect 20 and disconnect them, 3 times: 0.0019s / 60 = 0.s
Testing handle creation speed...
125000 NullP sth/s perl 5.016000 i686-linux-64int-ld (gcc 4.6.2 -O2) 0.08s
test.pl done
> t/49dbd_file.t .. 1/?
> # Failed test 'Listing tables gives test table'
> # at t/49dbd_file.t line 126.
> # Structures begin differing at:
> # $got->[0] = 'db_25542_'
> # $expected->[0] = '000_just_testing'
>
> # Failed test 'table_info gives test table'
> # at t/49dbd_file.t line 130.
> # Structures begin differing at:
> # $got->[0][0][2] = 'db_25542_'
> # $expected->[0][0][2] = '000_just_testing'
> # Looks like you failed 2 tests of 43.
> t/49dbd_file.t .. Dubious, test returned 2 (wstat 512,
> 0x200)
> Failed 2/43 subtests
>
> The order is vice versa than expected.
>
> But is early enough when your back! Just keeping it in mind (we both!).
>
> /Jens
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: list_tables / table_info failures ...
On Fri, 05 Oct 2012 15:54:31 +0200, Jens Rehsack
wrote:
> Hi Merijn,
>
> We have to think about both tests ...
my @tables = $dbh->func( "list_tables" );
is_deeply( \@tables, ["000_just_testing", $tbl], "Listing tables gives test
table" );
=>
my @tables = sort $dbh->func ("list_tables");
is_deeply (\@tables, [sort "000_just_testing", $tbl], "Listing tables gives
test table");
why can't we make list_tables return always sorted?
> t/49dbd_file.t .. 1/?
> # Failed test 'Listing tables gives test table'
> # at t/49dbd_file.t line 126.
> # Structures begin differing at:
> # $got->[0] = 'db_25542_'
> # $expected->[0] = '000_just_testing'
>
> # Failed test 'table_info gives test table'
> # at t/49dbd_file.t line 130.
> # Structures begin differing at:
> # $got->[0][0][2] = 'db_25542_'
> # $expected->[0][0][2] = '000_just_testing'
> # Looks like you failed 2 tests of 43.
> t/49dbd_file.t .. Dubious, test returned 2 (wstat 512,
> 0x200)
> Failed 2/43 subtests
>
> The order is vice versa than expected.
>
> But is early enough when your back! Just keeping it in mind (we both!).
>
> /Jens
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Refactoring DBD::File in preparation for ReadOnly and streams ...
On Wed, 19 Sep 2012 17:21:32 +0200, Jens Rehsack
wrote:
> Hi Merijn,
>
> while hacking around in DBD::File and DBI::DBD::SqlEngine I stumbled
> over a major design fault made in the past:
Some - backward compatible - thoughts:
Replace all dir-related parts in DBD::File with callbacks
Make streaming interfaces able to override dir-related parts
Backward compatible AND extendable
> sub DBD::File::Table::get_table_meta () ... evaluates
> $dbh->{f_meta}{$table}{initialized} and does something magic else. This
> magic is fully DBD::File addicted (heavily relies on file2table) and it
> should be broken into separate pieces to differ between initialisation
> done for DBI::DBD::SqlEngine and DBD::File and DBD::DBM ...
>
> I'd like to discuss it tomorrow in IRC (but I read my e-Mail if you have
> comments at the evening).
>
> If anyone else has ideas - please feel free to speak (but primary
> restriction is backward compatibility to avoid breakage of dependent DBD's).
>
> Best regards,
> Jens
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Patch for ReadOnly on DBI::DBD::SqlEngine and derived
On Thu, 20 Sep 2012 17:36:45 +0200, Jens Rehsack wrote: > Hi Merijn, > > does the attached patch looks good for you? yes > I decided to deal differently with lockMode, because I don't want > silently drop lock support ... > > Jens -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Refactoring DBD::File in preparation for ReadOnly and streams ...
On Wed, 19 Sep 2012 17:21:32 +0200, Jens Rehsack
wrote:
> Hi Merijn,
>
> while hacking around in DBD::File and DBI::DBD::SqlEngine I stumbled
> over a major design fault made in the past:
>
> sub DBD::File::Table::get_table_meta () ... evaluates
> $dbh->{f_meta}{$table}{initialized} and does something magic else. This
> magic is fully DBD::File addicted (heavily relies on file2table) and it
> should be broken into separate pieces to differ between initialisation
> done for DBI::DBD::SqlEngine and DBD::File and DBD::DBM ...
IIRC this was what you already advertised on your first round of
DBD::File internals redesign.
As long as "users" of DBD::File are not harmed, go ahead.
I do not want a truckload of code like
http://repo.or.cz/w/DBD-CSV.git/blob/8d7f4284:/lib/DBD/CSV.pm#l90
which has now been removed as the prereq's are higher:
PREREQ_PM=> {
"DBI"=> 1.614,
"DBD::File" => 0.40,
"Text::CSV_XS" => 0.91,
"SQL::Statement" => 1.33,
"Test::More" => 0.90,
"Encode" => 0,
"charnames" => 0,
},
But in future upgrades/updates, code like that is not unlikely to
re-appear
> I'd like to discuss it tomorrow in IRC (but I read my e-Mail if you have
> comments at the evening).
>
> If anyone else has ideas - please feel free to speak (but primary
> restriction is backward compatibility to avoid breakage of dependent DBD's).
>
> Best regards,
> Jens
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Enhancements to Pure-Perl DBD's (primarily DBD::File)
On Tue, 18 Sep 2012 02:12:18 -0700, Darren Duncan wrote: > Jens Rehsack wrote: > > today I got some people in irc://irc.perl.org/#dbi to discuss planned > > extension to DBD::File. > > > > There were several goals to reach: > > 1) add readonly mode to DBI::DBD::SqlEngine > >==> will be solved by adding a new attribute sql_readonly to > >DBI::DBD::SqlEngine and if required fix DBI::SQL::Nano and > >SQL::Statement and bump SQL::Statement requirement in *::Nano > > I would recommend doing the complement, backwards-compatibility concerns > aside. > > Make read-only the default behavior and have a new attribute sql_writable > instead. If the goal is to make it possible for safer behavior, that should > be > the default. Then people don't "accidentally" make changes when they didn't > mean to. I would not. That is VERY counter-intuïtive. All (other) DBD's are read-write by default, as it should be. > If backwards-compatibility is the only reason not to do that, you can phase > it > in over time maybe in a similar manner to how strictures were in Perl; eg, if > someone explicitly requires a version number that is greater than X, then > readonly is the default; if they have no explicit version requirement, then > something backwards-compatible is the default. No, read-only support is only added to make implementing streams as data-sources easier. Maybe just for the thought-process, but still. Jens and I talked this through when imagining a file like database.tar.gz being opened using Archive::Tar, which contains many CSV files (the tables). A good example for a read-only data-source. Jens then proclaimed it would probably not bee too hard to extend the API to allow writable streams, which I doubted, but discussion went on. > > 2) add support for other I/O layers to DBD::File > >a) add support for streams (PerlIO) > >b) add support for other kind of fetch_row/push_row processing > > Does the current version work with files in a stream fashion, No, DBD::File *always* uses open to open a data-source. Maybe that is why it is called DBD::File. > such as only reading in enough at a time that it needs, or does it > read the whole file before doing anything? That depends on the implementation in the DBD that extends DBD::File e.g. DBD::CSV reads the complete file at once. > Regardless, streaming is great for scalability. It means you can have > many-gigabyte files and be able to work with them. And security is helped as > it > isn't so easy for someone to DOS you by giving you a huge input. Yes, one of the thoughts we discussed -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: AnyData patches
fitting)' # expected: '' not ok 6 - AnyData/Format/HTMLtable.pm # Failed test 'AnyData/Format/HTMLtable.pm' # at /pro/bin/pod-spell-check line 96. # got: ''Sisk' => (Disk Sis Sask Sick Fisk Risk Silk Sink Sis's)' # expected: '' not ok 7 - AnyData/Format/Ini.pm # Failed test 'AnyData/Format/Ini.pm' # at /pro/bin/pod-spell-check line 96. # got: ''Ini' => (Uni IN In INRI Ni Ii Ina Inn Mini ING INS Inc Ind Iii Inf Ink Ins Int In's)' # expected: '' ok 8 - AnyData/Format/Mp3.pm ok 9 - AnyData/Format/Paragraph.pm ok 10 - AnyData/Format/Passwd.pm ok 11 - AnyData/Format/Pipe.pm ok 12 - AnyData/Format/Tab.pm ok 13 - AnyData/Format/Text.pm ok 14 - AnyData/Format/Weblog.pm not ok 15 - AnyData/Format/XML.pm # Failed test 'AnyData/Format/XML.pm' # at /pro/bin/pod-spell-check line 96. # got: ''DTD' => (DDT TDD STD TD DD DOD DAD DID DUD DMD DTP DVD ETD LTD IT'D) # 'formating' => (for mating for-mating formatting formation forming formulating formalin formative foaming firming fomenting formatting's floating fating format mating reformatting farming farting footing fording formfitting) # 'itslef' => (itself outsell oneself Edsel Adolf outsells dissolve)' # expected: '' ok 16 - AnyData/Storage/File.pm ok 17 - AnyData/Storage/FileSys.pm ok 18 - AnyData/Storage/PassThru.pm ok 19 - AnyData/Storage/RAM.pm ok 20 - AnyData/Storage/TiedHash.pm ok 21 - sandbox/genMETA.pm 1..21 # Looks like you failed 5 tests of 21. not ok 2 - Spell-check with aspell # Failed test 'Spell-check with aspell' # at /pro/bin/pod-spell-check line 100. ok 1 - AnyData.pm ok 2 - AnyData/Format/Base.pm ok 3 - AnyData/Format/CSV.pm ok 4 - AnyData/Format/FileSys.pm ok 5 - AnyData/Format/Fixed.pm ok 6 - AnyData/Format/HTMLtable.pm ok 7 - AnyData/Format/Ini.pm ok 8 - AnyData/Format/Mp3.pm ok 9 - AnyData/Format/Paragraph.pm ok 10 - AnyData/Format/Passwd.pm ok 11 - AnyData/Format/Pipe.pm ok 12 - AnyData/Format/Tab.pm ok 13 - AnyData/Format/Text.pm ok 14 - AnyData/Format/Weblog.pm ok 15 - AnyData/Format/XML.pm ok 16 - AnyData/Storage/File.pm ok 17 - AnyData/Storage/FileSys.pm ok 18 - AnyData/Storage/PassThru.pm ok 19 - AnyData/Storage/RAM.pm ok 20 - AnyData/Storage/TiedHash.pm ok 21 - sandbox/genMETA.pm 1..21 ok 3 - Spell-check with ispell 1..3 # Looks like you failed 1 test of 3. Not in MANIFEST: AnyData/Storage/File.pod Not in MANIFEST: t/htmltable.t Not in MANIFEST: t/xml.t * has_humanreadable_license Add a section called 'LICENSE' to the documentation, or add a file named LICENSE to the distribution. * has_test_pod_coverage Add a test using Test::Pod::Coverage to check for POD coverage. > Sven > > > On 04/09/12 21:05, H.Merijn Brand wrote: > > On Sun, 02 Sep 2012 08:56:04 +1000, Sven Dowideit > > wrote: > >> Heya > >> > >> I used git send-emails to post some patches to rehs...@cpan.org and > >> this list, but I suspect they haven't made it due to my server setup > >> > >> before I send them again, I thought I'd test, and ask if anyone has > >> received them :) > > > > Does all of this has some git repo we could clone so we can run some > > (more) tests on it? -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: AnyData patches
On Sun, 02 Sep 2012 08:56:04 +1000, Sven Dowideit wrote: > Heya > > I used git send-emails to post some patches to rehs...@cpan.org and > this list, but I suspect they haven't made it due to my server setup > > before I send them again, I thought I'd test, and ask if anyone has > received them :) Does all of this has some git repo we could clone so we can run some (more) tests on it? -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle RTs a summary and request for help
On Sun, 24 Jun 2012 14:26:13 +0200, "H.Merijn Brand" wrote: > On Sun, 24 Jun 2012 11:25:00 +0100, "Martin J. Evans" > wrote: > > > https://rt.cpan.org/Ticket/Display.html?id=69059 > > Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: > > 0712-001 Symbol OCIPing was referenced > > I don't have access to AIX or an Oracle 10 and op gone quiet. > > I have > AIX 5.3.0.0/ML12 IBM,9115-505 PowerPC_POWER5/1898(2) 3920 Mb > plus Oracle 10.2.0.1.0 > > I'll have a look later. maybe even today Test results added to ticket. Available now for help. (Will start xchat now) -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle RTs a summary and request for help
On Sun, 24 Jun 2012 11:25:00 +0100, "Martin J. Evans" wrote: > https://rt.cpan.org/Ticket/Display.html?id=69059 > Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: > 0712-001 Symbol OCIPing was referenced > I don't have access to AIX or an Oracle 10 and op gone quiet. I have AIX 5.3.0.0/ML12 IBM,9115-505 PowerPC_POWER5/1898(2) 3920 Mb plus Oracle 10.2.0.1.0 I'll have a look later. maybe even today -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBI : Extend 'ChopBlanks' support to variable length character types
On Sat, 2 Jun 2012 17:57:06 +, "Manikantan, Madhunapanthula_Naaga"
wrote:
> Hello DBI-Dev,
>
> After getting inputs from Martin and reading DBI documentation it became
> clear to me that 'ChopBlanks' attribute is designed to work for fixed length
> character types.
> Can you please let me know if this feature can be extended to variable length
> character types as well?
Not by design. See also. If a (new) attribute would be created, all
DBD's should implement/support it.
file://localhost/work/www/Talks/DBDc/null.html
> Thanks a lot!
> Manikantan.
>
> _
> From: Manikantan, Madhunapanthula_Naaga
> Sent: Friday, June 01, 2012 5:26 PM
> To: dbi-dev@perl.org; dbi-us...@perl.org
> Cc: martin.ev...@easysoft.com
> Subject: FW: :ODBC {ChopBlanks=>1} option issue
>
>
> Forwarding to DBI-dev , DBI-users as an fyi.
> Thanks
>
> _
> From: Manikantan, Madhunapanthula_Naaga
> Sent: Friday, June 01, 2012 5:02 PM
> To: 'Martin J. Evans'
> Subject: DBD::ODBC {ChopBlanks=>1} option issue
>
>
> Hello Martin,
>
> I hope you are doing well.
>
> ChopBlanks option, doesn't seem to work with DBD::ODBC. Can you please
> help?
>
> I checked out latest version of DBD::ODBC from svn.perl.org and tested
> the below script on solaris and Linux.
>
> Please let me know if you need further information.
>
> O/p from my test
>
> manik...@finop2.nyc:~/Driver$<mailto:manik...@finop2.nyc:~/Driver$>
> perl -I blib/lib/ -I blib/arch/ ~/chopblanks.pl
> $VAR1 = [
> [
> ' ' # has once space
> ]
> ];
>
> SQL
> ---
> # Create table
> create table test (v varchar(128))
> # set permissions
> grant all on public to test
> # populate data
> insert into test values(' ') -- one space
>
>
> Environment:-
> ---
> OS :- Red Hat Enterprise Linux 6
> Perl :- 5.10.1
> DBI :- 1.609
>
>
> Test Script
> -
> use DBI;
> use Data::Dumper;
> $dbh = DBI->connect('dbi:ODBC:DSN=DBTEST-es','','***',{ChopBlanks
> => 1});
> #$dbh->{TraceLevel}=15;
> $sth = $dbh->prepare('select v from sandbox.dbo.test');
> $sth->execute();
> $rows = $sth->fetchall_arrayref();
> print Dumper($rows);
>
>
> Regards,
> Mani.
>
>
> Ps:
> FTR, I read the below extract from DBD::ODBC documentation
>
> ---
> I am at present unsure if ChopBlanks processing on Unicode strings is
> working correctly on UNIX. If nothing else the construct L' ' in dbdimp.c
> might not work with all UNIX compilers. Reports of issues and patches welcome.
> ---
>
>
>
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: "unrecognised attribute name or invalid value"
On Mon, 7 May 2012 18:02:31 +0300, "Philip Stoev"
wrote:
> >> Can't set DBI::db=HASH(0x20e7098)->{State}: unrecognised attribute name
> >> or
> >> invalid value at /usr/lib64/perl5/vendor_perl/DBI.pm line 720.
> >> Can't set DBI::db=HASH(0x20e7098)->{Errstr}: unrecognised attribute name
> >> or
> >> invalid value at /usr/lib64/perl5/vendor_perl/DBI.pm line 720.
> >> Can't set DBI::db=HASH(0x20e7098)->{Driver}: unrecognised attribute name
> >> or
> >> invalid value at /usr/lib64/perl5/vendor_perl/DBI.pm line 720.
> >> Can't set DBI::db=HASH(0x20e7098)->{Err}: unrecognised attribute name or
> >> invalid value at /usr/lib64/perl5/vendor_perl/DBI.pm line 720.
> >>
> >> How can I make them go away? Err and Errstr both work in my driver, so it
> >> seems to me I am handling them correctly.
> >>
> >> Thank you!
> >
> > Did you look at other DBD XS drivers?
> >
>
> Yes I did, I used the MySQL, Firebird, Oracle and ODBC drivers as reference
> but I can not figure out what I am doing differently from them.
>
> >
> > It might also help to actually share the code yoiu suspect: the code
> > you have written to implement connect (). We could comment on that.
> >
>
> The perl portion of connect() is here
>
> https://github.com/nuodb/nuodb-drivers/blob/master/perl_dbi/lib/DBD/NuoDB.pm#L38
>
> The C++ portion is here:
>
> https://github.com/nuodb/nuodb-drivers/blob/master/perl_dbi/dbdimp.cpp#L11
>
> Thank you.
You should probably add them like this:
sub driver {
return $drh if $drh;
my($class, $attr) = @_;
$class .= "::dr";
$drh = DBI::_new_drh($class, {
'Name' => 'NuoDB',
'Version' => $VERSION,
'Err' => \my $err,# ADDED
'Errstr'=> \my $errstr, # ADDED
'State' => \my $state, # ADDED
'Attribution' => 'Perl DBI DBD NuoDB driver by Philip Stoev
',
});
return $drh;
}
Does that help?
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: "unrecognised attribute name or invalid value"
On Mon, 7 May 2012 17:00:34 +0300, "Philip Stoev"
wrote:
> Hello,
>
> I am building a new XS-based DBD driver, using the best practices of
> cargo-cult programming as recommended in the manual.
>
> However, on every connect() attempt, I get the following unsilencable
> warnings:
>
> Can't set DBI::db=HASH(0x20e7098)->{State}: unrecognised attribute name or
> invalid value at /usr/lib64/perl5/vendor_perl/DBI.pm line 720.
> Can't set DBI::db=HASH(0x20e7098)->{Errstr}: unrecognised attribute name or
> invalid value at /usr/lib64/perl5/vendor_perl/DBI.pm line 720.
> Can't set DBI::db=HASH(0x20e7098)->{Driver}: unrecognised attribute name or
> invalid value at /usr/lib64/perl5/vendor_perl/DBI.pm line 720.
> Can't set DBI::db=HASH(0x20e7098)->{Err}: unrecognised attribute name or
> invalid value at /usr/lib64/perl5/vendor_perl/DBI.pm line 720.
>
> How can I make them go away? Err and Errstr both work in my driver, so it
> seems to me I am handling them correctly.
>
> Thank you!
Did you look at other DBD XS drivers?
When writing DBD::Unify, I found several XS drivers very informative
and I stole^Wlooked at their code very carefully to see how I were to
do it. DBD::Oracle might be the most complete, but DBD::Pg has grown a
lot too since I started in DBD XS world.
It might also help to actually share the code yoiu suspect: the code
you have written to implement connect (). We could comment on that.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Status of DBI RT tickets
On Thu, 19 Apr 2012 17:25:04 +0100, Tim Bunce wrote: > On Wed, Apr 18, 2012 at 02:52:24PM +0100, Tim Bunce wrote: > > The DBI currently has 16 tickets in RT: > > > > https://rt.cpan.org/Public/Dist/Display.html?Name=DBI > > > I'd appreciate it if someone could review the other non-wishlist > > non-stalled tickets to see if they should be closed or acted on in some way. > > Merijn, what's the status of > https://rt.cpan.org/Public/Bug/Display.html?id=69260 > It's marked as patched but the change isn't in the DBI trunk yet. I think it is indeed "resolved". I have little access to my main workstation right now as it started to collapse, so my time is mainly getting into * trying to get it "working" again * installing a backup workstation as a fallback for option 1 > Is it stitting on a branch? > Are there any other changes on the branch? -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: why is imp_xxh stored in an SV?
itted DBIS patch represent the end of > > my work on improving performance on DBI, (not counting any remedial work > > that may be required). > > Many thanks again for your contributions to the DBI, Dave. > They are very much appreciated. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: feature request for SQL::Statement::Structure
On Sat, 7 Apr 2012 08:30:27 +0100, Jens Rehsack wrote: > Am 7. April 2012 01:30 schrieb Jeff Anderson : > > Greetings, > > > > I am wanting to take a SELECT statement and change the names of the > > tables without IMMEDIATELY executing that statement. I was hoping that > > SQL::Statement would solve the problem but apparently it can only > > EXECUTE a statement. Is this true? I could not find anywhere that > > deemed contrary in either the docs nor the source code. > > > > Seems to me that a lot of value is to be found in parsing statements, > > changing them and then PRINTING them out or storing them as scalars > > for execution at a later time. Would you be so kind as to provide > > this functionality? I honestly do not see any reason why it was not > > made available from the first release of this code. > > > > Sorry for the tone, but i was highly disappointed to learn that such a > > valuable and simple function was left out during my evaluation of this > > software. We will most likely use an alternative, but maybe the next > > person will not have to. Thanks in advance. > > Hey Jeff, > > please either open a ticket using RT or discuss it on dbi-dev@ or > probably dbi-users@. For now, I cc dbi-dev@. For feature > requests, cc'ing dbi-dev@ is always a good idea. > > To your mail itself: I absolutely don't know what you're talking about. Me neither. What /could/ help is a snippet of code that would do what you'd expect it to do as if SQL::Statement already supports what you want it to do. > No version information, nothing about the OS/distribution you use. > No test describing what you're doing and what's failing. > > Probably you can fix this and after that worry about your tone ;) -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: [rt.cpan.org #76276] support 0-column input tables?
On Wed, 4 Apr 2012 12:55:14 -0400, "Jens Rehsack via RT" wrote: > Merjin, By now, you'd know how not to switch the i and j, right? > can you throw it over into SQL::Statement Queue? It's reasonable to > handle it there. Sure. I thought it would be DBD::File, as the *file* is empty and thus would do the same for all DBD::File related DBD's. It might even warrant a new attribute to allow this as normally in DBI a table always has columns (but not always rows). If a file is empty, it doesn't even have columns. Not all databases allow the creation of "empty" tables, as in a table with no rows at all. Postgres does, but Unify and Oracle do not. I have included the devel list to see how others think > Best regards, > Jens -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On Tue, 13 Mar 2012 21:44:06 +, Tim Bunce wrote: > On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote: > > > > > > The second patch, which makes DBIS more efficient, is a lot more complex, > > > and more likely to break things (especially as it's changing a bunch of > > > macros that are directly #included by the DBD drivers. You may need to > > > bump API version numbers; I don't understand that bit. > > > > I'm concerned that changing the API, and thus forcing all compiled > > drivers to be recompiled at the same time the DBI is installed, > > isn't worth the gain. Especially as drivers shouldn't be using DBIS in > > any hot code anyway. > > I finally got around to looking at DBD::Pg and was horrified to discover > the number of DBIS calls made by hot paths in the code. Most are hidden > behind various tracing macros. Even fetch calls 3 + 3 * num_of_fields! When hidden, it won't stand out to the maintainers. How do we/I see where it happens? Do you have a (short) guide to check if my/a DBD (CSV, Unify, File) uses those too? > Then I looked at DBD::Oracle and discovered the same kind of thing. > Which is particularly disappointing for me as I wrote the tracing > mechanism it uses (though maybe that pre-dated thread support). > > Anyway, the upshot is that getting DBIS calls out of major drivers will > require a fair bit of work. It's just grunt-work really, nothing complicated. > As you noted with DBD::mysql, Dave, the performance gains are worth it. > > Any volunteers? Naturally I'll be happy to suggest an approach I think > will work well (basically an extension of that used by DBD::Oracle). > > Dave, I'll get back to you about the DBIS changes soon, I hope. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD-Oracle 1.40
On Mon, 12 Mar 2012 16:02:46 -0400, Yanick Champoux wrote: > On 12-03-11 11:48 AM, H.Merijn Brand wrote: > > On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux > > wrote: > > > >> On 12-03-11 06:01 AM, H.Merijn Brand wrote: > >>> t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) > >>> Failed tests: 2-3 > >>> Non-zero exit status: 2 > >>> Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr > >>> 0.01 csys = 0.08 CPU) > >> > >>That's not good. I'll issue a patch Monday, and try to narrow down on > >> which versions of Oracle the fix for rt-74753 isn't working. > > > > Note these: > > > > t/23wide_db.t . skipped: Database character set is not Unicode > > t/23wide_db_8bit.t skipped: Database character set is not Unicode > > t/23wide_db_al32utf8.t skipped: Database character set is not Unicode > > I have a new trial version changing the test so that it doesn't run if > the db character set is not unicode. I'm at home today, so I can't run > my battery of tests before releasing, but if anyone feel like giving it > a whirl, the new version is at > > svn repo: > http://svn.perl.org/modules/dbd-oracle/branches/DBD-Oracle-1.41_00 > > git repo: https://github.com/yanick/DBD-Oracle/tree/cand-v1.41 % git clone https://github.com/yanick/DBD-Oracle/tree/cand-v1.41 DBD-Oracle Cloning into 'DBD-Oracle'... fatal: https://github.com/yanick/DBD-Oracle/tree/cand-v1.41/info/refs not found: did you run git update-server-info on the server? % git clone https://github.com/yanick/DBD-Oracle DBD-Oracle Cloning into 'DBD-Oracle'... remote: Counting objects: 4891, done. remote: Compressing objects: 100% (1461/1461), done. remote: Total 4891 (delta 3470), reused 4763 (delta 3344) Receiving objects: 100% (4891/4891), 18.37 MiB | 1.07 MiB/s, done. Resolving deltas: 100% (3470/3470), done. % cd DBD-Oracle % git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/cand-v1.41 remotes/origin/cand_1.32 remotes/origin/candidate_1.31_00 remotes/origin/clean-changelog remotes/origin/cpan-changes remotes/origin/dist-zilla remotes/origin/doc-grooming remotes/origin/documentation-rt72252 remotes/origin/longdouble remotes/origin/master remotes/origin/oraperl-warning remotes/origin/pod-test remotes/origin/releases remotes/origin/rt-73206-ora_charset remotes/origin/rt13865 remotes/origin/rt30133 remotes/origin/rt71343-compile9i remotes/origin/rt74753 % git co remotes/origin/cand-v1.41 -b cand-v1.41 Branch cand-v1.41 set up to track remote branch cand-v1.41 from origin. Switched to a new branch 'cand-v1.41' % perl Makefile.PL Using DBI 1.618 (for perl 5.014001 on x86_64-linux-ld) installed in /pro/lib/perl5/site_perl/5.14.1/x86_64-linux-ld/auto/DBI/ Configuring DBD::Oracle for perl 5.014001 on linux (x86_64-linux-ld) Remember to actually *READ* the README file! Especially if you have any problems. Installing on a linux, Ver#2.6 Using Oracle in /usr/lib/oracle/11.2/client64 : : % make : ccache cc -c -I/usr/include/oracle/11.2/client64 -I/pro/lib/perl5/site_perl/5.14.1/x86_64-linux-ld/auto/DBI -fPIC -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"undef\" -DXS_VERSION=\"undef\" -fPIC "-I/pro/lib/perl5/5.14.1/x86_64-linux-ld/CORE" -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.2\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c dbdimp.c: In function ‘ora_db_login6’: dbdimp.c:765:5: warning: format ‘%d’ expects type ‘int’, but argument 12 has type ‘size_t’ dbdimp.c:765:5: warning: format ‘%d’ expects type ‘int’, but argument 14 has type ‘size_t’ : % make test PERL_DL_NONLAZY=1 /pro/bin/perl5.14.1 "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/00versions.t Use of uninitialized value in subroutine entry at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Use of uninitialized value in subroutine entry at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Use of uninitialized value in subroutine entry at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Invalid version format (version required) at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Compilation failed in require at t/00versions.t line 10. BEGIN failed--compilation aborted at t/00versions.t line 10. # Looks like your test exited with 2 before it could output anything. t/00versions.t Dubious, test returned 2 (wstat 512, 0x200) Failed 2/2 subtests > > > FWIW, DBD::Oracle-1.27 is the last to work on Oracle-9.2.0.8 &
Re: DBD-Oracle 1.40
On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux wrote: > On 12-03-11 06:01 AM, H.Merijn Brand wrote: > > t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) > >Failed tests: 2-3 > >Non-zero exit status: 2 > > Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.01 > > csys = 0.08 CPU) > > > That's not good. I'll issue a patch Monday, and try to narrow down on > which versions of Oracle the fix for rt-74753 isn't working. Note these: t/23wide_db.t . skipped: Database character set is not Unicode t/23wide_db_8bit.t skipped: Database character set is not Unicode t/23wide_db_al32utf8.t skipped: Database character set is not Unicode FWIW, DBD::Oracle-1.27 is the last to work on Oracle-9.2.0.8 All beyond 1.27 fail -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
DBD-Oracle 1.40
PERL_DL_NONLAZY=1 /pro/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/000-report-versions.t ... # Testing with Perl 5.014001, /pro/bin/perl t/000-report-versions.t ... 1/? # Carp version is 1.25 # Config version is undefined # DBI version is 1.618 # Data::Dumper version is 2.131 # Devel::Peek version is 1.07 # DynaLoader version is 1.13 # Encode version is 2.44 # Exporter version is 5.66 # ExtUtils::MakeMaker version is 6.62 # Math::BigInt version is 1.997 # Oraperl version is 1.44 # Scalar::Util version is 1.23 # Test::More version is 0.98 # Thread::Semaphore version is 2.12 # strict version is 1.04 # utf8 version is 1.09 # vars version is 1.02 # warnings version is 1.12 t/000-report-versions.t ... ok t/00versions.t # OCI client library version: 11.2.0.2 t/00versions.t 1/2 # database version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production t/00versions.t ok t/01base.t ok t/10general.t . ok t/12impdata.t . ok t/14threads.t . skipped: this linux perl 5.014001 not configured to support iThreads t/15nls.t . ok t/20select.t .. ok t/21nchar.t ... ok t/22nchar_al32utf8.t .. ok t/22nchar_utf8.t .. ok t/23wide_db.t . skipped: Database character set is not Unicode t/23wide_db_8bit.t skipped: Database character set is not Unicode t/23wide_db_al32utf8.t skipped: Database character set is not Unicode t/24implicit_utf8.t ... ok t/25plsql.t ... ok t/26exe_array.t ... ok t/28array_bind.t .. ok t/30long.t ok t/31lob.t . skipped: see RT#69350 t/31lob_extended.t ok t/32xmltype.t . ok t/34pres_lobs.t ... ok t/36lob_leak.t ok t/38taf.t . ok t/40ph_type.t . ok t/50cursor.t .. ok t/51scroll.t .. ok t/55nested.t .. ok t/56embbeded.t ok t/58object.t .. ok t/60reauth.t .. skipped: ORACLE_USERID_2 not defined. t/70meta.t ok t/80ora_charset.t . skipped: Database is set up as US7ASCII t/rt13865.t ... ok t/rt74753-utf8-encoded.t .. 1/3 # Failed test 'utf8 encoded' # at t/rt74753-utf8-encoded.t line 58. # got: '' # expected: '1' # Failed test 'truncated, yet utf8 encoded' # at t/rt74753-utf8-encoded.t line 80. # got: '' # expected: '1' # Looks like you failed 2 tests of 3. t/rt74753-utf8-encoded.t .. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests Test Summary Report --- t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 Files=36, Tests=2551, 113 wallclock secs ( 1.23 usr 0.10 sys + 5.07 cusr 1.04 csys = 7.44 CPU) Result: FAIL Failed 1/36 test programs. 2/2551 subtests failed. DBD-Oracle-1.40-mOxdTe > prove -vbw t/rt74753-utf8-encoded.t t/rt74753-utf8-encoded.t .. 1..3 ok 1 - utf8 encoded not ok 2 - utf8 encoded # Failed test 'utf8 encoded' # at t/rt74753-utf8-encoded.t line 58. # got: '' # expected: '1' not ok 3 - truncated, yet utf8 encoded # Failed test 'truncated, yet utf8 encoded' # at t/rt74753-utf8-encoded.t line 80. # got: '' # expected: '1' # Looks like you failed 2 tests of 3. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests Test Summary Report --- t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.01 csys = 0.08 CPU) Result: FAIL This is perl 5, version 14, subversion 1 (v5.14.1) built for i686-linux-64int-ld LANG=en_US.utf8 -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle v1.39_00 is out
On Mon, 27 Feb 2012 09:57:33 -0500, Yanick Champoux
wrote:
> On 02/27/12 02:02, H.Merijn Brand wrote:
> > On Fri, 24 Feb 2012 16:50:37 -0500, Yanick Champoux
> > wrote:
> >
> > > [OTHERS]
> > > - change the shebang line of examples to the more modern '/usr/bin/env
> > > perl'
> >
> > Personally I really really hate this change
>
> Fair enough. This being said, I have to point out that the change
> is only on the scripts in the 'examples/' directory, which are not
> installed as part of the distro.
Understood, but IMHO we/you should not/never promote that usage
> > Perl has been configured to use $Config{startperl}. Use it!
>
> I'm not sure I understand how you would like me to use it. I know that,
> if we ask nicely, MakeMaker and Module::Build will change the shebang
> of scripts that are to be installed to the local location of perl, but
> typically things that are not to be installed are left alone.
In which case I wonder why this change was needed in the first place
> Do you propose that the example directory get munged as part of the
> 'perl Makefile.PL' stage?
No, only if these examples are installed as option from Makefile.PL
(many modules allow that)
> Or do you know of a static shebang that goes straight for
> $Config{startperl} ?
No. Maybe #!your_path_to_perl_here
would be the best option :)
Maybe I sounded too harsh in my previous mail, but in the end, that
ticket should just have been marked "rejected" with exactly the
explanation you just wrote here. If it does not install those scripts
from examples, *ANY* shebang line is valid
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle v1.39_00 is out
On Fri, 24 Feb 2012 16:50:37 -0500, Yanick Champoux
wrote:
> [OTHERS]
> - change the shebang line of examples to the more modern '/usr/bin/env
> perl'
> [RT74001]
Personally I really really hate this change
App::Ack was the first I noted to make this horrid change and I always
revert the shebang line to reflect my production perl
I (very) often work on "other" perls than the one that is installed and
to make testing these with modules (like DBI, DBD::Oracle and many many
more, I temporary change my $PATH to have the perl I am testing first
In that perl, App::Ack is NOT (yet) installed.
For some/many scripts, it doesn't really matter if the script is
installed or not, but for all scripts that invoke modules it *does*
matter.
I certainly do NOT see this change as "more modern"
Perl has been configured to use $Config{startperl}. Use it!
$ perl -V:startperl
startperl='#!/pro/bin/perl';
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Problems with DBI 1.617_903 on MSWin32
le=0
ok 32 - should connect to
dbi:Gofer:transport=null;policy=rush;dsn=DBI:DBM:f_dir=C\:\strawberry\cpan\build\DBI-1.617_903\test_output_4772;dbm_type=SDBM_File;f_lockfile=0
ok 33
ok 34
ok 35
ok 36 - The object isa DBI::st
ok 37
ok 38
ok 39
ok 40
ok 41
ok 42
ok 43 - go_response executed flag should be true
ok 44
ok 45
ok 46
ok 47
# Testing go_request_count and caching of simple values
ok 48
ok 49
ok 50
# use_remote=0 (policy=rush, transport=null) HASH(0x3166ab0)
ok 51# Looks like you failed 1 test of 57.
ok 52
ok 53
ok 54 # skip caching of metadata methods returning sth not yet implemented
ok 55 # skip caching of metadata methods returning sth not yet implemented
ok 56
ok 57
1..57
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/57 subtests
(less 4 skipped subtests: 52 okay)
Test Summary Report
---
t\85gofer.t (Wstat: 256 Tests: 57 Failed: 1)
Failed test: 5
Non-zero exit status: 1
Files=1, Tests=57, 0 wallclock secs ( 0.06 usr + 0.02 sys = 0.08 CPU)
Result: FAIL
C:\strawberry\cpan\build\DBI-1.617_903>
I see:
#
dbi:Gofer:transport=null;policy=rush;dsn=DBI:DBM:f_dir=C\:\strawberry\cpan\build\DBI-1.617_903\test_output_4772;dbm_type=SDBM_File;f_lockfile=0
f_dir => test_dir (),
test_dir () uses the correct syntax for Windows, and will return
C:\strawberry\cpan\build\DBI-1.617_903\test_output_6836
or alike, but that should be passed to f_dir with forward slashes?
my @remote_dsns = DBI->data_sources( "dbi:DBM:", {
dbm_type => $opt_dbm,
f_lockfile => 0,
f_dir => test_dir() } );
The first entry is
DBI:DBM:f_dir=C\:\strawberry\cpan\build\DBI-1.617_903\test_output_6016;dbm_type=SDBM_File;f_lockfile=0
Is the DSN parser seeing those \'s as escapes to be able to escape
the ':' in C: ?
If you'd move the f_dir assignment from
my @remote_dsns = DBI->data_sources( "dbi:DBM:", {
dbm_type => $opt_dbm,
f_lockfile => 0,
} );
to
my $dbh = DBI->connect($dsn, undef, undef, { RaiseError => 1, PrintError =>
0, ShowErrorStatement => 1, f_dir => test_dir() } );
die "$test_run_tag aborted: $DBI::errstr\n" unless $dbh; # no point
continuing
ok $dbh, sprintf "should connect to %s", $dsn;
all tests pass
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Should we be updating dbipport.h before next release
On Tue, 14 Feb 2012 14:06:30 +, "Martin J. Evans" wrote: > Should we be updating dbipport.h before next release. I think yes, as the latest release only *add*s features, so there should be no backward compat issues > I'll do it we think it should be done. I believe we have 3.19 and > 3.20 is available. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle
On Fri, 10 Feb 2012 17:28:11 +, Charles Jardine wrote: > >> If this reproduces the problem, you have something nothing to do > >> with databases to investigate. If it doesn't reproduce the problem, > >> it may be that Oracle is messing with the SIGCHLD signal. > >> > >> Are you connecting directly to the database using the bequeather? > > > > I've never heard of anything called a "bequeather" :) > > If you call $ORACLE_HOME/bin/adapters, the list will include 'BEQ'. > This is the bequeather, which is the adapter used to connect to > a local database when ORACLE_HOME and ORACLE_SID are specified > and TWO_TASK is not. The BEQ adapter is inconsistent with the > with perl built-ins which use fork or popen unless you put > 'bequeath_detach = yes' in sqlnet.ora. It is a pity that this > sqlnet.ora option is not the default. All tests then pass -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle
On Fri, 10 Feb 2012 10:22:20 -0500, Yanick Champoux wrote: > On 02/10/12 09:56, Yanick Champoux wrote: > > which should be okay, but I'm suddenly thinking: on some shells > > 'exit' might not do what we would expect. Indeed, I just tried: > > > > $ perl -E'say system "exit 1"' > > -1 > > And just to keep things interesting, I've noticed that I forgot the > ending semi-colon that is in the test. But surely that won't-- > > $ perl -E'say system "exit 1"; say system "exit 1;"' > -1 > 256 % perl -E'say system "exit 1"; say system "exit 1;"' -1 256 > --make a difference... Uuuh, okay, I need to brush up my shell > syntax skills. And should probably look into making that test slightly > less shell-dependent. > > Joy, > `/anick -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle
On Fri, 10 Feb 2012 09:56:59 -0500, Yanick Champoux
wrote:
> On 02/10/12 09:30, Charles Jardine wrote:
> >> > t/10general.t Dubious, test returned 2 (wstat 512, 0x200)
> > This symptom indicates that the system built-in function is not working.
> >
> > Try
> >
> > perl -e 'print system("exit 1;"), "\n"'
>
> Hmmm... The test that is failing is
>
> is system("exit 1;"), 1<<8, 'system exit 1 should return 256';
>
> which should be okay, but I'm suddenly thinking: on some shells
> 'exit' might not do what we would expect. Indeed, I just tried:
My shell is not what most people use:
% echo $SHELL $version
/pro/bin/tcsh tcsh 6.17.02 (Astron) 2010-05-12 (x86_64-unknown-linux) options
wide,nls,vi,kan,rh,color,ccat,filec,procura
% perl -E'say system "exit 1"'
-1
% perl -E'say system "exit 0"'
-1
% perl -E'say system "exit -1"'
-1
% echo $status
0
> $ perl -E'say system "exit 1"'
> -1
>
> And yet the tests usually pass on my machine. I have to look at
> that in more details...
>
> Joy,
> `/anick
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle
On Fri, 10 Feb 2012 14:30:03 +, Charles Jardine
wrote:
> On 10/02/12 13:32, H.Merijn Brand wrote:
> > Preparing a new database machine ...
> >
> > Do I need to worry?
> > t/10general.t 1/30
> > # Failed test 'system exit 1 should return 256'
> > # at t/10general.t line 41.
> > # got: '-1'
> > # expected: '256'
> >
> > # Failed test 'system exit 0 should return 0'
> > # at t/10general.t line 42.
> > # got: '-1'
> > # expected: '0'
> > t/10general.t 3/30 # Looks like you failed 2 tests of 30.
> > t/10general.t Dubious, test returned 2 (wstat 512, 0x200)
>
> This symptom indicates that the system built-in function is not working.
>
> Try
>
> perl -e 'print system("exit 1;"), "\n"'
$ perl -e 'print system("exit 1;"), "\n"'
256
> If this reproduces the problem, you have something nothing to do
> with databases to investigate. If it doesn't reproduce the problem,
> it may be that Oracle is messing with the SIGCHLD signal.
>
> Are you connecting directly to the database using the bequeather?
I've never heard of anything called a "bequeather" :)
> If so, try connecting via SQL*Net instead. If avoiding the bequeather
> fixes the problem, try putting 'bequeath_detach = yes' in your
> sqlnet.ora file. This should allow you to use the bequeather and
> system at the same time.
above test was without TWO_TASK. Using the listener, I get
All tests successful.
Files=35, Tests=2008, 31 wallclock secs ( 0.40 usr 0.04 sys + 3.69 cusr 1.28
csys = 5.41 CPU)
Result: PASS
PERL_DL_NONLAZY=1 /pro/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
DBD::Oracle
til -lc -lgdbm_compat perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.11.3.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.11.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -L/pro/local/lib -fstack-protector' Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_LONG_DOUBLE USE_PERLIO USE_PERL_ATOF Built under linux Compiled at Jun 23 2011 13:31:44 %ENV: PERL5LIB="/pro/asql/o90D/lib/perl" PERLIO="perlio" @INC: /pro/asql/o90D/lib/perl /pro/lib/perl5/site_perl/5.14.1/x86_64-linux-ld /pro/lib/perl5/site_perl/5.14.1 /pro/lib/perl5/5.14.1/x86_64-linux-ld /pro/lib/perl5/5.14.1 . -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: warnings since last DBI release
On Fri, 03 Feb 2012 15:42:40 +, "Martin J. Evans" wrote: > On 03/02/12 15:16, Tim Bunce wrote: > > On Fri, Feb 03, 2012 at 11:22:19AM +0100, H.Merijn Brand wrote: > >> > >> Warnings (on HP-UX 11.31/5.14.2-64all-ld) *in* last release: > >> > >> "DBI.xs", line 1469: warning #4232-D: conversion from "XPVHV *" to a more > >>strictly aligned type "XPVMG *" may cause misaligned access > >> "DBI.xs", line 2582: warning #4232-D: conversion from "XPVHV *" to a more > >>strictly aligned type "XPVMG *" may cause misaligned access > >> "DBI.xs", line 2587: warning #4232-D: conversion from "XPVHV *" to a more > >>strictly aligned type "XPVMG *" may cause misaligned access > > > > Not sure what to do about those. > > They are not DBI ones, they are the Perl macro HvKEYS - on HPUX. Might want > mentioning on p5p - I think Merijn was thinking about doing that. I did. No reply yet. > >> "DBI.xs", line 4486: warning #2181-D: argument is incompatible with > >>corresponding format string conversion > >>NULL, > > > > Does adding a (void*) in front silence that one? > > Merijn discovered it does and it appears something redefines NULL as 0L > somewhere. And yes, (void *)NULL removes the warning. Note that this is a 64bitall build. I had no time to trace the exact location of the define to 0L, but it might be related. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: warnings since last DBI release
On Fri, 03 Feb 2012 10:04:28 +, "Martin J. Evans"
wrote:
> In file included from ODBC.c:70:
> /usr/local/lib/perl/5.10.1/auto/DBI/Driver_xst.h: In function
> ‘dbdxst_bind_params’:
> /usr/local/lib/perl/5.10.1/auto/DBI/Driver_xst.h:72: warning: passing
> argument 2 of ‘imp_sth->com.std.dbistate->set_err_char’ from incompatible
> pointer type
> /usr/local/lib/perl/5.10.1/auto/DBI/Driver_xst.h:72: note: expected ‘struct
> imp_xxh_t *’ but argument is of type ‘struct imp_sth_t *’
> /usr/local/lib/perl/5.10.1/auto/DBI/Driver_xst.h: In function
> ‘dbdxst_fetchall_arrayref’:
> /usr/local/lib/perl/5.10.1/auto/DBI/Driver_xst.h:98: warning: passing
> argument 2 of ‘imp_sth->com.std.dbistate->set_err_char’ from incompatible
> pointer type
> /usr/local/lib/perl/5.10.1/auto/DBI/Driver_xst.h:98: note: expected ‘struct
> imp_xxh_t *’ but argument is of type ‘struct imp_sth_t *’
> cc -c -I/usr/include -I. -I/usr/local/lib/perl/5.10.1/auto/DBI -D_REENTRANT
> -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g
> -DVERSION=\"1.34_3\" -DXS_VERSION=\"1.34_3\" -fPIC
> "-I/usr/lib/perl/5.10/CORE" -I/usr/include dbdimp.c
>
> It is 2 added calls to DBIh_SET_ERR_CHAR in Driver_xst.h.
Warnings (on HP-UX 11.31/5.14.2-64all-ld) *in* last release:
"DBI.xs", line 1469: warning #4232-D: conversion from "XPVHV *" to a more
strictly aligned type "XPVMG *" may cause misaligned access
PerlIO_printf(DBILOGFP,"%s CachedKids %d\n", pad,
(int)HvKEYS(hv));
^
"DBI.xs", line 2582: warning #4232-D: conversion from "XPVHV *" to a more
strictly aligned type "XPVMG *" may cause misaligned access
if (HvKEYS(hv)) {
^
"DBI.xs", line 2587: warning #4232-D: conversion from "XPVHV *" to a more
strictly aligned type "XPVMG *" may cause misaligned access
meth_name, neatsvpv(h,0), (int)HvKEYS(hv));
^
"DBI.xs", line 4486: warning #2181-D: argument is incompatible with
corresponding format string conversion
NULL,
^
All tests pass though
1465if (DBIc_TYPE(imp_xxh) <= DBIt_DB) {
1466SV **svp = hv_fetch((HV*)SvRV(inner), "CachedKids", 10, 0);
1467if (svp && SvROK(*svp) && SvTYPE(SvRV(*svp)) == SVt_PVHV) {
1468HV *hv = (HV*)SvRV(*svp);
1469PerlIO_printf(DBILOGFP,"%s CachedKids %d\n", pad,
(int)HvKEYS(hv));
1470}
1471}
2576clear_cached_kids(pTHX_ SV *h, imp_xxh_t *imp_xxh, const char
*meth_name, int trace_level)
2577{
2578if (DBIc_TYPE(imp_xxh) <= DBIt_DB) {
2579SV **svp = hv_fetch((HV*)SvRV(h), "CachedKids", 10, 0);
2580if (svp && SvROK(*svp) && SvTYPE(SvRV(*svp)) == SVt_PVHV) {
2581HV *hv = (HV*)SvRV(*svp);
2582if (HvKEYS(hv)) {
2583if (DBIc_TRACE_LEVEL(imp_xxh) > trace_level)
2584trace_level = DBIc_TRACE_LEVEL(imp_xxh);
2585if (trace_level >= 2) {
2586PerlIO_printf(DBIc_LOGPIO(imp_xxh),">> %s %s
clearing %d CachedKids\n",
2587meth_name, neatsvpv(h,0), (int)HvKEYS(hv));
2588PerlIO_flush(DBIc_LOGPIO(imp_xxh));
2589}
2590/* This will probably recurse through dispatch to
DESTROY the kids */
2591/* For drh we should probably explicitly do dbh
disconnects */
2592hv_clear(hv);
2593}
2594}
2595}
2596}
4476if (level != RETVAL) {
4477if ((level & DBIc_TRACE_LEVEL_MASK) > 0) {
4478PerlIO_printf(DBILOGFP,"DBI %s%s default trace level
set to 0x%lx/%ld (pid %d pi %p) at %s\n",
4479XS_VERSION, dbi_build_opt,
4480(long)(level & DBIc_TRACE_FLAGS_MASK),
4481(long)(level & DBIc_TRACE_LEVEL_MASK),
4482(int)PerlProc_getpid(),
4483#ifdef MULTIPLICITY
4484(void *)my_perl,
4485#else
4486 NULL,
4487#endif
4488log_where(Nullsv, 0, "", "", 1, 1, 0)
4489);
4490if (!PL_dowarn)
4491PerlIO_printf(DBILOGFP,"Note: perl is running
without the recommended perl -w option\n");
4492PerlIO_flush(DBILOGFP);
4493}
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Any reason not to make a new DBI release?
On Sat, 28 Jan 2012 10:41:56 +, Tim Bunce wrote: > I'd like to make a formal DBI release soon. > > DBI-1.616_901 tested well and I've just uploaded DBI-1.616_902. > > Any reason I shouldn't upload as DBI-1.617 soon? No objections from me. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Move rt 69864 to DBD::ODBC
On Tue, 29 Nov 2011 10:46:17 +, "Martin J. Evans" wrote: > https://rt.cpan.org/Ticket/Display.html?id=69864 > > Could someone with the permission to do so move rt 69864 from DBI to DBD:ODBC. Done > Martin -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: [svn:dbi] r14993 - dbi/trunk/ex
On Wed, 16 Nov 2011 19:59:30 +, Tim Bunce
wrote:
> On Sun, Nov 13, 2011 at 02:07:25PM +0100, H.Merijn Brand wrote:
> > On Sun, 13 Nov 2011 10:42:34 +, Tim Bunce ,
> > "H.Merijn Brand" wrote:
> >
> > > On Thu, Nov 10, 2011 at 09:15:43AM -0800, hmbr...@cvs.perl.org wrote:
> > > > +} elsif ($driver eq 'Unify') {
> > > > +# Unify does not have varchar
> > > > +$h->{ChopBlanks} = 1;
> > >
> > > Why ChopBlanks? Worth a # comment.
> >
> > I thought that the comment "Unify does not have varchar" was clear
> > enough. Unify only has "char", so when fetching a char(20) field where
> > only two characters were stored, you'll get it space-padded to 20 back.
>
> Ah, right. I didn't connect the two.
Feel free to extend on that comment if you still think it is not enough
sufficient
> > > > +$blob_column_type = 'binary';
> > > > +$unicode_column_type = 'char'; # or text
> > > > +$h->{uni_unicode} = 1; # Available in the upcoming 0.81
> > > > +$length_fn = 'undefined'; # I don't think Unify has a function
> > > > like this
> > >
> > > You can't ask Unify for the length of a string? Really?
> >
> > I didn't find it in the docs. really
>
> Wow. Can you give me a link to the docs? I'm curious. I've never looked
> at Unify SQL before.
http://unify.com/Products/Data_Management/DataServer/default.aspx
http://unify.com/Products/Data_Management/DataServer/DataServer9.1.pdf
http://support.unify.com/Docs/UnifyDocs/products/dataserver/documentation/dsOLmans.pdf
=> Unify dataServer: SQL/A Reference page #17
I must add that all of our customers - and thus my DBD::Unify - is
still at DataServer version 8.x, but 9.x has no length function either
> > > > sub do_connect {
> > > > -my ($dsn, $user, $pass, %attr);
> > > > -if (@ARGV) {
> > > > -# eg unicode_test.pl
> > > > "dbi:Pg(AutoCommit=0):host=example.com;port=6000;db=name" user pass
> > > > -($dsn, $user, $pass) = @ARGV;
> > > > -}
> > >
> > > Please restore that behaviour. Having people hard-code their own won't
> > > scale well.
> >
> > That behavior is still valid if you call it like that
>
> Ah, I missed the + my ($dsn, $user, $pass, %attr) = @ARGV; line in the
> patch. I'm sorry for my cursory skimming and terse replies. I'm rather
> distracted at the moment.
>
> > > > +$user //= $ENV{DBI_USER} // undef;
> > > > +$pass //= $ENV{DBI_PASS} // undef;
> > >
> > > Please avoid //= etc. The test scripts should be runnable with older
> > > perls.
> >
> > This script was for analysis only, not for inclusion in the test suite.
>
> Sure. I'd like people to be able to run it on older perls though.
> I'll change it.
No problem. I thought it to be of now harm in this stage.
And I would *STRONGLY* advice anyone to use Unicode with perl below
5.8.4 anyway :) [as a restriction to 'older' perls]. All my 5.8.x do
have define-or build in, so I'm kind of used to that by now :)
> Thanks.
> Tim.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: [svn:dbi] r14993 - dbi/trunk/ex
On Sun, 13 Nov 2011 10:42:34 +, Tim Bunce ,
"H.Merijn Brand" wrote:
> On Thu, Nov 10, 2011 at 09:15:43AM -0800, hmbr...@cvs.perl.org wrote:
> > +} elsif ($driver eq 'Unify') {
> > +# Unify does not have varchar
> > +$h->{ChopBlanks} = 1;
>
> Why ChopBlanks? Worth a # comment.
I thought that the comment "Unify does not have varchar" was clear
enough. Unify only has "char", so when fetching a char(20) field where
only two characters were stored, you'll get it space-padded to 20 back.
> > +$blob_column_type = 'binary';
> > +$unicode_column_type = 'char'; # or text
> > +$h->{uni_unicode} = 1; # Available in the upcoming 0.81
> > +$length_fn = 'undefined'; # I don't think Unify has a function
> > like this
>
> You can't ask Unify for the length of a string? Really?
I didn't find it in the docs. really
> > sub do_connect {
> > -my ($dsn, $user, $pass, %attr);
> > -if (@ARGV) {
> > -# eg unicode_test.pl
> > "dbi:Pg(AutoCommit=0):host=example.com;port=6000;db=name" user pass
> > -($dsn, $user, $pass) = @ARGV;
> > -}
>
> Please restore that behaviour. Having people hard-code their own won't
> scale well.
That behavior is still valid if you call it like that
> > +$user //= $ENV{DBI_USER} // undef;
> > +$pass //= $ENV{DBI_PASS} // undef;
>
> Please avoid //= etc. The test scripts should be runnable with older perls.
This script was for analysis only, not for inclusion in the test suite.
> > +$h->commit if $driver eq 'Unify';
>
> > return lives_ok {
> > +diag ($sql);
> > my $s = $h->prepare($sql);
> > $s->execute;
> > + $dbd eq "DBD::Unify" and $h->commit;
>
> Better as:
>
> +$h->commit if $driver eq 'Unify';
in the eye of the beholder. I /did/ try to use the style used, but
personally I *never* use statement modifiers. It doesn't fit to my
mind. When taking over someone else's code, this is - next to layout
and indents - the first thing to correct.
to me
expression and action;
reads MUCH better than
action if expression;
> for consistency with the others.
that's what I said. Sorry i missed that. I tried.
> Thanks!
>
> Tim.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Add Unicode Support to the DBI
VARBINARY
[ -2 => "BINARY" ], # SQL_BINARY
[ -1 => "TEXT"], # SQL_LONGVARCHAR
[ 0 => "UNKNOWN_TYPE"], # SQL_UNKNOWN_TYPE
[ 1 => "CHAR"], # SQL_CHAR
[ 2 => "NUMERIC" ], # SQL_NUMERIC
[ 3 => "DECIMAL" ], # SQL_DECIMAL
[ 4 => "INTEGER" ], # SQL_INTEGER
[ 5 => "SMALLINT"], # SQL_SMALLINT
[ 6 => "FLOAT" ], # SQL_FLOAT
[ 7 => "REAL"], # SQL_REAL
[ 8 => "DOUBLE PRECISION"], # SQL_DOUBLE
[ 9 => "DATE"], # SQL_DATE
[ 10 => "TIME"], # SQL_TIME
[ 11 => "TIMESTAMP" ], # SQL_TIMESTAMP
[ 12 => "VARCHAR" ], # SQL_VARCHAR
[ 16 => "BOOLEAN" ], # SQL_BOOLEAN
[ 19 => "ROW" ], # SQL_ROW
[ 20 => "REF" ], # SQL_REF
[ 30 => "BLOB"], # SQL_BLOB
[ 40 => "CLOB"], # SQL_CLOB
;
$odbc_types{DOUBLE} = $odbc_types{"DOUBLE PRECISION"};
my %uni_types = map { ( $_->[0] => $_->[1], $_->[1] => $_->[0] ) }
[ -18 => "CURRENCY"], # SQLAMT64
[ -17 => "HUGE INTEGER"], # SQLINT64
[ -12 => "BYTE"], # SQLBYTE
[ -11 => "HUGE DATE" ], # SQLHDATE
[ -10 => "BINARY" ], # SQLBINARY
[ -9 => "TEXT"], # SQLTEXT
[ -7 => "TIME"], # SQLSMTIME
[ -6 => "HUGE AMOUNT" ], # SQLHUGEAMT
[ -4 => "AMOUNT" ], # SQLAMOUNT
[ -3 => "DATE" ], # SQLDATE
[ 0 => "NOTYPE" ], # SQLNOTYPE
[ 1 => "CHAR"], # SQLCHAR
[ 2 => "NUMERIC" ], # SQLNUMERIC
[ 3 => "DECIMAL" ], # SQLDECIMAL
[ 4 => "INTEGER" ], # SQLINTEGER
[ 5 => "SMALLINT"], # SQLSMINT
[ 6 => "FLOAT" ], # SQLFLOAT
[ 7 => "REAL"], # SQLREAL
[ 8 => "DOUBLE PRECISION"], # SQLDBLPREC
;
$uni_types{CHARACTER} = $uni_types{CHAR};
$uni_types{DOUBLE}= $uni_types{"DOUBLE PRECISION"};
sub odbc_type
{
my $t = shift;
defined $t or return 0;
$t = $odbc_types{uc $t} || $t;
return $t;
} # uni_type
sub uni_type
{
my $t = shift;
defined $t or return 0;
$t = $uni_types{uc $t} || $t;
return $t;
} # uni_type
-->8---
which shows I have set up the DATA_TYPE, not the SQL_DATA_TYPE
shall I just copy DATA_TYPE to SQL_DATA_TYPE?
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Add Unicode Support to the DBI
On Wed, 09 Nov 2011 19:41:33 +, "Martin J. Evans" wrote: tl;dr; > On 09/11/2011 15:49, H.Merijn Brand wrote: > > On Tue, 08 Nov 2011 21:12:13 +, "Martin J. Evans" > > wrote: > > > >> I've just checked in unicode_test.pl to DBI's subversion trunk in /ex dir. > >> > >> It won't run right now without changing the do_connect sub as you have > >> to specify how to connect to the DB. > >> Also, there is a DBD specific section at the start where you might have > >> to add a DBD it does not know about (anything other than DBD::ODBC, > >> DBD::Oracle, DBD::SQLite, DBD::CSV, DBD::mysql) if it needs something > >> other than the defaults e.g., the name of the length function in SQL, > >> the column type for unicode columns and binary columns, the setting to > >> enable UTF8/Unicode support. It could be a bit of a pain if your DBD > >> does not support type_info_all but I'm around on irc and in this list if > >> anyone wants any help making it work. > >> > >> It needs rather a lot of tidying up so I'm not putting it forward as > >> code-of-the-year but it is a start. > >> > >> BTW, you'll need Test::More::UTF8 and perhaps a couple of other non core > >> modules to run it. > >> > >> Martin > > I'll have some deeper look at both Unify and CSV ... > > Attached is a revised version of the script (first argument is the > > driver to test, some need more work) > > > > $ perl /tmp/unicode_test.pl Unify > > # Driver DBD::Unify-0.78 > > # Using DBMS_NAME 'Unify DataServer' > > # Using DBMS_VER undef > > # Using DRIVER_NAME '/pro/asql/v83I/lib/perl/5.10.1/DBD/Unify.pm' > > # Using DRIVER_VER '00.78.' > > # SQL_IDENTIFIER_CASE 3 > > # LANGDIR = dutch > > print() on closed filehandle $fh at /tmp/unicode_test.pl line 438. > > Use of uninitialized value in concatenation (.) or string at > > /tmp/unicode_test.pl line 421. > > Use of uninitialized value in concatenation (.) or string at > > /tmp/unicode_test.pl line 421. > > # Found type (HUGE AMOUNT) size= > > Use of uninitialized value in string eq at /tmp/unicode_test.pl line 422. > > Use of uninitialized value in concatenation (.) or string at > > /tmp/unicode_test.pl line 421. > > Use of uninitialized value in concatenation (.) or string at > > /tmp/unicode_test.pl line 421. > > # Found type (AMOUNT) size= > > Use of uninitialized value in string eq at /tmp/unicode_test.pl line 422. > > Use of uninitialized value in concatenation (.) or string at > > /tmp/unicode_test.pl line 421. > > Use of uninitialized value in concatenation (.) or string at > > /tmp/unicode_test.pl line 421. > > # Found type (BINARY) size= > > Use of uninitialized value in string eq at /tmp/unicode_test.pl line 422. > > Use of uninitialized value in concatenation (.) or string at > > /tmp/unicode_test.pl line 421. > > : > > : > > # Found type (TIME) size= > > Use of uninitialized value in string eq at /tmp/unicode_test.pl line 422. > > DBD::Unify::db prepare failed: Syntax error in SQL dynamic statement. [for > > Statement "create table fredĀ ( a int)"] at /tmp/unicode_test.pl line 214. > > not ok 1 - unicode table name supported > > # Failed test 'unicode table name supported' > > # at /tmp/unicode_test.pl line 216. > > # died: DBD::Unify::db prepare failed: Syntax error in SQL dynamic > > statement. [for Statement "create table fredÄ ( a int)"] at > > /tmp/unicode_test.pl line 214. > > ok 2 # skip Failed to create unicode table name > > ok 3 # skip Failed to create unicode table name > > DBD::Unify::db prepare failed: Syntax error in SQL dynamic statement. [for > > Statement "create table fred ( daveĀ int)"] at /tmp/unicode_test.pl line > > 214. > > not ok 4 - unicode column name supported > > Your going to have a lot of problems with this test code and DBD::Unify > as we previously discovered that DBD::Unify does not decode the data I can change that as author and maintainer of this driver (if I want) > coming back from the database itself but it can be decoded by any Perl > script using DBD::Unify into the correct data. Any chance you could > change the test code to print out the results of type_info_all for > DBD::Unify and send me them? # Driver DBD::Unify-0.78 # Using DBMS_NAME 'Unify DataServer' # Using DBMS_VER undef # Using DRIVER_NAME '/pro/asql/v83I/lib/perl/5.10.1/DBD/Unify.pm' # Us
Re: Add Unicode Support to the DBI
On Wed, 9 Nov 2011 16:23:53 +, Tim Bunce wrote: > On Wed, Nov 09, 2011 at 04:50:29PM +0100, H.Merijn Brand wrote: > > On Tue, 08 Nov 2011 21:12:13 +, "Martin J. Evans" > > wrote: > > > > > I've just checked in unicode_test.pl to DBI's subversion trunk in /ex dir. > > > > So now attached > > Any chance you could rework your changes into the (recently updated) > version in the DBI svn repo? Yes, after I verify why DBD::Unify messes up on this (FWIW, the number of Unify customers is getting smaller and smaller, so the motivation to improve on DBD::Unify is diminishing) > Tim. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Add Unicode Support to the DBI
On Tue, 08 Nov 2011 21:12:13 +, "Martin J. Evans" wrote: > I've just checked in unicode_test.pl to DBI's subversion trunk in /ex dir. So now attached -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ unicode_test.pl Description: Perl program
Re: Add Unicode Support to the DBI
marker' # at /tmp/unicode_test.pl line 392. # died: DBD::SQLite::st bind_param failed: Unknown named parameter: fred⬠[for Statement "insert into fred (a) values (:fredâ¬)"] at /tmp/unicode_test.pl line 390. 1..20 # Looks like you failed 1 test of 20. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Add Unicode Support to the DBI
On Tue, 8 Nov 2011 13:16:17 +, Tim Bunce wrote: > On Mon, Nov 07, 2011 at 01:37:38PM +, Martin J. Evans wrote: > > > > > > I didn't think I was going to make LPW but it seems I will now - > > > although it has cost me big time leaving it until the last minute. > > All your beers at LPW are on me! > > > http://www.martin-evans.me.uk/node/121 > > Great work Martin. Many thanks. I more and more regret I cannot be there. Please, beside doing useful stuff, have FUN! -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle v1.32 and v1.33_00 on their way to CPAN
On Tue, 18 Oct 2011 13:15:58 -0400, Yanick Champoux
wrote:
> Hi all,
>
> As no issue has been found with DBD::Oracle v1.31_00, it has been
> promoted to v1.32 and is on its way to CPAN.
With a perl configured with -Duselongdouble:
This is perl 5, version 14, subversion 1 (v5.14.1) built for i686-linux-64int-ld
Installing on a linux, Ver#2.6
Using Oracle in /usr/lib/oracle/11.2/client
DEFINE _SQLPLUS_RELEASE = "1102000200" (CHAR)
Oracle version 11.2.0.2 (11.2)
SQL*Plus: Release 11.2.0.2.0 Production on Fri Oct 21 16:48:54 2011
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
t/58object.t 5/65
# Failed test 'new: Row 1 column 2 object attributes'
# at t/58object.t line 177.
# Structures begin differing at:
# $got->[7] = '12345.6788'
# $expected->[7] = '12345.6789'
# Failed test 'new: Row 1 column 2 object attributes'
# at t/58object.t line 184.
# Structures begin differing at:
# $got->[7] = '777.6660054'
# $expected->[7] = '777.666'
# Failed test 'DBD::Oracle::Object->attr_hash'
# at t/58object.t line 199.
# Structures begin differing at:
# $got->{AMOUNT} = '777.6660054'
# $expected->{AMOUNT} = '777.666'
# Failed test 'DBD::Oracle::Object->attr'
# at t/58object.t line 200.
# Structures begin differing at:
# $got->{AMOUNT} = '777.6660054'
# $expected->{AMOUNT} = '777.666'
# Looks like you failed 4 tests of 65.
t/58object.t Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/65 subtests
Test Summary Report
---
t/58object.t (Wstat: 1024 Tests: 65 Failed: 4)
Failed tests: 41, 45, 47-48
Non-zero exit status: 4
Files=33, Tests=2525, 23 wallclock secs ( 0.42 usr 0.04 sys + 3.38 cusr 0.56
csys = 4.40 CPU)
Result: FAIL
Failed 1/33 test programs. 4/2525 subtests failed.
> Also, the next trial version v1.33_00 is also to appear in a few
> instants. The changelog is small and deal mostly with doc changes:
>
> Changes in DBD-Oracle 1.33_00 (18-10-2011)
>
> [BUG FIXES]
> - COLUMN_SIZE of VARCHAR2 returns size in chars, not bytes. [RT#13865]
> (reported by Stefano and Laurent Dami)
>
> [DOCUMENTATION]
> - add mention of the github mirror of the subversion repository
> - add 'resources' info to META.yml
> - fixed broken link to Oracle DRCP doc in POD (John Scoles)
>
>
> As usual, if you are so inclined, please test and provide feedback.
> Unless issues are found, this load should be promoted for general
> consumption in 2 weeks.
>
> Joy,
> `/anick
>
> --
> Pythian proud winner of Oracle North America Titan Award for Exadata
> Solution... Read more & see us at OpenWorld bit.ly/pythianoow11
>
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Add Unicode Support to the DBI
On Tue, 04 Oct 2011 23:24:51 +0100, "Martin J. Evans" wrote: > Some might disagree but DB2 is a main > one I no longer have access to (please contact me if you use DBD::DB2 > and are prepared to spare half an hour or so to modify examples I have > which verify unicode support). Of course, if you use another DBD and can > send me info on unicode support I'd love to hear from you. There are two DB2 users on PerlMonks, who are rather helpful in testing areas. Ask [Tanktalus] & [talexb] :) $ grep -i -w db2 < "30 FreeNode-#cbstream.log" | grep -i -e unicode -e utf Sep 30 19:28:20 [Tanktalus] /me contemplates how to get unicode strings back out of db2 ... Feb 27 16:29:01 [talexb] /me returns to fiddling with utf-8 in DB2. Mar 06 17:56:26 [talexb] [Tanktalus]: Hey, looks like I solved the utf-8 DB2 problem .. just increase the field to 3n from n and it seems to work. Dec 16 21:19:11 [Tanktalus] The DB does. Thus, I would expect that the DBD *could* request data in whatever encoding it wants. And since it would want utf8 to mesh with Perl properly, and every encoding that DB2 supports has a mapping to utf8, this should be doable. Dec 16 21:25:24 [Tanktalus] [ambrus]: yeah, I would like to see it as "mandatory" for byte strings that are already utf-8 (which the DBD driver should be able to tell trivially, at least on DB2), or for connections/statements/something where said decoding was requested. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: New NestedHash module needs home
On Mon, 12 Sep 2011 17:29:57 +, "Byrd, Brendan" wrote: > DBD::NestedHash - This could also be its own Perl module within CPAN. > However, the hash to table conversion is such a thin wrapper around > DBD::AnyData that it just seems to make more sense to actually tie it > into that module somehow, so that developers can benefit from the > integration. Feel free to loan/borrow/steal from my Tie::Hash::DBD, which supports nested hashes using a serializer -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBI drivers by duck-typing
On Mon, 12 Sep 2011 19:23:02 -0700, Darren Duncan wrote: > Fundamentally I propose an inversion of control, where users invoke DBD > modules > directly that optionally invoke or compose DBI to help them, rather than > users > invoking DBI that uses DBD modules to help it. The other stuff flows from > that. The whole idea seems to make it unavoidable that all well functioning DBD modules have to be rewritten or changed, copying (big) parts of an extremely well functioning DBI module. The way DBI currently works, and the (restricted/restrictive) functionality it gives DBD authors has made it possible that there so many well functioning DBD's currently available. I for one know how much time has been involved in writing DBD's and I would certainly not jump for joy if I had to re-invest that time to (re)write my DBD's to match the new API. I have neither the time nor the tuits for that. I write DBD::Unify after having a buggy but functional integrated version in perl4, but waited SEVEN (7) years before writing DBD::Unify for DBI hoping wholeheartedly someone else would do it instead. The power of the current DBI - as it stands - is that it enables me to write *PORTABLE* perl scripts that work *without modification* on Oracle, Unify, MySQL, MariaDB, SQLite and CSV and probably other db's that I do not use. The fact that the DBI is restrictive (or restricted) is a good thing. First of all most of the restrictions are based on well thoughtthrough decisions based on speed and use of resources. I do not have to take those decisions again when implementing a DBD. The whole infrastructure is there just for grabs, which is the second point. Even though possibly I could have written some of that code more efficiently in the DBD directly, I will not have the maintenance burden for that code, not do I have to verify that the code is working correctly. I have all other DBD's do that with - and for me. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Add Unicode Support to the DBI
On Sat, 10 Sep 2011 03:06:49 -, "Greg Sabino Mullane" wrote: > One thing I see bandied about a lot is that Perl 5.14 is highly preferred. > However, it's not clear exactly what the gains are and how bad 5.12 is > compared to 5.14, how bad 5.10 is, how bad 5.8 is, etc. Right now 5.8 is > the required minimum for DBI: should we consider bumping this? I know TC > would be horrified to see us attempting to talk about Unicode support > with a 5.8.1 requirement, but how much of that will affect database > drivers? I have no idea myself. Unicode-6.0 and Unicode improvements in general are *THE* reason for me (our company) to plan for a 5.10.1 -> 5.14.2 update I use Unicode a lot, and we require 5.8.4 as an absolute minimum when dealing with Unicode. 5.8.1 is not good enough. > Another aspect to think about that came up during some offline DBD::Pg > talks was the need to support legacy scripts and legacy data. While the > *correct* thing is to blaze forward and use Do Things Correctly everywhere, > I think we at least need some prominent knobs so that we can maintain > backwards compatiblity for existing scripts that expect a bunch of > Latin1, or need the data to come back in the current, undecoded, > un-utf8-flagged way. > > - -- > Greg Sabino Mullane g...@turnstep.com -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: mo prefix request
On Thu, 11 Aug 2011 21:53:36 +0200, "Steffen Winkler"
wrote:
> Thank you, but there is mistake in trunk/DBI.pm
>
>,--- should be a "m"
> v
> 330: po_ => { class => 'DBD::MO', },
> 342: po_ => { class => 'DBD::PO', },
Oh my! yank-put failure. fixed now
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: mo prefix request
On Thu, 11 Aug 2011 07:28:00 +0200, "Steffen Winkler" wrote: > Hallo together, > > that is a good idea to register a prefix. > To ask is better than me during creating DBD::PO and the picked 'po_'. > I apologize for. > > I ask now for register 'mo_' for DBD::MO. > That is my plan with some work for basic module I use for. > At the end I renew DBD::PO too. Done. Good luck with the implementation! Saved working directory and index state WIP on master: 171528f Register mo_ for DBD::MO HEAD is now at 171528f Register mo_ for DBD::MO Committing to http://svn.perl.org/modules/dbi/trunk ... M DBI.pm Committed r14915 M DBI.pm r14915 = 37442e771cf742ffd2780cff902281ff2b567b4a (refs/remotes/git-svn) -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Spatialite prefix request
On Wed, 10 Aug 2011 00:42:05 -0700, Lokkju Brennr wrote: > Ok, I think I misunderstood - were you trying to tell me you had gone > ahead and made the change, not that it had already been reserved for > some other module? correct. mje is co-maint for DBI > Loki -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Spatialite prefix request
On Wed, 10 Aug 2011 00:37:07 -0700, Lokkju Brennr wrote: > Hmm - ok... I have the Perl DBD::Spatialite namespace with my > DBD::Spatialite driver currently, in CPAN (using x_spatialite_ as a > stopgap). I don't see a DBD::Spatialite in DBI's trunk. There will never be. You are now free to make DBD::Spatialite The driver specific prefix spatialite_ has been reserved to point to DBD::Spatialite, which you now have to provide DBI only bundles with a very few DBD's. Some of those are not to be used standalone (like DBD::File) You won't find a DBD::Oracle or DBD::Pg in DBI's trunk either. > Loki > > On Wed, Aug 10, 2011 at 12:22 AM, Martin J. Evans > wrote: > > On 09/08/11 21:44, Lokkju Brennr wrote: > >> > >> I'm perfectly happy with spatialite_ - it was my original proposal. > >> > >> Loki > > > > spatialite_ is reserved as a driver prefix with the driver > > beingDBD::Spatialite in DBI's trunk in subversion. > > > > Martin > > -- > > Martin J. Evans > > Easysoft Limited > > http://www.easysoft.com > > -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Spatialite prefix request
On Tue, 9 Aug 2011 01:05:40 -, "Greg Sabino Mullane"
wrote:
> > Did you have a prefix in mind that is not already in use? Would 'sl_' be
> > appropriate, for example? You can find the current list of assignments at
> > about line 320 in DBI.pm, and 'sl_' appears to be available. (The longest
> > current prefix is 'monetdb_'; if you requested 'spatialite_' as the prefix,
> > that would be 3 characters longer than the current longest.)
>
> I'd like to see the trend go the other way, and use the full name, just
> like many other DBDs do. Characters are cheap, and "sl" not only gives no
> clue as to what driver is meant to the viewer of code that uses it, but
> risks future collisions as well. So +1 to using 'spatialite_'
+1 from me on spatiale_ too (or spatle_ if you want to stay withing the
current max 6 letters).
sl already means "shared library" (at least on my HP-UX systems), and
I'd never "guess" spatiale from it. Oracle is big enough to make ora_
automatically trigger "Oracle", but MySQL already has 5 letters.
Here is the current full list:
my $dbd_prefix_registry = {
ad_ => { class => 'DBD::AnyData',},
ado_ => { class => 'DBD::ADO',},
amzn_=> { class => 'DBD::Amazon', },
best_=> { class => 'DBD::BestWins', },
csv_ => { class => 'DBD::CSV',},
db2_ => { class => 'DBD::DB2',},
dbi_ => { class => 'DBI', },
dbm_ => { class => 'DBD::DBM',},
df_ => { class => 'DBD::DF', },
f_ => { class => 'DBD::File', },
file_=> { class => 'DBD::TextFile', },
go_ => { class => 'DBD::Gofer', },
ib_ => { class => 'DBD::InterBase', },
ing_ => { class => 'DBD::Ingres', },
ix_ => { class => 'DBD::Informix', },
jdbc_=> { class => 'DBD::JDBC', },
monetdb_ => { class => 'DBD::monetdb',},
msql_=> { class => 'DBD::mSQL', },
mvsftp_ => { class => 'DBD::MVS_FTPSQL', },
mysql_ => { class => 'DBD::mysql', },
mx_ => { class => 'DBD::Multiplex', },
nullp_ => { class => 'DBD::NullP', },
odbc_=> { class => 'DBD::ODBC', },
ora_ => { class => 'DBD::Oracle', },
pg_ => { class => 'DBD::Pg', },
pgpp_=> { class => 'DBD::PgPP', },
plb_ => { class => 'DBD::Plibdata', },
po_ => { class => 'DBD::PO', },
proxy_ => { class => 'DBD::Proxy', },
ram_ => { class => 'DBD::RAM',},
rdb_ => { class => 'DBD::RDB',},
sapdb_ => { class => 'DBD::SAP_DB', },
solid_ => { class => 'DBD::Solid', },
sponge_ => { class => 'DBD::Sponge', },
sql_ => { class => 'DBI::DBD::SqlEngine', },
sqlite_ => { class => 'DBD::SQLite', },
syb_ => { class => 'DBD::Sybase', },
sys_ => { class => 'DBD::Sys',},
tdat_=> { class => 'DBD::Teradata', },
tmpl_=> { class => 'DBD::Template', },
tmplss_ => { class => 'DBD::TemplateSS', },
tuber_ => { class => 'DBD::Tuber', },
uni_ => { class => 'DBD::Unify', },
vt_ => { class => 'DBD::Vt', },
wmi_ => { class => 'DBD::WMI',},
x_ => { }, # for private use
xbase_ => { class => 'DBD::XBase', },
xl_ => { class => 'DBD::Excel', },
yaswi_ => { class => 'DBD::Yaswi', },
};
> Greg Sabino Mullane g...@turnstep.com
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Problem with Perl module DBI-1.616
On Sun, 03 Jul 2011 14:13:00 +, Jens Rehsack
wrote:
> On 07/03/11 14:02, H.Merijn Brand wrote:
> > On Sun, 3 Jul 2011 15:21:04 +0200, Norbert Gruener
> > wrote:
> >
> >> Hi Merijn,
> >>
> >> on the weekend I have upgraded to DBI version 1.616 and afterwards one
> >> of my Perl scripts did not work anymore.
> >>
> >> Please find attached a short script to reproduce my problem. When I
> >> run it I will get the following error message
> >>
> >>Can't use string ("gconfd-nog") as an ARRAY ref while "strict refs"
> >>in use at /usr/local/lib/perl/5.10.0/DBI/DBD/SqlEngine.pm line 688.
> >>
> >>
> >> I have looked into the function 'list_tables' in the module
> >> "DBI::DBD::SqlEngine". The attached patch will fix my problem. Maybe
> >> you can have a look into it to check if this is a proper solution.
> >
> > I'm just a co-maint to DBI, and this is not my area of expertise. I
> > hereby forward the problem to the correct ML.
>
> Attachement missing ;-)
And now?
> > If noone replies with a
> > decent answer, the best next thing to do is to create an RT ticket in
> > the DBI queue
>
> Creating an RT seems to be a good idea to me, otherwise I promise it
> will be lost in dark (of being currently to busy to track mails and IRC).
>
> >> Cheers,
> >>
> >> Norbert
> >
>
> Thanks for contacting Merijn and to Merijn thanks to forwarding.
>
> Jens
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
test
Description: Binary data
dbi-patch
Description: Binary data
Re: Problem with Perl module DBI-1.616
On Sun, 3 Jul 2011 15:21:04 +0200, Norbert Gruener
wrote:
> Hi Merijn,
>
> on the weekend I have upgraded to DBI version 1.616 and afterwards one
> of my Perl scripts did not work anymore.
>
> Please find attached a short script to reproduce my problem. When I
> run it I will get the following error message
>
> Can't use string ("gconfd-nog") as an ARRAY ref while "strict refs"
> in use at /usr/local/lib/perl/5.10.0/DBI/DBD/SqlEngine.pm line 688.
>
>
> I have looked into the function 'list_tables' in the module
> "DBI::DBD::SqlEngine". The attached patch will fix my problem. Maybe
> you can have a look into it to check if this is a proper solution.
I'm just a co-maint to DBI, and this is not my area of expertise. I
hereby forward the problem to the correct ML. If noone replies with a
decent answer, the best next thing to do is to create an RT ticket in
the DBI queue
> Cheers,
>
> Norbert
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Old bug rising with a new head
On Wed, 22 Jun 2011 15:08:47 +0200, "H.Merijn Brand"
wrote:
> http://www.perlmonks.org/?node_id=910793
>
> "You passed $nparm parameters where $n_req required"
>
> Once was a correct fix. Then all moved from DBD::File to
> DBI::DBD::SqlEngine and now SQL::Statement::Param roars its ugly head :)
With the below fix submitted to DBI about a week ago, [planetscape]
found that that breaks something else:
http://www.perlmonks.org/?node_id=911893
I'm going to do some digging, but it shows we need more tests.
> I'd like to suggest the current fix, for which I am convinced is the
> correct solution (unlit backends change again)
>
> I do *not* have a testcase for this as I do not see the impact of
> JOIN's and so here
>
> --8<--- suggested change
> diff --git a/lib/DBI/DBD/SqlEngine.pm b/lib/DBI/DBD/SqlEngine.pm
> index 51f2a0a..bcac88a 100644
> --- a/lib/DBI/DBD/SqlEngine.pm
> +++ b/lib/DBI/DBD/SqlEngine.pm
> @@ -781,7 +781,9 @@ sub execute
> {
> # bug in SQL::Statement 1.20 and below causes breakage
> # on all but the first call
> -unless ( ( my $req_prm = $stmt->params() ) == ( my $nparm = @$params
> ) )
> +my @req_prm = $stmt->params ();
> +my $n_req = @req_prm == 1 && ref $req_prm[0] ? $req_prm[0]->num :
> scalar @req_prm;
> +unless ( $n_req == ( my $nparm = @$params ) )
> {
> my $msg = "You passed $nparm parameters where $req_prm required";
> $sth->set_err( $DBI::stderr, $msg );
> -->8---
>
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Error in DBD::PO - our fault?
As I have updated two boxes to perl-5.14.1 in production code, I'm running through everything that I have ever tested on one of those boxes to check if that would still pass under perl-5.14.1. Of course there are some modules that won't ever compile/build/run again on a more modern box with a recent OS (like Bundle::Xmms), but some others warrant a mail to the author, like when the build issues warnings as Use of qw(...) as parentheses is deprecated at inc/Devel/CheckLib.pm line 191. But this one makes me wonder if we broke something in DBI, if is is perl-5.14 to blame or if it is the module to blame: CPAN.pm: Going to build S/ST/STEFFENW/DBD-PO-2.10.tar.gz Created MYMETA.yml and MYMETA.json Creating new 'Build' script for 'DBD-PO' version '2.10' Building DBD-PO STEFFENW/DBD-PO-2.10.tar.gz ./Build -- OK Running Build test t/01_Locale-PO/01_quote.t . ok t/01_Locale-PO/02_without_emty_lines.t ok t/02_Text-PO/01_quote.t ... ok t/03_DBD-PO/01_create_table.t . 1/7 DBD::PO::db do failed: Execution ERROR: Insecure dependency in open while running with -T switch at /pro/lib/perl5/5.14.1/x86_64-linux-ld/IO/File.pm line 185. called from t/03_DBD-PO/01_create_table.t at 39. at /pro/lib/perl5/site_perl/5.14.1/x86_64-linux-ld/DBI/DBD/SqlEngine.pm line 795 [for Statement "CREATE TABLE dbd_po_test.po ( commentVARCHAR, automatic VARCHAR, reference VARCHAR, obsolete INTEGER, fuzzy INTEGER, msgctxtVARCHAR, msgid VARCHAR, msgstr VARCHAR ) "] at t/03_DBD-PO/01_create_table.t line 39. # Looks like you planned 7 tests but ran 3. # Looks like your test exited with 2 just after 3. t/03_DBD-PO/01_create_table.t . Dubious, test returned 2 (wstat 512, 0x200) Failed 4/7 subtests -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: next DBI release
On Thu, 23 Jun 2011 22:43:28 +0100, "Martin J. Evans"
wrote:
> Although the changes in the current DBI trunk don't amount to that much
> there are 2 which I'd particularly like to be released - DBI->{attrs}
> fix and tracing changes - specifically the latter. In addition changes
> Tux made recently to fix an issue reported on perl monks is probably
> worth seeing the light of day - at least in a dev release. There are
+1 for the dev release (once the tests pass)
Both Martin's work and my bug fix show small weaknesses that are
addressed. My fix desperately needs a test case. I might add that it
needs a well-documented test case. It took me several hours to find the
week spot, where the error message was the hint. The piece of code
however did move around a bit over the past few years, making it harder
to spot the "why", which is where I feel less comfortable: did I now
find a cure for all cases or is this just one of many possibilities and
is the surrounding code fundamentally flawed. At this moment, I think
Jens is the only person that can tell.
> probably 2 issues in the way which are tests I added to reproduce bugs
> reported on rt. I'm really sorry I've not had time to address the
> actually issues reproduced with the tests for the rts but I'm unlikely
> to be address them in the near future. If someone can fix the 2 issues
> in the DBI test suite I'd really like to see at least a dev release. If
> it doesn't happen it is not the end of the world by a long way but in
> particular saying DBI_TRACE=DBD=x.log is worth it for me. However, it
> might not make a lot of difference as I'm unsure right now how much
> time I'll be able to put into DBI, DBD::ODBC and DBD::Oracle in the
> near future.
Making the DBI_TRACE stuff visible to "the world" enables DBD authors
to implement back-end stuff and actually use it.
> Thanks
> Martin
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Old bug rising with a new head
http://www.perlmonks.org/?node_id=910793
"You passed $nparm parameters where $n_req required"
Once was a correct fix. Then all moved from DBD::File to
DBI::DBD::SqlEngine and now SQL::Statement::Param roars its ugly head :)
I'd like to suggest the current fix, for which I am convinced is the
correct solution (unlit backends change again)
I do *not* have a testcase for this as I do not see the impact of
JOIN's and so here
--8<--- suggested change
diff --git a/lib/DBI/DBD/SqlEngine.pm b/lib/DBI/DBD/SqlEngine.pm
index 51f2a0a..bcac88a 100644
--- a/lib/DBI/DBD/SqlEngine.pm
+++ b/lib/DBI/DBD/SqlEngine.pm
@@ -781,7 +781,9 @@ sub execute
{
# bug in SQL::Statement 1.20 and below causes breakage
# on all but the first call
-unless ( ( my $req_prm = $stmt->params() ) == ( my $nparm = @$params )
)
+my @req_prm = $stmt->params ();
+my $n_req = @req_prm == 1 && ref $req_prm[0] ? $req_prm[0]->num :
scalar @req_prm;
+unless ( $n_req == ( my $nparm = @$params ) )
{
my $msg = "You passed $nparm parameters where $req_prm required";
$sth->set_err( $DBI::stderr, $msg );
-->8---
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Proposed change to disconnect in DBD::ODBC
On Wed, 16 Mar 2011 16:49:41 +, "Martin J. Evans" wrote: > This area is already inconsistent. From DBI under disconnect: > > "The transaction behaviour of the disconnect method is, sadly, > undefined. Some database systems (such as Oracle and Ingres) will > automatically commit any outstanding changes, but others (such as > Informix) will rollback any outstanding changes." This is something I should mention in my DBD talk about database inconsistencies. Thanks for reminding me. FWIW I agree with Greg that COMMIT on disconnect is insane -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle Release Candidate 1
On Wed, 16 Feb 2011 12:32:12 +0100, "H.Merijn Brand"
wrote:
> http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip
>
> You need to work on longdouble support I guess
Here's a patch to make the test PASS on all systems, but I'm not sure
if I'm using a carpet to shuv the problems under ...
--- t/58object.t.org2011-02-17 13:33:48.0 +0100
+++ t/58object.t2011-02-17 13:33:25.0 +0100
@@ -82,9 +82,9 @@ $dbh->do(qq{ INSERT INTO $table VALUES (
or die $dbh->errstr;
$dbh->do(qq{ INSERT INTO $table VALUES (2, $sub_type(NULL, 'obj2',
TO_DATE('2004-11-30 14:27:18', '-MM-DD HH24:MI:SS'),
-12345.6789)) }
+12345.9375)) }
) or die $dbh->errstr;
-$dbh->do(qq{ INSERT INTO $table VALUES (3, $sub_type(5, 'obj3', NULL,
777.666)) }
+$dbh->do(qq{ INSERT INTO $table VALUES (3, $sub_type(5, 'obj3', NULL,
777.875)) }
) or die $dbh->errstr;
$dbh->do(qq{ CREATE OR REPLACE TYPE $inner_type AS OBJECT (
@@ -159,14 +159,14 @@ ok (scalar @row2, 'new: Fetch second row
cmp_ok(ref $row2[1], 'eq', 'DBD::Oracle::Object', 'new: Row 2 column 2 is an
DBD::Oracle::Object');
cmp_ok(uc $row2[1]->type_name, "eq", uc "$schema.$sub_type", "new: Row 2
column 2 object type");
is_deeply([$row2[1]->attributes], ['NUM', undef, 'NAME', 'obj2',
-'DATETIME', '2004-11-30T14:27:18', 'AMOUNT', '12345.6789'], "new:
Row 1 column 2 object attributes");
+'DATETIME', '2004-11-30T14:27:18', 'AMOUNT', '12345.9375'], "new:
Row 1 column 2 object attributes");
@row3 = $sth->fetchrow();
ok (scalar @row3, 'new: Fetch third row');
cmp_ok(ref $row3[1], 'eq', 'DBD::Oracle::Object', 'new: Row 3 column 2 is an
DBD::Oracle::Object');
cmp_ok(uc $row3[1]->type_name, "eq", uc "$schema.$sub_type", "new: Row 3
column 2 object type");
is_deeply([$row3[1]->attributes], ['NUM', 5, 'NAME', 'obj3',
-'DATETIME', undef, 'AMOUNT', '777.666'], "new: Row 1 column 2
object attributes");
+'DATETIME', undef, 'AMOUNT', '777.875'], "new: Row 1 column 2
object attributes");
ok (!$sth->fetchrow(), 'new: No more rows expected');
@@ -178,7 +178,7 @@ my $expected_hash = {
NUM => 5,
NAME=> 'obj3',
DATETIME=> undef,
-AMOUNT => 777.666,
+AMOUNT => 777.875,
};
is_deeply($obj->attr_hash, $expected_hash, 'DBD::Oracle::Object->attr_hash');
is_deeply($obj->attr, $expected_hash, 'DBD::Oracle::Object->attr');
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle Release Candidate 1
ce
not ok 34 - nice_string test of row 4: column: nch (uft8) smiley face
ok 35 - byte_string test of row 4: column: descr smiley face
ok 36 - nice_string test of row 4: column: descr smiley face
ok 37 - number of rows fetched
# Failed test 'byte_string test of row 4: column: nch (uft8) smiley face'
# at t/nchar_test_lib.pl line 361.
# got: '38|58'
# expected: '9786'
# Failed test 'nice_string test of row 4: column: nch (uft8) smiley face'
# at t/nchar_test_lib.pl line 364.
# got: '&:'
# expected: '\x{263A}'
#row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58
# --- testing with NLS_NCHAR=AL32UTF8
# set $ENV{NLS_NCHAR}=AL32UTF8
# Database 9.2.0.8.0 CHAR set is US7ASCII (Non-Unicode), NCHAR set is AL16UTF16
(Unicode)
# Client 9.2.0.8 NLS_LANG is '', NLS_NCHAR is 'AL32UTF8'
ok 38 - prepared: insert into dbd_ora__drop_me ( idx, nch, descr, dt ) values(
?, ?, ?, sysdate )
ok 39 - bind_param idx
ok 40 - bind_param nch
ok 41 - bind_param descr withOUT attribute ora_csform
# create table dbd_ora__drop_me ( idx integer, nch nvarchar2(20), descr
varchar2(50), dt date )
ok 42 - insert row 1: control-C
ok 43 - bind_param idx
ok 44 - bind_param nch
ok 45 - bind_param descr withOUT attribute ora_csform
ok 46 - insert row 2: lowercase a
ok 47 - bind_param idx
ok 48 - bind_param nch
ok 49 - bind_param descr withOUT attribute ora_csform
ok 50 - insert row 3: lowercase b
ok 51 - bind_param idx
ok 52 - bind_param nch
ok 53 - bind_param descr withOUT attribute ora_csform
ok 54 - insert row 4: smiley face
ok 55 - prepared: select nch, descr, DUMP(nch), dt from dbd_ora__drop_me order
by idx
ok 56 - bind column nch
ok 57 - bind column descr
ok 58 - byte_string test of row 1: column: nch (uft8) control-C
ok 59 - nice_string test of row 1: column: nch (uft8) control-C
ok 60 - byte_string test of row 1: column: descr control-C
ok 61 - nice_string test of row 1: column: descr control-C
ok 62 - byte_string test of row 2: column: nch (uft8) lowercase a
ok 63 - nice_string test of row 2: column: nch (uft8) lowercase a
ok 64 - byte_string test of row 2: column: descr lowercase a
ok 65 - nice_string test of row 2: column: descr lowercase a
ok 66 - byte_string test of row 3: column: nch (uft8) lowercase b
ok 67 - nice_string test of row 3: column: nch (uft8) lowercase b
ok 68 - byte_string test of row 3: column: descr lowercase b
ok 69 - nice_string test of row 3: column: descr lowercase b
not ok 70 - byte_string test of row 4: column: nch (uft8) smiley face
not ok 71 - nice_string test of row 4: column: nch (uft8) smiley face
ok 72 - byte_string test of row 4: column: descr smiley face
ok 73 - nice_string test of row 4: column: descr smiley face
ok 74 - number of rows fetched
# Failed test 'byte_string test of row 4: column: nch (uft8) smiley face'
# at t/nchar_test_lib.pl line 361.
# got: '38|58'
# expected: '9786'
# Failed test 'nice_string test of row 4: column: nch (uft8) smiley face'
# at t/nchar_test_lib.pl line 364.
# got: '&:'
# expected: '\x{263A}'
#row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58
# Looks like you failed 4 tests of 74.
Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/74 subtests
Test Summary Report
---
t/24implicit_utf8.t (Wstat: 1024 Tests: 74 Failed: 4)
Failed tests: 33-34, 70-71
Non-zero exit status: 4
Files=1, Tests=74, 1 wallclock secs ( 0.14 usr 0.02 sys + 0.43 cusr 0.11
csys = 0.70 CPU)
Result: FAIL
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle Release Candidate 1
Fix for OCIPing in case where a 10 client tries to ping a <10 DB > from Tim Oertel >Fix for DBD-Oracle stored proc with array bug where second call array > size is unchanged from Tim Oertel >Fix for rt.cpan.org Ticket #=63332: Spelling error in POD from jonasbn >Fix for rt.cpan.org Ticket #=62152: t/28array_bind.t and t/31lob.t > may call plan() twice and others do not fail on not connect from John Scoles >Fix for rt.cpan.org Ticket #=61511 ORA-00942 when inserting into a > table with a LOB column over a synonym on HP-UX from Kris Lemaire >Fix for rt.cpan.org Ticket #=42842 Test 31lob fails with 64-bit > Instant Client by John Scoles >Fix for support for objects on big endian platforms from Charles > Jardine, John R Pierce >Fix for rt.cpan.org Ticket #=61225 Windows install (Stawberry Perl) > fails on long path names from David Tulloh >Fix for rt.cpan.org Ticket #=rt64524 Memory Leak when Oracle > connection fails by Martin J. Evans >Added all the missing ora_drcp values to dbh private_attribute_info > by Martin J. Evans >Removed a load of attributes from sth private_attribute_info which > are not handle attributes but attributes to bind_param/prepare by Martin > J. Evans >Fix for rt.cpan.org Ticket #=64244 - don't bail out, skip tests > when we cannot connect by Martin J. Evans and John Scoles >Added DBI to PREREQ_PM in Makefile.PL by Martin J. Evans >Added build_requires in Makefile.PL by Martin J. Evans >Added workaround for ExtUtils::MakeMaker problems by Martin J. Evans >Added LICENSE to Makefile.PL by Martin J. Evans > > Cheers John Scoles -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: promised trace flags change - a bit late
On Fri, 11 Feb 2011 10:14:12 +, "Martin J. Evans"
wrote:
> On 11/02/11 09:05, H.Merijn Brand wrote:
> > On Fri, 11 Feb 2011 08:42:21 +, "Martin J. Evans"
> > wrote:
> >
> >> On 10/02/11 22:27, Greg Sabino Mullane wrote:
> >>>
> >>>> Trace level is no good to get DBD only tracing since level
> >>>> 1 and 2 is for DBI and anything after that is DBD.
> >>>
> >>> Yes, sorry about that, I was being lazy in my comingling of
> >>> trace levels and trace flags.
> >>>
> >>>> In addition, at the LPW speaking to Tim I mentioned I had
> >>>> implemented some trace flags in DBD::ODBC which were probably
> >>>> generic in nature and agreed to add them to DBI.
> >>>
> >>> +1
> >>>
> >>>> Whilst I was there I thought I could sort the trace DBD only
> >>>> issue out as well by adding a DBD trace flag.
> >>> ...
> >>>> $dbh->trace('DBD');
> >>> ...
> >>>> Which is now duplicated in DBI for all DBDs.
> >>>> I didn't realise you did that and although I can see
> >>>> why it means you've added a flag with an uppercase
> >>>> name which is reserved for DBI. I'm not sure you'll
> >>>> ever see DBD in your parse_trace_flags after 1.617
> >>>> so you'll need to do something similar to what I
> >>>> did (below) in addition to keeping what you already
> >>>> have (above) to cover older DBIs before 1.617.
> >>>
> >>> Okay, all that is good to know. So it should do
> >>> the same thing post 1.617 and the dbd::pg specific
> >>> code will never fire, right?
> >>>
> >>> ...
> >>
> >> yup, if you OR your DBD flag with DBDs DBD flag nothing will change
> >> for you. If someone uses pre 1.617 you will work as before and 1.617
> >> you will continue to work but your flag will be redundant. When you
> >> eventually raise your requirement to DBI 1.617 you can take your DBD
> >> flag out.
> >>
> >>>> The ENC flag is for encoding tracing.
> >>>
> >>> Thanks for the explanation there, as well as all the others I
> >>> did not quote here.
> >>>
> >>
> >> BTW, on your comment to Merijn re dbd_verbose reinventing the wheel.
> >> That is how I felt and I did not want to add another test to all my
> >> trace tests which is why I added the DBD flag instead. I'm not
> >> criticising anyone using dbd_verbose, I just did not want to do it
> >> that way and would rather work with what was already present in DBI.
> >
> > I don't see it as re-inventing the/a wheel. The DBD flag is for me like
> > an alias to dbd_verbose.
> >
> > $DBD_VERBOSE = 7
> >
> > is (or should be) equal to
> >
> > $DBI_TRACE = 7|DBD
>
> Thats fine but that is not how some people have implemented it Merijn.
Which is probably why this whole discussion started.
I'm feeling guilty of not having enough time atm to actually come up
with the suggested doc changed so DBD authors have a guide. IMHO that
was the main cause for all DBD debugging diverging.
> From DBD::Oracle's dbdimp.c:
>
> /* defined globally at the top of dbdimp.c */
> int dbd_verbose = 0; /* DBD only debugging*/
>
> /* double test */
> if (DBIS->debug >= 6 || dbd_verbose >= 6 )
Is there a trigger that makes a DBD function being called if DBI->trace
is invoked?
What I currently do is set dbd_verbose on connect, and use that.
Afterwards, you can alter it using $h->{dbd_vebose}. But what if
meanwhile DBI->trace changes the level with DBD flag set? How is the
DBD being informed? If I just use the dbd_verbose flag, that won't work.
> > dbd_verbose has never been *new* functionality, It was implemented as a
> > shortcut for already existing trace features.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: promised trace flags change - a bit late
On Fri, 11 Feb 2011 08:42:21 +, "Martin J. Evans"
wrote:
> On 10/02/11 22:27, Greg Sabino Mullane wrote:
> >
> >> Trace level is no good to get DBD only tracing since level
> >> 1 and 2 is for DBI and anything after that is DBD.
> >
> > Yes, sorry about that, I was being lazy in my comingling of
> > trace levels and trace flags.
> >
> >> In addition, at the LPW speaking to Tim I mentioned I had
> >> implemented some trace flags in DBD::ODBC which were probably
> >> generic in nature and agreed to add them to DBI.
> >
> > +1
> >
> >> Whilst I was there I thought I could sort the trace DBD only
> >> issue out as well by adding a DBD trace flag.
> > ...
> >> $dbh->trace('DBD');
> > ...
> >> Which is now duplicated in DBI for all DBDs.
> >> I didn't realise you did that and although I can see
> >> why it means you've added a flag with an uppercase
> >> name which is reserved for DBI. I'm not sure you'll
> >> ever see DBD in your parse_trace_flags after 1.617
> >> so you'll need to do something similar to what I
> >> did (below) in addition to keeping what you already
> >> have (above) to cover older DBIs before 1.617.
> >
> > Okay, all that is good to know. So it should do
> > the same thing post 1.617 and the dbd::pg specific
> > code will never fire, right?
> >
> > ...
>
> yup, if you OR your DBD flag with DBDs DBD flag nothing will change
> for you. If someone uses pre 1.617 you will work as before and 1.617
> you will continue to work but your flag will be redundant. When you
> eventually raise your requirement to DBI 1.617 you can take your DBD
> flag out.
>
> >> The ENC flag is for encoding tracing.
> >
> > Thanks for the explanation there, as well as all the others I
> > did not quote here.
> >
>
> BTW, on your comment to Merijn re dbd_verbose reinventing the wheel.
> That is how I felt and I did not want to add another test to all my
> trace tests which is why I added the DBD flag instead. I'm not
> criticising anyone using dbd_verbose, I just did not want to do it
> that way and would rather work with what was already present in DBI.
I don't see it as re-inventing the/a wheel. The DBD flag is for me like
an alias to dbd_verbose.
$DBD_VERBOSE = 7
is (or should be) equal to
$DBI_TRACE = 7|DBD
dbd_verbose has never been *new* functionality, It was implemented as a
shortcut for already existing trace features.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: promised trace flags change - a bit late
tch done
=item 6
Level 5 plus internal coding for exchanges and low(er) level return codes:
DBD::Unify::fld_describe o_sql_00_00 (1 fields)
After get, sqlcode = 0
Field 1: [05 00 04 00 ] c_bar
DBD::Unify::st_prepare u_sql_00_00 (<= 1, => 0)
=item 7
Level 6 plus destroy/cleanup states:
DBD::Unify::st_free u_sql_00_00
destroy allocc destroy allocoAfter deallocO, sqlcode = 0
destroy alloci destroy allocpAfter deallocU, sqlcode = 0
destroy stat destroy growup destroy impset
=item 8
No messages (yet) set to level 8 and up.
=back
-->8---
As DBD::Unify uses levels only at the moment, there was no way to
*ONLY* get the DBD trace/debug messages without also getting the DBI
messages, as I shared DBI's trace level. This only became an issue once
the DBD was getting useful. In the beginning when I started to write
it, I (of course) also needed the DBI traces.
At that point I came up with the "uni_verbose" attribute which could
be passed to the connect method. This way I could set the DBD trace
flags without getting the DBI messages. For me this was so useful, that
I wanted it in other DBD's too. I talked to John Scoles on a YAPC
meeting and he very much agreed with me on this one. In a hacking
session, I changed my uni_verbose to dbd_verbose, added support for
$DBD_VERBOSE and helped John to convert his fixed level-based debugging
to allow support for dbd_verbose. This way, $DBD_VERBOSE and the
dbd_verbose attribute suddenly become extremely useful in
cross-database debugging. Most of my DBI scripting is database agnostic
and works evenly well on Unify, Oracle, Postgres, SQLite, CSV and mysql.
This is also the reason why I seldom use debugging flags. Flags are not
the same across database drivers.
> If DBD::Pg, this is as simple as:
>
> $dbh->trace('pglibpq'); ## as one example
Yes, and this shows a very good reason for using flags. "libpq" is
something that *only* DBD::Pg has, so it is useless for DBD::Oracle.
If e.g. we all could agree on $DBD_VERBOSE level >= 3 printing all SQL
statements (just an example)
DBD::Unify::st_prepare u_sql_00_00 ("select * from foo")
Then cross database scripting debugging could be made a whole lot more
useful. Also note that it imho would be no problem whatsoever to change
the implementation of debugging and debugging flags for DBD's as no
production code is (or at least should be) depending on debug output of
DBD's. What I mean is that if I change the definition of what is
printed at what level, I do not take away functionality that is only
used while debugging, I just redefine what is printed when, and I guess
that most people that debug using level-based debugging schemes will
start with level 9 when faced with serious trouble.
> We even have a specific flag for all DBD-specific and non-DBI output:
>
> $dbh->trace('DBD');
That is not (yet) documented in DBI, is it?
My ultimate goal would be to see a minimal set of flags documented in
the DBI that define how the DBD's are expected to debug/trace.
Something that has not been there before, so there will not be any
`alignment' in its use yet. But if we go there, I will change
DBD::Unify to mach it.
> Also, can you elaborate more on what things the CON and ENC will
> output? I'm wondering how similar the CON is to the DBD::Pg's
> 'pglogin' flag:
>
> =item pglogin
>
> Outputs a message showing the connection string right before a new
> database connection is attempted, a message when the connection
> was successful, and a message right after the database has been
> disconnected. Also output if trace level is 5 or greater.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: promised trace flags change - a bit late
On Sun, 6 Feb 2011 12:09:35 +, Tim Bunce wrote: > On Sun, Feb 06, 2011 at 12:16:33PM +0100, H.Merijn Brand wrote: > > On Sat, 5 Feb 2011 12:29:09 +, Tim Bunce > > wrote: > > > > > > As you note above, the current trace settings are encoded into an int: > > > > > > # 0xddrL (driver, DBI, reserved, Level) > > > > > > Where L is the DBI trace level (0-16) and the rest are bit flags. > > > The 4 reserved bits could be used as a driver trace level (0-16). > > > > # 0xddlDDDrL (driver, driver-level, DBI, reserved, Level) > > > > would be perfect in my world. > > That's fine. > > > l than is "level" to DBD, what "L" is to DBI > > > > How many bits in do you think will ever be used? If we now use 2 > > or 3, wouldn't it be better to change to > > > > # 0xddlDDDrL ? > > > > Which would mean that we stay 100% backward compatible (as the first D > > of was only reserved but never used. > > Yeap. > > > With this scheme, it is extremely easy for all drivers to update their > > docs to match DBI. Those drivers that used a level will just have to > > use the 'l', those that used flags will (still) have to use the dd. > > > > We could then document the use and support of DBD_VERBOSE to > > automatically translate to the ddl part. If a DBD already supported > > $DBD_VERBOSE instead of "ddl", it will work just as it did, if the DBD > > updates to the new scheme (requiring DBI-1.xxx that supports it), then > > the "upgrade" is automatic and doesn't change a thing from the user > > point of view. > > > > Am I being messy? Or does this all make sense? > > I think it makes sense. > > Thanks. I'll try to come up with a complete patch soon then -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: promised trace flags change - a bit late
he back.
So far I didn't get all the authors into a straight line. We all had
our own vision in what was most useful to debug our own DBD without
looking at how other DBD's did their debugging, and I must say I am
just as guilty.
Now back to that "need", I invented $DBD_VERBOSE => $dbh->{dbd_verbose}
to skip all the DBI messages (as said, they only caused noise to what I
wanted to see).
back to 0xddlDDDrL
l than is "level" to DBD, what "L" is to DBI
How many bits in do you think will ever be used? If we now use 2
or 3, wouldn't it be better to change to
# 0xddlDDDrL ?
Which would mean that we stay 100% backward compatible (as the first D
of was only reserved but never used.
With this scheme, it is extremely easy for all drivers to update their
docs to match DBI. Those drivers that used a level will just have to
use the 'l', those that used flags will (still) have to use the dd.
We could then document the use and support of DBD_VERBOSE to
automatically translate to the ddl part. If a DBD already supported
$DBD_VERBOSE instead of "ddl", it will work just as it did, if the DBD
updates to the new scheme (requiring DBI-1.xxx that supports it), then
the "upgrade" is automatic and doesn't change a thing from the user
point of view.
Am I being messy? Or does this all make sense?
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Clarification sought on execute_array
;connect(
> > 'DBI:ODBC:DSN=xxx', 'xxx', 'xxx',
> > { RaiseError => 1, PrintError => 0, HandleError => \&fred
> > });
> >
> > do_it($dbh);
> >
> > sub do_it {
> > my $dbh = shift;
> >
> > eval {$dbh->do(q/drop table mytest/);};
> > $dbh->do(q/create table mytest (a int primary key, b char(20))/);
> >
> > my $sth = $dbh->prepare(q/insert into mytest values (?,?)/);
> > $sth->bind_param(1, 1);
> > $sth->bind_param(2, 'onetwothree');
> > $sth->execute;
> >
> > $sth->bind_param_array(1, [51,1,52,53]);
> > $sth->bind_param_array(2, ['fiftyone', 'fiftytwo', 'fiftythree',
> > 'one']);
> > my (@tuple_status, $inserted);
> > eval {
> > $inserted = $sth->execute_array(
> > { ArrayTupleStatus => \@tuple_status } );
> > };
> > if ($@) {
> > print "Exception: $@\n";
> > }
> > print "Error from execute_array - " . $sth->errstr . ",",
> > $sth->err ."\n"
> > if (!$inserted);
> > for (@tuple_status) {
> > print Dumper($_), "\n";
> > }
> > }
> >
> > which outputs for the DBD::Oracle part:
> >
> > $ perl execute_array/execute_array.pl
> > DBD::Oracle::st execute_array warning: ORA-24381: error(s) in array
> > DML (DBD SUCCESS_WITH_INFO: OCIStmtExecute) [for Statement "insert
> > into mytest values (?,?)"] at execute_array/execute_array.pl line 43.
> > Error from execute_array - ORA-24381: error(s) in array DML (DBD
> > SUCCESS_WITH_INFO: OCIStmtExecute),0
> > $VAR1 = -1;
> >
> > $VAR1 = [
> > 1,
> > 'ORA-1: unique constraint (BET.SYS_C0096150) violated
> > (DBD SUCCESS_WITH_INFO)'
> > ];
> >
> > $VAR1 = -1;
> >
> > $VAR1 = -1;
> >
> > Notable from this is that:
> >
> > a) even though RaiseError was set, no error was raised although a
> > warning was.
> > b) execute_array returned undef (correct)
> > c) errstr is set but err is not (0)
> > d) the HandleError routine was not called - due to (a)?
> > e) the count of rows affected is -1 for all rows which worked - I
> > believe this is permissible
> >
> > For the DBD::ODBC run which does not do execute_array itself you get:
> >
> > Error Handler called
> > $VAR1 = [
> > 'DBD::ODBC::st execute_array failed: executing 4 generated 1
> > errors',
> > bless( {}, 'DBI::st' ),
> > undef
> > ];
> > handle_error: DBD::ODBC::st execute_array failed: executing 4
> > generated 1 errors
> > handle: DBI::st=HASH(0xa071d00)
> > val=Exception: DBD::ODBC::st execute_array failed: executing 4
> > generated 1 errors at
> > execute_array/execute_array.pl line 43.
> >
> > Error from execute_array - executing 4 generated 1 errors,20
> > $VAR1 = 1;
> >
> > $VAR1 = [
> > 1,
> > '[unixODBC][Easysoft][SQL Server Driver][SQL
> > Server]Violation of PRIMARY KEY constraint \'PK__mytest__3661ABE9\'.
> > Cannot insert duplicate key in object \'dbo.mytest\'. (SQL-23000)
> > [state was 23000 now 01000]
> > [unixODBC][Easysoft][SQL Server Driver][SQL Server]The statement has
> > been terminated. (SQL-01000)',
> > '01000'
> > ];
> >
> > $VAR1 = 1;
> >
> > $VAR1 = 1;
> >
> > Notice the difference:
> >
> > a) an error was raised (different from DBD::Oracle) saying 1 of 4 failed
> > b) execute_array returned undef (the same)
> > c) both errstr and err are set although where 20 comes from
> > I'm not sure
> > d) the HandleError routine was called (different from DBD::Oracle)
> > e) the count of rows affected is 1 for all the rows which worked
> >
> > For anyone using execute_array this represents somewhat of a problem
> > unless they write substantial code per DBD. The clarification required
> > is:
> >
> > a) if execute_array fails on any row should that raise an error?
> > Obviously, if it does, then HandleError comes in to it
> > b) if execute_array fails should that set errstr AND err
> >
> > I believe the count per row of affected is driver dependent so I'll
> > ignore that but there is a lot of code out there (perhaps doing things
> > wrong) which examines "err" (like DBIx::Class) which is not set in
> > DBD::Oracle's case. The strict interpretation of the pod for
> > execute_array suggests execute_array will return undef on any failure
> > (which it does in both cases) but not whether any row is an
> > error/warning and whether "err" and "errstr" are set.
> >
> > BTW, please keep Peter (ribasushi) on the cc list as he is not
> > subscribed to dbi-dev but is an interested party.
> >
> > Martin
>
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle - credentials
On Fri, 14 Jan 2011 15:21:39 +, "Martin J. Evans" wrote: > On 14/01/11 15:01, H.Merijn Brand wrote: > > On Fri, 14 Jan 2011 14:56:46 +, "Martin J. Evans" > > wrote: > > > >> On 14/01/11 14:30, H.Merijn Brand wrote: > >>> Maybe this is a feature request, but if I have > >>> > >>> ORACLE_USERID=john/sekrit > >>> DBI_USER=pablo > >>> DBI_PASS=neruda > >>> > >>> I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of* > >>> the ORACLE_USERID. Anyone can come up with a good reason why this os > >>> not happening at the moment? > >>> > >>> How do other DBD's set precedence if environment variable are allowed > >>> for login credentials? > >>> > >> > >> Just a minor point (not saying it stops the discussion) but I don't > >> think ORACLE_USERID is something DBD::Oracle defines (other than in > >> test code in t/*). So is your point to do with running tests in t/* or > >> in general? > > > > I ran into this in the test suite indeed. Your findings below just > > confirm my expectation :) > > > > I posted it here because I saw no generic docs about this > > It is in the README. Yes, the *DBD::Oracle* README. I know, I found it there, but I was more looking for guides from DBI. Does DBI document that DBU_USER/DBI_PASS would somehow overrule other (default) settings? I think the DBD::Oracle README does exactly what it said. So it is not wrong. > The supplied tests will connect to the database using the value of the > ORACLE_USERID environment variable to supply the username/password. > > Don't know why it cannot fall back on DBI_USER/DBI_PASS. > > >> $ export ORACLE_USERID=wrong/wrong > >> $ export DBI_USER=real_user > >> $ export DBI_PASS=valid_password > >> $ export DBI_DSN='dbi:Oracle:host=betoracle.easysoft.local;sid=devel' > >> $ perl -le 'use DBI; my $h = DBI->connect();' > >> > >> works for me. i.e., ORACLE_USERID contains invalid username/password > >> and DBI_USER/DBI_PASS contain valid username/password and it connects > >> fine. > >> > >> Perhaps I misunderstood you Merijn. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle - credentials
On Fri, 14 Jan 2011 14:56:46 +, "Martin J. Evans" wrote: > On 14/01/11 14:30, H.Merijn Brand wrote: > > Maybe this is a feature request, but if I have > > > > ORACLE_USERID=john/sekrit > > DBI_USER=pablo > > DBI_PASS=neruda > > > > I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of* > > the ORACLE_USERID. Anyone can come up with a good reason why this os > > not happening at the moment? > > > > How do other DBD's set precedence if environment variable are allowed > > for login credentials? > > > > Just a minor point (not saying it stops the discussion) but I don't > think ORACLE_USERID is something DBD::Oracle defines (other than in > test code in t/*). So is your point to do with running tests in t/* or > in general? I ran into this in the test suite indeed. Your findings below just confirm my expectation :) I posted it here because I saw no generic docs about this > $ export ORACLE_USERID=wrong/wrong > $ export DBI_USER=real_user > $ export DBI_PASS=valid_password > $ export DBI_DSN='dbi:Oracle:host=betoracle.easysoft.local;sid=devel' > $ perl -le 'use DBI; my $h = DBI->connect();' > > works for me. i.e., ORACLE_USERID contains invalid username/password > and DBI_USER/DBI_PASS contain valid username/password and it connects > fine. > > Perhaps I misunderstood you Merijn. > > Martin -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
DBD::Oracle - credentials
Maybe this is a feature request, but if I have ORACLE_USERID=john/sekrit DBI_USER=pablo DBI_PASS=neruda I *do* expect that DBD::Oracle uses DBI_USER and DBI_PASS *instead of* the ORACLE_USERID. Anyone can come up with a good reason why this os not happening at the moment? How do other DBD's set precedence if environment variable are allowed for login credentials? -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: SQL::Statement 1.31_001 dev-release and test rewrite
On Thu, 06 Jan 2011 11:08:15 +, Jens Rehsack wrote: > On 01/01/11 07:55, Michael G Schwern wrote: > > On 2011.1.1 12:38 AM, Jens Rehsack wrote: > >> Further I need some help on test rewrite (that's why you, Michael > >> Schwern, are on CC). > >> I'd like to rewrite step by step all tests like I did in t/06virtual.t > >> and t/08join.t. For this I > >> have to move the test main loop into the TestLib.pm and I would prefer > >> if I could setup > >> Test::More to print the file name and the line of the real test > >> (somewhere in the list of > >> tests - where the tests need some additional fields). > > > > There's one of a number of things you might be trying to do here. Mainly I > > don't know what the "main loop" is. If you rewrite the test how you want > > and > > show me, I can show you how to fix the file/line numbers. Likely it will > > be a > > simple matter of C< local $Test::Builder::Level = $Test::Builder::Level + > > 1> > > in your loop routine. > > That's only one step - I want the line numbers of the test, and the test is > currently written as an hash-entry in a test-list. > Probably it's wiser to create an own "sql_test" sub which contains the code > from the test loop (see t/06virtual.t for an example). > > > Also, your 1.31_001 alpha is actually $VERSION 1.32. If this was > > intentional, > > I would recommend against prematurely increasing the actual $VERSION. It > > will > > cause confusion with the real release, not everything respects the > > distribution version (ie. what's on the tarball), and it's odd to unpack > > Foo-1.23_01.tar.gz and get Foo-1.24. Now that 1.32 is confused, I would > > recommend you skip 1.32 and the next alphas be 1.32_0x. Then the final > > version be 1.33. > > Yes, maybe - but this might confuse others ... > I had chosen this kind of file renaming according to xdg's blog entry > "version numbers should be boring". > > > You're shipping .aspell.local.pws which looks like a local dictionary for a > > spell checker. Intentional? > > You had to ask Tux (Merijn) about this - he added that file. Not really meant to be distributed, but it does do no harm That file (these files) are a list in aspell format, just like in $HOME SS-svn> ls ~/.aspell* /home/merijn/.aspell.de.prepl /home/merijn/.aspell.en.pws /home/merijn/.aspell.de.pws/home/merijn/.aspell.nl.prepl /home/merijn/.aspell.en.prepl /home/merijn/.aspell.nl.pws It is a list of words that are not in default dictionaries, but are correct in the current documentation. Actually, it is now out-of-date SS-svn > pod-spell-check --aspell ok 1 - lib/SQL/Dialects/ANSI.pm ok 2 - lib/SQL/Dialects/AnyData.pm ok 3 - lib/SQL/Dialects/CSV.pm ok 4 - lib/SQL/Dialects/Role.pm ok 5 - lib/SQL/Eval.pm ok 6 - lib/SQL/Parser.pm ok 7 - lib/SQL/Statement.pm ok 8 - lib/SQL/Statement/Function.pm ok 9 - lib/SQL/Statement/Functions.pm ok 10 - lib/SQL/Statement/GetInfo.pm ok 11 - lib/SQL/Statement/Operation.pm ok 12 - lib/SQL/Statement/Placeholder.pm ok 13 - lib/SQL/Statement/RAM.pm ok 14 - lib/SQL/Statement/Term.pm ok 15 - lib/SQL/Statement/TermFactory.pm ok 16 - lib/SQL/Statement/Util.pm ok 17 - t/SQLtest.pm ok 18 - t/TestLib.pm 1..18 ok 1 - CommonMistakes ok 1 - lib/SQL/Dialects/ANSI.pm ok 2 - lib/SQL/Dialects/AnyData.pm ok 3 - lib/SQL/Dialects/CSV.pm ok 4 - lib/SQL/Dialects/Role.pm ok 5 - lib/SQL/Eval.pm ok 6 - lib/SQL/Parser.pm not ok 7 - lib/SQL/Statement.pm # Failed test 'lib/SQL/Statement.pm' # at /pro/bin/pod-spell-check line 94. # got: ''kibbitz' => (kibbutz kibitz)' # expected: '' ok 8 - lib/SQL/Statement/Function.pm ok 9 - lib/SQL/Statement/Functions.pm ok 10 - lib/SQL/Statement/GetInfo.pm ok 11 - lib/SQL/Statement/Operation.pm ok 12 - lib/SQL/Statement/Placeholder.pm ok 13 - lib/SQL/Statement/RAM.pm ok 14 - lib/SQL/Statement/Term.pm ok 15 - lib/SQL/Statement/TermFactory.pm ok 16 - lib/SQL/Statement/Util.pm ok 17 - t/SQLtest.pm ok 18 - t/TestLib.pm 1..18 # Looks like you failed 1 test of 18. not ok 2 - Spell-check with aspell # Failed test 'Spell-check with aspell' # at /pro/bin/pod-spell-check line 98. 1..0 # SKIP Ispell not selected ok 3 # skip Ispell not selected 1..3 # Looks like you failed 1 test of 3. SS-svn > pod-spell-check is attached in case you might want to play with it > > Finally, the disparity between the tarball name and the directory indicates > > that you're no
Re: confused about DBD implementation of ChopBlanks
On Mon, 03 Jan 2011 10:27:52 +, "Martin J. Evans"
wrote:
> On 02/01/2011 18:50, H.Merijn Brand wrote:
> > On Sun, 02 Jan 2011 18:07:13 +, "Martin J. Evans"
> > wrote:
> >
> >> Sorry if this turns out to be gibberish but I'm been battling with a
> >> host of unicode problems today and I am quickly losing track.
> >>
> >> I can't make ChopBlanks work properly in DBD::ODBC. It works if I use:
> >>
> >> $dbh->{ChopBlanks} = 1;
> >> $sth = $dbh->prepare (q/select * from sometable/);
> >>
> >> and does not work if I use:
> >>
> >> $sth = $dbh->prepare (q/select * from sometable/);
> >> $sth->{ChopBlanks} = 1;
> > The above completely meets my expectation.
>
> really. You expect ChopBlanks set directly on an sth to not work?
Damn :)
I read that as $dbh->{ChopBlanks} = 1;
> > Once the sth is created, and
> > all attributes are set (either directly or derived/inherited from dbh),
> > they should *not* change when dbh changes it on a higher level.
>
> I agree that once set on a sth, a change to the dbh should not change
> the sth but what I'm seeing is if they are NOT set on the dbh and then
> you create an sth, you cannot change it on the sth directly. The docs
> suggest ChopBlanks is for connection and statement handles.
>
> $dbh = DBI->connect;
> $sth = $dbh->prepare (q/select * from sometable/);
> $sth->{ChopBlanks} = 1
>
> now DBIc_has (imp_sth, DBIcf_ChopBlanks) returns false.
I fully agree that this sounds like unwanted behavior.
> >> and it seems "ChopBlanks = DBIc_has (imp_sth, DBIcf_ChopBlanks);" is not
> >> true in DBD::ODBC's dbdimp.c.
> >>
> >> Various DBD's use DBIc_has (DBD::ODBC, DBD::Pg, DBD::Oracle) or DBIc_is
> >> (DBD::mysql).
> > DBD::Unify uses DBIc_has ()
> > DBD::CSV (through DBD::File) use s DBIc_is ()
> >
> > In fact they are the same:
> >
> > DBIXS.h:#define DBIc_has(imp,flag) DBIc_is(imp, flag) /* alias for DBIc_is
> > */
>
> Should have looked - sorry, I did warn you I'm stuck in a world or pain
> with unicode right now.
I know the pain, and I'm not pointing fingers, just passing on info
> >> The DBI::DBD documentation says (for XS):
> >>
> >> "Note that you can also obtain standard attributes such as /AutoCommit/
> >> and /ChopBlanks/ from the attributes parameter, using
> >> |DBD_ATTRIB_GET_IV| for integer attributes."
> >>
> >> and
> >>
> >> "The dbd_db_STORE_attrib method
> >> You do not handle all attributes; on the contrary, you should not handle
> >> DBI attributes here: leave this to DBI. (There are two exceptions,
> >> /AutoCommit/ and /ChopBlanks/, which you should care about.)"
> >>
> >> I presumed a DBD should "care" about ChopBlanks as DBI is not going to
> >> remove the trailing blanks not that DBI is not going to store the
> >> ChopBlanks value and yet when I call DBIc_has(imp_sth, DBIcf_ChopBlanks)
> >> on a sth it returns false even though I set $sth->{ChopBlanks} = 1.
> >
> > Before or after the sth was created?
>
> Example above, after.
>
> >> DBD::ODBC (like all the other DBDs I've checked) does not handle
> >> ChopBlanks in the STORE or FETCH routines.
> >>
> >> Any ideas what is wrong?
>
> I may be making a mistake here, and may be ChopBlanks cannot be set on a
> sth, but in that case the docs are confusing.
I think it should be possible, at least it would be very DWIMmish
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: confused about DBD implementation of ChopBlanks
On Sun, 02 Jan 2011 18:07:13 +, "Martin J. Evans"
wrote:
> Sorry if this turns out to be gibberish but I'm been battling with a
> host of unicode problems today and I am quickly losing track.
>
> I can't make ChopBlanks work properly in DBD::ODBC. It works if I use:
>
> $dbh->{ChopBlanks} = 1;
> $sth = $dbh->prepare(q/select * from sometable/);
>
> and does not work if I use:
>
> $sth = $dbh->prepare(q/select * from sometable/);
> $sth->{ChopBlanks} = 1;
The above completely meets my expectation. Once the sth is created, and
all attributes are set (either directly or derived/inherited from dbh),
they should *not* change when dbh changes it on a higher level.
> and it seems "ChopBlanks = DBIc_has(imp_sth, DBIcf_ChopBlanks);" is not
> true in DBD::ODBC's dbdimp.c.
>
> Various DBD's use DBIc_has (DBD::ODBC, DBD::Pg, DBD::Oracle) or DBIc_is
> (DBD::mysql).
DBD::Unify uses DBIc_has ()
DBD::CSV (through DBD::File) use s DBIc_is ()
In fact they are the same:
DBIXS.h:#define DBIc_has(imp,flag) DBIc_is(imp, flag) /* alias for DBIc_is */
> The DBI::DBD documentation says (for XS):
>
> "Note that you can also obtain standard attributes such as /AutoCommit/
> and /ChopBlanks/ from the attributes parameter, using
> |DBD_ATTRIB_GET_IV| for integer attributes."
>
> and
>
> "The dbd_db_STORE_attrib method
> You do not handle all attributes; on the contrary, you should not handle
> DBI attributes here: leave this to DBI. (There are two exceptions,
> /AutoCommit/ and /ChopBlanks/, which you should care about.)"
>
> I presumed a DBD should "care" about ChopBlanks as DBI is not going to
> remove the trailing blanks not that DBI is not going to store the
> ChopBlanks value and yet when I call DBIc_has(imp_sth, DBIcf_ChopBlanks)
> on a sth it returns false even though I set $sth->{ChopBlanks} = 1.
Before or after the sth was created?
> DBD::ODBC (like all the other DBDs I've checked) does not handle
> ChopBlanks in the STORE or FETCH routines.
>
> Any ideas what is wrong?
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: sqlengine branch ready for dev-release
On Tue, 14 Dec 2010 22:47:38 +0100, Jens Rehsack wrote: > Hi Tim, > > I finished the corrections of DBI::DBD::SqlEngine and DBD::File > regarding proxying them via Gofer as discussed last week. > I think it's stable enough that it could be merged to the trunk for a > developer-release on your shout :) Tested on all the most recent stuff I have on my devel machine All tests passed I just committed a tiny tidy commit. > Thanks again for helping, Thanks for keeping the ball rolling -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
