Re: ANN - DBD::SQLite version 1.20
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 developer releases released starting 2009 March 27th (Adam Alias Kennedy has been doing release management). The previous production release of DBD::SQLite was version 1.14 about 18 months ago. Improvements in 1.20 over 1.14 include: * Updated the bundled SQLite library from v3.4.2 to v3.6.12, which carries many new features as well as bug fixes. * Added support for user-defined collations. * Added -column_info(). * Resolved all but a handful of the 60+ RT items. * Many bug fixes and minor enhancements. * Added more tests, large refactoring of tests. * Minimum dependencies are now Perl 5.006 and DBI 1.57. See http://cpansearch.perl.org/src/ADAMK/DBD-SQLite-1.20/Changes as well as http://sqlite.org/changes.html for details. Now it is especially important, since automatic updates from CPAN such as with the CPAN/CPANPLUS utilities, would now be pulling this new 1.20 by default, ... Please bash the hell out of the latest DBD::SQLite and report any outstanding bugs on RT. Test your dependent or compatible projects with it, which includes any DBMS-wrapping or object persistence modules, and applications. If you want in to DBD::SQLite development, then join the following email/IRC forums which MST created (the mailing list, I am administrating): http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite #dbd-sqlite on irc.perl.org And the canonical version control is at: http://svn.ali.as/cpan/trunk/DBD-SQLite/ Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null. Regarding near future plans: Now, the current 1.20 uses the pristine several-dozen SQLite library source files, same as 1.14 did. While reality may be different, I believe that the next major planned change to DBD::SQLite is to substitute in the amalgamation version, which combines all the SQLite source files into a single file; the amalgamation is the recommended form for users according to the SQLite core developers. See http://sqlite.org/download.html for a description of that. Meanwhile there should be another stable release with any bug fixes for 1.20 to come out first. Any other major changes or features for DBD::SQLite are expected to come out separately from and after the stabilized switch to the amalgamation sources. Please do not reply to me directly with your responses. Instead send them to the forums or file with RT as is appropriate. Thank you. -- Darren Duncan
Re: RFC: developing DBD::SQLite
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 life got too busy for it, so if you want to contact me directly you MUST NOT CC a mailing list, because otherwise my procmail will just dump it in a folder I'll never read. Matt.
Re: Add PERL_NO_GET_CONTEXT to DBI.xs
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 tweaked it a bit and appended the body of it below. Let me know if I've said anything wrong. Driver authors please take note! Can I add that in conditionally based on the DBI version? e.g. #if (DBI_VERSION 151) #define PERL_NO_GET_CONTEXT #endif Matt.
Re: Add PERL_NO_GET_CONTEXT to DBI.xs
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 this could have been made to work: #include DBIXS_VERS.h #if DBIXS_VERSION = 94 #define PERL_NO_GET_CONTEXT #endif #include DBIXS.h Shame. So I guess the other option is a MakeMaker pre-processing routine which modifies SQLiteXS.h Matt.
Re: Seeking *non* thread-friendly DBD
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 wo/ locking). I'm trying to test out a theory that DBIx::Threaded will make non-thread-friendly DBD's not only friendly, but thread-safe. DBD::SQLite.
Re: SQLite 3 declared stable today
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 the named params. Matt.
Re: interface ideas for non-blocking mode
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 threading is more sensible. It is also more likely to be widely achievable - IMNSHO. However, it is your itch, so you get to lay out your desires. However, be aware that not everyone suffers from the same sources of irritation as you do. So one way to do this to keep everyone happy might be to use threads to do things in the background, but use a file descriptor to notify of readiness. The DBI could do this transparently, or you could implement it natively if you preferred (or had access to your own descriptor that you could use). In terms of why I'm banging on about file descriptors, let me explain my itch. I work on very highly scalable network applications that process thousands of concurrent connections. In these programs NOTHING can block my event loop, because everything falls apart if I do. And I have to be very careful about slow system calls. If I can have a file descriptor it can fit in cleanly with my current event loop. If I can't, and have to rely on something like $sth-ready, which might call its own select() function, then I'm screwed, because select() is a slow system call. I'm absolutely willing to admit that my application is way out there compared to most people's. Matt.
Re: interface ideas for non-blocking mode
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 you, and you have to poll it, then you need to do that in a separate thread for this to work. I'm going to stop talking about this now, as it's clear I can make the filehandle thing work for me if I need it to, regardless of what scheme the DBI implements. I was just trying to think about efficiency for my apps. Matt.
Re: interface ideas for non-blocking mode
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 'readable' doesn't mean that the appropriate API function call won't block. So it doesn't have to be the filehandle that is connected across the network. It could be a pipe that you write to when stuff is ready. This would be compatible with either local or remote systems. Matt.
Re: interface ideas for non-blocking mode
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 event loop in your DBD then you BLOCK my event loop, which I cannot allow to happen. I don't believe that perl threads are stable/fast enough to fix this problem in a very large scale program. The API *has* to be something that can integrate with other event loops. My suggestion for the only thing scalable enough for this is a file descriptor which can be notified of readiness. Matt.
dbd_db_last_insert_id in 1.42
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.
Re: dbd_db_last_insert_id in 1.42
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 Jack's broken heart.
Re: DBI 2.0 interface change request
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 modular if you have separate functions, compared to a big honking dispatch table. It's minor quibbles though. Matt.
Re: DBI 2.0 interface change request
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.
Re: DBI version 2 - DBD-specific date parsing and formatting using DateTime
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 and formatting. My most recent DBI wrapper uses DateTime as the interchange format for dates. Like the transaction flag, this should be part of DBI. I've been using DateTime in production now for a year. While I think it's a great module for certain tasks, the biggest downfall is its size. It's ENORMOUS. Even compared to the DBI (last time I checked anyway). I'd be against mandating it, but would be happy with a flexible system whereby you could have an accessor mapping function, so you could get back DateTime objects for dates, or Time::Piece objects, or whatever alternative you can come up with (and apply the same logic to other data types). Matt. smime.p7s Description: S/MIME cryptographic signature
Re: Inline::C to write a DBD ?
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 performance/functionality. Inline::C looked like an attractive alternative (esp w/ Inline::Struct) to all the XS madness. This would allow the driver to exploit Perl's strenghts for parsing SQL, mapping things w/ hashes, etc, but use the vendor lib for the low level data movement, as opposed to writing a complete DBD in C/XS. Writing a DBD driver is almost all pure C and/or perl. There's very little XS. I don't think Inline::C would actually buy you anything because you have to know the perl internals API regardless of whether you use XS or Inline. Just skip the bootstrap call if you can't do XS. Or hack something into the Makefile.PL to edit the source code. Matt.
Re: mod_perl + Apache 1.3.28
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::DBI. Your code is not doing anything that it doesn't do, and is actually doing less to ensure safety when something crashes. Apache::DBI would issue a rollback if some code crashed part-way through a request. Unfortunately Apache::DBI is an ugly action at a distance hack :-) (And I'm on David's side - I never use it) Matt.
Re: mod_perl + Apache 1.3.28
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 could also be an attempt to reconcile Apache::DBI with
DBI-connect_cached. AFAIK, the only features Apache::DBI has over
connect_cached are the rollback cleanup handler and the transparency
part, which we don't like. Apache::DBI::Factory could just call
connect_cached and add the cleanup part.
Yeah basically that sort of thing, but also allow it to be used outside
mod_perl by making sure you wrap all the cleanup stuff in if
($ENV{MOD_PERL}) {} and do the cleanup in END{} otherwise. That's the
main reason I roll my own - because I use it extensively outside of
mod_perl (though like David, I'm also not doing cleanup *blush*).
Matt.
Re: Integrating date and time parsing and formatting
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. Like I said: On 1/20/03 11:34 AM, John Siracusa wrote: It would be nice if we had a canonical date/time representation. That's part of what the new DateTime modules being discussed on the [EMAIL PROTECTED] mailing list hope to deliver. I don't think we'll have a standardized interchange format for dates until/unless the new DateTime project matures. But such a thing is not required for database-independent code, provided you're not trying to move data from one database to another. All that's required by my proposal is that each DBD's formatter be able to read whatever is returned from its own parser: Does this cover DBD's (like mine) that don't support *any* data types? -- !-- Matt -- :-get a SMart net/:- Spam trap - do not mail: [EMAIL PROTECTED]
Re: DBI on a pocketPC - preliminary success
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 processor). The port also works on most other pocketPC and winCE device (e.g. Ipaq, Jornada, Casio, Dell Axim, etc.). Total storage requirement for perl, perlIDE, and all the required modules is about 3mb so it should run on a fairly minimal device, even one with no storage card and a low amount of ROM. I'll be doing more testing with other DBDs and eventually with Shell and Proxy. If anyone else is working on this, let me know. It'd be cool to see if DBD::SQLite worked there - then you'd have a fully transaction aware database on a handheld! Matt.
Re: Food for thought
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 Oracle. I'm attaching the beginnings of a module I've baptized DBD_create.pm which should eventually catch all these differences for our databases, so I can use Sounds like it might be worth you looking into either Alzabo (which hides all the details) or DBIx::AnyDBD (which shows all the details, but hides wierd which database am I? hacks). I don't think Alzabo supports your databases yet, but DBIx::AnyDBD does. -- !-- Matt -- :-Get a smart net/:-
Re: CPAN indexer (was Re: DBD::Pg CVS version.)
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 that everyone will have CPAN::MakeMaker in thier dist on search. I copied POE when I added ExtUtils::AutoInstall and put in in install/ to some of my modules. I think that's as good a place as any. Alternatively you could use a dot-dir. -- !-- Matt -- :-Get a smart net/:-
Re: [RFC] Date/Time standard for input/output
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::Piece object as
input and output.
On Sunday, August 4, 2002, at 03:22 PM, Daniel Ritz wrote:
hi
[please CC as i'm not on the list]
DBI has a real problem: input/output of date/time/timestamp values.
each driver handles it different.
most of the drivers returns string, but all in a different format. this
is where DBI should set a standard.
in DBD-InterBase we now have a very flexible interface. for input a
string is directly passed to the interbase
parser. for output we use strftime() to format the date/time/timestamp
string. when preparing a query one can
specify the output format with the attributes ib_dateformat,
ib_timeformat, ib_timestampformat. and if one
specifies 'TM' for the format string then DBD returns a refrerence to
an array with the same fields as perl's
localtime() function does (it is all the struct tm members). for input
it's the same. if a reference to an array
is detected that has enough element it is used to fill a struct tm.
now i'd like to see something similar to that in other DBDs. DBI should
set a standard here to allow one
to easly change the underlying database w/o changing to much in
scripts. DBI means Database independent
interface but it is not for date/time values.
may be there should be an attribute to dbh or an attribute for prepare
or whatever. arrayref for all DBD
would be very nice. it doesn't need to be like localtime(), something
like
(year, month, day, hour, minute, second, fraction)
would also do.
regards
-daniel
Re: Thoughts on DBD::Pg statement parser
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 across all grammars (START_COMMENT/END_COMMENT, NUMERIC_PLACEHOLDER, etc). If any (pre)parser at all, why not use perl, so we all understand. If it gets too complicated for straight perl, use Parse::RecDecsent Because parsing is easier in C ;-) -- !-- Matt -- :-Get a smart net/:-
Re: where should database pinging be automatic within the DBI(x::AnyDBD)?API?
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 calls to your database application handle will automatically do a $dbh-ping for you I tend to ping on connect, but obviously only when I've got persistent connections, and connect is just a no-op When will DBIx::AnyDBD take an initialized $dbh instead of a set of connection parameters? Should I fill out a request at rtcpanorg? Yes please -- !-- Matt -- :-Get a smart net/:-
Re: Should DBI/DBD support empty strings as an alternative to undeffor NULL?
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 as not to get warnings with 'perl -w'. Amen. The problem is compounded in drivers like DBD::CSV which can't consistently distinguish between empty strings and NULLs. So don't use CSV. Dump to XML with XML::Generator::DBI :-) My reluctance is mainly due to the many simple alternatives available. But I could probably be persuaded if enough driver authors gang up on me :) Gang, Gang. I'd rather not see it, personally. But then I'm new at this ;-) -- !-- Matt -- :-Get a smart net/:-
Re: DBD::SQLite
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) 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.tar.gz Well, it occurs Segmentation fault with 2 placeholders. A placeholder not occurs error but it makes warnings. Fixed. Just s/0.03/0.04/; -- Matt. :-Get a smart net/:-
Re: DBD::SQLite
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/download/DBD-SQLite-0.03.tar.gz Well, it occurs Segmentation fault with 2 placeholders. A placeholder not occurs error but it makes warnings. Fixed. Just s/0.03/0.04/; Great! It works fine. Thank you for your fast fix. And I've heard that it also works on Windows. #Sorry I just heard. I might be nagging ... 1) Active property with INSERT statement When I execute an INSERT statement, statement handle seems to be Active. I feel strange about this. Yes, I wasn't sure how to fix it. I'll look into it a bit further though. 2) test.pl test.pl ends up this line: Issuing rollback() for database handle being DESTROY'd without explicit disconnect(). To avoid this line, add $dbh-disconnect; at the end of test.pl. Other DBD drivers don't seem to report this, and I have no idea why not. If anyone knows why I'd love to know. -- !-- Matt -- :-Get a smart net/:-
