On Jul 19, 2015, at 7:41 AM, Tim Bunce wrote:
> Internally the DBI has a DBIc_ROW_COUNT(sth) macro that has an IV type.
> That's a signed int that would be 64 bits on most modern systems.
> On many of those systems the plain int type might be 32 bits.
>
> I've just pushed an experimental change
On Jul 16, 2015, at 6:40 AM, Tim Bunce wrote:
> Well, this contains lots more light! ...
>
>>> -> dbd_st_execute for 03fdf4e0
parse_params statement
>>>SELECT c.change_id ...
>
>>> Binding parameters: SELECT c.change_id
>
>>>--> do_error
>>> Out of sort memory, consider i
On Jul 14, 2015, at 3:24 AM, Tim Bunce wrote:
> I can't see anything obvious from this trace. Come back with a level 4
> trace and hopefully that'll shed sufficient light.
Here we go.
> $ DBI_TRACE=4 sqitch status
> DBI 1.630-ithread default trace level set to 0x0/4 (pid 10670 pi 2603010)
DBIers,
Got a complaint about a “fetch() without execute()” error. Asked for a trace,
got this. Looks like it’s coming from selectrow_hashref()? That shouldn’t
happen, right?
> $ DBI_TRACE=1 sqitch status
> DBI 1.630-ithread default trace level set to 0x0/1 (pid 3381 pi ed2010)
> at DBI.pm
On Nov 26, 2013, at 12:43 PM, Tim Bunce wrote:
> ODBC complicates that further.
Indeed. I want to avoid the protocol.
I've now written up my proposal as a blog post:
http://theory.so/rfc/2013/11/26/toward-a-database-uri-standard/
Thanks,
David
On Nov 26, 2013, at 11:49 AM, Gisle Aas wrote:
> There is also precedence for using "+" in scheme names. Something like
> "db+postgresql:" then. It's still cluttered, and not really compatible with
> what other have used. Or "x-postgres:" while it's still experimental.
> Naming stuff is ha
On Nov 26, 2013, at 11:26 AM, Gisle Aas wrote:
> I do find the "db:" prefix ugly. If you want users to see these strings I
> would think they find this prefix to be clutter too.
Yeah. But I would thin, that if it *was* a standard, there would be just one
scheme defined. That’s a guess, though
On Nov 26, 2013, at 10:53 AM, David E. Wheeler wrote:
> Well, I can see I have a bug or two to work out. That should be:
>
>$ perl -MURI -Ilib -E 'say
> URI->new("db:pg://me:sec...@example.com/foo.db")->dbi_dsn'
>dbi:Pg:host=example.com;db
On Nov 26, 2013, at 10:02 AM, David E. Wheeler wrote:
>$ perl-MURI -E 'say
> URI->new("db:pg://me:sec...@example.com/foo.db")->dbi_dsn'
>dbi:Pg:dbname=me:secret.com/foo.db
Well, I can see I have a bug or two to work out. That should be:
$ perl -
On Nov 26, 2013, at 9:32 AM, Gisle Aas wrote:
> To me the value of database urls would be compatibility with other
> implementations of this obvious idea. Some examples I found by quick
> googling:
>
> http://docs.sqlalchemy.org/en/rel_0_9/core/engines.html#database-urls
> http://docs.stack
On Nov 26, 2013, at 12:42 AM, Tim Bunce wrote:
> Why not define a direct translation from a URL to a DBI DSN?
> A translation that doesn't require knowledge of any driver-specifics.
Because I want to the onus of connecting to the database to be on the
developer, not the end-user. I personally d
On Nov 25, 2013, at 11:21 PM, H.Merijn Brand wrote:
> As I always use 2. when writing scripts, mostly because I use quite a
> few useful attributes in the 4th argument already, it is the most
> logical place: easy to maintain, easy to read and easy to extend.
Also very much specific to the DBI a
On Nov 25, 2013, at 11:02 PM, Jens Rehsack wrote:
>>
>> db:csv?f_dir=data&f_dir_search=foo&f_dir_search=bar&f_ext=.csv/r&f_lock=2&f_encoding=utf8&csv_eol=%0D%0A&csv_sep_char=,&csv_quote_char=%22&csv_escape_char=%22&csv+class=Text::CSV_XS&csv_null=1&RaiseError=1&PrintError=1&FetchHashKeyName=NA
On Nov 25, 2013, at 11:08 AM, Jens Rehsack wrote:
> Let’s go - shoot:
>
># specify most possible flags via driver flags
>$dbh = DBI->connect ("dbi:CSV:", undef, undef, {
>f_schema => undef,
>f_dir=> "data",
>f_dir_search => [],
>f_e
On Nov 25, 2013, at 3:50 AM, Jens Rehsack wrote:
>DBI->connect($dsn, $user, $passwd, \%attr)
>
> 4th argument is wasted in your current proposal.
Er, well, I failed to provide a complete set of examples. Here’s one from the
PostgreSQL docs:
postgresql://other@localhost/otherdb?connect_t
On Nov 22, 2013, at 8:48 PM, Darren Duncan wrote:
>> postgresql://user@localhost:5433/dbname
>> sqlite:///path/to/foo.db
>
> By "database name" do you mean "DBMS name"? Because I'd say the "database
> name" is what's on the right-hand side of the //, not what's on the left.
Yes, corre
DBI Folks & Gisle,
I want to add support for specifying database connections as URIs to Sqitch, my
DB change management system. I started working on it today, following the
examples of JDBC and PostgreSQL. Before I release, though, I’d like a bit of
feedback on a couple of things.
First, I'm u
On Nov 15, 2013, at 4:13 PM, Tim Bunce wrote:
> Make DBI::_handles return only the outer handle in scalar context
Tim++
David
On Nov 15, 2013, at 10:24 AM, Tim Bunce wrote:
> When the method call (which fired the callback) returns, the error
> recorded on the handle will trigger RaiseError etc.
Only on 1.630 and higher.
>> I *always* use RaiseError => 1 (or HandleError). Never ever check return
>> values.
>
> Ah, yo
On Nov 15, 2013, at 3:12 AM, Tim Bunce wrote:
> You'd need to write the callback code in the way you'd naturally write
> it when not using RaiseError. Which typically means something like:
>
>$dbh->do('SET search_path = ?', undef, 'foo')
>or return;
That will prevent any further cod
On Nov 14, 2013, at 9:17 AM, David E. Wheeler wrote:
> The error about "foo" not existing is gone, overridden by the second error
> about "bar" missing. This can lead to hard-to-find bugs. What if the second
> query depended on a condition set up by the firs
On Nov 14, 2013, at 7:57 AM, David E. Wheeler wrote:
> Yep, I am using 1.628.
>
> I'm wondering, though, if callbacks should not be considered internal calls,
> and the "outer" handle passed to them?
So the output with 6.30 is:
connected
done connectiong
On Nov 14, 2013, at 3:47 AM, Tim Bunce wrote:
> So I'll take a guess that you're not using DBI 1.630. (And hope I'm right.)
Yep, I am using 1.628.
I'm wondering, though, if callbacks should not be considered internal calls,
and the "outer" handle passed to them?
D
DBIers,
Given this script:
use v5.18;
use warnings;
use utf8;
use DBI;
my $dbh = DBI->connect('dbi:SQLite:', '', '', {
PrintError => 0,
RaiseError => 1,
AutoCommit => 1,
Callbacks => {
connected => sub {
say
On Nov 9, 2012, at 4:13 AM, John Scoles wrote:
> Well I made that ping patch for DBIx::Connector a few months ago on one of my
> production boxes with no impact but then again I am not doing anything fancy
> (no rac raid etc).
>
> If it is critical to DBDx::Connector to ensure a query can be r
On Nov 5, 2012, at 7:59 AM, Martin J. Evans wrote:
> Just to reiterate what I eventually said. I don't want ping changed in
> DBD::Oracle.
>
> All I was saying is you should only read anything useful into ping returning
> false and not true unless your only purpose is like Oracle's OCIPing whi
On Nov 5, 2012, at 8:57 AM, Greg Sabino Mullane wrote:
> Ah, so Oracle still requires an actual table? Thought they might
> have joined the rest of us by now in allowing things like
> 'SELECT 2+2;' :)
No, it always requires a FROM clause, which is typically `FROM dual` for stuff
like this.
B
On Nov 5, 2012, at 5:52 AM, John Scoles wrote:
>> Does it automatically reconnect? That certainly seems like the wrong thing
>> to do, especially in light of the docs for connect_cached.
>
> got that from the MySql doc it can be set up to reconnect if ping fails
>
> http://dev.mysql.com/doc/con
On Nov 2, 2012, at 4:46 AM, John Scoles wrote:
> David if you have a repeatable test or set of conditions or recipe of how you
> get into this state where DBD::Oracle pings but cannot run queries my buddies
> over at Oracle would love to get it.
I don’t, I only know what Peter Rabbitson told m
Fellow DBIers,
When I wrote DBIx::Connector, I borrowed this code from DBIx::Class to “work
around an issue”:
sub ping {
my ($self, $dbh) = @_;
eval {
local $dbh->{RaiseError} = 1;
$dbh->do('select 1 from dual');
};
return $@ ? 0 : 1;
On Jan 29, 2012, at 11:06 AM, Martin J. Evans wrote:
> I'd be happy with that as I'm looking forward to asking people to use
> DBI_TRACE=DBD.
>
> I've had no problems with the lastest releases and subversion trunk.
I’d like to see a statement about Unicode support in the docs, and any
recommen
On Nov 8, 2011, at 5:16 AM, Tim Bunce wrote:
> 1. Focus initially on categorising the capabilities of the databases.
>Specifically separating those that understand character encodings
>at one or more of column, table, schema, database level.
>Answer the questions:
>what "Unicod
On Nov 4, 2011, at 10:33 AM, Martin J. Evans wrote:
>> Did you ever get any data from DBD::SQLite folks?
>
> Yes. I found a bug in the process and it was fixed but I have a working
> SQLite example.
Oh, great.
> I'm only really missing DB2 but I have contacts for that on #dbix-class who
> I'v
On Nov 4, 2011, at 1:39 AM, Martin J. Evans wrote:
> Sorry David, I've been snowed under. I will try very hard to publish the
> research I found this weekend.
Awesome, thanks.
Did you ever get any data from DBD::SQLite folks?
> I didn't think I was going to make LPW but it seems I will now - a
On Oct 7, 2011, at 5:06 PM, David E. Wheeler wrote:
>> Perhaps we could carve out some time at LPW to sit together and try to
>> progress this.
>
> That would be awesome you guys!
So gents, do you plan to do this a bit? Martin, do you have the data you wanted
to collec
On Oct 13, 2011, at 6:03 AM, Greg Sabino Mullane wrote:
>> I think what I haven't said is that we should just use the same
>> names that Perl I/O uses. Er, well, for the :raw and :utf8
>> varieties I was, anyway. Perhaps we should adopt it wholesale,
>> so you'd use ":encoding(UTF-8)" instead o
On Oct 7, 2011, at 1:47 AM, Tim Bunce wrote:
> Perhaps we could carve out some time at LPW to sit together and try to
> progress this.
That would be awesome you guys!
D
On Oct 6, 2011, at 8:56 AM, Greg Sabino Mullane wrote:
>> I still prefer an encoding attribute that you can set as follows:
>
>> * undef: Default; same as your A.
>> * ':utf8': Same as your B:
>> * ':raw': Same as your C
>> * $encoding: Encode/decode to/from $encoding
>
> I like that. Although t
On Oct 2, 2011, at 8:49 PM, Greg Sabino Mullane wrote:
> DEW> I assume you also mean to say that data sent *to* the database
> DEW> has the flag turned off, yes?
>
> No: that is undefined. I don't see it as the DBDs job to massage data
> going into the database. Or at least, I cannot imagine a
On Sep 22, 2011, at 11:57 AM, Martin J. Evans wrote:
> ok except what the oracle client libraries accept does not match with Encode
> accepted strings so someone would have to come up with some sort of mapping
> between the two.
Yes. That's one of the consequences of providing a single interfac
On Sep 22, 2011, at 11:14 AM, Martin J. Evans wrote:
>> Right. There needs to be a way to tell the DBI what encoding the server
>> sends and expects to be sent. If it's not UTF-8, then the utf8_flag option
>> is kind of useless.
> I think this was my point above, i.e., why utf8? databases accept
On Sep 22, 2011, at 2:26 AM, Martin J. Evans wrote:
> There is more than one way to encode unicode - not everyone uses UTF-8;
> although some encodings don't support all of unicode.
Yeah, maybe should be utf8_flag instead.
> unicode is not encoded as UTF-8 in ODBC using the wide APIs.
>
> Usin
On Sep 21, 2011, at 7:53 PM, Brendan Byrd wrote:
> Okay, this is a big blue sky idea, but like all things open-source, it comes
> out of a need. I'm trying to merge together Excel (or CSV), Oracle, Fusion
> Tables, JSON, and SNMP for various data points and outputs. DBIC seems to
> work great fo
On Sep 21, 2011, at 1:52 PM, Greg Sabino Mullane wrote:
> Since nobody has actally defined a specific interface yet, let me throw out a
> straw man. It may look familiar :)
>
> ===
> * $h->{unicode_flag}
>
> If this is set on, data returned from the database is assumed to be UTF-8,
> and
> th
On Sep 10, 2011, at 3:08 AM, Martin J. Evans wrote:
> I'm not sure any change is required to DBI to support unicode. As far as I'm
> aware unicode already works with DBI if the DBDs do the right thing.
Right, but the problem is that, IME, none of them do "the right thing." As I
said, I've submi
On Sep 10, 2011, at 7:44 AM, Lyle wrote:
>> Right now 5.8 is the required minimum for DBI: should we consider bumping
>> this?
>
> I know a lot of servers in the wild are still running RHEL5 and it's
> variants, which are stuck on 5.8 in the standard package management. The new
> RHEL6 only ha
DBI peeps,
Sorry for the delayed response, I've been busy, looking to reply to this thread
now.
On Sep 9, 2011, at 8:06 PM, Greg Sabino Mullane wrote:
> One thing I see bandied about a lot is that Perl 5.14 is highly preferred.
> However, it's not clear exactly what the gains are and how bad 5
DBIers,
tl;dr: I think it's time to add proper Unicode support to the DBI. What do you
think it should look like?
Background
I've brought this up a time or two in the past, but a number of things have
happened lately to make me think that it was again time:
First, on the DBD::Pg list, we've b
On Oct 15, 2010, at 7:43 AM, H.Merijn Brand wrote:
> Good enough for now.
>
> And here's the patch. FWIW HP-UX 9 is so archaic that even /I/ do not
> have access to it anymore :)
>
> --8<---
> --- Makefile.PL.org 2010-04-07 22:52:55 +0200
> +++ Makefile.PL 2010-10-15 16:35:35 +0200
> @@ -211
Hey All,
Just installed 1.614 on three of my boxes. Looks good, and thanks for getting
it out! I did notice some warnings, though:
/usr/local/bin/perl /usr/local/lib/perl5/5.12.2/ExtUtils/xsubpp -typemap
/usr/local/lib/perl5/5.12.2/ExtUtils/typemap -typemap typemap DBI.xs > DBI.xsc
&& mv DBI
On Aug 31, 2010, at 1:08 PM, Tim Bunce wrote:
>>> It's back in. I may remove it for 1.615 or, more likely, may leave it out
>>> and
>>> individual developers deal with failure reports on perl 5.13.3+/5.14.
>>
>> You may “remove it…or, more likely, leave it out”? Huh?
>
> Ug. I meant "may restor
On Aug 31, 2010, at 2:52 AM, Tim Bunce wrote:
> It's back in. I may remove it for 1.615 or, more likely, may leave it out and
> individual developers deal with failure reports on perl 5.13.3+/5.14.
You may “remove it…or, more likely, leave it out”? Huh?
David
On Aug 10, 2010, at 3:09 PM, Jan Dubois wrote:
>> You have DBD::Oracle installed but no Oracle libraries?
>
> Yes, DBD::Oracle is included in ActivePerl, but it will of course
> only work if you install the client libraries as well.
Ah, I see.
David
On Aug 9, 2010, at 4:44 PM, Jan Dubois wrote:
> DBI->installed_versions will attempt to load *all* installed drivers.
You have DBD::Oracle installed but no Oracle libraries?
> But I see now that that test is only executed if you are running from a GIT
> or SVN checkout, so maybe it doesn't reall
On Aug 9, 2010, at 4:21 PM, Jan Dubois wrote:
> On Mon, 09 Aug 2010, David E. Wheeler wrote:
>> Tim, I think we're ready for another dev release, especially since I added
>> this test to the MANIFEST.
>
> Running tests on the latest ActivePerl shows 2 issues:
>
&g
On Aug 9, 2010, at 1:06 PM, Cosimo Streppone wrote:
>> Which nasty part?
>
> Ehm... scrap that :)
> Your patch with 'unless' reversed to 'if' works fine.
Thanks! Committed in r14317.
> Just for clarity, here's the full DESTROY() of 16destroy.t:
Yep, thanks.
>>> Will try and let you know.
>>
On Aug 9, 2010, at 9:51 AM, Jan Dubois wrote:
> I tried to look into this on the weekend, but ran out of time. I didn't
> get *any* segfaults though, neither from 16destroy.t nor from any of the
> samples below.
>
> I *did* only get 18 passing tests instead of 20 from 16destroy.t though.
Yes, I
On Aug 9, 2010, at 8:21 AM, Cosimo Streppone wrote:
>>package Foo;
>>sub DESTROY { exit; }
>>my $foo = bless {}, 'Foo';
>
> I couldn't try this yet, but, I don't think this
> would segfault.
>
> What I *guess* happens is that the 'exit' will cause
> the script to immediately exit, sk
On Aug 7, 2010, at 2:07 AM, Cosimo Streppone wrote:
> Hi DBI Win32 hackers,
>
> David E. Wheeler wrote:
>
>> I *think* it works the way it does because on Win32 it's not really a fork,
>> but a thread, and when you exit in a child thread, it exits the parent,
On Aug 6, 2010, at 5:42 PM, Jan Dubois wrote:
> Against my better judgment I couldn't prevent myself from peeking at
> the magical patch. I don't understand what it is doing, and I don't
> have any candies so sacrifice right now either.
>
> However, I'm always suspicious when I see code like thi
:
> In data 26 luglio 2010 alle ore 23:11:42, David E. Wheeler
> ha scritto:
>
>> [...] AutoInactiveDestroy.
>
>> We need to make sure that it doesn't die an ugly death
>> on systems without fork (and on Win32, where it's emulated).
>
> It seems to di
./t/16destroy.t line 44
> > STORE in DBD::Test::db ('DBI::db=HASH(0x1fe033c)' 'AutoCommit' 1) []
> < STORE= 1 at ./t/16destroy.t line 45
> > STORE in DBD::Test::db ('DBI::db=HASH(0x1fe033c)' 'AutoInactiveDestroy'
> 1) []
> &
On Jul 27, 2010, at 11:17 AM, John Scoles wrote:
> David E. Wheeler wrote:
>
> now we are getting
>
> t/zvp_16destroy.t(Wstat: 0 Tests: 18 Failed: 0)
> Parse errors: Bad plan. You planned 20 tests but ran 18.
> t/zvxgp_16destroy.t (Wstat: 0 Tests: 18 Failed: 0
On Jul 27, 2010, at 9:42 AM, Martin J. Evans wrote:
> Test has no driver CLONE() function so is unsafe threaded
> FAILED tests 19-20
>Failed 2/20 tests, 90.00% okay
> Failed Test Stat Wstat Total Fail List of Failed
>
On Jul 27, 2010, at 5:01 AM, John Scoles wrote:
> Which test is it exactly??
t/16destroy.t
> Ok here you go
>
> Windblows XP home SP3
>
> Visual C++ 2003
>
> here is the output from the nmake test
Thanks!
> t/01basics.t ... ok
> t/02dbidrv.t ... ok
> t/03handle.t ...
Fellow DBIers,
With a bit of help from me, Tim added a new feature to the DBI yesterday:
AutoInactiveDestroy. I wrote the test for it. The test, however, forks. We need
to make sure that it doesn't die an ugly death on systems without fork (and on
Win32, where it's emulated). If you have such a
On Jul 12, 2010, at 8:54 PM, Greg Sabino Mullane wrote:
> Doesn't that mean
> perl -MDBI -e 'print $DBI::VERSION'
> cannot indicate if you've got a dev version or a final release?
Yes, thank god. Because that's not where that information should be!
David
On Jul 9, 2010, at 5:52 AM, Tim Bunce wrote:
>> In principle, and as an end-user I would wholeheartedly agree, but the
>> way CPAN /and/ CPANTESTERS is currently set up, having _XX support is a
>> huge win.
>
> Agreed. But there's no need to use them *in modules*.
>
> The dev releases of DBI 1.
Underscores should be banned from version numbers. Full stop.
Best,
David
On Jul 8, 2010, at 3:46 PM, Darren Duncan wrote:
> Tim Bunce wrote:
>> My take on this, for the record, is to prefer two part numbers
>> in the form X.YYY where YYY never has a trailing zero.
>> Short, sweet, simple.
>> T
On Jul 8, 2010, at 3:29 PM, Tim Bunce wrote:
> My take on this, for the record, is to prefer two part numbers
> in the form X.YYY where YYY never has a trailing zero.
And thus may be X.Y or X.YY as well.
> Short, sweet, simple.
Yeah, I'm with you. All of my modules use this format. (Except Bric
On Jul 8, 2010, at 10:46 AM, Greg Sabino Mullane wrote:
>> But then that would screw things up for modules that unfortunately
>> changed their versioning algorithm. I would no longer be able to
>> require DBD::Pg 1.49, for example, even thought that's perfectly valid.
>
> Good point, but hopefu
On Jul 8, 2010, at 10:09 AM, Greg Sabino Mullane wrote:
> Perhaps it would be good if the mixing of two and three
> dot versions on the same check was treated as a severe
> error and caused an automatic FAIL report.
>
> I can't see a case where using both forms would ever be desired.
In my MET
On Jul 8, 2010, at 9:38 AM, Jens Rehsack wrote:
>> Looks like it should have been 2.6.0:
>>
>> 2.6.0 = 2.006001
>> 2.17.1 = 2.017001
>>
>> 2.006001< 2.017001
>>
>> Version number suck. And clearly, three-version numbers suck harder.
>
> I think, the best way out would be a hard consensus a
On Jul 8, 2010, at 8:31 AM, Tim Bunce wrote:
> FYI
>
> On Thu, Jul 8, 2010 at 3:48 AM, Nigel Horne wrote:
>> ! DBD::Pg2.6 2.17.1
>
> Let's review version number math:
>
> 2.6 = 2.60
> 2.17.1 = 2.017001
>
> 2.60 > 2.017001
Looks like it should have been 2.6.0:
2
On Apr 16, 2010, at 3:13 AM, Tim Bunce wrote:
>> In connect(), before $connect_meth, just as connected() is called in that
>> method after $connect_meth.
>>
>> $dbh->connected(@orig_args);
>> unless ($dbh = $drh->$connect_meth($dsn, $user, $pass, $attr)) {
>
> $dbh is undef before the
On Apr 15, 2010, at 5:17 AM, Tim Bunce wrote:
>$drh = DBI->install_driver($driver);
>$dbh = $drh->connect(...);
>
> Assuming we added a $dbh->connecting() method, how would it be called,
> and how would the callback have been enabled prior to calling it?
In connect(), before $connect_met
Fellow DBIers,
I was just discussing writing a callback on connect() to change authentication
(my correspondent wants to use realm files). But then I discovered to my
disappointment that there is no support for callbacks on connect(). This makes
sense, frankly, since the method is called before
On Mar 7, 2010, at 3:27 PM, Tim Bunce wrote:
> Uh, yeah, I just looked at the code. Sometimes I confuse myself.
> I think that's a bug. I always intended connected() to be used as an
> on-new-physical-connection-established hook.
>
> Any objections to making it so?
Not from me, but you might get
On Mar 7, 2010, at 5:43 AM, Tim Bunce wrote:
>> Looks good, thanks. Pity you removed the `$dbh->{private_myapp_sql_mode}`
>> bit, though, as that's required when using C, which
>> you almost certainly are doing if you need this hack.
>
> Are you sure it's required when using connected()? The conn
On Mar 6, 2010, at 3:45 PM, Tim Bunce wrote:
> I was tempted to leave "The cool thing is" but opted to drop it as it
> doesn't match the tone of the rest of the docs - although they are
> rather dry :)
Pity. Thought I was starting to change that. ;-P
> I've made assorted edits and added some ext
Howdy,
I've just committed r13835, which documents Callbacks. Yay! A few notes:
* Tim, you earlier said:
> I could arrange for Callbacks to only apply to methods called by the
> applicationi, and not to 'nested calls'. That's a fairly major change
> after this length of time but given the limite
On Oct 29, 2009, at 5:10 PM, David E. Wheeler wrote:
Well, yes. But if there were 'fetch*' and 'select*' keys that could
go to all of them at once, that would be cool, too.
I found another great use for callbacks: A callback on `connected()`
to set things up for a hand
On Oct 29, 2009, at 4:24 PM, Tim Bunce wrote:
I could arrange for Callbacks to only apply to methods called by the
applicationi, and not to 'nested calls'. That's a fairly major change
after this length of time but given the limited use Callbacks have
had,
and the lack of documentation, it's
On Oct 28, 2009, at 1:55 PM, Tim Bunce wrote:
If you're applying a callback to the "fetch" method and then your code
calls fetchrow_hashref, for example, how do you know if the driver's
fetchrow_hashref() method calls fetch() or fetchrow_arrayref()?
Franky, if I've applied a callback to `fetch
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
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.
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 { .
On Oct 27, 2009, at 1:38 PM, David Nicol wrote:
one would do
$sth->AddPostCallback( fetch => sub {
my ($sth, $row) = @_;
$row->[3] = DateTime::Format::Pg->parse_datetime($row->[3]);
});
+1
David
On Oct 26, 2009, at 1:59 PM, Tim Bunce wrote:
It output nothing. When I uncommented that second-to-last line, it
output
"Set in STH". So it seems that a callback added to the dbh for a
statement
method name does not end up getting passed on to the statement
handle. So I
guess the Callbacks
On Oct 25, 2009, at 10:24 PM, David E. Wheeler wrote:
It output nothing. When I uncommented that second-to-last line, it
output "Set in STH". So it seems that a callback added to the dbh
for a statement method name does not end up getting passed on to the
statement handle. So I
On Oct 24, 2009, at 2:50 PM, Tim Bunce wrote:
Callbacks are handled by the method dispatcher so all method names are
valid (so don't bother trying to list them in the docs :)
Plus the two special cases for connect_cached: 'connect_cached.new'
and
'connect_cached.reused'. (There's also '*' but
Tim,
I think it's high time we documented callbacks. I'm pretty sure the
DBIx::Class folks are going to want to make use of them shortly. I'd
be happy to contribute the docs. Is there a way to get a list of all
possible callback keys?
Thanks,
David
On Oct 14, 2009, at 11:39 PM, Darren Duncan wrote:
Also be sure to look at the section http://sqlite.org/foreignkeys.html#fk_enable
, because you have to enable a pragma on each connect to use the
foreign keys feature; it isn't yet on by default for backwards
compatibility purposes.
I sug
On Oct 7, 2009, at 3:24 PM, Tim Bunce wrote:
We'll go with savepoint($name), release_savepoint($name) and
rollback_to_savepoint($name) as method names.
Got a commit bit?
No.
David
On Oct 5, 2009, at 5:41 PM, Darren Duncan wrote:
But from what you've described in your blog to be the state of
affairs, I think that having a distinct DBIx::Connector module is a
good idea, versus embedding that functionality in a larger DBI-using
module.
Yes, that's the idea.
I've neve
On Oct 5, 2009, at 12:23 PM, Darren Duncan wrote:
SQLite also has savepoints, since 3.6.8 around January.
See http://sqlite.org/lang_savepoint.html for details.
SQLite:
SAVEPOINT $name
RELEASE [SAVEPOINT] $name
ROLLBACK [TRANSACTION] TO [SAVEPOINT] $name
Adding that to DBIx::Class sh
Howdy Tim et al.,
I've just released [DBIx::Connector](http://search.cpan.org/perldoc?DBIx::Connector
) to the CPAN. It does connection caching and transaction management,
borrowing pages from `connect_cached()`, Apache::DBI, and DBIx::Class,
but usable in any of these environments. The tran
On Oct 5, 2009, at 5:01 AM, Tim Bunce wrote:
We already have the example of DBI transaction support; savepoints
are just
an extension of that.
Well, as you said earlier David, "Transactions <> Savepoints."
No, but they're closely related.
Commit and rollback are methods partly to support
On Sep 29, 2009, at 2:51 PM, Darren Duncan wrote:
Going the other way, in SQL, there is a single terse SQL statement
for starting/ending transactions, and doing the thing with
savepoints. So for aside from maybe some consistency with legacy
DBI features, why should DBI objects have begin/c
On Sep 29, 2009, at 2:25 PM, Darren Duncan wrote:
1. The basic idea is that we have nested transactions, and starting
a child is defining a subunit that needs to succeed or be a no-op as
a whole.
I agree in principal; DBIx::Class has this feature, and it's fairly
nice. I'm borrowing it f
1 - 100 of 111 matches
Mail list logo
