Congrats guys - glad this finally came about.
On Tue, 7 Apr 2009, Darren Duncan wrote:
All,
I am pleased to announce that DBD::SQLite (Self Contained RDBMS in a DBI
Driver) version 1.20 has been released on CPAN.
http://search.cpan.org/dist/DBD-SQLite/
This follows on the heels of 10 deve
On Fri, 27 Mar 2009, Greg Sabino Mullane wrote:
I have tried emailing Matt several times without response already.
Did you cc modu...@perl.org? What did they say? They've been helpful
with me in the past in tracking module owners down.
I very rarely read mailing list mail these days - my lif
On 15-Feb-06, at 4:23 AM, Tim Bunce wrote:
But is that needed? We're not changing any interfaces here - just
suggesting (strongly) to driver authors that defining
PERL_NO_GET_CONTEXT
is 'best practice'.
The problem is it causes errors if you define it with the current DBI:
[EMAIL PROTECTED
On 14-Feb-06, at 6:20 PM, Gisle Aas wrote:
There isn't currently a DBI_VERSION to test against. DBIXS.h does
define DBIXS_VERSION and this could have been incremented, but
PERL_NO_GET_CONTEXT need to be defined before this file is included.
If DBIXS_VERSION was moved to a different header file
On 6-Feb-06, at 5:10 PM, Tim Bunce wrote:
On Mon, Feb 06, 2006 at 05:53:18AM -0800, Gisle Aas wrote:
Tim Bunce <[EMAIL PROTECTED]> writes:
I agree. Any chance yould you patch lib/DBI/DBD.pm to add in a
section
describing what driver authors need to do?
Is this enough?
That's great. I tw
On 22 Jul 2005, at 12:30, Dean Arnold wrote:
Hoping someone can point me at a DBD thats known
to be non-thread-friendly (ie, hasn't implemented
the clone() methods). However, its underlying
client libs and XS subs (if any) do need to be
thread-capable (ie, no writing to process-global
variables
On 14 Jul 2005, at 13:16, David Nicol wrote:
I have uploaded asynchronous::universal::ready and
asynchronous::universal::set_callback
to CPAN. They are both entirely trivial packages with a mess of
documentation. The
idea behind them is to support asynchonous frameworks in which the
immediate
On 18 Sep 2004, at 22:00, Darren Duncan wrote:
Meanwhile, I eagerly look forward to another DBD::SQLite 1.x release
which bundles 3.0.7 and provides its own interface to the named
params.
I've updated to 3.0.7, but not done named params yet. 1.06 is heading
to CPAN as I type this. 1.07 will add
On 18 Sep 2004, at 22:00, Darren Duncan wrote:
This afternoon, the http://www.sqlite.org/ was updated to declare that
SQLite 3.x is now officially stable with the new 3.0.7 release;
previously it was in beta status. This is a big milestone.
One of the things that this version adds (AFAIK), whic
On Thu, 9 Sep 2004, Dominic Mitchell wrote:
> Even if your DB library doesn't provide access to the file descriptor,
> you can still use the self pipe trick to work around that.
>
>http://cr.yp.to/docs/selfpipe.html
I believe that's exactly what I'm talking about. Only if your DB doesn't
noti
On 9 Sep 2004, at 08:14, Jonathan Leffler wrote:
==> Yes this class of issues can be trivially solved by demanding
threading,
==> but that does not help when a(n unrealistic?) design constraint
limits
==> you to one thread.
This worries me. I really think that asynchronous support via
thread
On 3 Sep 2004, at 17:19, David Wheeler wrote:
On Sep 2, 2004, at 8:58 PM, Darren Duncan wrote:
In order for 'make test' to see a perl module that is being stored
under the t/ directory in a Perl module distribution, rather than the
lib/ directory with the main modules, I found that adding a simpl
On 2 Sep 2004, at 23:31, Tim Bunce wrote:
I haven't had a chance to read through all the comments in this thread
yet,
but I'll point out two flies in the ointment:
1. Many database API's don't offer access to the filehandle.
2. Even for those that do, just because the filehandle becomes
'readabl
On 1 Sep 2004, at 03:13, david nicol wrote:
Based on this comment I would like to extend the proposed extension
to include an optional $h->fileno() method, which would return
an arrayref containing file descriptor numbers for use in the main
event loop, so a busy event-driven system will know when
As an addition to this thread, I just wanted to add that having each
DBD implement their own event loop (via select() or otherwise) is not
acceptable. Anyone who has done event driven programming will
understand the mantra: There can be only one. Only one event loop that
is. If you implement an
On 26 Aug 2004, at 16:48, Dean Arnold wrote:
While this handles async execution, esp. in support of multiconnection
operations relevant to Teradata's parallel nature,
it doesn't really handle async completion notification, and
I'm not certain there's a clean, DBMS-independent way to support
that wi
On Mon, 23 Aug 2004, Tim Bunce wrote:
> #ifndef no_last_insert_id
> #define dbd_db_last_insert_id sqlite_db_last_insert_id
> #endif
>
> pass a -Dno_last_insert_id to the compiler is using DBI 1.42.
OK, I've done that. (and uploaded DBD::SQLite 1.04 to cpan).
--
<:->get a SMart net
I am Jack's
There was a change in prototype for dbd_db_last_insert_id in 1.43.
How should DBD developers handle this change in their code?
--
<:->get a SMart net
I am Jack's broken heart.
On 8 Aug 2004, at 17:35, David Wheeler wrote:
On Aug 8, 2004, at 9:14 AM, Matt Sergeant wrote:
i.e. for every fetch call, you need to do:
SvUTF8_off(AvARRAY(av)[i]);
Now, people using your DBD can decide to upgrade the variable if they
wish to, but most people who don't need to wi
OK, sorry to bring up everyone's least favourite subject, but I had a
conversation with Nick Clark at OSCon, who suggested that the best
route to Unicode conformance (for now - until DBIv2) is to actually
explicitly turn off the UTF-8 flag when you populate the record AV
during fetch(). The rea
On 6 Aug 2004, at 08:53, Jochen Wiedmann wrote:
Matt Sergeant wrote:
And easier to implement in C.
I never found any difficulties in the methods handling properties?
It's the difference between implementing a function called xyz and
doing a string comparison for xyz. It's easier to ma
On 3 Aug 2004, at 14:41, John Siracusa wrote:
On Tue, 03 Aug 2004 09:35:25 +0200, Jochen Wiedmann
That gains absolutely *no* functionality
It's a heck of a lot easier to subclass...
And easier to implement in C.
Matt.
On 18 Jan 2004, at 17:14, John Siracusa wrote:
This topic came up before, when DateTime was just getting off the
ground.
DateTime is a lot more mature now, and I still think it's a good idea
:)
Along those lines, all of my DBI wrappers have also had a uniform API
for
DB-specific date parsing a
On 16 Oct 2003, at 22:12, Dean Arnold wrote:
Has anyone attempted to write a DBD
using Inline::C (or C++) ? I'm looking into updating a driver
to selectively switch between a pure Perl implementation,
and a native C i/f to a low level vendor API library if its available,
in order
to get more perf
On Wednesday, Aug 13, 2003, at 21:24 Europe/London, Perrin Harkins
wrote:
On Wed, 2003-08-13 at 16:07, David Wheeler wrote:
On Wednesday, August 13, 2003, at 12:32 PM, David Wheeler wrote:
The code that's causing the hangup looks like this:
First, we all need to yell at you for not using Apache:
On Wednesday, Aug 13, 2003, at 22:46 Europe/London, Perrin Harkins
wrote:
My idea would be to leave Apache::DBI as it is for use with legacy CGI
code and then add a new module to the distribution that is called
explicitly so it has no "distance" issues. Maybe call it
Apache::DBI::Factory?
There
On Tue, 21 Jan 2003, John Siracusa wrote:
> On 1/21/03 3:38 AM, H.Merijn Brand wrote:
> > FWIW *if* there should be a default date format for DBI, *please* make it
> > universal: MMDD and not MMDD or MM/DD/, because you have no idea
> > how much irritation this arouses in European coun
On Wednesday, Dec 18, 2002, at 01:26 Europe/London, Jeff Zucker wrote:
Just a preliminary report - thanks to Rainier Keuchel's port of perl
to winCE, I now have DBI (PurePerl) and DBD::AnyData doing database
read access on my Toshiba e740 (a palm-like handheld running pocketPC
on an xScale pro
On Wed, 4 Dec 2002, H.Merijn Brand wrote:
> I'm working in a multi DB environment, and ddd statements prove to be as
> unportable as hell, to say the least :)
>
> My scripts however should be able to deal with whatever database (supported by
> us) is thrown at it. At current time it is Unify and O
On Tue, 26 Nov 2002, Graham Barr wrote:
> On Tue, Nov 26, 2002 at 10:51:10AM +0000, Matt Sergeant wrote:
> > On Mon, 25 Nov 2002, Graham Barr wrote:
> >
> > > If the inclusion of modules in distributions is common and t/ is not
> > > acceptable then a common p
On Mon, 25 Nov 2002, Graham Barr wrote:
> If the inclusion of modules in distributions is common and t/ is not
> acceptable then a common place should be agreeded. I almost suggested
> this recently with the release of CPAN::MakeMaker which depends on .
> being in @INC. But it has the side affect
ODBC has a built-in standard for this - I forget exactly what it is, but
it's something like {d -MM-DD}, {t HH:MM:SS} and {ts -MM-DD
HH:MM:SS}
(for input, that is - I think output is still database specific, but I
could be wrong).
Alternatively, you could specify something like a Time
On Mon, 11 Mar 2002, H.Merijn Brand wrote:
> On Mon 11 Mar 2002 01:12, [EMAIL PROTECTED] wrote:
> > On Sun, 10 Mar 2002, Jonathan Leffler wrote:
> >
> > Hrm, any reason why this cannot (or should not?) be done with yacc?
> >
> > Give each driver its own .y grammar file, however keep the tags cons
On Wed, 31 Dec 1969, Terrence Brannon wrote:
> Call me paranoid. I have never ever had a database connection die
> after I got it.
>
> However, I feel funny writing a book on coding Industry-Strength
> DBI (co-authors welcome)
> without being able to say "...and via this attribute or hook, all
>
On 21 Feb 2002, Jeff Zucker wrote:
> Tim Bunce wrote:
> >
> > On Wed, Feb 13, 2002 at 01:52:11PM -0800, Jonathan Leffler wrote:
> > >
> > > I've been emulating a pseudo-SQL command, UNLOAD, in DBI and
> > > DBD::Informix, and one of the messy parts is handling the mapping of
> > > undef into an e
On Wed, 20 Feb 2002, KAWAI,Takanori wrote:
> - Original Message -
> From: "Matt Sergeant" <[EMAIL PROTECTED]>
> To: "KAWAI,Takanori" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 19, 2002 10:16 PM
> Subject
On Tue, 19 Feb 2002, KAWAI,Takanori wrote:
>
> - Original Message -
> From: "Matt Sergeant" <[EMAIL PROTECTED]>
> To: "KAWAI,Takanori" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 19, 2002 6:45 PM
>
On Tue, 19 Feb 2002, H.Merijn Brand wrote:
> On Tue 19 Feb 2002 08:12, Matt Sergeant <[EMAIL PROTECTED]> wrote:
> > On Tue, 19 Feb 2002, KAWAI,Takanori wrote:
> > > On Tue, 19 Feb 2002 04:29, Matt Sergeant" <[EMAIL PROTECTED]> wrote:
> > >
On Tue, 19 Feb 2002, KAWAI,Takanori wrote:
> Thank you for your fast fix.
No, thank *you* for testing it ;-)
> It works almost fine.
> But unfortunately, it makes a error when I call execute twice on the
> same statement handle.
OK, new release out - http://axkit.org/download/DBD-SQLite-0.03.t
On Tue, 19 Feb 2002, KAWAI,Takanori wrote:
> - Original Message -
> From: "Matt Sergeant" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 19, 2002 4:29 AM
> Subject: DBD::SQLite
>
>
> > I've finished my first
On 18 Feb 2002, Jeff Zucker wrote:
> Matt Sergeant wrote:
> >
> > Some benchmarks:
> >
> > First DBD::CSV latest from CPAN:
> >
> > Using /root/.cpan/build/DBD-CSV-0.2001/blib
>
> The relevant thing for the speed of DBD-CSV is the version of
> SQL:
On Tue, 19 Feb 2002, KAWAI,Takanori wrote:
> - Original Message -
> From: "Matt Sergeant" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 19, 2002 4:29 AM
> Subject: DBD::SQLite
>
>
> > I've finished my first
Some benchmarks:
First DBD::CSV latest from CPAN:
Using /root/.cpan/build/DBD-CSV-0.2001/blib
Testing empty loop speed ...
10 iterations in 0.2 cpu+sys seconds (624999 per sec)
Testing connect/disconnect speed ...
2000 connections in 2.4 cpu+sys seconds (840 per sec)
Testing CREATE/DROP T
I've finished my first stab at DBD::SQLite.
It's a simple driver for small needs databases, such as when you want
something to ship with a product to demo it, or when DBD::CSV isn't fast
enough, or when MySQL is too much.
It includes the entire transaction capable RDBMS code in the DBD driver,
a
On Mon, 18 Feb 2002, Sterin, Ilya wrote:
> Hmmm, how would you pass that function to execute. I don't believe the dbi
> interface allows that right now. Maybe func() will have to do. Unless you
> can fake a bind var as an actual function reference.
It wouldn't be a perl callback - just a C on
DBI uses "pull" - you execute a statement then pull the results one by
one - exactly the same as a cursor in SQL terms.
But I'm working on a DBD driver [1] for a "push" engine - you pass a
callback function to execute() and it calls that for every row in the
result set.
Has anyone done a DBD dri
On 2 Feb 2002, Jeff Zucker wrote:
> Tim Harsch wrote:
> >
> > I am writing perl software that I would like validate against a test
> > suite. I kind of like the Perl method of 'make test' I've seen in so
> > many modules. If any of you know a tutorial or have a trival test suite
> > I can expan
On 2 Feb 2002, Brian Aker wrote:
> I am in somewhat of a pickle right now.
>
> SQL::Catalog is written to work with DBIx::AnyDBD, but
> DBIx::Password, by policy, will only return a database connection
> not database connection information. However, the DBIx::AnyDBD
> constructor requires connect
On Fri, 11 Jan 2002, Terrence Brannon wrote:
> in Example::DB in DBIx::AnyDBD, we see code which always returns
> a viable database handle or throws an exception. The question is
> shouldn't this type of behavior be available as part of DBI?
>
> sub instance {
> if ($DB && $DB->ping) {
>
On Fri, 11 Jan 2002, Terrence Brannon wrote:
> I was wondering something about DBIx::AnyDBD's implementation:
>
> Since eval "require $class" will automatically do a substitution
> of :: for / and then append .pm why does AnyDBD.pm always opt for
> specifying $filename.pm instead of specifying $m
On Thu, 27 Dec 2001, Tim Bunce wrote:
> On Thu, Dec 27, 2001 at 04:04:55PM +0000, Matt Sergeant wrote:
> > On Thu, 27 Dec 2001, Tim Bunce wrote:
> >
> > > Or maybe this would work:
> > >
> > > $dbh = DBI->connect("dbi:Or
On Thu, 27 Dec 2001, Tim Bunce wrote:
> Or maybe this would work:
>
> $dbh = DBI->connect("dbi:Oracle:...", "","", { RootClassThingy => "MySubclass"
>});
>
> Giving a class hierarchy like:
>
> DBI::db
>`-- MySubclass::db
> `-- MySubclass::Oracle::db
But to what purp
On Wed, 26 Dec 2001, Tim Bunce wrote:
> On Mon, Dec 10, 2001 at 09:22:16PM -0000, Matt Sergeant wrote:
> > What I can see doing here is returning a subclass of DBI using similar rules
> > to what's in AnyDBD... However, one thing AnyDBD does, which makes it
> > us
On Mon, 24 Dec 2001, Terrence Brannon wrote:
> I am inlining a classic example of DBI subclassing written by
> Stephen Clouse and posted to dbi-users awhile back. My point in
> doing so is to ask how the fact that AnyDBD groks with @ISA would
> affect the $dbh of a straightforward DBI subclass li
On Mon, 24 Dec 2001, Terrence Brannon wrote:
> Because AnyDBD needs to handle $dbh connection creation, it is
> necessary for DBIx::Password to return the connection information
> hash instead of conveniently making the connection.
I'd venture to suggest that's a bug. A slight re-implementation
On Mon, 24 Dec 2001, Terrence Brannon wrote:
> I instrumented AnyDBD.pm because I could not get my module loaded:
>
> no strict 'refs';
> my $dir;
> ($dir = $self->{package}) =~ s/::/\//g;
> use Cwd;
> my $cwd = getcwd;
> load_module("$dir/Default.pm") or die "Cannot fi
On Tue, 11 Dec 2001, Terrence Brannon wrote:
>
> On Monday, December 10, 2001, at 08:48 AM, Tim Bunce wrote:
> > At this point I'd just like to solicit some feedback from anyone
> > who's used DBIx::AnyDBD and got any ideas or comments etc about it
> > and how it could be improved.
> >
>
> I read
hinking strongly of merging DBIx::AnyDBD into the DBI.
>
> DBIx::AnyDBD is orthogonal and complementary to the planned
> support for parsing and rewriting ODBC SQL escape sequences.
> Both are key parts of the DBI growing to address portability
> among SQL dialects.
>
> I like t
On Mon, 10 Dec 2001, Mike wrote:
> I'm just completing MSc (using DBI)and would appreciate any more info on
> DBIx::AnyDBD. Is anything else available?
Unfortunately I do a lot of talking in my talks, so the slides won't
really cover everything you want to know, so feel free to ask. But here's
t
59 matches
Mail list logo
