On Mon, May 09, 2011 at 02:24:21PM -0400, Patrick Galbraith wrote:
>
> You can make a single asynchronous query per MySQL connection; this
> allows you to submit a long-running query to the server and have an
> event loop inform you when it’s ready.
That's great, but...
> An asynchronous query i
On Tue, Mar 15, 2011 at 07:13:02PM +, Martin J. Evans wrote:
> >
> >Just call execute(1,2); # not enough args
> >check that that returns an error
> >and the errstr values don't contain ParamValues
> >and that $sth->{ParamValues} is empty.
> >
> I didn't do it quite like that mostly because errs
On Fri, Mar 11, 2011 at 10:27:16PM +, Martin J. Evans wrote:
> On 11/03/2011 16:53, Tim Bunce wrote:
> >Time's in very short supply at the moment, but if someone can contribute
> >tests for these (ideally as patches to existing test scripts) then I'll
> >f
Time's in very short supply at the moment, but if someone can contribute
tests for these (ideally as patches to existing test scripts) then I'll
fix'em as soon as I get a moment.
Both are simple:
https://rt.cpan.org/Public/Bug/Display.html?id=66127
https://rt.cpan.org/Public/Bug/Display.ht
On Mon, Feb 21, 2011 at 05:59:34PM +, Martin J. Evans wrote:
> It would appear this problem and possibly other leaks are attracting quite a
> lot of attention now. Someone else just posted another cpan rating mentioning
> leaks at:
>
> http://cpanratings.perl.org/dist/DBD-Pg#8254
>
> I nar
On Sun, Feb 06, 2011 at 02:39:09PM +, Martin J. Evans wrote:
> On 06/02/2011 13:00, Tim Bunce wrote:
> >On Sat, Feb 05, 2011 at 01:27:11PM +, Martin J. Evans wrote:
> >>>ok, the 3 new trace flags are in and I added macros (slight shame
> >>>you cannot use t
On Sun, Feb 06, 2011 at 01:17:15PM +0100, H.Merijn Brand wrote:
> > >
> > > # 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
On Sat, Feb 05, 2011 at 01:27:11PM +, Martin J. Evans wrote:
> >
> >ok, the 3 new trace flags are in and I added macros (slight shame
> >you cannot use them in DBI.pm too but not a great deal).
I think they should be added to the ALIAS list in constant().
> All done in DBD::ODBC, tested and c
On Sun, Feb 06, 2011 at 12:16:33PM +0100, H.Merijn Brand wrote:
> On Sat, 5 Feb 2011 12:29:09 +0000, Tim Bunce
> wrote:
> >
> > As you note above, the current trace settings are encoded into an int:
> >
> > # 0xddrL (driver, DBI, reserved, Level)
>
On Fri, Feb 04, 2011 at 08:00:13PM +, Martin J. Evans wrote:
> Tim,
>
> At the LPW I think I promised to add connection and encoding trace
> flags to DBI which add to the already existing SQL flag. I never got
> around to it and Merijn reminded me today on #dbi. The change is
> trivial and onc
On Wed, Feb 02, 2011 at 03:52:00PM +, Martin J. Evans wrote:
>
> [...]
>
> So, I think DBI works fine right now (given slight pod change) and
> don't want to complicate it or worse, break peoples existing code.
Great! :)
> DBD:: Oracle on the other hand does not but I believe John has alread
On Tue, Feb 01, 2011 at 09:02:26PM +, Martin J. Evans wrote:
> On 01/02/2011 20:50, Tim Bunce wrote:
> >On Tue, Feb 01, 2011 at 10:58:14AM -0500, John Scoles wrote:
>
> >>My only concern is when it does error (no matter what the setting of
> >>AutoCommit) yo
On Tue, Feb 01, 2011 at 10:58:14AM -0500, John Scoles wrote:
> On 01/02/2011 10:48 AM, Tim Bunce wrote:
> >On Mon, Jan 31, 2011 at 08:39:40PM +, Martin J. Evans wrote:
> >>I imagine most DBDs [if not all] that implement execute_array
> >[Just a reminder that drivers c
On Mon, Jan 31, 2011 at 08:39:40PM +, Martin J. Evans wrote:
> I imagine most DBDs [if not all] that implement execute_array
[Just a reminder that drivers can opt to implement just
execute_for_fetch() and use the DBI's default execute_array() method,
which then calls execute_for_fetch().]
> t
On Sun, Jan 30, 2011 at 05:46:49PM +, Martin J. Evans wrote:
>
> push @$tuple_status, [ $sth->err, $sth->errstr, $sth->state ];
>
>so I guess the pod should say:
>
>"If the execution of a tuple causes an error, then the corresponding
> status array element will be set to
>a ref
On Wed, Jan 19, 2011 at 10:25:05PM +, Martin J. Evans wrote:
> On 19/01/2011 11:47, Tim Bunce wrote:
> >
> >- I think it's reasonable for execute_array() and execute_for_fetch()
> > to return an error (ie err() true and so trigger RaiseError etc.)
> > i
I'm sorry to arrive here late. Seems I've been missing all the fun!
Some observations:
- I think it's reasonable for execute_array() and execute_for_fetch()
to return an error (ie err() true and so trigger RaiseError etc.)
if execution of any of the tuples encountered an error.
- That'll
On Fri, Jan 14, 2011 at 04:45:52PM +0100, H.Merijn Brand wrote:
>
> 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?
DBI_USER and DBI_PASS are applied
On Mon, Jan 03, 2011 at 02:50:21PM +, Martin J. Evans wrote:
> On 03/01/2011 13:08, Tim Bunce wrote:
> >
> >Generally "method attributes" and "handle attributes" are quite
> >distinct. The one place they're not is the connect() methods tha
In the DBI repro there are several "forward looking" docs:
TASKS.pod - 55 lines - 2006-09-26
TODO_2005.txt - 508 lines - 2005-03-22
Roadmap.pod- 394 lines - 2004-11-12
There are clearly all out of date and sometimes also inconsistent.
Some consolidation, review, and editor
On Mon, Jan 03, 2011 at 11:52:45AM +, Martin J. Evans wrote:
> Ok, as I suspected, this was sort of my fault. You can indeed do:
>
> $h = DBI->Connect;
> $s = $h->prepare(q/select * from sometable/);
> $s->{ChopBlanks} = 1;
>
> and it chops blanks but you cannot do:
>
> selectall_arrayref(q/
Great. Thanks Martin.
Tim.
On Tue, Dec 14, 2010 at 03:26:41PM +, Martin J. Evans wrote:
> On 13/12/10 21:00, Tim Bunce wrote:
> > On Mon, Dec 13, 2010 at 05:30:10PM +, Martin J. Evans wrote:
> >> See RT http://rt.cpan.org/Public/Bug/Display.html?id=63550 which star
On Mon, Dec 13, 2010 at 05:30:10PM +, Martin J. Evans wrote:
> See RT http://rt.cpan.org/Public/Bug/Display.html?id=63550 which started this
> off.
>
> DBD::ODBC optimises calls to the do method when no parameters are
> involved. Normally do is just a shortcut for prepare/execute except it
>
On Mon, Dec 06, 2010 at 12:54:57AM -0800, Jonathan Leffler wrote:
> Two related questions (prompted by a question from people using
> DBD::Informix):
>
> 1. Are there any known problems with $sth->fetchall_arrayref({}, 50);?
Nope.
> 2. Are there any requirements on a DBD module to make the lim
On Mon, Nov 15, 2010 at 10:04:56AM -0800, Brian Phillips wrote:
> - DBD::Oracle::db::_login($dbh, $dbname, $user, $auth, $attr)
> - or return undef;
> +{
> +my @local_signals = @{ $attr->{ora_local_signals} || [] };
> +local @s...@local_signals} if @local_signals;
>
On Sun, Nov 07, 2010 at 08:14:47PM +, Tim Bunce wrote:
> > > I have to say I would be strongly against returning all signals to
> > > their original state after a connect call. I know for a fact that
> > > some oracle clients (depending on how you connect to Orac
On Thu, Nov 04, 2010 at 10:19:27AM -0400, Rudy Lippan wrote:
> On 11/04/2010 06:00 AM, Tim Bunce wrote:
> > On Wed, Nov 03, 2010 at 09:13:38PM -0400, Rudy Lippan wrote:
> >>
> >> Hi Tim, &al.,
> >>
> >> I am working on writing a DBD for mongoDB,
On Wed, Nov 03, 2010 at 10:29:18PM +0100, Jens Rehsack wrote:
> 2010/11/3 Martin J. Evans :
> [...]
> > From time to time something similar to Brian's post turns up on this list
> > although it is usually something to do with pipes not working as you expect.
> >
> > I have to say I would be strong
On Wed, Nov 03, 2010 at 09:13:38PM -0400, Rudy Lippan wrote:
>
> Hi Tim, &al.,
>
> I am working on writing a DBD for mongoDB, but before I get too far into
> the code, I'd like to get an official prefix for it. I am leaning
> towards 'hu_'* this way I won't have to worry about any of my names
>
On Mon, Oct 25, 2010 at 01:05:52PM +0100, Martin J. Evans wrote:
> >>
> >> As a result, I'd like to change that include in DBIXS.h to add this
> >> flexibility in the future.
> >>
> >> Any objections?
> >
> > None.
>
> Done, thanks.
>
> I didn't add a change entry. Sometimes I'm unsure whether t
On Mon, Aug 30, 2010 at 07:28:31AM -0400, John Scoles wrote:
> Tim Bunce wrote:
>
> Looks like DBD::Oracle as PERL_POLLUTE as well.
>
> Lucy!!! You have some renaming to do!!!
>
> A project of 1.26 perhaps
As 5.13.x comes closer to being 5.14 this issue is becoming mor
On Fri, Oct 22, 2010 at 06:59:57PM +0100, Martin J. Evans wrote:
> I've released a DBD::ODBC requiring Perl 5.8 but included the use of
> my_snprintf (from ppport.h) which unfortunately was not defined
> until 5.9.4. Fair enough, my fault but I have no way of fixing it
> (other than reversing my_sn
On Thu, Oct 07, 2010 at 11:52:01AM +0100, Martin J. Evans wrote:
>
> You obviously addressed the profile issues.
>
> This all works lovely for me now. Wish I'd put more effort into looking at it
> when I first saw it but I just noted it down and forgot about it.
>
> Thanks again Tim.
Thanks fo
Try r14463 :)
Tim.
p.s. The redundant FETCH has been happening for years.
On Wed, Oct 06, 2010 at 07:15:03PM +0100, Martin J. Evans wrote:
> Hi,
>
> Hoping someone can help me identify what might be going on here but
> it looks to me like something in DBI has changed.
>
> use strict;
> use D
On Wed, Oct 06, 2010 at 07:15:03PM +0100, Martin J. Evans wrote:
> Hi,
>
> Hoping someone can help me identify what might be going on here but
> it looks to me like something in DBI has changed.
>
> use strict;
> use DBI;
>
> my $attrs = { RaiseError => 1, PrintError => 0, AutoCommit => 1 };
>
at 10:23:49AM +0200, Mara wrote:
> On Wed, Sep 22, 2010 at 11:02 PM, Tim Bunce wrote:
> > On Wed, Sep 22, 2010 at 04:56:31PM +0200, Mara wrote:
> >> Hi Tim,
> >>
> >> On Wed, Sep 22, 2010 at 11:24 AM, Tim Bunce wrote:
> >> > On Tue, Sep 21, 2010 at 06:01
On Tue, Sep 21, 2010 at 10:35:16PM +0200, Jens Rehsack wrote:
> 2010/9/21 Tim Bunce :
> >> Tim suggest that Pure-Perl DBD development can happen in branches and
> >> they should be merged into the trunk when they are ready. Well, I had
> >> merged the state of r1
On Tue, Sep 21, 2010 at 04:27:25PM +0200, Jens Rehsack wrote:
> 2010/9/21 Tim Bunce :
> >
> > I believe the server is 1.6.9 (Server:Apache/2.2.14 (Unix) DAV/2
> > SVN/1.6.9 mod_python/3.3.2-dev-20080819 Python/2.4.1 mod_ssl/2.2.14
> > OpenSSL/0.9.8e-fips-rhel5 mod_fastcg
On Tue, Sep 21, 2010 at 11:37:33AM +0200, Jens Rehsack wrote:
> Hi all,
Hi Jens. [FYI Your email crossed with my "1.615 and onwards" one.]
> I'm a bit confused about the immediate requirement of a fix for RT#61445
> and not even a development release 2 days after the fix has been committed,
> but
On Tue, Sep 21, 2010 at 01:56:49PM +0200, H.Merijn Brand wrote:
> On Tue, 21 Sep 2010 13:21:53 +0200, Jens Rehsack
> wrote:
>
> > > Does that sound ok?
> >
> > Partially for me.
> >
> > 1) I don't know which svn version is used to store the repository,
> >so we might run into trouble when
Thankfully RT#61445 hasn't turned out to be a major problem.
Presumably because none of the cpantesters, so far, are using
"~/Library/Application Support/.cpan" as their build path.
And the "whitespace characters in the current directory path" warning
that Makefile.PL issues may be helping those wh
On Mon, Sep 20, 2010 at 02:45:27PM +0200, Jens Rehsack wrote:
> 2010/9/19 Craig A. Berry :
> > In article <20100911171359.gb2...@timac.local>,
> > tim.bu...@pobox.com (Tim Bunce) wrote:
> >
> >> On Thu, Sep 09, 2010 at 06:05:09PM -0500, Craig A. Berry wro
On Wed, Sep 15, 2010 at 03:41:36PM +0200, Jens Rehsack wrote:
> 2010/9/15 Tim Bunce :
> > On Mon, Aug 09, 2010 at 10:13:03PM +0300, Gabor Szabo wrote:
> >> The next European PostgreSQL day is going to be between 6-8 December
> >> in Stuttgart, Germany. http://www.p
On Sat, Sep 18, 2010 at 12:12:21PM +, Jens Rehsack wrote:
> On 09/18/10 10:26, H.Merijn Brand wrote:
> >On Sat, 18 Sep 2010 09:13:15 +, Jens Rehsack
> > wrote:
> >
> >>>(I may also move the code to github to make it easier, presumably, for
> >>>others to work together on branches without a
On Fri, Sep 17, 2010 at 09:13:20PM +0100, Martin J. Evans wrote:
> >DBI.xs:4965: warning: value computed is not used
> >
> >New DBIx::Connector now on its way to CPAN, too.
Thanks.
> They are all hv_store calls and hv_store returns a value.
>
> I think they are all harmless and the only way to m
Did you run make test?
This causes a whole bunch of (gofer related) test failures for me:
t/zvg_51dbm_file.t (Wstat: 512 Tests: 8 Failed: 0)
t/zvxgn_51dbm_file.t (Wstat: 512 Tests: 8 Failed: 0)
t/zvxgnp_51dbm_file.t(Wstat: 512 Tests: 8 Failed: 0)
t/zvxgp_51dbm_file.t
No tests?
Tim.
On Wed, Sep 15, 2010 at 10:48:36PM -0700, rehs...@cvs.perl.org wrote:
> Author: REHSACK
> Date: Wed Sep 15 22:48:35 2010
> New Revision: 14407
>
> Modified:
>dbi/trunk/Changes
>dbi/trunk/lib/DBD/DBM.pm
>dbi/trunk/lib/DBD/File.pm
>dbi/trunk/lib/DBD/File/Developers.p
On Wed, Sep 15, 2010 at 10:35:03AM -0400, John Scoles wrote:
> Ok here I am again for the fourth time :(
>
> You can find it here
>
> http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.25-RC4.tar
John, I've mentioned this to you before, and so have the svn.perl.org
admins: PLEASE DO NOT U
On Mon, Aug 09, 2010 at 10:13:03PM +0300, Gabor Szabo wrote:
> The next European PostgreSQL day is going to be between 6-8 December
> in Stuttgart, Germany. http://www.pgday.eu/
>
> It seems like a very cool conference and it might be interesting to
> offer some Perl related talks there. It mig
On Thu, Sep 09, 2010 at 06:05:09PM -0500, Craig A. Berry wrote:
> In article <4c88ecbf.8040...@easysoft.com>,
> martin.ev...@easysoft.com ("Martin J. Evans") wrote:
>
> > I ran DBI trunk on VMS (perl, v5.8.1 built for VMS_AXP) just to check it
> > out.
> > There were a lot of failures.
>
> I
On Tue, Sep 07, 2010 at 09:43:50PM +0100, Mark Morgan wrote:
> On 7 September 2010 20:52, Tim Bunce wrote:
> >
> > Assuming you go with this approach (did I mention it was highly
> > recommended :) then your logic would live in a Gofer transport class
> > like DBI::G
On Tue, Sep 07, 2010 at 05:29:44PM +0100, Mark Morgan wrote:
> Heya folks,
>
> I'm looking to write DBD::Mock (proposed name) that can be used for
There's already a DBD::Mock http://search.cpan.org/perldoc?DBD::Mock
> transparent mocking of other DBDs for purposes of integration tests, and am
>
On Mon, Sep 06, 2010 at 03:29:11PM +0200, rosenfield.alb...@gmail.com wrote:
> > Where do you get the 70%/30% ratio from?
>
> Uploaded a package to CPAN with
> - a test that fails when DBI is not installed, and
> - a Build.PL which does not indicate that DBI is a requirement (even
> though it is
On Sun, Sep 05, 2010 at 05:17:45PM -0700, Darren Duncan wrote:
> Okay, I'm not sure I understand the problem here.
>
> I thought that the point of PERL_POLLUTE was to provide things that
> were removed from the Perl core so that code which depends on the
> old removed APIs would continue to work w
On Wed, Sep 01, 2010 at 02:18:19PM +0200, Jens Rehsack wrote:
> 2010/8/31 Tim Bunce :
> > On Mon, Aug 30, 2010 at 01:49:10PM -0700, hmbr...@cvs.perl.org wrote:
> >> Log:
> >> Fix for failing t/50 when old SQL::Statement available (e.g. 1.16)
> >
> > Does t
On Wed, Sep 01, 2010 at 08:56:22AM +0200, H.Merijn Brand wrote:
> On Tue, 31 Aug 2010 21:07:46 -0700, Darren Duncan
> wrote:
>
> > Tim Bunce wrote:
> > > On Tue, Aug 31, 2010 at 08:55:32AM -0700, David E. Wheeler wrote:
> > >> On Aug 31, 2010, at 2:52 AM,
On Mon, Aug 30, 2010 at 01:49:10PM -0700, hmbr...@cvs.perl.org wrote:
> Log:
> Fix for failing t/50 when old SQL::Statement available (e.g. 1.16)
Does this fix http://www.cpantesters.org/cpan/report/8392757 ?
> my $dbi_sql_nano = $ENV{DBI_SQL_NANO};
> unless( $dbi_sql_nano ) {
> -$@ = undef
On Tue, Aug 31, 2010 at 08:55:32AM -0700, David E. Wheeler wrote:
> On Aug 31, 2010, at 2:52 AM, Tim Bunce wrote:
>
> > It's back in. I may remove it for 1.615 or, more likely, may leave it out
> > and
> > individual developers deal with failure reports on perl 5.13.
On Mon, Aug 30, 2010 at 02:15:32PM -0700, Darren Duncan wrote:
> Tim Bunce wrote:
> >What's the state of play?
>
> Will DBI 1.614 still lack the POLLUTE or did you put that back in? -- Darren
> Duncan
It's back in. I may remove it for 1.615 or, more likely, may
On Mon, Aug 30, 2010 at 01:13:30PM -0700, Jonathan Leffler wrote:
>
> Where do I download DBI 1.613_71 from? I go the DBI 1.613 page at
> search.cpan.org and click on the link that says "download the latest dev
> build" which is identifies as 1.613_71, but it goes to a 404 page.
There are severa
What's the state of play?
Tim.
The renaming is prety trivial and mechanical.
Tim.
On Mon, Aug 30, 2010 at 07:28:31AM -0400, John Scoles wrote:
> Tim Bunce wrote:
>
> Looks like DBD::Oracle as PERL_POLLUTE as well.
>
> Lucy!!! You have some renaming to do!!!
>
> A project of 1.26 perhaps
>
> che
On Fri, Aug 27, 2010 at 09:53:09PM +0100, Tim Bunce wrote:
>
> Perl 5.13.3+ removes support for PERL_POLUTE. [...]
[Sigh] s/PERL_POLUTE/PERL_POLLUTE/g
Tim [a little too much wine with friends this evening me'thinks]
Short version:
Please download build test *and install* DBI 1.613_71, then download build
and test any compiled drivers you use to check they work with DBI 1.613_71.
Let us know about any failures *and* successes.
Also grep the source code of the driver to see if it defines
PERL_POLUTE. If it do
Rather than a skeleton I think I'd prefer an actual useful simple driver
with an implementation that's kept clean and clear enough for use as a
base for cloning. I.e., a "reference implementation".
It would also be handy if the driver had a name that was easy/safe to do
a global replace on. Then w
On Wed, Aug 04, 2010 at 10:51:41PM +0200, H.Merijn Brand wrote:
>
> My intention was/is to have a DBI replacement for DB_File, so the
> *only* thing I have to change to use it is
>
> tie my %hash, "DB_File", "file.db", O_RDWR|O_CREAT, 0666;
>
> with
>
> tie my %hash, "Tie::DBD", $dbh;
>
I missed this thread, so I'm sorry for my late reply.
On Thu, Jul 22, 2010 at 8:28 PM, Jan Dubois wrote:
> I think the "correct" way would be to update the sources to use the "new"
> names and not add defines for the old ones. It is really up to the
> maintainers of DBI to decide what to do, bu
On Fri, Jul 23, 2010 at 10:16:16AM +, Jens Rehsack wrote:
> On 07/20/10 19:20, Tim Bunce wrote:
> >>I can imagine at least 2:
> >>1) Bundle::DBD::DBM
> >> - requires DB_File and BerkeleyDB
> >> - requires MLDBM, MLDBM::Serializer::JSON and YAML::MLDBM
On Tue, Jul 20, 2010 at 09:46:42PM +0100, Martin J. Evans wrote:
> [...]
>
> As a result of the above, I don't see any way of supporting the existing
> blob_read in DBI and as it is undocumented anyway and no DBDs seem to
> use it
Feel free to mark it deprecated in the DBI docs..
> I've put a te
On Sun, Jul 18, 2010 at 07:50:16PM +0200, Jens Rehsack wrote:
> Hi Tim,
>
> yesterday after updating the pkgsrc packages around DBI while having
> picknick at the event Cologne lights up
> (http://www.koelner-lichter.de/pages/en.html),
Nice.
> I had an idea
> (nothing new, nothing great): how ab
- Forwarded message from Serguei Trouchelle via RT
-
Date: Tue, 20 Jul 2010 10:55:17 -0400
From: Serguei Trouchelle via RT
To: undisclosed-recipients: ;
Subject: [rt.cpan.org #59568] Wrong prerequisite for MSWin32
Tue Jul 20 10:55:16 2010: Request 59568 was acted upon.
Transaction: Tic
Hello Taro!
Firstly, thank you for being a cpantester and helping us improve the
quality of our code.
I see you've sumbitted a test failure for "DBI-1.611_94 v5.8.8 Windows"
http://www.cpantesters.org/cpan/report/7996865
Sadly we've not been able to identify a cause or reproduce the problem.
Ca
On Fri, Jul 09, 2010 at 07:47:00AM +0200, H.Merijn Brand wrote:
> On Thu, 8 Jul 2010 15:56:38 -0700, "David E. Wheeler"
> wrote:
>
> > Underscores should be banned from version numbers. Full stop.
>
> In principle, and as an end-user I would wholeheartedly agree, but the
> way CPAN /and/ CPANTE
My take on this, for the record, is to prefer two part numbers
in the form X.YYY where YYY never has a trailing zero.
Short, sweet, simple.
Tim.
p.s. No one commented on the DBI going from 1.609 to 1.611 :)
On Thu, Jul 08, 2010 at 04:33:28PM +, Jens Rehsack wrote:
> On 07/08/10 14:21, Gabor Szabo wrote:
>
> >How do you think vendors could help?
> >(Giving money?, Giving software licenses? Allocating developer time?)
>
> If a company would hire/contract DBI/DBD developers to get a specific
>
FYI
- Forwarded message from David Golden -
Date: Thu, 8 Jul 2010 06:52:57 -0400
From: David Golden
To: Nigel Horne
Cc: CPAN Testers Discuss
Subject: Re: CPAN::Reporter: test results were not valid, Prerequisite
version too *high*
On Thu, Jul 8, 2010 at 3:48 AM, Nigel Horne
On Fri, Jul 02, 2010 at 08:43:08AM +0200, Jens Rehsack wrote:
> Hi Tim,
>
> I think it's time for a new DBI development release. I've uploaded
> SQL-Statement-1.27_02 a few minutes ago waiting for DBI-1.611_93 ;)
> When it's out, I put DBD-AnyData-0.10_90 upstream, too. I think,
> Merijn will do t
On Wed, Jun 23, 2010 at 07:56:14PM +0200, Jens Rehsack wrote:
> 2010/6/23 Tim Bunce :
> > On Wed, Jun 23, 2010 at 04:18:27PM +0200, Jens Rehsack wrote:
> >>
> >> Of course, another way could be to extract the SQL-engine interface
> >> from DBD::File into a DBI::
On Wed, Jun 23, 2010 at 04:18:27PM +0200, Jens Rehsack wrote:
>
> Of course, another way could be to extract the SQL-engine interface
> from DBD::File into a DBI::DBD::SqlEngine and DBD::AnyData uses that
> without caring of DBD::File (for some time until we could do better).
> That's why I ask:
On Wed, Jun 16, 2010 at 03:18:15PM +0200, Jens Rehsack wrote:
> 2010/6/16 Tim Bunce :
> > On Wed, Jun 16, 2010 at 08:41:27AM +0200, Jens Rehsack wrote:
> >> 2010/6/16 Tim Bunce :
> >> > On Tue, Jun 15, 2010 at 09:10:38PM +0200, Jens Rehsack wrote:
> >> >
On Wed, Jun 16, 2010 at 08:41:27AM +0200, Jens Rehsack wrote:
> 2010/6/16 Tim Bunce :
> > On Tue, Jun 15, 2010 at 09:10:38PM +0200, Jens Rehsack wrote:
> >> Hi Tim,
> >>
> >> from my point of view, the current trunk of DBI is ready to be shipped
> >>
On Wed, Jun 16, 2010 at 09:03:09AM +0200, Jens Rehsack wrote:
> 2010/6/16 Tim Bunce :
> > On Tue, Jun 15, 2010 at 09:10:38PM +0200, Jens Rehsack wrote:
> >> Hi Tim,
> >>
> >> from my point of view, the current trunk of DBI is ready to be shipped
> >&g
On Tue, Jun 15, 2010 at 09:10:38PM +0200, Jens Rehsack wrote:
> Hi Tim,
>
> from my point of view, the current trunk of DBI is ready to be shipped
> as next development release.
Not in MANIFEST: t/51dbm_file.t
Not in MANIFEST: t/52dbm_complex.t
Should they be in the MANIFEST?
Tim.
Also, FYI, please don't use tim.bu...@gmail.com - I use it as a
read-only archive and (occasionally) route outbound smtp through it.
Any email sent only there is very unlikely to be seen.
Tim.
On Tue, Jun 15, 2010 at 09:10:38PM +0200, Jens Rehsack wrote:
> Hi Tim,
>
> from my point of view, the current trunk of DBI is ready to be shipped
> as next development release.
Great.
> Because it should be uploaded together with the development release of
> SQL::Statement, we should synchroniz
On Wed, Jun 09, 2010 at 02:45:18PM +, Jens Rehsack wrote:
> On 06/09/10 14:36, Tim Bunce wrote:
> >>
> >>The interface of the per-table API doesn't allow that :(
> >>That's exactly the reason why I thought it's required to warn about that.
> &g
On Tue, Jun 08, 2010 at 02:12:18PM +0200, H.Merijn Brand wrote:
> > > Any suggestions?
> >
> > I'm not really sure I understand the question/proposal/issues.
>
> for all DBD::File methods/functions that are shared between ad_, csv_,
> dbm_, and po_ (and maybe more in the future), the f_ method as
On Tue, Jun 08, 2010 at 11:54:32AM +, Jens Rehsack wrote:
> On 06/08/10 11:42, Tim Bunce wrote:
> >On Fri, Jun 04, 2010 at 04:12:18AM -0700, rehs...@cvs.perl.org wrote:
> >>
> >>+statements really do the same (even if they mean something completely
> >&g
On Tue, Jun 01, 2010 at 11:10:44AM +, Jens Rehsack wrote:
> Hi Tim,
>
> during the update of DBD::AnyData I hit some nice methods, which
> Jeff has added to it, e.g. ad_get_catalog, ad_mod_catalog and
> ad_clear.
>
> These methods modify the meta data of the tables managed by DBD::AnyData
> (
On Fri, Jun 04, 2010 at 04:12:18AM -0700, rehs...@cvs.perl.org wrote:
>
> +This modules uses hash interfaces of two column file databases. While
> +none of supported SQL engines have a support for indeces, following
s/indeces/indices/
> +statements really do the same (even if they mean somethin
On Mon, Jun 07, 2010 at 09:52:52PM +0200, H.Merijn Brand wrote:
> On Mon, 07 Jun 2010 13:51:26 -0400, John Scoles
> wrote:
>
> Summary:
>
> ☑ unicode => Unicode
> ☐ DBDs<= DBD's
> ☐ DSNs<= DSN's
> ☑ unlikey => unlikely
> ☑ abreviated => abbreviated
> ☐ NULLs
On Sun, May 30, 2010 at 12:33:44PM +0200, H.Merijn Brand wrote:
> In DBI-1.611 I introduced f_encoding for tables. That works great.
>
> In 1.611, f_encoding was evaluated from the database handle each time a
> table (file) was opened, so
>
> my $dbh = DBI->connect ("dbi:File:");
>
> $dbh->{
On Thu, May 27, 2010 at 01:05:05PM +0200, H.Merijn Brand wrote:
> On Thu, 27 May 2010 09:53:02 +, Jens Rehsack
> wrote:
>
> > Hi developers,
> >
> > during refactoring of DBD::File and new wishes (e.g. SQL_IDENTIFIER_CASE
> > from Martin Evans, getinfo() support, ...) and my own try of a pur
On Mon, May 10, 2010 at 08:57:01PM +0100, Martin J. Evans wrote:
>> [1]rosenfield.alb...@gmail.com wrote:
>
>>> In practice this results in circa 70% of smoke testers running the
>>> module with DBI installed.
>>> The remaining 30% however, fails with this error:
>
>> Where d
Sorry for the delay replying, and the top-post.
All sounds good. Thanks!
Tim.
On Thu, May 06, 2010 at 10:28:29AM +, Jens Rehsack wrote:
> Hi Tim, hi DBI developers,
>
> inspired by the issues reported against DBD::DBM and SQL::Statement
> regarding Test-Database, I checked SQL::Statement, D
On Sun, May 09, 2010 at 10:45:23PM -0700, rehs...@cvs.perl.org wrote:
> - move from "die" to "croak"
> +croak "Can't find columns\n" unless $self->{column_names};
> +croak "Can't find columns\n" unless $self->{column_names};
> +croak "Can't parse valu
It would be nice to also get coverage of the nano + DBI::PurePerl case.
Tim.
On Fri, May 07, 2010 at 02:18:46PM +0200, Jens Rehsack wrote:
> Hi,
>
> as requested, I'd like to allow tests against SQL::Statement for those
> DBD's which support it, too.
> If no one has objections, I'd like to commi
[Sorry for the delay]
On the one hand, the DBI makes a distinction between "method attributes"
and "handle attributes. They're different things.
On the other hand, the handle constructor methods are a special case.
The method attributes passed to connect() are applied to the newly
created dbh as
On Sun, Mar 28, 2010 at 11:40:35PM +0200, rosenfield.alb...@gmail.com wrote:
> In practice this results in circa 70% of smoke testers running the
> module with DBI installed.
>
> The remaining 30% however, fails with this error:
> =
> # Failed test 'use DBI;'
> #
On Fri, Apr 30, 2010 at 08:53:19AM +0200, H.Merijn Brand wrote:
> On Fri, 30 Apr 2010 06:20:02 +, Jens Rehsack
> wrote:
>
> > On 04/29/10 17:32, Tim Bunce wrote:
> > > On Wed, Apr 28, 2010 at 12:49:21PM +, Jens Rehsack wrote:
> > >> Hi Tim,
> >
401 - 500 of 1961 matches
Mail list logo
