Re: Time to Document Callbacks
On Tue, Oct 27, 2009 at 06:07:46PM -0700, David E. Wheeler wrote:
On Oct 27, 2009, at 3:24 PM, Tim Bunce wrote:
The simplest thing that could possibly work is probably:
$dbh-{Callbacks} = {
method_foo = sub { ... },
method_bar = sub { ... },
ChildCallbacks = {
method_foo = sub { ... },
method_bar = sub { ... },
}
}
so the code that creates a child handle can just check for
ChildCallbacks on the parent handle and set those as the Callbacks for
the new handle.
That looks nice. Are STHs the only things that are children?
DBHs are children of DRHs (but I try to avoid talking about DRHs).
Yes, I saw that in our
[exchange](http://markmail.org/message/m2lr3n74nluh52jn) in 2005. What
would it take to make this happen?
Let's get Callbacks and ChildCallbacks documented first.
Okay. Maybe it'll be done when I wake up in the morning? ;-P
Here's a deal: you write some tests for ChildCallbacks in
t/70callbacks.t and I'll implement them.
Oh, that kind of callback. I'd love to see attributes to prepare passed
on
to the sth. It makes perfect sense to me. I note that you thought in 2005
that it wouldn't happen before DBI2, but since that's probably another 5
years away at this rate…
[Tangental observation: NYTProf v3 is nearly done... :-]
Oh, nice. Does that mean you'll have more time for the DBI?
That's the hope.
ChildCallbacks seems like the way to go. Simple, effective, and easy to
implement.
Yeah, looks pretty nice. Would we also be able to pass them to prepare()?
No. Much as I'd like to change prepare() to take method attributes like
connect I'm nervous of making that change. I'd happily support someone
else doing the leg work though.
Well, and tie is pretty hackish IMHO.
The implementation (and performance) may not be great, but the concept
of tie (values vs containers) is good. Overloading would also work.
Either way it should be wrapped up in a nice interface.
Such as?
Dunno. Would need some exploration and thought.
Note that sth callbacks, for example, give you a relatively clean way to
set the UTF8 flag on fetched data.
It seemed like a good idea at the time but I recant that now.
It's workable only for someone who knows what driver and methods will be
used to fetch data from a given handle. So it's just about okay for
in-house use but I couldn't recommend it as a general solution.
I'm starting to fail to see the point of callbacks aside from connect().
:-(
I'm probably being over-cautious. Most drivers use fetch() or
fetchrow_arrayref() as the lowest-level calling method used by the other
fetch* ad select* methods. So applying the same callback to both would
work find in most cases.
It would need post-call callbacks. How they get called would depend on
what works most efficiently and reasonably elegantly. I'd guess that the
values being returned would be in @_ (as aliases) and $_ would contain
the handle.
Hrm. That'd be inconsistent with the way precallbacks work.
Yeah, well, it was just a guess off the top of my head :)
I'd need to think about it and look at what could would be involved and
what would be effcient.
Tim.
Re: DBD::Oracle, Support binding of integers so they are returned as IVs
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I cannot say why you changed DBD::Pg for JSON::XS but I can say why I want integers back from Oracle instead of strings when I ask for integers and the column is an integer. I don't think it is square pegs into round holes. Well you'll never get a Perl integer (IV) to match Oracle's integer: NUMBER(38). But sounds like y'all have found a good enough solution. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200910281253 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkrodzUACgkQvJuQZxSWSsjR7QCeKbkwnKKZK7zgC0laJ3sozeoh JccAnA8puFN+uX7ieOSzf924LJuj72qw =yYAY -END PGP SIGNATURE-
Re: Time to Document Callbacks
On Oct 28, 2009, at 2:59 AM, Tim Bunce wrote: That looks nice. Are STHs the only things that are children? DBHs are children of DRHs (but I try to avoid talking about DRHs). Yes, let's pretend they don't exist here. Here's a deal: you write some tests for ChildCallbacks in t/70callbacks.t and I'll implement them. Deal. Oh, nice. Does that mean you'll have more time for the DBI? That's the hope. W00t. Yeah, looks pretty nice. Would we also be able to pass them to prepare()? No. Much as I'd like to change prepare() to take method attributes like connect I'm nervous of making that change. I'd happily support someone else doing the leg work though. Out of my league. I'm starting to fail to see the point of callbacks aside from connect(). :-( I'm probably being over-cautious. Most drivers use fetch() or fetchrow_arrayref() as the lowest-level calling method used by the other fetch* ad select* methods. So applying the same callback to both would work find in most cases. If I'm applying a callback to the fetch method, I expect it to execute when I actually call the fetch method on the STH to which I applied it. Reasonable, no? Is there some reason that wouldn't happen? If so, I'd call it a bug in the driver, frankly. Hrm. That'd be inconsistent with the way precallbacks work. Yeah, well, it was just a guess off the top of my head :) I'd need to think about it and look at what could would be involved and what would be effcient. I was thinking it would get the same arguments as the precallback, with an additional one that's a reference to the return value(s). Best, David
Re: Time to Document Callbacks
On Oct 28, 2009, at 10:26 AM, David E. Wheeler wrote: Here's a deal: you write some tests for ChildCallbacks in t/70callbacks.t and I'll implement them. Deal. Done in r13445. Best, David
test DBD::SQLite 1.26_06 please
All, I am pleased to announce that DBD::SQLite (Self Contained RDBMS in a Perl DBI Driver) version 1.26_06 has been released on CPAN (by Adam Kennedy). http://search.cpan.org/~adamk/DBD-SQLite-1.26_06/ TESTING NEEDED! 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. This developer release includes both several changes which *might break your applications* if not accounted for, and it has a lot of code refactoring. This release should also fix the known problem with full-text search (FTS3) that was reported in the 1.26_05 release but had existed in many prior versions; the included test for that problem now passes. From the Changes file: *** CHANGES THAT MAY POSSIBLY BREAK YOUR OLD APPLICATIONS *** - Removed undocumented (and most probably unused) reset method from a statement handle (which was only accessible via func().) Simply use $sth-finish instead. (ISHIGAKI) - Now DBD::SQLite supports foreign key constraints by default. Long-ignored foreign keys (typically written for other DB engines) will start working. If you don't want this feature, issue a pragma to disable foreign keys. (ISHIGAKI) - Renamed unicode attribute to sqlite_unicode for integrity. Old unicode attribute is still accessible but will be deprecated in the near future. (ISHIGAKI) - You can see file/line info while tracing even if you compile with a non-gcc compiler. (ISHIGAKI) - Major code refactoring. (ISHIGAKI) - Pod reorganized, and some of the missing bits (including pragma) are added. (ISHIGAKI) The bundled SQLite version (3.6.19) is unchanged from last time. 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 is also welcome! If you feel that a bug you find is in SQLite itself rather than the Perl DBI driver for it, the main users email forum for SQLite in general is at: http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ... where you can report it as an appropriate list post (the SQLite issue tracking system is no longer updateable by the public; posting in the list can cause an update there by a registered SQLite developer). 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: DBD::Oracle, Support binding of integers so they are returned as IVs
On Wed, Oct 28, 2009 at 04:54:06PM -, Greg Sabino Mullane wrote: I cannot say why you changed DBD::Pg for JSON::XS but I can say why I want integers back from Oracle instead of strings when I ask for integers and the column is an integer. I don't think it is square pegs into round holes. Well you'll never get a Perl integer (IV) to match Oracle's integer: NUMBER(38). But sounds like y'all have found a good enough solution. We could always make bind_col(..., SQL_BIGINT) enable creation of Math::BigInt objects for values that are too large for IV. Tim.
