On May 2, 2008, at 15:24, Tim Bunce wrote:
You've not given me much to go on, but I'd guess it's related to the
timing of when perl invokes the DESTROY method (which has changed
between perl versions). In which case it may be mostly beyond the
control of the DBI.
A small self-contained example
On May 9, 2008, at 04:42, Tim Bunce wrote:
Only now I'm seeing that test fail on 5.6.2. Is it possible that
5.6.2
destroys the handle by the type the do() is called?
Seems likely.
Yes, I've released a new version where the test checks for $] 5.6.1
instead of 5.8.0.
Got removed in
Howdy dbi-devers,
More and more lately, I'm writing database functions in PL/pgSQL (in
PostgreSQL) or SQL (in MySQL and others) to do the heavy lifting of
interacting with database tables. I've been thinking that I'd really
love a DBI method to call these functions without having to do the
On Wed, 14 May 2008 10:05:22 -0700, Martin Evens wrote:
That is slightly more complicated than it looks. DBD::Oracle already
magics a sth into existence for reference cursors but some databases
can return more than one result-set from a procedure - e.g., SQL
Server and the SQLMoreResults
On Aug 7, 2008, at 09:29, Greg Sabino Mullane wrote:
For DBD::Pg, it prints:
$VAR1 = [
'Goldfish'
];
$VAR1 = [
'goldfish'
];
$VAR1 = undef;
$VAR1 = [
'goldfish'
];
$VAR1 = undef;
DBD::SQLite:
$VAR1 = [
'Goldfish'
];
$VAR1 = [
On Mar 26, 2009, at 10:30 PM, Darren Duncan wrote:
Hello,
So, out of my un-paid projects, my promise to take over release
management of DBD::SQLite (from the still incommunicado previous
owner) has now come to the front of my queue (now that Set::Relation
0.9.0 is out), so I'm now
On Mar 28, 2009, at 12:40 AM, Darren Duncan wrote:
I'm not a pushover. It's more that I wasn't strongly opinionated on
the matter in the first place and I was fishing; your response led
to me realizing that a simpler plan of action was better (and less
work for both me and others).
Tim et al.,
Anyone given any thought to an interface for savepoints? They're a
part of the SQL standard, and basically look like named
subtransactions. The SQL looks like this:
BEGIN;
INSERT INTO table1 VALUES (1);
SAVEPOINT my_savepoint;
INSERT INTO table1
On Sep 29, 2009, at 12:34 PM, David E. Wheeler wrote:
Compared to transactions, the statements look like this:
TRANSACTIONS | SAVEPOINTS
-
BEGIN;| SAVEPOINT :name;
COMMIT; | RELEASE :name;
ROLLBACK; | ROLLBACK TO :name;
Apologies, I
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
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
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
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
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
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
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 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
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 '*'
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 guess
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
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
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 limited
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 extra
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 Cconnect_cached(), which
you almost certainly are doing if you need this hack.
Are you sure it's required when using connected()?
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
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
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_meth, just
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 Jul 8, 2010, at 8:31 AM, Tim Bunce wrote:
FYI
On Thu, Jul 8, 2010 at 3:48 AM, Nigel Horne n...@bandsman.co.uk 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
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 and CPAN reindex.
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
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 hopefully
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
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.
Tim.
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
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
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
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 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)
Parse errors: Bad plan
($@: , $!: )
DESTROY in DBD::Test::db ('DBI::db=HASH(0x202058c)') []
FETCH in DBD::Test::db ('DBI::db=HASH(0x202058c)' 'Active') []
FETCH= 0 at ./t/16destroy.t line 79
On Jul 27, 2010, at 11:17 AM, John Scoles wrote:
David E. Wheeler wrote:
now we are getting
t
:
In data 26 luglio 2010 alle ore 23:11:42, David E. Wheeler
da...@kineticode.com 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 die an ugly death for me.
I'm
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 this:
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, too.
Correct?
Sounds reasonable
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, skipping the
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 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.
Thanks!
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:
1) t/01basics.t fails to load DBD
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 really
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 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 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 restore it or, more
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
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,19
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
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
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 has
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
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
the utf8
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 for a
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 and
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 interface
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 DBI
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 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 of UTF-8.
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 collect on this?
Thanks,
David
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 -
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've just
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 Unicode
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
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 Nov 2, 2012, at 4:46 AM, John Scoles byter...@hotmail.com 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
On Nov 5, 2012, at 5:52 AM, John Scoles byter...@hotmail.com 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
On Nov 5, 2012, at 8:57 AM, Greg Sabino Mullane g...@turnstep.com 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
On Nov 5, 2012, at 7:59 AM, Martin J. Evans martin.ev...@easysoft.com 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
On Nov 9, 2012, at 4:13 AM, John Scoles byter...@hotmail.com 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
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 14, 2013, at 3:47 AM, Tim Bunce tim.bu...@pobox.com 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
On Nov 14, 2013, at 9:17 AM, David E. Wheeler da...@justatheory.com 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 first, and the first
On Nov 15, 2013, at 3:12 AM, Tim Bunce tim.bu...@pobox.com 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
On Nov 15, 2013, at 10:24 AM, Tim Bunce tim.bu...@pobox.com 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
On Nov 15, 2013, at 4:13 PM, Tim Bunce tim.bu...@pobox.com wrote:
Make DBI::_handles return only the outer handle in scalar context
Tim++
David
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
On Nov 22, 2013, at 8:48 PM, Darren Duncan dar...@darrenduncan.net 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.
On Nov 25, 2013, at 3:50 AM, Jens Rehsack rehs...@gmail.com 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:
On Nov 25, 2013, at 11:08 AM, Jens Rehsack rehs...@gmail.com 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 = [],
On Nov 25, 2013, at 11:02 PM, Jens Rehsack rehs...@gmail.com wrote:
On Nov 25, 2013, at 11:21 PM, H.Merijn Brand h.m.br...@xs4all.nl 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
On Nov 26, 2013, at 12:42 AM, Tim Bunce tim.bu...@pobox.com 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
On Nov 26, 2013, at 10:02 AM, David E. Wheeler da...@justatheory.com 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 -MURI -Ilib -E 'say
On Nov 26, 2013, at 10:53 AM, David E. Wheeler da...@justatheory.com 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;dbname=foo.db
Oh silly me
On Nov 26, 2013, at 11:26 AM, Gisle Aas gi...@activestate.com 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.
On Nov 26, 2013, at 11:49 AM, Gisle Aas gi...@activestate.com 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
On Nov 26, 2013, at 12:43 PM, Tim Bunce tim.bu...@pobox.com 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 Jul 16, 2015, at 6:40 AM, Tim Bunce tim.bu...@pobox.com 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
On Jul 14, 2015, at 3:24 AM, Tim Bunce tim.bu...@pobox.com 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
On Jul 19, 2015, at 7:41 AM, Tim Bunce tim.bu...@pobox.com 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
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
97 matches
Mail list logo