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
Subject: Re: DBD::SQLite
On Tue, 19 Feb 2002, KAWAI,Takanori wrote:
(snip
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: Re: DBD::SQLite
(snip)
OK, new release out - http://axkit.org
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 empty string so
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
of your
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 consistent
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
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
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
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
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 countries.
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
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 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
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
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 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 make it more
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?
--
!-- Matt --
:-get a SMart net/:-
I am Jack's broken heart.
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).
--
!-- Matt --
:-get a SMart net/:-
I am
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
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
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
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
notify
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 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 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
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 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
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
28 matches
Mail list logo
