in SQL::Statement. I'd
also like to thank the many people over the years who sent bug reports
and patches and jumped in to help when I needed it, especially Tim Bunce
and Dean Arnold.
Thanks for all your help w/ S::S (and your patience w/ me)
I've also been afflicted with too busy to keep up w
?
TIA,
Dean Arnold
Presicient Corp.
[EMAIL PROTECTED] wrote:
On Mar 23, 3:49 pm, [EMAIL PROTECTED] (Dean Arnold) wrote:
Anyone know where the spec might be hiding ?
Last clue I had was some MSDN CD circa 2000.
Hi, Dean --
The ODBC info is still on the Microsoft site, albeit at a new URL.
Try here for the ODBC Programmer's
Tim Bunce wrote:
On Sun, Mar 23, 2008 at 12:49:22PM -0700, Dean Arnold wrote:
I've finally have a reason to write an ODBC wrapper around
Perl/DBI (not DBD::ODBC, but the other way around).
Strange what some people have to do for a living! :)
Do you mean a Perl-level wrapper (ala Win32::ODBC
.
Anyone know where the spec might be hiding ?
Last clue I had was some MSDN CD circa 2000.
TIA,
Dean Arnold
Presicient Corp.
in ODBC's header files.
Gruesome details of ODBC's SQLFetchScroll are here:
http://msdn2.microsoft.com/en-us/library/ms714682(VS.85).aspx
Dean Arnold
Presicient Corp.
with DBIx::Chart...)
OTOH, I may be having one of my less coherent moments...
Dean Arnold
Presicient Corp.
, altho its pretty cheap.
I'll see what I can morph from DBD::Amazon.
Dean Arnold
Presicient Corp.
Dean Arnold wrote:
Tim Bunce wrote:
So, who's going to be first to mash up Amazon::SimpleDB::* and
perhaps DBI::SQL::Nano into a DBI driver for Amazon's new SimpleDB
service?
http://www.amazon.com/gp/browse.html?node=342335011
Tim.
Do you have driver prefix for it yet ? Maybe simpdb_
throw in a plug for SQL::Preproc...it may make
your solution even easier to use)
Dean Arnold
Presicient Corp.
Followup: I've added more links to the TOC (including
FAQ, Driver Writers Guide, and links to most DBDs).
It may a take a while to load, due to the Javascript,
but its more comprehensive now.
For the curious: The classdocs are rendered w/ Pod::Classdoc
and the TOC is generated with
Tim Bunce wrote:
On Fri, Jul 20, 2007 at 07:26:28AM -0700, Dean Arnold wrote:
For those attending OSCON next week: I've talked Mssr. Bunce into
an informal BOF at the Oregon Brewers Festival
(http://www.oregonbrewfest.com/) across the
bridge sometime Thursday afternoon. Let me know
if you're
.
Dean Arnold
Presicient Corp.
CPAN using the NAME one-liner + DESCRIPTION section ?
2. Perhaps a DBIx section is needed ?
Dean Arnold
Presicient Corp.
Hicks, Robert wrote:
1. Any chance the driver descriptions can be initially populated
from CPAN using the NAME one-liner + DESCRIPTION section ?
Something like (or with NAME/DESC on a different line):
NAME: DBD::ADO - A DBI driver for Microsoft ADO (Active Data Objects)
DESCRIPTION: The
Jeff Zucker wrote:
Dean Arnold wrote:
Jeff Zucker wrote:
I am preparing to add the ability to attach metadata to DBDs that
subclass DBD::File.
Will there be a std. i/f to get at that info from within
SQL::Statement (and its subclasses) ?
Yes definitely. though probably to start you'll
mechanism to assure they get deleted when a table is dropped ?
Dean Arnold
Presicient Corp.
if there's an outstanding error), but that seems a
bit dangerous e.g., if $sth-DESTROY
is being called in response to a $dbh-DESTROY.
Dean Arnold
Presicient Corp.
);
If OTOH you're trying to validate $@ from C, then you
need to run under eval_pv/sv(). See
Evaluating a Perl statement from your C program
in perlembed (http://perldoc.perl.org/perlembed.html)
HTH,
Dean Arnold
Presicient Corp.
Tim Bunce wrote:
On Sun, Apr 29, 2007 at 09:53:29AM -0700, Dean Arnold wrote:
It doesn't appear in CPAN search, and the link from
DBI's POD returns not found. I found an old email
pointing to Stas Beckman's personal website, but
its no longer there either.
I've attached the latest copy I have
in, you're pretty much out of luck wrt support.
If you really need to create a standalone executable, I'd
suggest you look into PAR/pp, or any of the commercial
alternatives (my personal fav is perl2exe). While they're
not really compiled, they generally accomplish the same
net effect.
Dean Arnold
Tim Bunce wrote:
On Fri, Sep 22, 2006 at 05:40:53PM -0700, Dean Arnold wrote:
Just so I'm clear:
DBI's default execute_array()/execute_for_fetch() requires the use of
positional (i.e., '?') placeholders. Drivers which Brequire named
placeholders must implement their own execute_array
Tim Bunce wrote:
On Fri, Dec 15, 2006 at 03:26:46PM -0800, Dean Arnold wrote:
One item: I'm currently using a separate 19fhtrace.t test script;
should I merge it into 09trace.t ? Or leave it separate ?
(I'll vote for separate, since its easier to test the feature
standalone that way)
I agree
Tim Bunce wrote:
sv_2io never returns false, it croaks. But since you're only calling it
if SvROK is true, and the croak error is meaningful (Bad filehandle ...)
I think that's fine. Also, IoOFP(io) might be false in some odd cases.
So I'd suggest a slight tweak:
if (SvROK(file)) {
the HandleError invokation code could be copied
to provide the ability.
Has this been discussed before, or have I overlooked something that already
exists ? It seems like a capability that would be useful.
Dean Arnold
Presicient Corp.
H.Merijn Brand wrote:
On Wed, 13 Dec 2006 11:31:00 -0800, Dean Arnold [EMAIL PROTECTED]
wrote:
Has there been any thought to extending the target for
trace() beyond simple filenames ? I'm looking for a means
to supply either a coderef, or maybe an object implementing
a simple print/write
Tim Bunce wrote:
On Wed, Dec 13, 2006 at 11:31:00AM -0800, Dean Arnold wrote:
I realize the tracing is currently buried in XS code, but
it appears the HandleError invokation code could be copied
to provide the ability.
Only for errors, not for general tracing.
Sorry, I meant in a general
After a bit more research, I think I've figured out
how to get the PerlIO object from an SV:
IO *io;
if (!file) /* no arg == no change */
return 0;
/* XXX need to support file being a filehandle object */
if (SvROK(file)) {
/* DAA must be a filehandle...we
of exotic JOIN ?):
my $dbh = DBIx::PDL-connect($dsn, $user, $passwd);
my $results = $dbh-selectall_arrayref(
'SELECT * from
(SELECT * from TABLE1) a X
(SELECT * FROM TABLE2) b');
(Yes, my claims to sanity are often disputed).
Dean Arnold
Presicient Corp.
side. Or maybe Net::MySQLServer
to better disambiguate.
OTOH, there's an equivalent module for Sybase/TDS called Sybase::TdsServer,
and there's at least one MySQL toplevel module, so MySQL::ServerSide might be
reasonable as well.
Dean Arnold
Presicient Corp.
Tim Bunce wrote:
Also, FYI: on AS 5.8.6, WinXP:
t\40profile..ok 24/45
# Failed test in t\40profile.t at line 240.
# Structures begin differing at:
t\40profile..NOK 32# $got-{t\40profile.t} = Does not
exist
# $expected-{t\40profile.t} =
Dean Arnold wrote:
Basically, my driver was causing DBI to silently die on return from
the dr::connect() routine, even tho the connection had been
completely successfully setup in the driver. DBI-trace(15)
didn't show anything, other than DBI::END was called immediately
on return from $drh
While testing my execute_array() implementation, I've added
something that might be generally useful: a progress-report
callback. I realize that ArrayTupleFetch might be adapted
to provide the concept with a bit more coding in the app, but
if all the app is doing is either dumping a file to the
Tim Bunce wrote:
On Tue, Sep 26, 2006 at 11:02:00AM -0700, Dean Arnold wrote:
My driver specific version is a stmt handle attribute that
supplies an arrayref of [ $tupleincr, $callback ], where
$tupleincr is the minimum number of tuples between invoking $callback,
and $callback is just s CODE
Tim Bunce wrote:
On Tue, Sep 19, 2006 at 01:41:22PM -0700, Dean Arnold wrote:
I stumbled on an oddity in execute_array() I'm hoping can
be clarified (it maybe a bug, or just an undoc'd requirement
of driver authors)
The following bit of code appears to require that the hash returned
attribute ? Or maybe the requirement is that drivers w/ named
placeholders have to implement their own execute_array() ?
Dean Arnold
Presicient Corp.
Tim Bunce wrote:
Which brings me back to the notion of non-blocking requests. Assuming
many/most client libs do support an async capability, and a OOB
cancel, then it should be possible to standardize the behavior
externally.
Attempting to standardize, let alone implement, non-blocking
(I've added dbi-dev as this seems relevant)
Tim Bunce wrote:
On Sat, Sep 16, 2006 at 08:31:54PM -0400, Sam Tregar wrote:
On Sat, 16 Sep 2006, Dean Arnold wrote:
I think your best bet might be to work with the DBD::mysql maintainers
to implement some driver-specific nonblocking versions
Tim Bunce wrote:
Probably no good reason, or at least none that I can remember.
Patches welcome! Send me your auth.perl.org username and I'll give you
commit rights...
I don't have a patch, but here's what appears to be
going on:
DBI::_new_sth() calls DBI::_new_handle(),
which creates both
This has been a puzzler for me for some time, so hopefully
someone can edify me.
I have a pure Perl driver on which I'm doing some serious
refactoring (removing 6 years of accumulated cruft),
and added a simple function to build $sth's from an input
argument hash. Since most of the arguments are
probably something very
simple and obvious, but its got me stumped...)
Dean Arnold
Presicient Corp.
Tim Bunce wrote:
The default execute_array method calls execute_for_fetch. So drivers
only have to implement execute_for_fetch - and execute_for_fetch is
designed to allow drivers to decide batch sizes for themselves.
Please excuse my ignorance, I've had severe cognitive turbulence
wrt
web service.
Or you can just start hacking a lot of C code...
HTH, and best of luck,
Dean Arnold
Presicient Corp.
do *not* need this module for typical DBI usage.
MSG
sleep 2;
}
Dean Arnold
Presicient Corp.
Dean Arnold wrote:
I've recently surfaced a bug in a pure Perl DBD that
ChildHandles solves quite nicely...except it appears
to require Scalar::Util, which is not a CORE module
(tho perhaps it should be). While DBI gracefully degrades
if Scalar::Util isn't found - and ActiveState appears
Please disregard. I've located the module in CORE
(just in a non-obvious location).
Sorry for the interruption.
Dean Arnold
Presicient Corp.
on Callbacks? Are they ready to go into a release?
Thanks,
David
Er, care to refresh our collective memories w/ the executive
overview of what callbacks is ? My DBI inbox doesn't surface
anything, and Google ain't much help either...I see a blurb
in the CPAN roadmap doc, but thats it.
Dean Arnold
interesting applications...
Dean Arnold
Presicient Corp.
seem the most thread-friendly
at this point.
I'd appreciate test reports for other drivers,
perls, or platforms. I'll CPAN it after its had
a week or 2 to ripen.
Regards,
Dean Arnold
Presicient Corp.
perl 5.8.7 on Core 4 and run DBI yet ?
Note that Core 4 uses gcc 4.01; are there any known issues
with that combo I should know about ?
Regards,
Dean Arnold
Presicient Corp.
::Teradata
Are there others ?
TIA,
Dean Arnold
Presicient Corp.
Tim Bunce wrote:
On Wed, Aug 03, 2005 at 05:29:28PM -0700, Dean Arnold wrote:
Since I've forgotten about this only a few dozen times now,
I'll offer this bit of text for future inclusion in the
DBI POD (where to put it, and the exact text, I'll leave
to the keepers):
BNote that DBI
::Threaded::common Thread::Queue::Queueable DBI::db);
(I've also tried @ISA = ...)
Is there something else I need to do ?
Dean Arnold
Presicient Corp.
Dean Arnold wrote:
(FYI: AS perl 5.8.3, DBI 1.48, WinXP)
Does DBI subclassing permit/play nice with multiple
inheritance ?
Nevermind. I forgot that the subclassing root starts
at DBI::dr w/ the connect(), not DBI...which creates
its own set of issues for me, but hopefully will let
DBI base
Dean Arnold wrote:
Dean Arnold wrote:
(FYI: AS perl 5.8.3, DBI 1.48, WinXP)
Does DBI subclassing permit/play nice with multiple
inheritance ?
Nevermind. I forgot that the subclassing root starts
at DBI::dr w/ the connect(), not DBI...which creates
its own set of issues for me
David Nicol wrote:
After reading http://www.presicient.com/dbixthrd
I don't like all the explicit waiting, although I suppose it fits the explicit
nature of DBI better than something more abstract. It would be
possible to create a wrapper around DBIx::Threaded that would provide
Tim Bunce wrote:
On Tue, Jul 26, 2005 at 01:20:44PM -0700, Dean Arnold wrote:
Dean, check the discussion on take_imp_data and DBI::Pool[1] in this
list's archives.
[1] http://stason.org/tmp/DBI-Pool-0.02.tar.gz
You can't really use Storable to snatch the underlaying datastructs from
Tim Bunce wrote:
On Wed, Jul 27, 2005 at 10:21:10AM -0700, Dean Arnold wrote:
Will it work for
pure-Perl DBDs (seems like there'd be lots of driver-specific
context copying required...) ?
It can be made to work for pure-Perl DBDs.
Let's start with the docs for take_imp_data() (added in DBI
Stas Bekman wrote:
Dean Arnold wrote:
I'd appreciate any reviews of my current
DBIx::Threaded design as outlined at
http://www.presicient.com/dbixthrd
I've already implemented most of it, and have begun
testing, but I'd like a bit more feedback before
I rollout RC1. If you see something thats
Tim Bunce wrote:
On Sat, Jul 23, 2005 at 10:13:05AM -0700, Dean Arnold wrote:
The more I think about this, the more I'm convinced
I should just POD a caveat that fetchall_XXX with bind_col()
isn't supported (much like binding multiple variables to a single
column). Why would anyone want to do
Dean Arnold wrote:
It also doesn't require any changes to apps, other than to use
use DBIx::Threaded;
$dbh = DBIx::Threaded-connect(...);
...and maybe observe some of the other limitations (most of
which appear to be very minor corner cases). I spose if an
app gets clever about ref $sth
Tim Bunce wrote:
On Sat, Jul 23, 2005 at 10:13:05AM -0700, Dean Arnold wrote:
The more I think about this, the more I'm convinced
I should just POD a caveat that fetchall_XXX with bind_col()
isn't supported (much like binding multiple variables to a single
column). Why would anyone want to do
, please let me know.
TIA,
Dean Arnold
Presicient Corp.
Tim Bunce wrote:
On Fri, Jul 22, 2005 at 01:18:07PM -0700, Dean Arnold wrote:
In the DBI 1.48 POD, it says...
Multiple variables can be bound to a single column, but there's rarely
any point.
Is that true ?
Yes.
Does that mean that I have to explicitly
$sth-bind_col($colnum, undef
that DBIx::Threaded
will make non-thread-friendly DBD's
not only friendly, but thread-safe.
TIA,
Dean Arnold
Presicient Corp.
Jonathan Leffler wrote:
I've dropped perl6-language off the addressee list - this is pretty much
internals of DBI or DBD::WhatNot and not Perl language per se.
On 7/12/05, Sam Vilain [EMAIL PROTECTED] wrote:
Dean Arnold wrote:
RE: LOBs and SQL Parse Trees: having recently implemented
LOB
, and demonstrably function against,
the DBD's selected in requirement (2) above.
Once you've implemented the subclass, you'll have empirical proof
of the feasibility, and, more importantly, you'll be able to port
the subclass to DBIv2, without any additional burden on DBI
developers.
Regards,
Dean Arnold
BTW: If you need a list of DBD's meeting said requirement, let me know,
I just pulled one down.
Sure, send it over.
[ ] DBD-ADO-2.94.tar.gz 31-Jan-2005 02:4041k GZIP compressed docume
[ ] DBD-ASAny-1.13.tar.gz 31-Oct-2003 15:0030k GZIP compressed docume
[ ]
David Nicol wrote:
On 7/2/05, Dean Arnold [EMAIL PROTECTED] wrote:
- Asynchronous queries (coroutines? threads?)
Threads. If you've ever done much Java/JDBC work, you'll
realize how much simpler a solution to async it is.
(Ignoring the rest of Java/JDBC's undesirable traits)
A couple
Sam Tregar wrote:
On Sat, 2 Jul 2005, Dean Arnold wrote:
Er, marketting in what way ?
I see the email as an attempt to attract new developers to the
project. Hence it is, in some respects, an attempt to market DBI v2
to developers.
My rant redacted.
Relax. I'm just suggesting
Tim wrote:
Could you send me a doc patch based on my emails in that thread?
Tim.
First draft derived mainly from the ParamValues pod
(see embedded [NOTES TO TIM]):
=item CParamTypes (hash ref, read-only)
Returns a reference to a hash containing the type information
currently bound to
Tim wrote:
[ NOTE TO TIM: Your note in the roadmap shows both the scalar and
hashref form of type info...in the interest of simplicity, I'd prefer
a single form (hashrefs); do you have a strong opinion one way
or the other ? ]
The goal is to keep bind_param cheap. But drivers can defer the cost
Tim Bunce wrote:
Okay. You send, I'll apply.
Thanks Dean!
Tim.
Here 'tis. (diff'd against DBI 1.48)
- Dean
--- DBI.pm Thu May 12 12:40:53 2005
+++ ../DBI-1.48/DBI.pm Mon Mar 14 07:45:38 2005
@@ -6055,44 +6055,6 @@
The CParamValues attribute was added in DBI 1.28.
-=item CParamTypes (hash
, or the PRECISION/SCALE for an INTEGER),
then that piece of info is omitted.
Thoughts ? Did I overlook an existing attribute or i/f ?
Regards,
Dean Arnold
Presicient Corp.
Tim wrote:
On Wed, May 11, 2005 at 09:36:26AM -0700, Dean Arnold wrote:
I may have missed this in the archives, but google
didn't shed any light, so here goes...
DBI currently defines a readonly ParamValues $sth attribute;
is there a need for an equivalent ParamTypes attribute ?
Yeap: http
;
archives of this maillist are difficult to search, and pretty
unstructured (Googled or otherwise); rt.cpan is for bug reports, and
I've never seen cpan.forum.
BTW: should dbi-users be included in this discussion ?
Dean Arnold
Presicient Corp.
to
bring me around to the original notion. If DBI
ever gets a full 2PC capability, such capability
may be desirable (or at least, the creation of
commit groups, as an earlier poster intimated.)
Dean Arnold
Presicient Corp.
cents,
Dean Arnold
Presicient Corp.
can't be shared between threads,
I wonder how Apache connection pools will behave in
such an environment (if at all) ?
Dean Arnold
Presicient Corp.
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...
for the burden of loosing compatibility.
There's no reason the old interface couldn't continue to exist.
OK, I'll bite
Hashrefs are
Understood. Sorry.
- Dean
caveat
while not strictly a DBI issue, I'm going to
kick this off here, since its pretty relevant
(ala SQL::Statement).
If I'm out of line, or should restrict this
to one or the other lists, please advise
/caveat
A couple years ago, someone posted an RFC and some
questions about building an
Matthew O. Persico wrote:
My 0.02USD is this implementation detail: you have to tell Filter::Simple not to
replace the embedded SQL but to comment it out and add the filtered code or else
debugging will be a royal PITA.
Yep. And presumably, sprinkle with #line pragmas so line numbers of
and timeframe aren't yet
well defined, and may require DBD authors to
fork anyway. (Well, maybe not require, since many DBD authors are
working gratis, so users will get only what the authors choose
to provide)
Discretely drags soapbox offstage
Dean Arnold
Presicient Corp.
DBD support for such facilities (which is why I kept
pounding the table for array binding), as perl makes a *great*
ECTL tool.
Regards,
Dean Arnold
Presicient Corp.
www.presicient.com
they can have precision...
Dean Arnold
Presicient Corp.
www.presicient.com
- Original Message -
From: Tim Bunce [EMAIL PROTECTED]
To: Dean Arnold [EMAIL PROTECTED]
Cc: Tim Bunce [EMAIL PROTECTED]; DBI developers [EMAIL PROTECTED]
Sent: Thursday, April 29, 2004 1:49 AM
Subject: Re: Any interest in a $sth-{TYPE_STRING} ?
On Wed, Apr 28, 2004 at 11:17:30PM -0700
for which
types have precision and scale, and where those items would be applied
eg, DECIMAL(precision, scale) vs.
INTERVAL HOUR(precision) TO SECOND(scale)
(Is that how other drivers use PRECISION and SCALE with INTERVAL types ?)
TIA,
Dean Arnold
Presicient Corp.
www.presicient.com
On Sat 24 Apr 2004 21:38, Dean Arnold [EMAIL PROTECTED] wrote:
I'm finding I frequently need to convert the DBI type metadata
from a result set into a string representation (either for display purposes,
or to generate additional queries).
Is there a need/desire to add a new $sth
(), if driver provides it, else just
a best guess)
Opinions ? Have I overlooked something like this thats already in the DBI ?
Dean Arnold
Presicient Corp.
www.presicient.com
,
Dean Arnold
Presicient Corp.
www.presicient.com
?
Maybe once I clear my own teetering pile of works, I'll take a
stab at a DBIx that implements that behavior. Shouldn't be
any later than 2007 or so...
Dean Arnold
Presicient Corp.
www.presicient.com
, it would be
useful to know if both drivers support threaded operation, and
native array binding, in order formulate an optimal execution
environment/strategy.
Probably on the bleeding edge again, but hopefully food for thought,
Dean Arnold
Presicient Corp.
www.presicient.com
ODBC)
Dean Arnold
Presicient Corp.
www.presicient.com
compile in my IDE, TeraForge).
In that case, I've provided a 'tdat_compatibility' attribute that
specifies a maximum compatibility level of the DBD version
that the app expects. This has the advantage that it can be
applied not only to this particular issue, but to other
behaviors as well.
HTH,
Dean
Just a followup:
ActiveState now has Perl 5.8.3 available, it appears
to eliminate the threading warning issue I reported earlier.
Dean Arnold
Presicient Corp.
www.presicient.com
to handle internally by tracking PID's ?
Dazed confused,
Dean Arnold
Presicient Corp.
www.presicient.com
Nevermind...my bad, I dropped a bit of code
during the latest updates.
Sorry,
Dean Arnold
Presicient Corp.
www.presicient.com
Test completed\n;
sub child_thread {
my ($queue) = @_;
$queue-dequeue();
my $dbh = DBI-connect('dbi:Sponge:', '', '', {
PrintError = 1,
RaiseError = 0,
AutoCommit = 1
}) || die DBI-errstr;
print Child: connected and exitting\n;
$dbh-disconnect;
}
Dean Arnold
Presicient Corp.
www.presicient.com
open connections.
Dean Arnold
Presicient Corp.
www.presicient.com
1 - 100 of 129 matches
Mail list logo
